Protocol Overview

Relationship to OAuth and OIDC

AgentAuthn complements OAuth and OpenID Connect. OAuth establishes who the human is and grants application access. AgentAuthn establishes which autonomous agent is acting at runtime and what intent it is declaring.

OAuth answers: "Who authenticated?" — AgentAuthn answers: "Which agent is acting, for whom, and for what action right now?" AAP assertions are evaluated alongside existing authorization systems and do not replace access tokens or identity providers.

Core Model

AAP introduces three bound identities: Principal (sub) — the user who owns permissions; Actor (act) — the autonomous agent; Intent (int) — the declared action. An API evaluates all three before allowing execution.

Agents do not obtain permissions independently. They derive authority from an existing identity context.

Mental Model

WebAuthn proves a human is present. AAP proves an agent is acting with a specific intent and delegation.

Agent IAM and the Role of AAP

Agent IAM platforms provide policy, audit, and risk evaluation. But they do not define a standard way for agents to cryptographically assert identity and intent at runtime. AAP introduces that ceremony: verifiable assertions with actor (act), audience (aud), intent (int), subject (sub), and provenance chain.

AAP is a runtime assertion profile that Agent IAM platforms could implement. It complements OAuth, WebAuthn, and mTLS — it does not replace them.

Assertion Format

The assertion is sent as two HTTP headers — similar to a Bearer token, but structured as separate assertion + signature:

POST /api/workorders HTTP/1.1
Content-Type: application/json
X-AAP-Assertion: eyJ2IjoiYWFwLTEiLCJhY3QiOiJhZ3RfLi4uIiwiYXVkIjoiZGVtb19hcGkiLC4uLn0=
X-AAP-Signature: aap1=base64url_ed25519_signature

{"title":"Fix leak"}

{
  "v": "aap-1",
  "act": "agt_demo_01",
  "aud": "demo_api",
  "int": "workorders.create",
  "ts": 1760000000,
  "nonce": "...",
  "m": "POST",
  "p": "/api/workorders",
  "bodyHash": "sha256:...",
  "sub": "usr_789"
}

The API decodes the assertion, verifies the Ed25519 signature (signed over v, act, sub, aud, int, ts, nonce, m, p, bodyHash newline-delimited), then checks policy.

Public Key Discovery

APIs verify AAP signatures using the agent's registered public key. Public keys may be obtained via: application registry, configuration file, hosted registry service, or .well-known discovery endpoint. The exact registry mechanism is implementation-specific.

Ceremonies

• Registration — Agent generates keypair, sends public key to registry
• Assertion — Agent builds assertion, signs, attaches headers
• Verification — Resource server parses, verifies signature, checks policy, emits audit

Error Codes

MISSING_ASSERTION, AGENT_UNKNOWN, SCHEMA_INVALID, SIG_INVALID, AUD_MISMATCH, TS_EXPIRED, NONCE_REPLAY, BODY_HASH_MISMATCH, INTENT_DENIED, AGENT_REVOKED