Authorization

An agent that calls tools acts on systems that have owners, so something has to answer one question for every action: may this subject do this, to this resource, right now? Most systems collapse that into authentication (holding a token means you're allowed), scatter checks across ad-hoc if statements, and have no resource-level granularity. OAP checks every action against a SpiceDB graph.

Three gates, one graph

Authorization in OAP is one relationship graph consulted three ways:

  • Every action is checked. Each tool call resolves to a permission on a resource and is checked per-action — not once at the start, but every time.
  • The risky ones ask a human. Actions whose effects leave the session, or that reach an owned resource, pause for an explicit human approval — and the person who may approve is derived from the graph, not from whoever happens to be talking.
  • Access is earned, then scoped. An approval doesn't hand over a standing key; it writes a grant scoped to exactly what was approved — this plan, this resource, this session — and no more.

Because the unit of trust is the resource, "who can decide this" is answered by who owns the resource, and an approval can never be transplanted onto something it wasn't for.

Go deeper

  • Multiplayer sessions — more than one human in a shared session, gated at the door and at the dangerous step.
  • Plan gating & approvals — approving a whole multi-step plan at once, scoped to exactly the plan — and the exact resources — it named.
  • Shared permissions — data owned by a resource, released only with its owner's approval, routed to the owner rather than the requester.
  • Information leakage & egress — the right data reaching the wrong audience is a permission question too, gated per-datum and routed to the data owner.