> ## Documentation Index
> Fetch the complete documentation index at: https://agenticadvertisingorg-feature-feedback.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/dist/docs/3.1.0-rc.13/building/verification/compliance-catalog) for the full taxonomy.
| Specialism | Status | What it covers |
| ----------------- | ------ | ---------------------------------------------------------------------------------------------------------------------- |
| `security` | stable | Authentication baseline — unauth rejection, static-credential 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
AdCP's five-layer defense model: identity, isolation, idempotency, signed governance, and auditability.
Implementation reference: idempotency enforcement, webhook HMAC verification, SSRF discipline, signed governance, principal isolation, and insert-rate ceiling.
Governance token structure, the JWS verification model, and the correlation model for multi-party lifecycle tracking.
Security as an operating concern: credential management, rotation cadences, and incident response.
Principal isolation, account-scoped access, and multi-tenant separation.
static-credential 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:
```bash theme={null}
export ADCP_AUTH_TOKEN="1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ"
export AGENT_URL="https://test-agent.adcontextprotocol.org/mcp"
```
See the [Quickstart](/dist/docs/3.1.0-rc.13/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%.