Agent Authorization Protocol

Why it exists

Trust tells you who an agent is. AAP governs what it may do, and it starts from an uncomfortable truth: an agent is non-deterministic and persuadable. The same agent, with the same permissions, behaves differently depending on its inputs. So any secret in its context is a secret one prompt injection away from being leaked.

AAP's answer is simple: never let the credential into the agent at all. The agent emits an abstract grant:// reference; a local, operator-controlled broker resolves the real, scoped access behind a trust boundary, performs the operation, and returns only the result.

The whole idea, in one picture

A grant reference goes in; a result comes out. The credential itself is bounced at the boundary, it never crosses into anything a language model can read.

The grant reference

What the agent holds is deliberately uninformative. A grant reference is an opaque logical name, it encodes no backend, no credential, and no hint of how it will be resolved.

grant-reference = "grant://" grant-name      ; e.g. grant://orders-db

# A grant name carries NO structure a model could learn from:
#   ✗ no backend host or address
#   ✗ no credential or token
#   ✗ no resolution mode (Retrieve / Assume / Exchange)
# It names what the agent is trusted to do, in the abstract, nothing more.

Inside the broker

The broker is AAP's enforcement point: a local process the operator controls. It verifies the ATX, applies policy, mints a short-lived assertion from the ATX's claims, exchanges it for a scoped downstream credential, runs the operation in an ephemeral, isolated worker, and returns only the result. The scoped credential exists only inside that worker, briefly, and never re-enters the agent process.

Three ways to resolve a grant

Retrieve

The broker proxies the operation or injects a value into the ephemeral worker. Simplest, but holds standing secrets.

Assume

The broker mints an assertion and obtains short-lived, role-scoped credentials (like STS AssumeRole). No standing secret.

Exchange

The broker performs an RFC 8693 token exchange for a scoped downstream token. The v1 reference target. No standing secret.

Because the resolution mode never leaks to the agent, operators can change how a grant resolves without touching agent code.

AAP vs. OAuth

AAP is OAuth's authorization model with one rule OAuth never needed, because OAuth clients aren't language models that can be talked into leaking a token.

What it defends against

By construction, no credential value enters the agent context, which removes the substrate whole classes of attack depend on (mapped here to the AI Agent Threat Matrix):

• Environment-variable exposure, there is no secret env var for a compromised tool to read.
• Tool-response credential capture, the broker returns results, never credentials.
• Context-window credential leak, a secret that never entered the window cannot leak from it.
• Exfiltration, even a fully hijacked agent can leak only grant names and results, nothing reusable.

Conformance & status

Level 1, Context Hygiene

Grant syntax, the no-credential-in-context invariant, default-deny, ATX verification, ephemeral-worker confinement, opaque denials, signed audit. One resolution mode.

Level 2, Agile + Negotiated

Adds version negotiation, cryptographic agility (hybrid default suite), safe-ignore claims, and a discovery document.

Level 3, Federated

Adds federation-aware policy (issuer chain, trust level, scan summary), cross-broker verification, and jurisdiction enforcement.