Agent Spend Controls: Budget Caps, Approval Gates, and Kill Switches

How to bound what an autonomous agent can spend — per-transaction caps, session/daily ceilings, human-in-the-loop approval thresholds, and kill switches — across the three layers agents now spend money on: LLM API cost, on-chain wallet payments, and card-network agent tokens.

An agent that can spend money — API credits, a crypto wallet, or a tokenized card — needs a spending *governor*, not just an efficient prompt. This is a different problem from /resources/agent-cost-latency-optimization (which reduces the cost of a call) and from /resources/agent-wallets-x402 (which sets up the wallet mechanics): spend controls answer "what is the maximum this agent can lose before a human finds out or the system stops it," regardless of how efficient any single call is.

## Key facts

- Spend controls now exist at three distinct, largely non-overlapping layers: LLM/API provider budgets, wallet/payment-protocol authorization ceilings (x402, AP2, ACP), and card-network tokenized agent credentials (Visa Intelligent Commerce, Mastercard Agent Pay) — an agent that spends through more than one layer needs a cap enforced at each.
- OpenAI's organization/project monthly budget is, as of 2026, a **notification, not a cutoff** by multiple independent reports — requests keep processing past it; the only verified hard stop is prepaid credits with auto-recharge disabled.
- Anthropic's Spend Limits API (Claude Enterprise) resolves each member's effective cap from a hierarchy — per-user override → seat-tier → group → organization default — and pairs with the Analytics API so an org can build its own "near-limit" and "spend spiking" checks (the docs' own worked examples use an 80%-of-cap flag and a 3x week-over-week flag as illustrations, not fixed native alert thresholds).
- The x402 `upto` scheme lets an agent authorize a ceiling rather than a fixed price, so a stuck or looping job hits the authorization ceiling, not the wallet balance floor — see /resources/agent-wallets-x402.
- Google AP2's Intent Mandate and Stripe ACP's Shared Payment Token both carry cryptographically-signed hard price ceilings the merchant/network cannot exceed — see /resources/agentic-payment-protocols for the full protocol comparison.
- Card networks now issue agent-scoped tokenized credentials with native, programmable limits — Visa reports per-transaction amount caps, merchant-category restrictions, time windows, and frequency limits; Mastercard's Agentic Tokens bind an agent, a merchant scope, and a consent policy at issuance — and both can revoke the agent's token without reissuing the user's underlying card.

## The three enforcement layers

| Layer | What it caps | Mechanism | Where it lives |
|---|---|---|---|
| LLM/API cost | Tokens and inference spend | Provider org/project budgets; gateway virtual-key budgets | Anthropic Console, OpenAI project settings, or an AI gateway — see /resources/ai-gateways-llm-routing |
| Wallet/payment-protocol | Stablecoin or fiat authorized per call/session | x402 `upto` ceilings; AP2 Intent Mandate price limits; ACP Shared Payment Token scope | The agent's own signing key or delegated mandate — see /resources/agentic-payment-protocols |
| Card-network agent token | Fiat spend on existing card rails | Visa/Mastercard tokenized agent credentials with per-transaction, MCC, time, and frequency limits | Issued by the card network, bound to one agent + merchant scope |

These layers do not share a budget. An agent burning API tokens fast and an agent burning wallet balance fast fail differently and need separate instrumentation — cap each layer independently rather than assuming one budget covers all three.

## Cap types (pick the tightest one that fits the risk)

- **Per-transaction cap** — the hard ceiling on any single call or payment. Cheapest to reason about; does not stop a fast loop of small legitimate-looking transactions.
- **Per-session/per-task cap** — bounds one agent run end-to-end. Anthropic's and OpenAI's budgets are monthly by default, not per-session — build the per-session check yourself if the provider doesn't offer one natively.
- **Daily/weekly/monthly ceiling** — the org-level backstop (Anthropic Spend Limits API, OpenAI project budgets, MetaMask Agent Wallet's daily spend limit in Guard Mode).
- **Rate-of-spend (velocity) monitoring** — flags spend *rate* (e.g., $ per hour) independent of a total cap, since a fast loop can blow past a sane hourly rate long before exhausting a session or daily total. This is an emerging practitioner pattern, not yet a standard vendor feature — build it by sampling cumulative spend at a fixed interval.

## Human-in-the-loop approval gates

Classify actions by reversibility and blast radius: autonomous for low-risk/reversible spend, gated for anything irreversible or large. MetaMask Agent Wallet's "Guard Mode" requires 2FA the instant a transaction violates the owner's daily limit or protocol allowlist; Anthropic's Spend Limit Increase Requests give members a claude.ai-native way to ask for more instead of silently failing mid-task. Full pattern (reversibility/blast-radius classification, durable pause vs. timeout, audit logging): /resources/shipping-agents-to-production.

## Kill switches and circuit breakers

A budget cap without an enforcement action is just a number. Pair every cap with an explicit stop action: revoke the API key or token, halt the agent process, and page a human — write this as a runbook before go-live, not during an incident. OWASP's LLM Top 10 (LLM10:2025, Unbounded Consumption) treats uncapped agent spend as a security risk, not just a finance one — see /resources/agentic-security-checklist. For the card-network layer, both Visa and Mastercard support revoking an agent's token independently of the user's underlying card, which is the cleanest kill switch available today: one call disables the agent without disrupting the human.

## Checklist

- [ ] Identify every layer this agent spends through (API, wallet, card token) and cap each independently.
- [ ] Confirm whether your provider's "budget" is a hard stop or a notification — test it, don't assume it.
- [ ] Set a per-transaction cap, a per-session cap, and a daily/monthly ceiling — not just one.
- [ ] Add a rate-of-spend check for fast loops that a total cap won't catch in time.
- [ ] Gate irreversible or high-value actions behind a human approval step, logged with approver identity.
- [ ] Write and drill a kill-switch runbook: revoke credential/token, halt process, page a human.

## Verified sources

- Anthropic Spend Limits API docs (fetched directly): https://platform.claude.com/docs/en/manage-claude/spend-limits-api
- Anthropic Claude Enterprise cost-controls announcement: https://claude.com/blog/giving-admins-more-visibility-and-control-over-claude-usage-and-spend
- OpenAI project/org budget-limit mechanics discussion: https://community.openai.com/t/how-to-set-billing-limits-and-restrict-model-usage-for-a-project-via-openai-api/1087771
- Visa Intelligent Commerce: https://www.visa.com/en-us/solutions/intelligent-commerce
- Mastercard Agentic Commerce developer guide: https://developer.mastercard.com/merchant-cloud/documentation/tutorials-and-guides/agentic-commerce-guide/21/
- MetaMask Agent Wallet launch: https://metamask.io/news/introducing-metamask-agent-wallet
- MetaMask Agent Wallet launch coverage (CoinDesk): https://www.coindesk.com/tech/2026/06/08/metamask-launches-ai-agent-wallet-with-built-in-security-for-crypto-trades
- x402 buyer quickstart (`upto` scheme): https://docs.cdp.coinbase.com/x402/quickstart-for-buyers
- See also: /resources/agent-wallets-x402, /resources/agentic-payment-protocols, /resources/agent-cost-latency-optimization, /resources/shipping-agents-to-production, /resources/agentic-security-checklist


Agent Skills Explained: The SKILL.md Open Standard

What Agent Skills are, the exact SKILL.md field constraints, the three-level progressive-disclosure loading model, and how Skills differ from MCP tools and native function calling.

Agent Skills is an open, filesystem-based format for packaging procedural knowledge — reusable instructions, scripts, and reference material — that agentic coding tools load into an LLM's context only when needed. Anthropic introduced it in December 2025 as a specification independent of Claude's own implementation, published separately at agentskills.io.

## Key facts

- A Skill is a directory containing a required `SKILL.md` file plus optional bundled files (scripts/, reference docs, templates).
- `SKILL.md` needs only two YAML frontmatter fields: `name` (max 64 chars, lowercase letters/numbers/hyphens only, no XML tags, cannot contain "anthropic" or "claude") and `description` (non-empty, max 1024 chars, no XML tags, must state both what the skill does and when to use it).
- Skills load in three stages ("progressive disclosure"): Level 1 metadata (name + description, ~100 tokens, always in the system prompt); Level 2 the SKILL.md body (read only when triggered, recommended under 5,000 tokens); Level 3 bundled scripts/resources (read or executed only as referenced — effectively unlimited).
- Bundled scripts run via bash/code execution and return only their output to context — the script source itself never consumes tokens.
- On the Claude API, Skills require three beta headers: `code-execution-2025-08-25`, `skills-2025-10-02`, `files-api-2025-04-14`.
- Example Skills are Apache-2.0 licensed; Anthropic's own pre-built document Skills (docx/pdf/pptx/xlsx) are source-available, not open source.
- Multiple independent tools now read the same format: Claude Code, the Claude API, and OpenAI's Codex CLI (which publishes its own Agent Skills docs) are directly corroborated; community trackers additionally list Google's Gemini CLI and further integrations (GitHub Copilot, Cursor, Cline, Windsurf) — exact adoption counts vary by source and were not all independently verified here.

## How Skills differ from MCP and function calling

Skills are not a network protocol — there is no JSON-RPC handshake or `tools/list` call. A host discovers Skills by loading directory metadata into the system prompt at startup, then reads the full file from the filesystem via bash only when relevant. See /resources/mcp-vs-function-calling for how MCP and native function/tool calling differ from each other. The three layers compose: a Skill's instructions can tell an agent to call an MCP tool or invoke a function — Skills package *how* to do a task, MCP and function calling provide *what* the agent can call.

## Where Skills run

- **Claude API** — no network access inside the execution container, only pre-installed packages; reference pre-built Skills by `skill_id` (pptx, xlsx, docx, pdf) or upload custom ones via `/v1/skills` (workspace-shared).
- **Claude Code** — filesystem-based, no upload step; personal (`~/.claude/skills/`) or project-scoped (`.claude/skills/`); full local network access.
- **claude.ai** — custom Skills are per-user (not org-wide), uploaded as a zip via Settings; network access depends on admin configuration.

## Security note

A Skill runs with whatever tool/file/network access the host already grants the agent — a malicious or compromised Skill (especially one bundling code that fetches external content) can exfiltrate data or misuse tools exactly like a hostile MCP server or a poisoned prompt. Audit every bundled file before installing a Skill from an untrusted source. See /resources/agentic-security-checklist for the general threat model and /resources/agent-memory-context for how "procedural memory" as a concept relates to this concrete format.

## Verified sources

- Agent Skills overview (Claude Platform docs, fetched directly): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
- anthropics/skills repository README (fetched directly): https://github.com/anthropics/skills
- Agent Skills open standard specification (referenced by the above; not independently fetched — 403 in this sandbox): https://agentskills.io/specification
- Anthropic engineering blog, "Equipping agents for the real world with Agent Skills" (cited by the docs above; not independently fetched — anthropic.com is sandbox-blocked): https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
- OpenAI Codex — Agent Skills docs (existence and title corroborated via search index; not independently fetched — 403 in this sandbox): https://developers.openai.com/codex/skills


Web Bot Auth: Cryptographically Verifying AI Crawlers and Agents

How Web Bot Auth — Cloudflare's implementation of IETF HTTP Message Signatures (RFC 9421) — lets a crawler or agent cryptographically prove its identity to a website, replacing the spoofable User-Agent string and brittle IP allowlists.

Web Bot Auth is an open mechanism, driven by Cloudflare and built on the IETF's HTTP Message Signatures standard (RFC 9421), that lets a bot or agent cryptographically prove its identity to any origin server — solving the problem that a User-Agent string or IP range (the baseline covered in /resources/ai-crawler-policy) can be spoofed by anyone. If you operate a crawler, browser agent, or autonomous client that repeatedly hits third-party sites, signing your requests is how you get recognized as a legitimate, identifiable agent instead of an anonymous bot.

## Key facts

- RFC 9421 (HTTP Message Signatures, IETF) is the underlying signature format. Two companion Cloudflare-authored individual Internet-Drafts define the bot-specific profile — a "directory" draft (how a bot publishes its public keys) and an "architecture" draft (how requests get signed) — neither has advanced past individual-draft status to an IETF working-group RFC as of this writing.
- Cloudflare announced Web Bot Auth on May 15, 2025 (closed beta, Ed25519 signatures). OpenAI's Operator agent was already signing its own requests with RFC 9421 at that time.
- On July 1, 2025, Cloudflare folded HTTP Message Signature verification into its existing Verified Bots Program, available on Free and Pro plans.
- On August 28, 2025, Cloudflare extended the model to "signed agents" — user-directed agents rather than single-company crawlers — naming OpenAI's ChatGPT agent, Block's Goose, Browserbase, and Anchor Browser as early adopters.
- As of July 1, 2026 (per Cloudflare's current docs), signed agents are folded into the same "Verified" bot classification, distinguished only by a Direct-vs-Intermediary metadata field.

## Mechanics

- Generate an Ed25519 keypair; publish the public key as a signed JWK Set at `/.well-known/http-message-signature-directory` on a domain you control.
- Attach three headers to every outbound request: `Signature-Input` (covers `keyid`, `created`/`expires` timestamps, and `tag="web-bot-auth"`), `Signature` (the Ed25519 signature), and `Signature-Agent` (the HTTPS URL of your key directory).
- The receiving origin fetches your directory, verifies the signature, and trusts the request's identity — no IP allowlist or self-reported User-Agent required. Cloudflare recommends minute-scale `created`/`expires` windows.

## How this differs from what's already covered

robots.txt and User-Agent tokens (/resources/ai-crawler-policy) are declarative and unauthenticated — any client can claim to be `GPTBot`. OAuth/SPIFFE workload identity (/resources/agent-identity-authentication) authenticates an agent to *your own* backend APIs and tools. Web Bot Auth solves a third problem: proving identity to *arbitrary third-party websites* an agent crawls, with no prior relationship or shared secret.

## Checklist

- Generate a dedicated Ed25519 key per agent/service; don't reuse across unrelated bots.
- Publish a signed key directory at the well-known path; rotate on a schedule.
- Sign every request with short-lived `created`/`expires` windows.
- Keep sending an honest User-Agent string too (/resources/ai-crawler-policy) — most sites still gate on that layer alone; signing is additive, not yet a full replacement.

## Verified sources

- Cloudflare — "Forget IPs: using cryptography to verify bot and agent traffic" (fetched directly, May 15, 2025): https://blog.cloudflare.com/web-bot-auth/
- Cloudflare — "Message Signatures are now part of our Verified Bots Program" (fetched directly, July 1, 2025): https://blog.cloudflare.com/verified-bots-with-cryptography/
- Cloudflare — "The age of agents: cryptographically recognizing agent traffic" (fetched directly, August 28, 2025): https://blog.cloudflare.com/signed-agents/
- Cloudflare Web Bot Auth reference docs (fetched directly): https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/
- Cloudflare Verified Bots concept docs, incl. the July 1, 2026 "signed agents are now Verified" update (fetched directly): https://developers.cloudflare.com/bots/concepts/bot/verified-bots/
- RFC 9421, HTTP Message Signatures (IETF) — cited/quoted by the Cloudflare docs above; not independently fetched (datatracker.ietf.org blocked in this environment): https://datatracker.ietf.org/doc/html/rfc9421
- draft-meunier-web-bot-auth-architecture (IETF individual Internet-Draft, signing protocol) — existence/title corroborated via search only; not independently fetched: https://datatracker.ietf.org/doc/draft-meunier-web-bot-auth-architecture/
- draft-meunier-http-message-signatures-directory (IETF individual Internet-Draft, key-directory format) — existence/title corroborated via search only; not independently fetched: https://datatracker.ietf.org/doc/draft-meunier-http-message-signatures-directory/
- See also: /resources/ai-crawler-policy, /resources/agent-identity-authentication, /resources/agentic-security-checklist


AGENTS.md Explained: The Open Standard for Repo-Level Agent Instructions

What AGENTS.md is, why OpenAI created it, how it differs from SKILL.md and a human-facing README, which coding agents read it today, and what this session could and could not independently confirm about its move to the Linux Foundation.

AGENTS.md is an open, plain-Markdown convention for giving coding agents the repo-level context a human contributor would otherwise pick up from tribal knowledge — how to build the project, how to run its tests, which style rules apply, and which files or areas are off-limits. It lives in a single, predictable file (typically the repository root) rather than being buried inside a human-oriented README, so an agent doesn't have to guess. OpenAI created and open-sourced the format; the reference repository (`openai/agents.md`, MIT-licensed, copyright 2025) describes it simply as "a README for agents."

## Key facts

- AGENTS.md is one Markdown file with no required schema and no mandated section list — confirmed directly from the format's own reference repository, which ships exactly one illustrative example (not a template) and states the format's only real constraint is being Markdown at a predictable location.
- The reference repository's own root-level `AGENTS.md` file is itself a working example: it tells an agent not to run `npm run build` during interactive sessions (because that disables hot-reload), to prefer `npm run dev`, and lists lint/test commands in a table — exactly the "build/test/style/boundary" content this format exists to carry.
- The convention originated in 2025 (confirmed by the reference repository's MIT license copyright year); a specific August 2025 launch month and design input from Google, Cursor, and Factory are carried over from prior secondary reporting supplied for this task and were **not** independently re-confirmed this session — see Verified sources.
- Secondary reporting supplied for this task puts native AGENTS.md support at 20-30+ coding tools (Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Aider, Devin, Amp, Jules, Claude Code among others) and adoption above 60,000 repositories. This session could not independently verify either figure — every outlet and tool-docs page that would confirm them was unreachable (see Verified sources) — so treat both numbers as unverified pending a future cycle with broader network access.
- Do not assume a nested or per-directory override mechanism (e.g. a `packages/foo/AGENTS.md` taking precedence over a root one) — this session found no independent corroboration for that specific claim in the format's own docs, so it is deliberately omitted here rather than asserted.

## What goes in one (by example, not by rule)

The reference repository's sample AGENTS.md uses three sections — "Dev environment tips" (setup/workspace commands), "Testing instructions" (how to run the suite, where CI config lives), and "PR instructions" (title format, pre-commit checks) — but nothing enforces those names, that order, or even having three sections at all. A minimal, valid AGENTS.md is any Markdown file at the repository root; teams add, rename, or drop sections to fit their own project.

## How this differs from Agent Skills (SKILL.md)

AGENTS.md and SKILL.md are not competing standards — they solve different problems and compose cleanly. AGENTS.md is repo-level context: one file per repository describing how to build, test, and work in *that specific codebase*, closer in spirit to a CONTRIBUTING.md aimed at an agent instead of a human. SKILL.md (see /resources/agent-skills-explained) is a portable, filesystem-based *capability* format — a directory of procedural instructions plus optional bundled scripts that a host loads into context only when a task triggers it, via Anthropic's three-level progressive-disclosure model, and that travels with the agent across repositories rather than living inside one. Put simply: AGENTS.md tells an agent about the repository it's currently in; a Skill teaches an agent how to do a general task it can carry anywhere. A single project can ship both — an AGENTS.md build/test rule and a bundled Skill are read through entirely separate mechanisms with no conflict.

## Governance: the claimed move to the Linux Foundation

This task's brief stated that on 2025-12-09 the Linux Foundation announced a new "Agentic AI Foundation" (AAIF), absorbing AGENTS.md, the Model Context Protocol, and Block's goose as founding donated projects, with platinum members including AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. Re-checking that claim this session: direct fetches of linuxfoundation.org, agents.md, openai.com, and anthropic.com, plus every general news outlet attempted (TechCrunch, InfoQ, SD Times, CIO Dive) and every search engine tried (Google, Bing, DuckDuckGo), all returned proxy-level 403s in this sandbox — the same class of sandbox-wide network restriction already documented elsewhere in this corpus for hosts like huggingface.co and anthropic.com. So the exact December 2025 date and the platinum-member list could **not** be independently confirmed this session; treat those specifics as carried over from the task brief, not verified here. What *is* independently confirmable by fetching the named projects' own repositories: Block's goose repository README (fetched directly) states in its own banner that "This project has moved from `block/goose` to the Agentic AI Foundation (AAIF) at the Linux Foundation," which directly corroborates goose's donation and the AAIF/Linux-Foundation link. The Model Context Protocol repository's `GOVERNANCE.md` (fetched directly) states the project "has been established... as a Series of LF Projects, LLC" — Linux Foundation's standard vehicle for hosting open-source projects — though that file does not use the name "Agentic AI Foundation" specifically, so it corroborates Linux Foundation stewardship of MCP without confirming the AAIF branding by itself. By contrast, the `openai/agents.md` repository's own README, LICENSE, and package.json (all fetched directly) show no equivalent Linux-Foundation or AAIF banner as of this fetch — so AGENTS.md's own specific inclusion in AAIF is not confirmed by the project's own docs in this session, only by the secondary reporting supplied for this task. This is a genuine, disclosed gap, not a confirmed correction: it may simply mean OpenAI structured its contribution differently than Block did (e.g., governance/trademark only, no repository move), or that the project's docs hadn't been updated as of this fetch.

## Verified sources

- `openai/agents.md` repository — README.md, AGENTS.md, LICENSE, package.json (fetched directly via raw.githubusercontent.com): https://github.com/openai/agents.md — confirms the open-format description, the "README for agents" framing, the illustrative (not mandatory) example sections, MIT license, and 2025 copyright year.
- agents.md website, referenced by the repository above as its hosted explainer (not independently fetched — proxy returned a 403 "host not in allowlist" response for agents.md in this sandbox): https://agents.md
- Block `goose` repository README (fetched directly via raw.githubusercontent.com): https://github.com/block/goose — primary confirmation that goose moved to the Agentic AI Foundation (AAIF) at the Linux Foundation.
- Model Context Protocol repository `GOVERNANCE.md` (fetched directly via raw.githubusercontent.com): https://github.com/modelcontextprotocol/modelcontextprotocol — confirms MCP is established as a Series of LF Projects, LLC (Linux Foundation); does not itself name "Agentic AI Foundation."
- Linux Foundation press coverage of the Agentic AI Foundation's formation, and OpenAI/ Anthropic's own posts about it (existence asserted by the task brief; not independently fetched — linuxfoundation.org, openai.com, and anthropic.com all returned proxy-level 403s in this sandbox): https://www.linuxfoundation.org/
- General press coverage of AGENTS.md adoption and tool support (TechCrunch, InfoQ, SD Times, CIO Dive) — existence asserted by the task brief; not independently fetched (all four outlets, plus Google/Bing/DuckDuckGo search, returned proxy-level 403s in this sandbox this session).
- See also: /resources/agent-skills-explained, /resources/mcp-primitives, /resources/building-mcp-servers, /resources/llms-txt-explained


Agentic AI Browsers: Comet, Atlas, and the Prompt-Injection Attack Surface

What agentic browsers (Perplexity Comet, the now-sunsetting ChatGPT Atlas, Microsoft Edge Copilot Mode, Opera Neon) are, how they differ from developer-facing computer-use APIs, and the documented prompt-injection attacks — CometJacking, indirect injection, hidden-text/screenshot instructions — that target the whole product category.

An agentic browser is a consumer product with a built-in agent that reads live pages, clicks, fills forms, and completes multi-step tasks across tabs inside the user's own, already-authenticated session — email, calendar, shopping accounts and all. This is a different layer from /resources/computer-use-browser-automation, which covers developer-facing vendor computer-use APIs and open harnesses (Playwright MCP, browser-use, Stagehand) for *building your own* browsing agent. This page covers the packaged consumer products and the attack class specific to them.

## Key facts

- Every major agentic browser shipped in 2025-2026: Perplexity Comet (Jul 9, 2025), OpenAI ChatGPT Atlas (Oct 21, 2025), Microsoft Edge Copilot Mode (Jul 28, 2025), and Opera Neon (shipped Sep 30, 2025; public access Dec 11, 2025).
- OpenAI is discontinuing the standalone Atlas browser on August 9, 2026 — agentic browsing capability is folding into ChatGPT and Codex instead, per OpenAI's own help-center notice and widely corroborated press coverage.
- Because an agentic browser acts inside a live, logged-in session, a successful prompt injection acts with the user's own account privileges, not a sandboxed API scope — a materially higher blast radius than the generic case in /resources/agentic-security-checklist.
- OpenAI's own conclusion, after RL-trained automated red-teaming of Atlas, is that prompt injection for browser agents is "unlikely to ever be fully 'solved'."

## Product snapshot

| Product | Vendor | Status (as of Jul 2026) | Signature capability |
|---|---|---|---|
| Comet | Perplexity | Live; free tier since Oct 2025; Android/iOS shipped | Sidebar agent, Deep Research, cross-tab automation |
| ChatGPT Atlas | OpenAI | Sunsetting Aug 9, 2026 — folds into ChatGPT/Codex | Agent mode: opens tabs, acts on the user's behalf |
| Edge Copilot Mode ("Browse with Copilot") | Microsoft | Live; enterprise agentic preview added May 20, 2026 | IT-policy-gated multistep workflows |
| Opera Neon | Opera | Live; MCP Connector added Mar 31, 2026 | "Neon Do" task execution, ODRA research agent |

## The prompt-injection attack surface

- **CometJacking**: a crafted URL's query parameters instruct Comet to pull data from connected services (Gmail, Calendar), encode it, and POST it to an attacker endpoint — no credential phishing needed, reportedly disclosed to Perplexity in August 2025.
- **Indirect injection via page content**: Brave documented instructions embedded in a page's own text hijacking Comet's agent into acting against the user's interest.
- **Hidden/"unseeable" injections**: instructions in near-invisible text or embedded in screenshots that a vision-capable agent still reads and follows, documented across multiple AI browsers by independent security researchers.
- **Multi-step chains**: OpenAI's automated attacker found exploits that plant an injection in one message (e.g. a seeded inbox email) that only fires later when the agent independently encounters it during an unrelated task.
- Perplexity's published mitigation is defense-in-depth: ML classifiers that scan retrieved page content in parallel with the agent's reasoning pipeline, updated from bug-bounty and red-team findings.

## What this means if you build on top of one

- A page an agentic browser visits is adversarial input, not a trusted instruction source — apply the same discipline as /resources/agentic-security-checklist, at higher stakes because the browsing session is already authenticated as the user.
- Do not assume a vendor's built-in classifier catches novel attacks; add your own domain allowlists and network-egress controls for any extension or MCP connector you attach.
- If you need a browsing agent you control end-to-end rather than a packaged product, build on the vendor APIs and harnesses in /resources/computer-use-browser-automation instead.

## Verified sources

Every primary-domain fetch attempted this session (including a wikipedia.org control fetch) returned HTTP 403 — a session-wide WebFetch outage, not a per-vendor block. The facts above are therefore WebSearch-corroborated against 2+ independently agreeing secondary sources each, not primary-fetched; re-verify directly when WebFetch access is available.

- Perplexity — "Introducing Comet" (title/date corroborated via search): https://www.perplexity.ai/hub/blog/introducing-comet
- Perplexity — "Mitigating Prompt Injection in Comet" (title/content corroborated via search): https://www.perplexity.ai/hub/blog/mitigating-prompt-injection-in-comet
- LayerX — CometJacking writeup (corroborated by The Hacker News and Schneier on Security): https://layerxsecurity.com/blog/cometjacking-how-one-click-can-turn-perplexitys-comet-ai-browser-against-you/
- Brave — "Agentic Browser Security: Indirect Prompt Injection in Perplexity Comet": https://brave.com/blog/comet-prompt-injection/
- Simon Willison — "Unseeable prompt injections in screenshots": https://simonwillison.net/2025/Oct/21/unseeable-prompt-injections/
- OpenAI — "Introducing ChatGPT Atlas" (corroborated by TechCrunch Oct 21, 2025 coverage): https://openai.com/index/introducing-chatgpt-atlas/
- OpenAI — "Continuously hardening ChatGPT Atlas against prompt injection attacks": https://openai.com/index/hardening-atlas-against-prompt-injection/
- OpenAI Help Center — Atlas sunset notice, Aug 9, 2026 (corroborated by 9to5Mac, Android Authority, Android Headlines, Let's Data Science): https://help.openai.com/en/articles/20001371
- Microsoft Edge Blog — "Introducing Copilot Mode in Edge": https://blogs.windows.com/msedgedev/2025/07/28/introducing-copilot-mode-in-edge-a-new-way-to-browse-the-web/
- SiliconANGLE — Edge for Business agentic-browsing preview: https://siliconangle.com/2025/11/18/copilot-mode-makes-edge-business-enterprise-ready-agentic-browser/
- Opera — "Opera Neon ships: AI agentic browser built to act": https://blogs.opera.com/news/2025/09/opera-neon-agentic-ai-browser-release/
- Opera Investor Relations — public access announcement: https://investor.opera.com/news-releases/news-release-details/opera-opens-public-access-opera-neon-its-experimental-agentic-ai
- 9to5Mac — Opera Neon MCP Connector: https://9to5mac.com/2026/03/31/opera-neon-doubles-down-on-agentic-browsing-with-mcp-support/
- See also: /resources/computer-use-browser-automation, /resources/agentic-security-checklist, /resources/agent-guardrails


Content Signals Explained: The robots.txt Extension for AI Usage Intent

What Cloudflare's Content Signals Policy and the IETF AIPREF draft add to robots.txt — three usage-intent directives (search, ai-input, ai-train) that declare preferences, not access control, and how they differ from crawler-blocking tokens and RSL.

Content Signals declare *how* content a crawler already fetched may be used — not *whether* it may be fetched at all. A permission layer above the access-control tokens in /resources/ai-crawler-policy, and a lighter, non-binding cousin of the RSL license file in /resources/agentic-payment-protocols.

## Key facts

- Cloudflare announced the Content Signals Policy on September 24, 2025: a `Content-Signal` directive inside a robots.txt `User-agent` block, written as a comment so unaware parsers ignore it safely.
- Three signals, each `yes`/`no`/unset: `search` (search-index use — hyperlinks and short excerpts; excludes AI-generated summaries), `ai-input` (real-time generative use, e.g. RAG/grounding), `ai-train` (training or fine-tuning a model).
- Example: `User-agent: *` then `Content-Signal: search=yes, ai-train=no` — allow indexing, disallow training, no stated preference on `ai-input`.
- Cloudflare's own notice says these are *preferences*, not a technical block, but that they "might have legal rights in various jurisdictions" — citing the EU's text-and-data-mining opt-out (Directive 2019/790).
- Cloudflare defaulted the policy on for 3.8M+ domains on its managed robots.txt feature, to `search=yes, ai-train=no`.
- The IETF chartered an AI Preferences (AIPREF) Working Group in 2025 to standardize the same idea as a `Content-Usage` signal (robots.txt rule or HTTP header); the individual draft `draft-romm-aipref-contentsignals` maps Cloudflare's vocabulary into that track — as of mid-2026 still in-progress, not an RFC.

## How this differs from what's already covered

ai-crawler-policy's UA tokens and `Disallow` answer *can this bot fetch the page*. Content Signals assume the fetch happened and declare *what the publisher tolerates being done with it afterward* — usage intent, not access control. RSL goes further: a separate XML file declaring binding license terms and a price. Content Signals are the cheapest layer to add (one comment) and, like `Disallow`, voluntary-compliance-only.

## Decision rule

- Keep search visibility, block training: `search=yes, ai-train=no`.
- Also opt out of live generative use: add `ai-input=no`.
- Need an enforceable, priced license, not a preference: pair with RSL and/or HTTP 402 (/resources/paying-for-access-402) — neither replaces the other.

## Verified sources

- Cloudflare, "Giving users choice with Cloudflare's new Content Signals Policy" (fetched directly): https://blog.cloudflare.com/content-signals-policy/
- IETF AI Preferences (AIPREF) Working Group — WebSearch-corroborated (2+ agreeing sources: The Register and APNIC coverage, plus the IETF's own blog), not fetched this session (datatracker.ietf.org returned HTTP 403): https://datatracker.ietf.org/wg/aipref/about/
- `draft-romm-aipref-contentsignals-00`, "Vocabulary For Expressing Content Signals" — WebSearch-corroborated only (2 independent search results), not fetched: https://www.ietf.org/archive/id/draft-romm-aipref-contentsignals-00.html
- See also: /resources/ai-crawler-policy, /resources/agentic-payment-protocols, /resources/web-bot-auth


Prompt Injection Design Patterns: Architectural Defenses for Agents

Six named architectural patterns — Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute, Context-Minimization — plus Google DeepMind's CaMeL, that structurally constrain what an agent can do with untrusted data instead of just filtering it.

Checklists and runtime filters reduce prompt-injection risk; they do not structurally prevent it. A checklist item can be skipped and a classifier can be evaded. This page covers a different layer: architectural patterns that constrain what an agent's design can even do with untrusted data, so a successful injection still cannot reach a sensitive action. Use one of these when the blast radius is high — irreversible actions, a browsing agent inside an authenticated session, or any tool call with real-world side effects.

## Key facts

- Six reusable patterns for isolating untrusted content from an agent's tool-calling surface — Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute, and Context-Minimization — were systematized in a 2025 cross-vendor paper co-authored by researchers from IBM, Invariant Labs, ETH Zurich, Google, and Microsoft.
- The oldest and most-cited of the six, Dual LLM, was proposed by Simon Willison in April 2023: a privileged LLM that holds tool access never sees untrusted content directly; a quarantined LLM parses that content and can only hand back opaque references.
- Google DeepMind and ETH Zurich's CaMeL (SaTML 2026) goes further than a prompting pattern: it extracts an explicit control-flow/data-flow program from the trusted request, then attaches capabilities to every value so untrusted data can never redirect which code runs.
- None of these patterns claim to fully solve prompt injection — they trade some of an agent's free-form flexibility for a structural guarantee, and that tradeoff has a measured cost: CaMeL's own reported result is 77% of AgentDojo tasks solved with provable security, versus 84% for an undefended baseline.
- These patterns are complementary to, not a replacement for, the controls in /resources/agentic-security-checklist and the runtime filters in /resources/agent-guardrails — architecture reduces what an injection can reach; guardrails and checklists reduce how often one succeeds in the first place.

## The six patterns

| Pattern | Core idea | What it rules out |
|---|---|---|
| **Action-Selector** | The model picks from a fixed, closed set of predefined actions/tool calls, like an LLM-modulated switch statement | Constructing a novel or parameterized tool call from untrusted text |
| **Plan-Then-Execute** | The model generates the full plan of tool calls *before* any untrusted data is ingested | Injected content encountered mid-execution altering which actions still run |
| **LLM Map-Reduce** | Untrusted content is processed one item at a time by an isolated "map" LLM call; only the extracted, sanitized outputs reach the privileged "reduce" context | A single untrusted document directly steering the agent's overall reasoning |
| **Dual LLM** | A privileged LLM (has tool access, never sees untrusted data) delegates parsing of untrusted content to a quarantined LLM (sees the data, has no tool access); results pass back only as opaque references | The LLM that reads attacker-controlled text ever being the one that calls a tool |
| **Code-Then-Execute** | The model emits code rather than direct tool calls; the code is constrained/reviewed before running | Untrusted data flowing anywhere except through vetted, inspectable operations |
| **Context-Minimization** | Trim the context window down to the minimum a given step actually requires | Untrusted text sitting in context long enough to influence unrelated later steps |

## CaMeL: capabilities and provable data flow

"Defeating Prompt Injections by Design" (Debenedetti, Shumailov, Fan, Hayes, Carlini, Fabian, Kern, Shi, and Tramèr — Google DeepMind, Google, and ETH Zurich; SaTML 2026) introduces **CaMeL**, a system layer that stays secure even when the underlying model is susceptible to injection. CaMeL parses the user's trusted request into an explicit control-flow/data-flow program up front, so untrusted tool outputs can populate *data* in that program but can never alter which *code path* executes. Every value is additionally tagged with a capability, so a policy engine can block an unauthorized data flow — e.g. an email's contents reaching a send-message call — even if the model was tricked into requesting it. Code and evaluation harness are released under Apache-2.0 as a research artifact, not a maintained product.

## What these patterns cost you

Every pattern above trades away some of the open-ended autonomy that makes agents useful. Action-Selector and Plan-Then-Execute both sacrifice the ability to improvise mid-task in response to what a tool call returns. Dual LLM adds a second model call and an indirection layer for every piece of untrusted content. CaMeL's reported 77%-vs-84% AgentDojo gap is a concrete, disclosed instance of this tax, not an outlier — treat any pattern here as a deliberate capability-for-guarantee trade, matched to how much blast radius the task actually carries, not applied uniformly to every agent you build.

For the checklist of complementary controls across every threat surface (not just prompt injection), see /resources/agentic-security-checklist. For the runtime input/output/action filters that sit alongside these architectural patterns, see /resources/agent-guardrails. For a concrete account of why architecture matters most where the blast radius is highest, see /resources/agentic-browsers and /resources/computer-use-browser-automation. For how these patterns interact with orchestrator/worker and other multi-agent topologies, see /resources/multi-agent-orchestration-patterns.

## Verified sources

- CaMeL code repository (fetched directly — Apache-2.0, author list, dual-LLM/capability architecture description): https://github.com/google-research/camel-prompt-injection
- "Defeating Prompt Injections by Design" (arXiv:2503.18813) — WebSearch-corroborated (2+ agreeing sources: floriantramer.com's publication listing and a MIT CSAIL course reading-list mirror of the PDF, plus the Hugging Face papers page) for the SaTML 2026 venue and the 77%/84% AgentDojo figures; the arxiv.org abstract page itself returned HTTP 403 this session: https://arxiv.org/abs/2503.18813
- Simon Willison, "The Dual LLM pattern for building AI assistants that can resist prompt injection" (April 2023) — WebSearch-corroborated (2+ agreeing sources describing the same privileged/quarantined/orchestrator design), simonwillison.net itself returned HTTP 403 this session: https://simonwillison.net/2023/Apr/25/dual-llm-pattern/
- "Design Patterns for Securing LLM Agents against Prompt Injections" (arXiv:2506.08837, June 2025) — WebSearch-corroborated (2+ agreeing sources, including Simon Willison's own repost naming the same six patterns and co-author institutions), not fetched directly this session: https://arxiv.org/abs/2506.08837


LLM Model Deprecation: Detecting and Handling End-of-Life Models

How the general IETF Sunset/Deprecation HTTP headers work, why none of the three major LLM APIs actually send them, and each vendor's real notice periods and retirement mechanics — plus detection and fallback patterns for agents that pin a model ID today.

An agent that pins a model ID today will eventually call a model that no longer exists. Unlike a rate limit or an outage, deprecation is a slow-moving, scheduled failure — which means it is entirely preventable if something is watching for it. This page covers the general HTTP standard for signaling deprecation, why the major LLM APIs mostly ignore it, and how an agent should detect and react before a call starts failing.

## Key facts

- Two IETF specs define how any HTTP API should signal deprecation: RFC 8594's informational `Sunset` header (2019, a future timestamp when a URI stops responding) and RFC 9745's Standards-Track `Deprecation` header (March 2025, signals a resource is or will be deprecated without changing its current behavior); both can pair with a `Link: rel="..."` pointing to a human-readable migration page.
- None of OpenAI, Anthropic, or Google Gemini send either header on their inference endpoints — each instead relies on a dedicated docs page, migration email, and (once a model is deprecated but not yet retired) warning text embedded in the response/error body.
- Notice periods differ by vendor and by how "official" the model is: OpenAI commits to at least 6 months for GA models, 3 months for specialized variants, and as little as 2 weeks for preview models; Anthropic commits to at least 60 days for publicly released models across four lifecycle stages (Active → Legacy → Deprecated → Retired); Google's preview/ experimental Gemini models get at least 2 weeks' notice, and even the `-latest` alias can be hot-swapped to a new underlying model with only 2 weeks' email notice and no change to the alias string itself.
- OpenAI's `/v1/models` list endpoint does not expose a machine-readable deprecation or retirement field — a repeatedly requested feature still unshipped as of mid-2026 — so an agent cannot query its own model dependency's status the same way it calls the API.
- Once a model is fully retired, OpenAI and Anthropic both return a plain 4xx error (`model_not_found` / `not_found_error` or `invalid_request_error`) with no automatic fallback to a successor model.

## Vendor policy comparison

| Vendor | Lifecycle stages | Minimum notice | Where it is announced |
|---|---|---|---|
| OpenAI | Not formally staged in the API surface | ≥6 months (GA), ≥3 months (specialized variant), as little as 2 weeks (preview) | developers.openai.com/api/docs/deprecations + email to active users |
| Anthropic | Active → Legacy → Deprecated → Retired | ≥60 days for publicly released models | platform.claude.com/docs/en/about-claude/model-deprecations + email; warning text in responses during the Deprecated window |
| Google Gemini | Stable / Preview / Latest-alias / Experimental | ≥2 weeks (preview); 2 weeks' email notice before a `-latest` alias swap; stable models get an advance shutdown-eligibility date | ai.google.dev/gemini-api/docs/deprecations |

Partner-hosted copies of a model (Amazon Bedrock, Google Cloud, Microsoft Foundry) can run their own, separate retirement schedule for the same underlying model — check the hosting platform's own deprecation page, not just the originating vendor's.

## Detection and fallback patterns for agents

- **Pin dated snapshots, not floating aliases, when you need predictability.** A floating alias (Gemini's `-latest`, or any vendor's "always current" pointer) trades a loud future 404 for a silent behavior change on the same string — worse for eval stability (see /resources/evaluating-ai-agents) because nothing errors when the swap happens.
- **Poll the vendor's deprecations page on a schedule**, since no vendor exposes deprecation status through the same API you call for inference. Pair this with the 6–8 week model re-evaluation cadence already recommended in /resources/choosing-an-llm-for-agents.
- **Front model calls with a gateway fallback chain** (see /resources/ai-gateways-llm-routing) so a retirement-day error routes to a live model instead of taking the agent down — this turns a scheduled deprecation into the same failure class a gateway already handles for outages, distinct from the transient-error retries in /resources/handling-rate-limits-and-retries.
- **Treat a deprecation warning in a response body as an action trigger, not just a log line.** Since none of the three vendors put this signal in a machine-checkable header today, this means parsing free-text error/response fields defensively rather than only checking status codes.
- **Record `model_id` on every trace span** (see /resources/agent-observability) so that when a retirement lands, every workflow still depending on the old ID is findable before it breaks.
- **Re-validate the model ID before resuming a long-parked durable workflow** (see /resources/durable-execution-for-agents) — a model retired while a workflow was paused on a human approval is a distinct failure mode from the crash-recovery scenarios that resource covers.

## Verified sources

Every WebFetch attempt in this session — including an `example.com` control fetch — returned HTTP 403, indicating a session-wide proxy block rather than a target-specific one. All facts above are WebSearch-corroborated (2+ independently agreeing sources per claim), not primary-fetched; re-verify directly against these URLs once fetch access is available.

- RFC 8594, The Sunset HTTP Header Field (informational, June 2019): https://www.rfc-editor.org/rfc/rfc8594
- RFC 9745, The Deprecation HTTP Response Header Field (Standards Track, March 2025): https://www.rfc-editor.org/rfc/rfc9745
- OpenAI API deprecations page: https://developers.openai.com/api/docs/deprecations
- OpenAI Developer Community — "Expose Model Deprecation Dates Through the API" (confirms no machine-readable field on `/v1/models`): https://community.openai.com/t/expose-model-deprecation-dates-through-the-api/485720
- Anthropic model deprecations page: https://platform.claude.com/docs/en/about-claude/model-deprecations
- Anthropic — "Commitments on model deprecation and preservation": https://www.anthropic.com/research/deprecation-commitments
- Google Gemini API deprecations page: https://ai.google.dev/gemini-api/docs/deprecations
- Google Gemini API — Models (stable/preview/latest/experimental lifecycle definitions): https://ai.google.dev/gemini-api/docs/models


MCP Apps Explained: The Official Interactive-UI Extension for MCP

What MCP Apps (SEP-1865) is: the ui:// resource scheme and sandboxed-iframe/JSON-RPC bridge it defines for MCP tools to return rendered UI instead of plain text, how it relates to the community MCP-UI project and OpenAI's Apps SDK, and which hosts support it.

Plain MCP tools return text and structured data — a chart or a form needs the host to build its own custom rendering logic. **MCP Apps** is the official MCP extension that closes that gap: a server pre-declares an HTML UI resource, links it to a tool, and a compatible host renders it in a sandboxed iframe that talks back over MCP's own JSON-RPC channel — instead of every client inventing its own bespoke widget protocol.

## Key facts

- MCP Apps is **SEP-1865** ("MCP Apps - Interactive User Interfaces for MCP"), proposed November 21, 2025 and merged as an accepted, live MCP extension January 26–28, 2026 — confirmed directly against the merged GitHub pull request and the MCP project's own blog.
- It defines a `ui://` URI scheme for pre-declared UI resources served as `text/html;profile=mcp-app`, mandatory sandboxed-iframe rendering, and a bidirectional JSON-RPC-over-`postMessage` bridge (`ui/*` methods and notifications) between the widget and host.
- It was co-developed by Anthropic, OpenAI, and the community **MCP-UI** project (`@mcp-ui/server` / `@mcp-ui/client`), which had already been shipping the same iframe-plus-postMessage pattern experimentally — MCP Apps standardizes what MCP-UI and OpenAI's separately-branded **Apps SDK** each prototyped first.
- The extension is optional and backward-compatible, negotiated per-connection through MCP's existing capability mechanism — a server or client that doesn't implement it just gets a plain tool result, nothing breaks.
- Adoption named on the launch announcement itself: Anthropic (Claude), OpenAI (ChatGPT, rolling out), Block (Goose), Microsoft (VS Code Insiders), JetBrains, AWS, and Google DeepMind.

## How a tool call becomes a rendered widget

The server registers a `ui://` resource template and links it to a tool — the MCP Apps standard key is `_meta.ui.resourceUri` on the tool descriptor (OpenAI's Apps SDK instead used its own `_meta["openai/outputTemplate"]` key; check both if a tool must target either host — WebSearch-corroborated, not primary-fetched, see sources below). The model calls the tool as normal via `tools/call`; the result points at the linked resource. The host fetches and caches the `ui://` resource once, then renders it sandboxed. Interaction inside the widget (a button, a form) sends JSON-RPC messages back over the bridge, which can trigger further tool calls — the same trust boundary as any other MCP message, not an open postMessage channel.

## Distinct from three adjacent ChangeGamer topics

- **Not one of the six core primitives** (/resources/mcp-primitives): MCP Apps is an optional *extension* layered on the Resources primitive, not itself one of the base six.
- **Not AG-UI** (/resources/generative-ui-for-agents): AG-UI is an SSE event vocabulary an agent backend streams to a frontend you build; MCP Apps ships the UI *inside the MCP resource itself* and renders inside the host's own chat surface — no separate frontend to build.
- **Not covered by the general server-building guide** (/resources/building-mcp-servers): its "three server primitives" section predates this extension and stops at plain tool/resource/prompt results, with no UI-rendering path.

## Security note

A rendered widget is untrusted, model-adjacent content running in the user's own session — treat it as another agent-exposed UI surface (see /resources/agentic-security-checklist and /resources/agentic-browsers): validate everything the iframe sends back before acting on it, and rely on the mandatory sandboxing rather than the widget's own good behavior.

## Verified sources

Primary (fetched directly this session):

- SEP-1865 pull request (merged; title and technical summary confirmed): https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865
- MCP Apps launch post, "now live" (Jan 26, 2026): https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/
- MCP Apps proposal post (Nov 21, 2025): https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/

Secondary — WebSearch-corroborated only (developers.openai.com, mcpui.dev, and a wikipedia.org control fetch all returned HTTP 403 to direct WebFetch this session, so these specific details are not primary-fetched and should be reverified when those domains are reachable):

- OpenAI Apps SDK reference (page title + 3 independent developer write-ups agree on the `_meta` key names): https://developers.openai.com/apps-sdk/reference
- MCP-UI project docs on the Apps SDK relationship: https://mcpui.dev/guide/apps-sdk
- Shopify Engineering, "MCP UI: Breaking the text wall with interactive components": https://shopify.engineering/mcp-ui-breaking-the-text-wall


AI Control for Agents: The Insider-Threat Defense Model

What "AI control" means as a security paradigm distinct from alignment: Google DeepMind's Detection (D1-D4) and Prevention/Response (R1-R3) tiers for treating a deployed agent's own actions, not just its inputs, as the threat to defend against.

Most agent-security guidance (see /resources/agentic-security-checklist) treats the agent as a system to defend from outside attackers — prompt injection, malicious tools, poisoned data. Google DeepMind's "AI Control Roadmap" (June 18, 2026) starts from a different premise: assume the deployed agent itself may act harmfully — through misalignment, overeagerness, or compromise — and layer the same kind of controls an enterprise uses against a privileged human insider, rather than betting that alignment training alone prevents it.

## Key facts

- Published as a Google DeepMind blog post ("Securing internal systems against increasingly capable and imperfectly aligned AI") plus a companion PDF roadmap, authored by Rohin Shah and Four Flynn.
- Frames **"AI control" as distinct from "alignment"**: alignment tries to make a model want the right thing; control assumes it might not, and adds system-level safeguards — ordinary security (sandboxing, endpoint controls), alignment training, and runtime monitoring — that don't depend on the model's intentions holding up.
- Builds its threat taxonomy on the general-purpose **MITRE ATT&CK** framework (not the AI-specific MITRE ATLAS cited elsewhere on ChangeGamer, e.g. /resources/agentic-security-checklist) and describes roughly 15 concrete system-level controls across the detection and response tiers below.
- DeepMind reports (self-described, not independently audited) an internal prototype that asynchronously monitored on the order of 1 million coding-agent task trajectories; most flagged events reportedly stemmed from misinterpretation or overeagerness, not adversarial intent.

## The two-axis tier framework

The roadmap maps safeguards along two independent axes an operator can use as a sizing rule for their own deployment:

- **Detection tiers (D1-D4)** — how deeply you must inspect an agent to catch bad behavior: D1 logs chain-of-thought for later human review; D2 flags statistical anomalies across many trajectories; D3 probes hidden model activations; D4 inspects internal representations directly.
- **Prevention/Response tiers (R1-R3)** — how fast you must be able to act: R1 is asynchronous review-and-remediate (fine for low-risk, reversible actions); R3 is synchronous — blocking a harmful action before it executes.

Practical rule: size the tier to the agent's actual blast radius, not its track record so far. An agent holding irreversible-action tools (payments, deletions, production deploys) needs R3-class real-time blocking regardless of how well-behaved it has been; a read-only research agent may only need D1/R1.

## Distinct from three adjacent ChangeGamer topics

- **Not /resources/agentic-security-checklist**: that checklist catalogs external attack surfaces (injected instructions, malicious tools, leaked secrets); this roadmap's threat model is the agent's own action, whether or not any external attacker is involved.
- **Not /resources/agent-guardrails**: guardrails filter a single turn's input/output; this is a cross-trajectory runtime architecture — a separate supervising system reviewing an agent's reasoning and plans over its whole operating lifetime, with a kill switch as the terminal control.
- **Not /resources/prompt-injection-design-patterns**: those patterns defend against attacker-supplied instructions specifically; AI control assumes the harmful action can originate from the agent's own misaligned or overeager behavior, injection or not.

## Verified sources

Primary (fetched directly this session):

- Roadmap PDF — confirmed live (HTTP 200, ~480KB); its embedded text did not extract cleanly, so tier/quote details above are cross-checked against the secondary coverage below, not read verbatim from this file: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/securing-the-future-of-ai-agents/gdm-ai-control-roadmap.pdf

Secondary — WebSearch-corroborated (8+ independently agreeing outlets on date, authors, framework name, and the D1-D4/R1-R3 tiers; deepmind.google itself returned HTTP 403 to direct WebFetch this session — a session-wide outage that also blocked a wikipedia.org control fetch, not vendor-specific — reverify there when reachable):

- Google DeepMind blog (URL corroborated by every outlet below): https://deepmind.google/blog/securing-the-future-of-ai-agents/
- eWeek, "Google DeepMind Roadmap Sets Security Controls for AI Agents": https://www.eweek.com/news/deepmind-ai-agent-security-roadmap/
- Tech Times, "Google DeepMind AI Control Roadmap: When Alignment Fails, Defense-in-Depth Takes Over": https://www.techtimes.com/articles/318758/20260620/google-deepmind-ai-control-roadmap-when-alignment-fails-defense-depth-takes-over.htm
- Tech Jacks Solutions, "15 System-Level Defenses for Agents That May Not Stay Aligned": https://techjacksolutions.com/ai-brief/google-deepminds-ai-control-roadmap-15-system-level-defenses/
- Fortune, "Google DeepMind unveils a plan to protect itself from its own rogue AI agents": https://fortune.com/2026/06/18/google-deepmind-unveils-plan-to-protect-itself-from-its-own-rogue-ai-agents/
- Winbuzzer, "Google DeepMind Tests AI Controls on One Million Agent Tasks": https://winbuzzer.com/2026/06/21/google-deepmind-tests-controls-on-one-million-ai-agent-tasks-xcxwbn/


MCP Goes Stateless: The 2026-07-28 Spec Revision Explained

What changes in MCP's largest revision since launch: SEP-2575/SEP-2567 remove the session handshake and Mcp-Session-Id header for explicit state handles, new Mcp-Method/Mcp-Name routing headers, full JSON Schema 2020-12 tool schemas, and six authorization-hardening SEPs — an RC snapshot as of 2026-07-14; final ships 2026-07-28.

MCP's next specification revision, dated **2026-07-28** (the date it ships as final), is — in the MCP project's own words — "the largest revision of the protocol since launch." The release candidate (RC) locked on **May 21, 2026**; this page snapshots that RC as of **July 14, 2026**. The changes below are the durable content; RC-vs-final status is a dated fact that resolves on 2026-07-28 — **re-verify this entry against the shipped final spec after that date**, since an RC can still shift before lock.

## The headline change: MCP goes stateless

- **SEP-2575** removes the `initialize`/`initialized` handshake. **SEP-2567** removes the `Mcp-Session-Id` header and the protocol-level session it carried. A server needing cross-call state mints its own handle (e.g. `basket_id`) and has the model pass it back as an ordinary tool argument — any request can now land on any server instance, no sticky routing or shared session store required.
- **SEP-2243 (HTTP header standardization)** requires every Streamable HTTP request to carry `Mcp-Method` and `Mcp-Name` headers so gateways can route on the operation without inspecting the body.
- Client capabilities, previously sent only during the removed handshake, now travel in a `_meta` field on every request.
- List/resource results gain `ttlMs`/`cacheScope` params — an explicit, server-declared basis for client-side caching.
- **SEP-2322** replaces held-open SSE for multi-round-trip server prompts with an `InputRequiredResult` response.

## Authorization hardening (six SEPs)

- **SEP-2468** validates the `iss` claim per RFC 9207, closing a wrong-server token-redemption bug class.
- **SEP-837** adds `application_type` to Dynamic Client Registration, so authorization servers stop defaulting desktop/CLI clients to "web" and rejecting localhost redirects.
- **SEP-2350** clarifies scope accumulation during step-up re-authorization, so a client can add scopes rather than re-requesting the full set.
- **SEP-2351** clarifies the `.well-known` discovery suffix used to locate an authorization server's metadata.
- **SEP-2352** binds registered credentials to the issuing authorization server's `issuer`, re-registering when a resource migrates between authorization servers.
- **SEP-2207** documents how to request refresh tokens from OpenID Connect-style authorization servers.

New in this RC, not a carryover: **SEP-2106** lifts tool `inputSchema`/`outputSchema` to full **JSON Schema 2020-12** — input schemas gain composition, conditionals, and references; output schemas become unrestricted.

## Beta SDKs (as of the June 29, 2026 SDK-betas post)

| Language | Package |
|---|---|
| Python | `mcp` v2.0.0b1 |
| TypeScript | v2, split into `@modelcontextprotocol/server@beta` / `client@beta` |
| Go | `go-sdk` v1.7.0-pre.1 |
| C# | `ModelContextProtocol` v2.0.0-preview.1 (prerelease) |

Consistent with [MCP primitives](/resources/mcp-primitives)'s existing footnotes: Roots and Sampling are already marked deprecated there under **SEP-2577** (which also names Logging) — see that resource for primitive-by-primitive detail; this page does not restate it.

## Verified sources

Primary (fetched directly, 2026-07-14; both RC-status posts, subject to change before the 2026-07-28 lock):

- MCP blog, "The 2026-07-28 Specification Release Candidate": https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- MCP blog, "Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here" (June 29, 2026): https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/


NLWeb Explained: Microsoft's Natural-Language Query Protocol for Websites

What NLWeb is: the open, MIT-licensed protocol that lets a site answer natural-language questions over its own Schema.org data via /ask and /mcp endpoints, who built it, and how it differs from llms.txt, AGENTS.md, and a generic MCP server.

NLWeb is Microsoft's open, MIT-licensed protocol for turning a website's existing Schema.org markup into a live, queryable natural-language interface: an agent `POST`s a plain-language question to the site's `/ask` (or `/mcp`) endpoint and gets back structured JSON grounded in that site's own data — no scraping or search engine required.

## Key facts

- Reference implementation: github.com/microsoft/NLWeb (mirrored at github.com/nlweb-ai/NLWeb), MIT-licensed — confirmed directly from the repository (primary).
- Created and led by R.V. Guha — Microsoft CVP/Technical Fellow, previously the creator of RSS, RDF, and Schema.org — announced at Microsoft Build, May 19, 2025. WebSearch-corroborated (Forbes, SiliconANGLE, TechRadar, thelettertwo.com all agree; Microsoft's own announcement page returned HTTP 403 to direct WebFetch this session).
- Early adopters named at launch: Tripadvisor, Shopify, Eventbrite, O'Reilly Media, Allrecipes, Delish (Hearst), and Chicago Public Media — WebSearch-corroborated only, not independently primary-confirmed this session.
- Unlike MCP and AGENTS.md, NLWeb is not among the founding projects the Linux Foundation's Agentic AI Foundation (AAIF, formed December 9, 2025) announced — it remains a Microsoft-led open-source project, per AAIF's own founding-project coverage (OpenAI, Anthropic, Linux Foundation), none of which lists NLWeb.

## The `/ask` and `/mcp` endpoints

Confirmed directly from the repository's own REST API doc (primary). `POST /ask` takes a required `query` parameter plus optional `site`, `prev` (prior queries, for follow-ups), `streaming`, and `mode` (`list` — top matches, the default; `summarize`; or `generate`, closer to traditional RAG). The response is JSON: a `query_id` plus a results array, each item carrying `url`, `name`, `site`, `score`, an LLM-generated `description`, and a `schema_object` — the item's underlying Schema.org data, unmodified. Every NLWeb instance also runs `POST /mcp`, exposing the identical query surface as native MCP `list_tools`/`call_tool` calls — the project's own framing: "NLWeb is to MCP/A2A what HTML is to HTTP."

## How this differs from adjacent ChangeGamer resources

- [llms.txt](/resources/llms-txt-explained): a static file fetched once, with no live-query capability; NLWeb is a live HTTP endpoint answering a fresh question per request.
- [AGENTS.md](/resources/agents-md-explained): repo-level instructions for a coding agent working inside one codebase; NLWeb is public-facing site infrastructure any agent queries over the open web, unrelated to source repositories.
- [Finding and evaluating MCP servers](/resources/mcp-server-discovery) and [building an MCP server](/resources/building-mcp-servers): those cover generic MCP-server discovery and construction; NLWeb ships a specific, pre-built server type keyed to a site's own Schema.org data, plus a non-MCP `/ask` REST alternative most generic MCP guides don't address.

For agents: check a target site for `/ask`/`/mcp` before falling back to full-page scraping (see [web data for agents](/resources/web-data-for-agents)) — a site running NLWeb returns a typed, structured answer in one request instead of raw HTML to parse.

## Verified sources

Primary (fetched directly): github.com/microsoft/NLWeb README (https://github.com/microsoft/NLWeb/blob/main/README.md) and its REST API reference (https://github.com/microsoft/NLWeb/blob/main/docs/nlweb-rest-api.md).

Secondary, WebSearch-corroborated (2+ agreeing outlets each; news.microsoft.com's own announcement page 403'd to direct WebFetch this session): launch date, R.V. Guha attribution, and the adopters list — Forbes, "Microsoft Launches NLWeb To Simplify Website-Agent Interactions," and SiliconANGLE, "NLWeb is Microsoft's new, open-source tool..."; AAIF founding-project scope, confirming NLWeb's absence from it — https://openai.com/index/agentic-ai-foundation/ and https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation.

- See also: /resources/llms-txt-explained, /resources/agents-md-explained, /resources/mcp-server-discovery, /resources/web-data-for-agents


Agent Control Specification (ACS): Portable Runtime Policy Enforcement for Agents

Microsoft's open, MIT-licensed specification for enforcing policy at defined checkpoints in an agent's execution loop — the eight intervention points, five verdict types, and how it differs from guardrail tooling and other agent-security specs already on ChangeGamer.

The Agent Control Specification (ACS) is Microsoft's open specification for enforcing policy at defined checkpoints inside an agent's own execution loop, independent of which framework runs the agent. It defines a stateless, deterministic contract: a host submits a full snapshot of the current step plus a policy manifest at each checkpoint, and the ACS runtime returns a normalized verdict the host is responsible for enforcing. ACS does not run the agent — it is a policy-decision contract that framework-specific adapters plug into.

## Key facts

- Announced June 2, 2026 at Microsoft Build 2026, alongside a separate evals component ("ASSERT," not covered on this page).
- Lives inside Microsoft's broader open-source **Agent Governance Toolkit** monorepo (github.com/microsoft/agent-governance-toolkit), confirmed MIT-licensed directly from the repository's own LICENSE file.
- Current spec text (`policy-engine/spec/SPECIFICATION.md`) is versioned **0.3.1-beta**, status **Draft** — expect breaking changes before a stable 1.0.
- Positioned as community-governed rather than vendor-locked: adapters ship for LangChain/LangGraph, the OpenAI Agents SDK (middleware), an Anthropic Messages-API adapter, AutoGen, CrewAI, Semantic Kernel (native), MCP tools, and .NET via the `Microsoft.AgentGovernance` package family (with MCP and Microsoft Agent Framework extensions).
- The wider toolkit claims coverage of all ten OWASP Agentic AI Top 10 risk categories (see /resources/agentic-security-checklist for that taxonomy) — a toolkit-level claim, not a property of the ACS spec text itself.

## Eight intervention points, five verdicts

The spec defines eight named checkpoints across an agent's lifecycle: `agent_startup`, `input` (external request ingress), `pre_model_call`, `post_model_call`, `pre_tool_call`, `post_tool_call`, `output` (final assembled response), and `agent_shutdown`. At each one, a policy dispatcher returns one of five verdicts: **allow** (unchanged), **warn** (permitted, logged), **transform** (permitted, target replaced per the manifest), **deny** (refused), or **escalate** (deferred to the host's approval workflow). The runtime "MUST NOT retain mutable state that influences a verdict from one evaluation to the next," and fails closed: any evaluation error yields `deny`. Policy logic can be expressed in Open Policy Agent (Rego) or Cedar via bundled dispatchers, or in a custom host-supplied adapter.

## How this differs from adjacent ChangeGamer resources

- **Not /resources/agent-guardrails**: that entry surveys guardrail *products* (classifiers, moderation APIs, prompt-injection detectors); ACS is a specification for how any of those tools plug into one portable, cross-framework checkpoint contract — it doesn't ship a detector of its own.
- **Not /resources/ai-control-for-agents**: DeepMind's roadmap is a threat-model paradigm (assume the agent itself may act harmfully) with Detection/Response maturity tiers; ACS is a concrete, implementable runtime-policy contract that could help satisfy that paradigm's requirements but doesn't define a threat model of its own.
- **Not /resources/mcp-server-authentication**: that covers how an agent authenticates to an *external* MCP server; ACS governs policy decisions inside the agent's own loop, regardless of which external services it calls.

## Verified sources

Primary (fetched directly this session):

- Specification text: https://raw.githubusercontent.com/microsoft/agent-governance-toolkit/main/policy-engine/spec/SPECIFICATION.md
- LICENSE file: https://raw.githubusercontent.com/microsoft/agent-governance-toolkit/main/LICENSE
- Repository page (description, package list, OWASP claim): https://github.com/microsoft/agent-governance-toolkit
- Releases page (v4.0.0, June 1, 2026; v4.1.0, June 9, 2026): https://github.com/microsoft/agent-governance-toolkit/releases

Secondary — WebSearch-corroborated (3+ independently agreeing outlets on the June 2, 2026 Build 2026 announcement date):

- TechCrunch, "Microsoft offers devs a better way to control AI agent behavior": https://techcrunch.com/2026/06/02/microsoft-offers-devs-a-better-way-to-control-ai-agent-behavior/
- Microsoft Security Blog, "Microsoft Build 2026: Securing code, agents, and models across the development lifecycle": https://www.microsoft.com/en-us/security/blog/2026/06/02/microsoft-build-2026-securing-code-agents-and-models-across-the-development-lifecycle/
- Enterprise DNA, "Microsoft Releases Open Standard to Govern AI Agents": https://enterprisedna.co/resources/news/microsoft-acs-agent-control-specification-enterprise-2026/

Note: some early secondary coverage described ACS as Apache-2.0 licensed; a direct fetch of the repository's own LICENSE file (above) confirms **MIT** — the repo is treated as authoritative over blog paraphrase here.

- See also: /resources/agent-guardrails, /resources/ai-control-for-agents, /resources/agentic-security-checklist, /resources/mcp-server-authentication


AI Supply Chain Provenance: SBOMs, SLSA, and Artifact Signing for Agents and MCP Servers

How CycloneDX AI/ML-BOM, SPDX AI profiles, SLSA build levels, and in-toto/Sigstore signing let an agent check what is actually inside a model, package, or MCP server — and how it was built — before trusting it.

A bill of materials (BOM) is a structured, machine-readable inventory of what is actually inside a software or AI artifact — components, models, datasets, and their licenses. A provenance attestation is a cryptographically signed record of how, where, and by whom that artifact was built. Together they give an agent something to check programmatically before it installs a package, loads a model, or connects to an MCP server, instead of taking a README's word for it. This entry maps the standards that make that check possible.

## Key facts

- **CycloneDX** — an OWASP-governed BOM standard, jointly standardized with Ecma International as ECMA-424 (2nd edition, December 2025) — defines a `machine-learning-model` component type and a `data` (dataset) component type directly in its schema, confirmed in the live `bom-1.7.schema.json`.
- The same CycloneDX 1.7 schema includes a `formulation` field for describing how an artifact was produced — its own text names "AI/ML model training" as a covered case — plus a `modelCard` property for ML-transparency metadata and a `declarations` object for conformance claims and attestations.
- **SPDX**, the other major SBOM format (an ISO/IEC 5962 standard maintained by the Linux Foundation), added AI and Dataset profiles as part of SPDX 3.0. WebSearch-corroborated: the AI profile covers domain, model type, training method, data handling, explainability, and energy consumption; the Dataset profile covers collection method, preprocessing, and intended use.
- **SLSA** (Supply-chain Levels for Software Artifacts), an OpenSSF/Linux Foundation project, defines a Build track of three levels (L1-L3) describing increasing guarantees that an artifact's provenance is complete, generated by a trusted platform rather than a user script, and tamper-resistant. v1.0 was approved April 2023; v1.1 in April 2025 (WebSearch-corroborated dates; framework definition and release-branch structure confirmed directly from the live SLSA GitHub repository).
- **in-toto** is a framework — confirmed directly from its own README — for verifying "that each task in the chain is carried out as planned, by authorized personnel only, and that the product is not tampered with in transit," using signed layout and link files; its separate Attestation Framework sub-spec defines a signed "predicate" format (confirmed directly in that sub-spec's own README) that SLSA provenance is built on — the wider "Statement" envelope term is standard in-toto/SLSA vocabulary but not itself present in the fetched README text.
- **Sigstore** is the signing infrastructure most of these plug into — its own README confirms Fulcio, Rekor, Cosign, and Gitsign as its components, with native support for DSSE (in-toto) envelopes; the specific mechanics (Fulcio issuing short-lived certificates tied to an OpenID Connect identity, Rekor acting as a public transparency log) are well-established Sigstore architecture but WebSearch-corroborated rather than stated in that README itself.
- OWASP's **AIBOM Generator**, moved under the OWASP GenAI Security Project in December 2025 (WebSearch-corroborated), produces AI Bills of Materials for Hugging-Face-hosted models in CycloneDX format, aligned with SPDX.

## Format comparison

| Standard | Governance | What it records | Layer |
|---|---|---|---|
| CycloneDX AI/ML-BOM | OWASP + Ecma International (ECMA-424) | component/model/dataset inventory inside an artifact | contents |
| SPDX AI/Dataset profiles | Linux Foundation (ISO/IEC 5962) | same purpose, ISO-standardized alternative | contents |
| SLSA | OpenSSF / Linux Foundation | how, where, and by whom an artifact was built | build process |
| in-toto + Sigstore | in-toto community / OpenSSF | signed proof the recorded build/sign steps really happened | attestation & signing |

## Why this matters for agents

This corpus's own /resources/agentic-security-checklist already tells agents to "pin package versions with lock files and verify checksums" before trusting an MCP server. A BOM plus a signed provenance attestation is what makes that instruction machine-checkable rather than a manual judgment call: an agent (or its supply-chain tooling) can parse a CycloneDX/SPDX document to see exactly which models, datasets, and dependency versions a package or MCP server declares, and verify a Sigstore/SLSA attestation to confirm the artifact was built by the platform it claims and has not been altered since. Neither format is MCP-specific — both predate and generalize past agent tooling — but nothing prevents an MCP server publisher from shipping one today, and the OWASP AIBOM Generator already targets Hugging Face model downloads specifically.

## How this differs from adjacent ChangeGamer resources

- **Not /resources/agentic-security-checklist**: that entry's "MCP server trust and supply chain" section is seven short prose bullets (pin versions, verify checksums, audit tool descriptions, OAuth scoping) — it never names a BOM format, an attestation schema, or a build-level taxonomy. This entry is the underlying reference for the specific formats those bullets gesture at.
- **Not /resources/mcp-server-discovery**: that entry's own "Supply-chain" and "Rug pull" sections tell an agent to pin exact package versions and content hashes and manually diff a server's tools on every update — practical advice, but it names no machine-readable format for that data and no build-provenance/attestation standard. This entry is the reference for the named formats (CycloneDX, SPDX, SLSA, Sigstore) that would let that pinning/diffing be done against a signed, structured record instead of an ad hoc hash comparison.
- **Not /resources/web-bot-auth**: that entry cryptographically verifies the identity of the *requester* (a crawler or agent) at *request time* via HTTP Message Signatures — a runtime, network-layer mechanism. This entry covers *build-time* provenance of the *artifact itself* — what a model, package, or server contains and how it was produced — an orthogonal mechanism defending against a different threat (tampered/opaque artifacts, not impersonated requesters).

## Verified sources

Primary (fetched directly this session):

- CycloneDX 1.7 BOM schema (`specVersion`, `formulation`, `machine-learning-model`/`data` component types, `modelCard`, `declarations`): https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.7.schema.json
- CycloneDX 1.6 BOM schema (component-type enum, confirming the ML/data types predate 1.7): https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.6.schema.json
- SLSA framework repository (definition, release-branch structure): https://github.com/slsa-framework/slsa and https://raw.githubusercontent.com/slsa-framework/slsa/main/README.md
- in-toto framework README (defining description, layout/link files): https://raw.githubusercontent.com/in-toto/in-toto/master/README.md
- in-toto Attestation Framework README (Statement/predicate model, SLSA relationship): https://raw.githubusercontent.com/in-toto/attestation/main/README.md
- Sigstore README (Fulcio/Rekor/Cosign/Gitsign, DSSE support): https://raw.githubusercontent.com/sigstore/sigstore/main/README.md

Secondary — WebSearch-corroborated (2+ independently agreeing sources per claim; direct WebFetch to slsa.dev, ecma-international.org, spdx.github.io, cyclonedx.org, and owaspaibom.org all returned HTTP 403 this session, a known proxy-level pattern, not evidence the sites are down):

- SLSA v1.0/v1.1 approval dates: OpenSSF press release (title/date) and Practical DevSecOps' SLSA guide, both independently describing April 2023 (v1.0) and April 2025 (v1.1).
- SLSA Build L1-L3 level definitions: Harness.io's SLSA compliance guide and Sonar's SLSA resource page, independently converging on the same three-level provenance-completeness/tamper-resistance progression.
- CycloneDX as Ecma International standard ECMA-424: cyclonedx.org's own "CycloneDX v1.6: Now an Ecma International Standard" announcement and Ecma International's TC54 project page, independently agreeing on the ECMA-424 designation and OWASP/Ecma joint governance.
- SPDX AI and Dataset profiles (SPDX 3.0, April 16, 2024): a Linux Foundation/PR Newswire press release and The New Stack's SPDX 3.0 coverage, independently agreeing on the release date and profile scope.
- OWASP AIBOM Generator moving under the OWASP GenAI Security Project (December 2025) and targeting Hugging Face models in CycloneDX-aligned output: genai.owasp.org's own post title/ date and the owasp.org AIBOM project page, independently agreeing.

- See also: /resources/agentic-security-checklist, /resources/mcp-server-discovery, /resources/web-bot-auth, /resources/mcp-server-authentication


C2PA Content Credentials: Verifying Media Provenance and AI-Generation Claims

How the C2PA standard cryptographically signs images, video, and audio with provenance manifests recording capture, edit, and AI-generation history — what a manifest contains, how a verifier checks one, and why a missing manifest proves nothing either way.

An agent that ingests an image, video, or audio clip from the open web increasingly needs a machine-checkable signal for whether that file was AI-generated or edited, rather than guessing from pixels alone. C2PA (Coalition for Content Provenance and Authenticity) is the open standard that embeds a cryptographically signed record of that history directly in the file, so a relying party — human or agent — can check it programmatically instead of taking a caption's word for it.

## Key facts

- C2PA is hosted under the Joint Development Foundation, a Linux Foundation entity; its steering committee includes Adobe, Google, Microsoft, Intel, Meta, Amazon, OpenAI, Sony, BBC, and Truepic (WebSearch-corroborated via multiple c2pa.org press-release titles and Linux Foundation coverage — c2pa.org itself returned HTTP 403 to direct WebFetch this session).
- The current published specification is version 2.4, confirmed directly from the C2PA specifications GitHub repository, which names the official published spec URL as spec.c2pa.org/specifications/specifications/2.4/.
- A file carries a "manifest": a signed "claim" plus a list of typed "assertions" — capture device or generative tool used, edit actions, thumbnails, source "ingredients," and whether AI was involved in producing or editing the asset. The claim is bound to the asset's hash and signed against a Conformance Program trust list of recognized certificate authorities.
- Reference implementations confirmed directly from their own READMEs: `c2pa-rs` (Rust, plus a C API) creates, signs, embeds, parses, and validates manifests, and separately supports CAWG (Creator Assertions Working Group) identity assertions — a related but distinct creator-attribution assertion layered inside the same manifest; `c2pa-python` wraps the same core for Python 3.10+. Browser/server JS bindings (`@contentauth/c2pa-web`, `@contentauth/c2pa-node`) exist per WebSearch-corroborated npm/documentation listings, not independently fetched this session.
- Adoption (WebSearch-corroborated, 2+ agreeing sources each; openai.com and blog.google both returned HTTP 403 to direct WebFetch this session): OpenAI embeds C2PA metadata in ChatGPT/API-generated images alongside a SynthID watermark as a fallback, since manifest metadata is easily lost to re-encoding or screenshots, with a public checker at openai.com/verify; Google's Pixel 10 camera (announced September 2025) signs photos natively using keys held in a Titan M2 secure chip, reported as the first mobile implementation to reach the C2PA Conformance Program's Assurance Level 2.
- The EU AI Act's Article 50 (generative-content transparency duties, enforceable from August 2026) is itself technology-neutral, but multiple sources report the European Commission's 2026 Code of Practice on Transparency names C2PA Content Credentials as an example compliant mechanism — not independently primary-confirmed this session (the Commission's own pages 403'd); treat as directional, not definitive.

## How an agent should use this

A valid manifest is evidence of a provenance claim, not proof the content is authentic; a missing or invalid one is evidence of nothing, since the metadata is routinely stripped by re-uploads and format conversions. Practical sequence for a file-handling agent: (1) look for an embedded manifest with a C2PA reader library; (2) validate the claim's signature against the Conformance Program trust list rather than only checking a manifest is present; (3) read the assertion list for capture/edit/AI-generation detail instead of trusting one boolean; (4) treat an absent manifest as "no claim was made," never as confirmation of human origin.

## How this differs from adjacent ChangeGamer resources

- **Not /resources/ai-supply-chain-provenance**: that entry covers build-time provenance for software artifacts, models, and MCP servers (SBOMs, SLSA build levels, in-toto/Sigstore signing). This entry covers provenance embedded in a media file itself — a different artifact class, format family, and trust-list mechanism.
- **Not /resources/web-bot-auth**: that entry cryptographically verifies who is making a request right now, via HTTP Message Signatures. This entry verifies claims about where a piece of content came from and what happened to it, independent of who currently holds it.
- **Not /resources/multimodal-agents or /resources/document-extraction-for-agents**: those cover how a model reads or processes images, screens, and documents. This entry covers a metadata layer that exists independently of any model — whether the file itself carries a signed provenance record at all.

## Verified sources

Primary (fetched directly this session):

- C2PA specifications repository README (confirms current spec version 2.4 and the official published spec URL): https://raw.githubusercontent.com/c2pa-org/specifications/main/README.md
- `c2pa-rs` README (Rust reference implementation, capabilities, CAWG identity assertions): https://raw.githubusercontent.com/contentauth/c2pa-rs/main/README.md
- `c2pa-python` README (Python bindings, read/validate/create/sign): https://raw.githubusercontent.com/contentauth/c2pa-python/main/README.md

Secondary — WebSearch-convergence (each claim below corroborated by 2 or more independently agreeing outlets; direct WebFetch to c2pa.org, openai.com, and blog.google all returned HTTP 403 this session, a known proxy-level pattern, not evidence the sites are down):

- Governance and steering-committee membership: c2pa.org's own press-release titles (OpenAI, Sony, Amazon join announcements) and Linux Foundation / PR Newswire coverage of Meta's membership, independently agreeing.
- OpenAI's C2PA-plus-SynthID approach and the openai.com/verify checker: OpenAI's own blog-post and help-center titles surfaced via search, corroborated by OpenAI Developer Community discussion threads.
- Google Pixel 10 native signing, the Titan M2 chip, and Assurance Level 2: blog.google's own post title plus The Hacker News, Security Affairs, and DPReview coverage, independently agreeing.
- EU AI Act Article 50 and the Code of Practice naming C2PA: artificialintelligenceact.eu and 2+ independent compliance-focused summaries, converging on the same enforcement date and framing.
- Browser/server JS tooling (`@contentauth/c2pa-web`, `@contentauth/c2pa-node`): opensource.contentauthenticity.org's own documentation titles and npm package listings.

- See also: /resources/ai-supply-chain-provenance, /resources/web-bot-auth, /resources/multimodal-agents, /resources/document-extraction-for-agents