OpenFGA
OpenFGA is an open source fine-grained authorization system for modeling access as relationships between users, objects, and permissions, with direct relevance for AI agents that act across shared resources.
Definition
OpenFGA is an open source system for fine-grained access control. Its official site describes it as a developer-facing authorization solution with a readable modeling language and APIs. The Cloud Native Computing Foundation lists OpenFGA as an Incubating project, accepted on September 14, 2022, and moved to Incubating maturity on October 28, 2025.
The central idea is relationship-based access control, or ReBAC. Instead of asking only whether a user has a global role, OpenFGA asks whether a user has the right relationship to an object. The model can express document viewers, organization members, repository maintainers, folder inheritance, or team membership.
OpenFGA is not an identity provider, authentication protocol, or general policy engine. It answers authorization questions once the calling system supplies the actor, object, relation, model, and stored relationship data.
How It Works
OpenFGA uses authorization models and relationship tuples. A model defines object types and relations. Relationship tuples represent current facts, such as a user being a team member or a team having editor access to a document. A check request asks whether the modeled relationships imply access.
The project is inspired by Google's Zanzibar paper, which described a global authorization system for evaluating access control lists across services such as Calendar, Cloud, Drive, Maps, Photos, and YouTube. Zanzibar made the tuple-and-configuration style widely visible; OpenFGA applies related ideas for application developers.
OpenFGA also supports contextual tuples, which allow a check to include dynamic relationships that are not written to the store. Its documentation presents this as a way to cover some attribute-driven cases, such as token claims.
Agent Context
Agent systems create new authorization pressure because a software actor may act for a human across documents, repositories, calendars, tickets, memories, and databases. A tool broker can use OpenFGA to ask whether the delegated actor has the right relationship to the object.
That is a better pattern than giving an agent a broad token and relying on prompt instructions. A coding agent might read any repository where the user is a member, write only to a working branch, and request approval for protected settings. A research agent might read project notes through group membership but fail checks against personnel records.
OpenFGA's relationship graph can also model inheritance. If a team has access to a folder and a document belongs to that folder, a check can follow the modeled path. For agents, that matters because authority is often inherited through projects, teams, workspaces, and data collections.
Governance and Safety
OpenFGA can make delegated authority more legible, but it does not make an agent safe by itself. It does not decide whether a prompt is malicious, a retrieved record is accurate, or a user should have made the request. It evaluates the relationship check.
The main governance risk is stale or incorrect relationship data. If group membership, document ownership, project state, or tenant boundaries are not synchronized, OpenFGA can return a correct answer over incorrect facts. For agents, automated actions can compound a stale permission quickly.
A governed agent deployment should record the authorization model version, tuple version or consistency marker where available, human principal, agent identity, object, relation, decision, enforcement result, and side effect. The audit trail should show both the graph question and the action that followed.
Defense Pattern
- Model resources before tools. Define object types, relations, and inheritance before wiring agent actions to checks.
- Bind agents to principals. Record whether the agent acts as the user, as a service account, or under delegated task authority.
- Synchronize relationship facts. Treat tuple updates as part of user, group, project, and document lifecycle management.
- Check before side effects. Put OpenFGA checks at the tool boundary, not in a logging layer after the action.
- Test graph edges. Verify denial through nested groups, inherited folders, deleted memberships, and cross-tenant objects.
- Log the tuple question. Preserve the checked user, relation, object, model version, decision, and enforcement result.
Source Discipline
Claims about OpenFGA should cite the official OpenFGA documentation, the OpenFGA GitHub repository, the CNCF project page, or the Zanzibar paper when discussing its lineage. Do not collapse OpenFGA into Open Policy Agent, Cedar, AuthZEN, Zanzibar itself, or every authorization product that uses the phrase fine-grained access control.
Spiralist Reading
Spiralism reads OpenFGA as a map of delegated permission. It turns authority into relations: member of, owner of, editor of, viewer of, parent of, belongs to. That map matters because agents increasingly move through shared institutional objects.
The danger is mistaking the map for the territory. A relationship graph is only as honest as the systems that maintain it. When the graph is wrong, the agent inherits the error.
Open Questions
- Should agents be modeled as users, service accounts, delegated tasks, or separate object types?
- How should short-lived task authority be represented without polluting long-lived relationship data?
- What consistency guarantee is required before an agent acts on recently changed permissions?
- How should a denial be explained without revealing the structure of private groups or resources?
Related Pages
- Open Policy Agent
- Cedar Authorization Policy Language
- AuthZEN Authorization API
- AI Agent Identity
- Confused Deputy Problem
- Capability-Based Security
- AI Agent Sandboxing
- AI Audit Trails
- SCIM (System for Cross-domain Identity Management)
- OAuth Resource Indicators
- Model Context Protocol
- Tool Use and Function Calling
Sources
- OpenFGA, Fine-Grained Authorization, reviewed June 25, 2026.
- OpenFGA, Concepts, reviewed June 25, 2026.
- OpenFGA, Use Token Claims As Contextual Tuples, reviewed June 25, 2026.
- Cloud Native Computing Foundation, OpenFGA project page, reviewed June 25, 2026.
- openfga maintainers, OpenFGA GitHub repository, reviewed June 25, 2026.
- Ruoming Pang et al., Zanzibar: Google's Consistent, Global Authorization System, USENIX ATC 2019.