S6: Security

AdCP specialist module S6: Security mastery. Threat model, 5-layer defense model, idempotency semantics, governance token verification, SSRF discipline, and operational incident response.

S6: Security

Members only — Requires Practitioner credential. ~60 minutes with Addie. Combines hands-on lab and adaptive exam.

This specialist module tests your mastery of AdCP’s security model. You’ll work with sandbox agents to demonstrate the protocol’s five-layer defense in practice: identity verification, tenant isolation, idempotency semantics, signed governance verification, and SSRF discipline. Addie evaluates both hands-on execution and your ability to reason about threat scenarios and incident response.

Passing earns the AdCP specialist — Security credential.

This module is in development and not yet available via Addie. The curriculum, sandbox exercises, and teaching flow are being finalized. Check back soon.

This module covers AdCP-specific controls — the threat model, layered defenses, and operational response patterns specific to agentic advertising systems. It is not a replacement for a general security program. Certified specialists can reason about how AdCP’s controls compose; for OWASP Top 10 or general security engineering, see your organization’s security training.

Specialisms this track prepares you to validate

The following specialisms fall under the security domain. Each has its own compliance storyboard — see the Compliance Catalog for the full taxonomy.

Specialism	Status	What it covers
security	stable	Authentication baseline — unauth rejection, API key enforcement, OAuth discovery + RFC 9728 audience binding
signed-requests	stable	RFC 9421 transport-layer request-signing verification

What you’ll demonstrate

• Explain the agentic advertising threat model: credential theft, replay attacks, cross-tenant data leakage, SSRF on outbound fetches, spoofed agent identity, unauthorized governance token use, and audit log tampering
• Walk through AdCP’s 5-layer defense model — identity, isolation, idempotency, signed governance, auditability — and name the specific attack each layer closes
• Mint an idempotency key and demonstrate all four outcomes against a sandbox: successful first call, idempotent replay (replayed: true), conflict on payload change, and expiry on TTL lapse. Explain the side-effect implications of each outcome.
• Verify a signed governance token against a JWKS endpoint: walk the 15-step verification checklist (alg allowlist, typ match, SSRF-validated JWKS fetch, aud/sub/phase binding, jti replay dedup, revocation list check), tamper with a claim and observe rejection, trace the revocation mechanics
• Implement the 6-point SSRF check on an outbound fetch: HTTPS-only enforcement, reserved-IP deny list (including cloud metadata endpoints), IP-pin validation, redirect suppression, size and timeout caps, and suppressed error detail in responses
• Design an operational runbook covering credential compromise, webhook secret rotation, governance key revocation, and cross-party incident communication
• Given an incident description, identify which defense layer failed and what specific control to harden

S4 (Governance) covers the 15-step JWS seller verification from the seller’s perspective — how a seller validates a governance token issued by a buyer’s governance agent. S6 covers it from the security operator’s perspective — verifying your own token issuance implementation is correct and reasoning about what each step closes. Overlap is intentional; the framing is different.

Prerequisite reading

Security model

AdCP’s five-layer defense model: identity, isolation, idempotency, signed governance, and auditability.

Security implementation

Implementation reference: idempotency enforcement, webhook HMAC verification, SSRF discipline, signed governance, principal isolation, and insert-rate ceiling.

Campaign governance specification

Governance token structure, the JWS verification model, and the correlation model for multi-party lifecycle tracking.

Operating an agent

Security as an operating concern: credential management, rotation cadences, and incident response.

Accounts and security

Principal isolation, account-scoped access, and multi-tenant separation.

Authentication

API key enforcement, OAuth discovery, RFC 9728 audience binding, and the authentication baseline specialism.

Connecting to the test agent

Lab exercises run against the public test agent. Use the shared token — no signup required:

export ADCP_AUTH_TOKEN="1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ"
export AGENT_URL="https://test-agent.adcontextprotocol.org/mcp"

See the Quickstart for a walkthrough of your first call.

Lab exercises

1. Threat model walkthrough — Map each threat (credential theft, replay, cross-tenant leakage, SSRF, spoofed identity, unauthorized governance, audit tampering) to the specific AdCP control that closes it. Explain why no single layer is sufficient alone.
2. Idempotency lifecycle — Submit four requests to a sandbox endpoint using the same idempotency key: (a) first call — observe success; (b) identical replay — observe replayed: true and confirm no side effect; (c) same key, different payload — observe conflict error; (d) after TTL lapse — observe expiry. Reason about what a missing idempotency key means for the seller’s safety guarantees.
3. Governance token verification — Fetch a signed governance token from the sandbox governance agent. Walk the 15-step verification checklist. Tamper with the aud claim and observe rejection. Check the revocation list for a pre-revoked key (test-revoked-2026) and confirm the token is rejected before signature verification completes. Explain what each step closes.
4. SSRF defense implementation — Given a skeleton outbound-fetch function, add the 6-point SSRF check. Verify that a request to a cloud metadata endpoint (169.254.169.254) is blocked, that a redirect to a reserved IP is caught at the IP-pin step, and that error detail is suppressed in the response.
5. Principal isolation probe — Use two sandbox principals on the same seller. Attempt to read resources scoped to the other principal. Confirm isolation. Explain the separation model and what would break if account-scoped tokens were not enforced.
6. Incident runbook design — Given a credential compromise scenario (API key leaked in a public repo), design the response: which keys to rotate and in what order, how to notify counterparties, what audit events to review, and how to verify the compromise window.
7. Defense layer diagnosis — Given three incident descriptions (replay attack succeeded, cross-tenant data returned, governance token accepted after key revocation), identify which layer failed in each case and what specific control to harden.

Assessment

Dimension	Weight	What Addie evaluates
Threat model fluency	20%	Can you name an attack and the specific layer that closes it?
Hands-on idempotency	20%	Can you produce all four idempotency outcomes on demand and explain their implications?
Governance verification	25%	Can you walk the 15-step checklist and explain what each step prevents?
SSRF discipline	15%	Can you implement the 6-point check correctly?
Operational design	20%	Can you design a runbook for credential compromise, including rotation order and cross-party communication?

Passing threshold: 70%.