Fine-grained authorization (FGA).
Fine-grained authorization (FGA) is access control that decides permissions at the level of individual resources, actions, and relationships — "can user A edit document 42?" — rather than granting broad capabilities through coarse roles. It is typically implemented with ReBAC (relationship-based, the Google Zanzibar model) or ABAC (attribute-based), and often externalized to a dedicated authorization service. FGA matters most for multi-tenant SaaS, resource sharing, and AI agents that need delegated, per-resource access.
Key takeaways
- FGA decides access per resource, action, and relationship — not per coarse role.
- Usually implemented with ReBAC (the Zanzibar model) or ABAC, often via a dedicated authorization service (OpenFGA, SpiceDB, Cedar, OPA).
- Solves what RBAC can’t: per-document sharing, hierarchies, and multi-tenancy without role explosion.
- For AI agents, FGA expresses delegated, downscoped, per-resource access.
Why coarse roles aren’t enough
Role-based access control works until access stops being role-shaped. "Editors, but only their own team’s documents", "admins, except in the EU tenant", "this contractor, just this project" — each exception becomes a new role, and roles multiply faster than people (role explosion). Fine-grained authorization answers the per-resource question directly instead of inventing a role for every case.
How FGA is implemented
FGA is usually expressed as either relationships or attributes, and increasingly evaluated outside the application by a dedicated policy decision point:
- ReBAC — store relationships as tuples (object, relation, subject) and answer checks by traversing the graph. The Google Zanzibar model; implemented by OpenFGA and SpiceDB.
- ABAC — decide on attributes of the user, resource, and environment at request time (often via OPA/Rego or Cedar).
- Externalized authorization — a policy service (PDP) makes decisions so logic isn’t scattered across services; policy-as-data (tuples) or policy-as-code (Rego/Cedar).
FGA for AI agents
AI agents make FGA urgent. An agent acting for a user should be able to touch only the resources that user can — and only for the current task. That is a per-resource, delegated, downscoped decision: exactly what FGA expresses and coarse roles cannot. Pair FGA with zero standing privileges (so access is just-in-time) and enforce it at the tool-call layer, and a hijacked or mis-steered agent is contained to the specific resources its task authorized.
Common questions.
What is fine-grained authorization?+
Access control that decides permissions per individual resource, action, and relationship — "can this user perform this action on this object?" — rather than granting broad permissions through coarse roles. It is the umbrella practice; ReBAC and ABAC are the common implementation models.
What is the difference between FGA and RBAC?+
RBAC grants access through roles assigned to users — simple but coarse and prone to role explosion. FGA decides at the resource/relationship/attribute level, handling per-object sharing, hierarchies, and multi-tenancy that RBAC struggles with. Many systems use RBAC for broad roles and FGA for resource-level decisions.
What tools implement fine-grained authorization?+
Open-source and vendor options include OpenFGA and SpiceDB (ReBAC / Zanzibar-style), AWS Verified Permissions and Cedar, and OPA/Rego (policy-as-code). The right choice depends on whether your access is best modeled as relationships, attributes, or a mix.
The whole picture, in one place.
This explainer is part of our complete guide to IAM — authentication, authorization, governance, privileged access, the standards, and how to run a program.