Skip to main content

Patterns

Worked, version-pinned deployment patterns that trace real-world agent topologies through the spec end-to-end. Each pattern cites specific section numbers — §1.1 verification, §1.2 presentation proof, §10.3.3 credential schemes, §10.4 authorization scopes — so an implementer reading along can move from "I want this behavior in production" to "the normative paragraph that says how" in one lookup.

This section is non-normative. The normative content lives in the specification. Patterns illustrate composition, document failure modes, and provide regulators or auditors with reconstructable end-to-end traces — but if a pattern ever conflicts with the spec, the spec wins.

What belongs here

  • Multi-hop scenarios that exercise the cohesive Authentication structure (§10.3) and Authorization Scopes (§10.4) across both the human/external boundary (§10.3.3 OAuth 2.1) and the agent-to-agent boundary (§1.1 + §1.2).
  • Real-world deployment shapes with concrete actors, scopes, audit chains, and failure modes — not abstract "Alice and Bob" pedagogy.
  • Cross-flow composition where the §2.3 independent-vs-reduction patterns become operationally visible.

What does not belong here

  • Standalone ADL document samples — those go in Examples (e.g. minimal.yaml, production.yaml).
  • Test vectors — those go in versions/draft/test-vectors/, with their own SCHEMA.md and conformance runners.
  • Implementer guides that prescribe "do these steps to build X" — patterns describe how the spec composes, not how to build something.

Index

PatternIllustrated byAuthentication pathsAuthorization patterns
Multi-hop authentication and authorizationVacation-booking scenario: human → assistant → MCP calendar / travel discovery / flight + hotel agentsOAuth 2.1, OAuth Token Exchange, ADL passport + presentation proofScope reduction across hops, escalated scopes for booking, sender-constrained proof.scopes
Exposing agents to external callersFortune-50 brokerage scenario: human client website chat + well-known discovery for peer agentsOIDC per session, ADL passport + presentation proof per requestEntitlements as scopes, provider allowlist + attestation, classification gating, step-up for high-stakes
Verifying inbound callers (the PEP)One Policy Enforcement Point across host shapes — agent-runtime plugin, AI-aware gateway, dedicated ADL verifier, and (incidentally) a generic API gatewayOIDC (human path) + ADL passport/proof (agent path) at one PEPCeiling + route-required scopes, principal/delegation enforcement, classification gating, verification boundary vs internal trust domain
Mediating agent egress through an AI gatewaySupport-agent platform behind an AI gateway (Kong AI / Cloudflare / Portkey / LiteLLM): model + tool + agent-to-agent egressGateway custodies the agent key, constructs passport + proof + delegation per outbound callKey custody, per-call tool/MCP credentialing, budget + classification enforcement, model routing vs declared model

Conventions

  • One pattern per file, named after the capability it demonstrates.
  • Section anchors at the end of every pattern mapping every operation to the exact §10.x.y.z it cites.
  • Failure modes section documenting what happens when each authentication or authorization gate rejects.
  • End-to-end audit reconstruction showing how the chain reconstructs across hops where no single hop sees the full picture.
  • Version-pinned: this directory lives under versions/draft/. When the draft is released, patterns move with it.