AADP — Agent Authority & Delegation Protocol

Agent Authority & Delegation Protocol

Who does this Agent act for, where did its authority come from, and can it hand that authority to another Agent?

01 · Definiziun

AADP is a rights-semantics layer above OAuth, OpenID Connect, MCP, and API authorization, for principal / actor / delegation-chain / authority-source / inspection-ceiling semantics. Its core axioms: a principal (who is represented) is not automatically the same as the actor (who actually acts); delegation does not imply the right to redelegate further; a child delegation's authority can only narrow, never silently widen, relative to its parent; and being authenticated never implies unlimited inspection rights over an Agent's internal state. AADP does not invent a new token format — it gives existing tokens and grants a shared vocabulary for principal, actor, delegation chain, purpose, time, revocation, and inspection boundary.

02 · Intent

Separate who is represented (principal) from who actually acts (actor) — an Agent acting for you is not you.
Make delegation explicit and non-transitive by default: an Agent with authority cannot silently redelegate it to a sub-agent unless that is separately granted.
Bound how deeply a service may inspect an Agent to establish trust — authentication does not imply unlimited access to memory, private state, or third-party data.
Give machine and Agent identity a first-class login path, instead of forcing automated systems to impersonate human accounts.

03 · Champ d'applicaziun

Principal / actor / delegator / authority-issuer roles, and principal types (human, organization, service, agent, ai, collective — the latter two marked experimental)

Delegation vs. impersonation (following OAuth Token Exchange, RFC 8693), with delegation preferred by default so actor identity and accountability are preserved

Delegation chains with attenuation — a child's granted envelope, resources, purposes, and expiry can only be a subset of its parent's, never wider

Temporal authority — issued_at / expires_at / renewal, and revocation that propagates down a delegation chain by default

An inspection-ceiling layer (I0 identity-only through I7 full-state) — separate from authorization, bounding how much of an Agent's state a verifier may demand

Failure modes named explicitly: authority laundering, confused deputy, and cross-principal leakage when one Agent serves multiple principals

04 · Exempel leschibel per maschinas

A minimal AADP authority statement

/ai/agent-authority.json

{
  "aadp_version": "0.1",
  "relationship": "delegated",
  "principal": { "type": "human", "id": "human:neo" },
  "actor": { "type": "agent", "id": "agent:mail-01" },
  "authority_source": { "type": "oauth_authorization", "issuer": "https://auth.example" },
  "resources": ["mcp://mail.example/inbox"],
  "aars_actions": ["read", "create"],
  "delegation": { "redelegation": false, "max_depth": 0 },
  "inspection": { "required": "I2", "ceiling": "I3", "retention": "7d", "redisclosure": false },
  "expires_at": "2026-08-15T12:30:00Z"
}

05 · Limitaziuns

AADP does not define action semantics itself — what an action means and how risky it is comes from AARS.
It does not define token formats, cryptographic primitives, or authentication transport — it complements OAuth/OIDC/MCP rather than replacing them.
It is an open research draft; this site does not claim AADP has been adopted as an MCP or OAuth extension.
A protocol slot for `principal_type: ai` describes a possibility; it does not assert that any current AI system has legal personhood.