Introducing the Agent Authorization Standard (AAS) v0.1

OAuth 2.1. RBAC. API keys. These are the systems guarding enterprise resources today. They were designed to answer one question: is this identity allowed in?

That question is no longer sufficient.

An autonomous AI agent doesn't just authenticate once and stop. It reads files. Calls APIs. Delegates work to sub-agents. Moves money. And it does all of this continuously, at a speed and volume no human can supervise. The credential systems we inherited from the web era were never designed to answer the questions that actually matter for an agent:

Should this specific action, in this sequence, by this delegated agent, for this declared purpose, be allowed to execute right now?

The Agent Authorization Standard (AAS) v0.1 is our answer to that question. It is a vendor-neutral, open specification published today for public comment, with AgentGate as its reference implementation.

Why a Standard, Not Just a Product

In May 2026, five national cybersecurity agencies — CISA, NSA, and the cyber authorities of Canada, Australia, and the United Kingdom — jointly identified autonomous AI agents as a critical-infrastructure risk. They named four failure modes: privilege creep, behavioral misalignment, obscure event records, and an expanded attack surface. They called for cryptographically anchored agent identities and tamper-evident audit trails.

Most enterprises cannot implement these controls today. Not because they don't want to — because the infrastructure layer doesn't exist in their stack.

The EU AI Act's high-risk obligations require operators to prove that automated systems cannot act outside authorized scope, that every action is logged, and that a human can intervene. OWASP lists Excessive Agency (LLM06) as a critical risk. MITRE ATLAS catalogues the adversarial tactics — reconnaissance, privilege escalation, exfiltration — that apply directly to agents.

These mandates all describe the same missing layer from different angles. AAS specifies that layer. And because it's a standard — not a product — any system can implement it.

Six Design Principles

AAS is built on six principles that distinguish it from existing access control frameworks:

• Pre-execution, not post-hoc. Authorization happens before the action runs. Logging what an agent did is not authorization.
• Action-level, not session-level. Every individual action is evaluated, not just the initial login.
• Sequence-aware. Some attacks are invisible in any single request and only emerge across a window of actions. The model must be able to reason over time.
• Delegation-native. Multi-agent chains are the default, not the exception. Authority must only narrow as it is delegated.
• Verifiable. Every decision must be reconstructable and tamper-evident, without trusting the infrastructure that produced it.
• Vendor-neutral. Any system may implement AAS. The standard is not the product.

The Core Model

Agent Identity

Every agent must have a cryptographically anchored identity — not a shared API key. The credential must be a signed token (e.g., an Ed25519-signed JWT) whose embedded scope is part of the signed payload, so scope cannot be altered without invalidating the signature. Each agent instance gets a distinct identity. Unregistered agents attempting any action receive DENY.

Agent Declaration and Behavioral Contracts

Before acting, an agent must register a declaration containing its agent_id, a declared_purpose (a natural-language statement of intent), its authorized_resources, and its authorized_actions.

Optionally, agents may declare behavioral contracts — hard, self-declared limits that, when violated, result in DENY regardless of any trust score:

• max_requests_per_minute
• allowed_time_windows
• max_consecutive_same_action

The agent's own declaration is used to bound the agent. A contract violation is always final.

Delegation and Scope Attenuation

When an agent delegates authority to a child, four rules apply:

1. Attenuation. A child's scope must be a subset of its parent's. A child cannot be granted authority its parent did not hold.
2. Chain traversal. At authorization time, every ancestor in the delegation chain is verified — not only the immediate parent.
3. Trust ceiling. A low-trust parent cannot spawn a higher-trust child. Trust cannot be laundered through delegation.
4. Atomic revocation. Revoking an agent atomically neutralizes that agent and all of its descendants in a single operation.

Most systems today verify that the final token presented is valid. None verify whether the agent presenting it was legitimately authorized to inherit the scope it claims. The gap between "valid credential" and "legitimate delegation" is where the next class of enterprise breach lives.

