AI Agent Authorization

Autonomous and copilot agents act on behalf of users — but "on behalf of" is not the same as "as." A well-modeled agent has its own identity, inherits only the permissions it actually needs, and can be revoked independently of the user it serves.

OpenFGA models this directly:

• Agents are first-class principals. They appear on the left side of tuples like users do, so checks, list-objects, and list-users all work on agent identities.
• Permissions are delegated, not copied. Relations like can_act_on_behalf_of make the delegation explicit and revocable.
• Scope is bounded. An agent can be granted access to a specific workspace, document set, or tool — not the user's entire footprint.

The modeling pieces

The modeling guides below cover the building blocks:

• Agents as principals — define an agent type and use it like a user.
• Task-based authorization — bound an agent to a single task or session.
• RAG authorization — filter retrieved context by the user's permissions before the model sees it.
• MCP server authorization — protect tools and resources exposed via Model Context Protocol.

Why ReBAC fits agent workflows

Agent workflows are graph-shaped: a user grants an agent access to a workspace; the workspace contains documents; some documents are shared from other workspaces. Roles can't model that without exploding into per-resource role definitions. Relationships do it natively — and OpenFGA's reverse queries (list-objects, list-users) let the agent ask "what can I see?" without scanning everything.

Related reading

• Authorization for AI Agents — the full modeling guide, with examples.
• Policy vs Relationship Engines — when relationship modeling is the right tool for agent workflows.