Fine-grained authorisation
Four gates. Every action.
One coarse role for everyone is how over-permissioning happens. Your platform team sets the guardrails once, and every action passes four gates, for a person or an AI assistant, powered by OpenFGA.
One action, four gates
The gap
What fine-grained authorisation actually means
Most platforms authorise at the org level. A handful of broad roles, and everyone lands in one of them. It’s quick to set up and impossible to govern. The person who can deploy to staging can usually destroy production too, because the role was drawn wide enough to cover every case. Cycloid draws the line per action and per resource, so a permission means one specific thing. That’s the difference between a role you can explain and a role you hope nobody tests.
Cycloid for your team
What four layers mean for each reader
Grant exactly what
the job needs
The problem
Broad roles you widen once and never tighten.
With Cycloid
Visibility, action, condition and approval set independently.
The outcome
A permission you can explain in one sentence.
See only what's yours,
act only where you should
The problem
Either locked out, or handed the keys to everything.
With Cycloid
Exactly the resources and actions your role and relationships allow.
The outcome
No ticket to see your own estate, no path to break someone else’s.
An access model that
survives an audit
The problem
“Who can do what” has no clean answer.
With Cycloid
Four named layers, one chain, the same for people and assistants.
The outcome
Least privilege you can actually demonstrate.
How it works
Set the guardrails others can use
01 · ReBAC, can I see it?
Visibility comes from ownership and team relationships in OpenFGA. A resource you have no relationship to isn’t in a list, a search or an API response.
02 · RBAC, what can I do?
Your role maps to a fixed set of actions per resource type. A Developer can’t call environment:destroy, whatever they own.
03 · ABAC, under what conditions?
Tenant rules narrow a granted action, say to non-production or business hours. ABAC can tighten a role and never widen one.
04 · Approval, who signs off?
If an approval rule matches, the action waits for the right people. Approval workflows covers it in full.
05 · Then it checks again
The chain runs again at execution. If a role was revoked while the request waited, the approved action fails and names the layer.
Authority can split across one resource. Ops runs it, security approves the risky changes, and whoever holds the DBA field approves schema changes, with no team ID hard-coded anywhere. Custom roles come after launch, and until then that routing covers the same ground. Keeping tenants apart is a different wall, with tenant checks and Postgres row-level security underneath all four layers. OpenFGA isn’t what separates tenants.
Set the guardrails others can use
The short version
The rules that never bend
4
layers on every action
2
checks: at submit, and again at run time
1
named action per operation. No blanket grants
0
ways a condition can widen access
Destroy the staging database.
I can see it, but this stops at the action layer. Your role has deploy on staging, not destroy, so I can’t run it either.
Check · environment:destroy
Denied · Layer 2 RBAC
Your role
Developer: deploy, not destroy
Result
Denied, same as it would be for you
Working with your assistant
One chain, whoever is asking
Does the assistant get its own permissions?
No. There’s no service account and no elevated assistant role. If you can’t deploy to production, neither can the assistant you’re talking to, in Cycloid’s own assistant or any compliant MCP host.
Your assistant runs the same chain you do. It sees what your relationships allow and does what your role permits, under the same conditions and behind the same approvals. There’s no fast lane and no second policy engine to keep in sync.
When a layer would stop you, it stops the assistant for the same reason. Anything you can’t see isn’t there for the assistant either, and it’s never listed as withheld.
Frequently asked questions
ReBAC decides what you can see, from relationships. RBAC decides what you can do, from your role. ABAC decides under what conditions, and only ever restricts. All three run before any approval.
Yes, through the same code path. Every tool call lands in the same service layer as the portal and the API. A tenant can narrow assistants further, to read-only say, but never loosen them. See how the assistant works.
OpenFGA, the open-source take on Google’s Zanzibar, answers the visibility and action layers. ABAC runs in the application as a restrict-only filter, so a failed condition removes an action and never adds one.
Yes. A directory group maps to teams with a role on each. People in a mapped group are in from their first login, and SCIM 2.0 applies changes as your IdP pushes them. Org modelling and SSO covers the rest.
See the whole chain on one action
Bring an action you suspect is over-permissioned. In twenty minutes we’ll walk it through all four layers and show you exactly where it would stop.