The Authorization Decision

For every action, the Policy Enforcement Point (PEP) calls the Policy Decision Point (PDP) before execution. The PDP returns exactly one decision: PERMIT, ESCALATE, or DENY.

Where a trust score is used, it is computed from four independent dimensions:

Dimension	What it answers	Reference weight
Identity	Valid signed token? Action and resource in declared scope?	25%
Delegation chain	Was authority legitimately inherited and narrowed at every hop?	25%
Purpose alignment	Does this action match the agent's declared purpose?	30%
Behavioral	Is this consistent with the agent's normal velocity and pattern?	20%

The same trust score may PERMIT a LOW-sensitivity action and DENY a CRITICAL one.

Stateful, Multi-Step Evaluation

A per-request decision is necessary but not sufficient. AAS Level 3 requires maintaining per-agent behavioral state across a rolling time window and being able to deny or escalate a sequence of actions that are each individually permissible but collectively constitute an attack.

At minimum, four kill-chain patterns must be detectable:

Pattern	Description	Decision
BULK_READ_THEN_EXFIL	Many reads in a short window followed by an export/exfiltration attempt	DENY
READ_THEN_DELETE	A read followed by a delete on the same resource	DENY
SENSITIVITY_RAMP	Progressive escalation from low- to critical-sensitivity resources	ESCALATE
DIRECTORY_SWEEP	Systematic reconnaissance across many resource prefixes	ESCALATE

The defining property of this level: the decision depends on history, not just the current request.

Tamper-Evident Audit

AAS Level 4 requires recording every authorization decision in a tamper-evident structure such that any post-hoc modification is cryptographically detectable. Decisions are sealed into a hash-linked structure (SHA-256 Merkle tree over batches of entries). An inclusion proof for any individual decision must be producible, allowing an auditor to verify that a specific decision is present and unaltered without trusting the host infrastructure.

Critically: the seal is created before the action executes. A log assembled after execution can be manipulated between the action and the record. A pre-execution seal is proof of what was authorized — not just a record of what happened.

Conformance Levels

Level	Name	What it stops
L0	Credential-only	Nothing agent-specific. A valid token does anything.
L1	Per-action authorization	Out-of-scope actions, unauthorized action types.
L2	Delegation integrity	Privilege inheritance attacks; trust laundering through sub-agents.
L3	Behavioral / sequence-aware	Attacks that look clean request-by-request and only reveal intent across time.
L4	Accountable	Repudiation; undetectable log tampering; unsupervised critical actions.

Most "agent security gateways" available today reach L1, some partial L2. Full conformance — L4 — requires all of the above. AgentGate is the reference implementation targeting L4.

Attack Taxonomy

Attack class	OWASP / MITRE	Defending level
Excessive agency / out-of-scope action	OWASP LLM06	L1
Privilege inheritance via delegation	—	L2
Trust laundering through sub-agents	—	L2
Slow exfiltration below rate limits	MITRE ATLAS (Exfiltration)	L3
Reconnaissance / directory sweep	MITRE ATLAS (Discovery)	L3
Prompt injection via processed content	OWASP LLM01	L1 (input scan)
Log tampering / repudiation	—	L4

What Happens Next

This is version 0.1, a working draft. It is published openly so the agent ecosystem, framework maintainers, and regulators can converge on a shared model rather than a fragmented one.

A reference implementation is not the standard. Alternative implementations at any conformance level are encouraged and welcome. The intent is to move governance to an open working group as adoption grows.

Implement it. Fork it. Argue with it. But position around it.

---

AAS v0.1 full spec: Available in the AgentGate repository.

Reference implementation (AgentGate): Open source, MIT licensed. github.com/ElamOlame31/agentgate-public

Comments and conformance reports: Invited via the repository's issue tracker.

Try the live demo: tryagentgate.com/playground