Authorization for multi-hop AI agent systems. At every hop, before the call goes out, one question gets answered: is this caller allowed to do this, right now?
A model picks its own call graph at runtime. Authority should narrow every time it changes hands, and trace back to the human who granted it.
Agentic systems break the assumption security is built on
Traditional application security assumes a developer wrote the call graph and fixed it at deploy time. A model picks its own at runtime, and authority travels unchanged across every hop.
Nothing separates what the model decided to do from what it was allowed to do. That opens four gaps:
Over-broad propagation
Whatever hop 1 can do, hop 4 inherits. The blast radius grows with every delegation.
Injection propagation
Content an agent reads can steer a tool call several hops later, and nothing tells a real instruction apart from an injected one.
No audit path
Answering "who authorized this, and which agents did it pass through?" means correlating logs across services.
Unbounded delegation
Nothing caps how deep or how wide a delegation chain can spread.
A system-prompt rule is text the model reads, and the same injection that steers the agent can steer the rule. An identity check tells you which agent is calling and on whose authority. It does not tell you what that agent may do at this hop. How the pieces fit together
Features
Everything an agent needs to act on your behalf
The authorization pattern your stack already uses, run again at every hop and narrowed each time.
Authority that narrows
Every hop gets its own decision, scoped tighter than the last. Permission shrinks as it travels. Why it narrows
One consent, every hop
A human approves once. Every call after that is checked against that pinned policy. No agent re-asks, and none quietly escalates. How decisions are made
An audit you can query
Every allow and deny is written before the call goes out, linked to the hop above it. One query returns the whole chain back to the human. The audit model
Declared, then proven
A manifest states what an agent may do. Reconciliation checks it against what the tools really expose, and CI fails when the two drift apart. Reconciliation
Enforcement beside your agent
A sidecar sits on the agent's egress path, so its only route to a tool runs through a policy check. No agent code changes, any language. Deploy the sidecar
Decisions you can see
Each decision emits a trace and a structured log with the policy version it used, so you can look up why a call was denied in production. The telemetry surface
How it works
One decision per hop, narrowed each time
Authorization is built from two pieces. A policy decision point answers “is this caller allowed to do this?”. A policy enforcement point (a gateway, sidecar or middleware) asks it and blocks the call if the answer is no. Authz AI keeps both and changes when they run: at every hop, not once at the front door.
1
Declare
Each agent registers a manifest: the tools it may call, the data classes it may touch, the agents it may hand work to. Reconciliation checks that against what the tools really expose.
2
Consent
A human approves one scope. That pins a single policy version for the whole chain, and every later decision traces back to it.
3
Decide
Before any call goes out, the policy decision point rules on this hop. Is the target in scope? Is the hop budget spent? Is the caller who it says it is?
4
Narrow
On an allow, the token is swapped for a narrower one scoped to this hop. It carries a nested claim naming the agent above it and the human at the root.
5
Record
The decision is written before the call goes out, so the audit trail holds what was decided at the time.
A conventional check runs once, at login or at the gateway, and every hop after it is trusted. That works when a developer fixed the downstream graph in advance. Why authority narrows per hop
Use cases
What a bounded agent looks like
The same consent, applied to six different jobs. Each one names the scope a human approved, and what happens when the agent reaches past it.
Allow and deny alike are written to an append-only log with the acting agent, the delegating chain, the target, the data class and the policy version evaluated. The write happens before the call goes out.
A manifest is reconciled against what an agent's tools really expose, and the CI check fails when the two diverge. Authority creep shows up in a pull request.
Limits: A tool whose discovery endpoint is unreachable is flagged for review rather than silently accepted.
Every manifest change creates a new version; nothing is edited in place. A session is pinned to one version, so you can always see what a decision was judged against.
An agent that proves possession of its signing key is identified, not authorized. A resource-side check requires both a verified identity and a scoped grant for that specific hop.
What the layer takes from each specification it builds on. Each entry names the part in use and links to where it is documented.
OAuth 2.0 protected-resource metadata
Declared tools are resolved against each server's own published metadata, so reconciliation compares a declaration with what the resource actually advertises. Capability discovery
RFC 8693 Token Exchange
The hop-by-hop narrowing mechanism. Each hop exchanges its token for a narrower one carrying a nested act claim, which is what preserves "agent A acting for agent B on behalf of human C". The token exchange service
RFC 9396 Rich Authorization Requests
Per-call scope at a resource boundary you own, for agents whose code you cannot change. It is the strongest of the boundary enforcement options. Deploy a boundary adapter
The MCP authorization model
The integration surface. Enforcement sits in front of MCP servers instead of replacing them, and discovery reads their metadata, so existing connectors keep working. Enforcement point tradeoffs
AAuth proof-of-possession
The agent identity handshake, kept separate from authorization. Completing it proves which agent is calling and grants it nothing. The identity registry and verifier
JWKS offline verification
Resource-side identity checks against pinned keys with no network call on the hot path, so enforcement does not depend on reaching a central service. Enroll and verify agent identity
The project holds no certification, assessment, or standing with any regulator, and claims none. What is on this page is what the documentation can substantiate, and every entry above links to it.
Pricing
Open core, in three stages
The enforcement engine is free and open source, and stays that way. You pay when you would rather not run it yourself.
Open source
FreeOpen source, no agent limit.
Any team that wants to enforce per-hop authorization and own the code that does it.
The SDK and the policy decision point
Sidecar enforcement on the agent's egress path
Manifests, reconciliation, and the scope→capability DAG
The append-only audit log and delegation-chain queries
The CI drift check
Decision traces and structured logs you can point at your own stack
The enforcement engine itself, emitting everything your own tooling needs. You run it, you upgrade it, you operate it.
Self-deployed licence
Talk to usPriced per agent, licensed.
Teams in regulated environments who must keep every component inside their own infrastructure.
Everything in open source
The shipped dashboards and alert rules, maintained
Decision history retained and queryable at scale
A licence covering the agents it runs and verifies
Support, and help with upgrades and policy review
The same engine, licensed, plus the dashboards and retained history you would otherwise build yourself. Nothing leaves your environment.
Hosted platform
from ~$10–20 / agent / monthIndicative only. Pre-launch, and still being validated with design partners.
Teams who would rather not run the decision point, the audit store, and the dashboards themselves.
Everything in the self-deployed licence, operated by us
The hosted decision point and audit store
Dashboards, alerting and retained decision history, operated for you
You stop operating any of it. The enforcement is identical; what you buy is not having to run it.
Figures are indicative and pre-launch. They are hypotheses being tested with design partners, not a price list, and they will change.