OpenFGA: Relationship-Based Authorization from Google Zanzibar

▶ Watch (0:17)

OpenFGA is an authorization service for developers inspired by Google Zanzibar. Zanzibar powers Google Docs, Google Cloud, and YouTube. It builds on relationship-based access control, an extension of RBAC and ABAC, designed to scale to large request volumes. OpenFGA packages those ideas with developer tooling. Since the last KubeCon US, the project was accepted into CNCF incubation. Docker migrated to the latest version and saw latency drop significantly on the graph Aguiar shared. OpenFGA also launched support for OpenZen 1.0, an OpenID spec for authorization checks.

Zero-Permission Start: Ephemeral Task Grants

▶ Watch (1:42)

Agents start with zero permissions. OpenFGA assigns permissions per task, per resource, and only for the duration of that task. An authorization model defines entities like tools and parameters. Tuples instantiate the model with actual data. You can grant any task the ability to call a Slack list-channels tool, but restrict sending a message to a specific channel to task one only. That same pattern extends to application domains: a task that can edit a project also gets edit rights on every ticket within it.

Inferring Permissions from the Prompt

▶ Watch (3:42)

Intent-based permissions derive what an agent needs from its prompt, not from a static list. A dedicated LM processes the prompt and infers the required permissions. In the example, the prompt asks the agent to summarize a Linear project and post it to a Slack channel. The LM infers read access to Linear and write access to that channel. This LM runs without tool access and cannot be prompt injected. In interactive mode, the user approves the list. In autonomous mode, permissions are granted automatically.

Blocking Prompt Injection at the Permission Boundary

▶ Watch (4:41)

The demo ran both modes against a real scenario. The task read a Linear project and posted to Slack. The Linear project contained an injected prompt telling the agent to send an email to an external address. In interactive mode, the agent surfaced the email request, the user denied it, and the agent reported it could not send the email. In autonomous mode, the agent detected that the email instruction exceeded its inferred permissions and cancelled the task entirely without taking any action.

Notable Quotes

Agents start with zero permissions and we run them ephemeral per task permissions. Andres Aguiar · ▶ 2:02

It’s an LM that cannot be prompt injected, has the whole context there, cannot call tools, very constraint. Andres Aguiar · ▶ 4:18

So, now it’s not just going to send the message and it’s going to tell me that it couldn’t send the email. Andres Aguiar · ▶ 5:36

Key Takeaways

  • OpenFGA reached CNCF incubation and Docker’s migration produced measurable latency reductions in production.
  • Agents start with zero permissions and receive only the ephemeral, task-scoped grants they need.
  • A separate, injection-resistant LM infers required permissions from the prompt before the agent runs.
  • In autonomous mode, permissions inferred at start time block injected instructions that exceed that scope.

About the Speaker(s)

Andres Aguiar is Director of Product at Okta and an OpenFGA maintainer. His work focuses on solving authorization at openfga.dev and fga.dev.