Permissions, entitlements, and flags
Permissions, entitlements, and flags
Four different questions gate what you see and do on Furnace, and they are deliberately not the same mechanism:
| Layer | Question it answers | Who changes it |
|---|---|---|
| Permission | Are you allowed? | An administrator |
| Entitlement | Is it in your plan? | Your subscription |
| Feature flag | Is it rolled out? | Falcata engineering |
| Preference | Do you want it? | You |
Two consequences worth knowing as an API consumer:
- Denials are distinct. "Not authorized" (permission) and "not in your plan" (entitlement) are different errors with different remedies — the first is an access request, the second an upgrade.
- Everything resolves server-side. Clients never see targeting rules or rollout percentages; the API answers what this identity can do now. The same resolution applies to the human UI, REST, and MCP — there is no surface where a hidden button is still callable.
Permissions are strings checked per namespace, with ownership-scoped variants (a …:own permission covers only records you created). Your effective permissions are visible via the account API.