> ## 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.
# Governance protocol
> AdCP governance ensures human oversight of autonomous AI advertising through three-party validation, budget controls, and brand safety enforcement.
An AI agent is about to spend \$50,000 on advertising. No human reviewed the plan. No system checked the budget. No policy filtered the inventory. The agent has credentials, a brief, and a BUY button.
Jordan is a campaign operations manager at Pinnacle Agency. This is her nightmare. Not because the technology failed — because nobody was accountable. Responsibility cannot be delegated to software.
She doesn't want to slow agents down — they're faster and more thorough than her team at managing cross-platform campaigns. But she needs to know that when an agent buys media for Acme Outdoor, it stays within budget, runs on approved publishers, and meets Canadian privacy rules. She needs to know that if something exceeds authority, a human gets asked — not after the fact, but before the money moves.
AdCP's governance system is built on a principle: [human judgment must be embedded in system design](/docs/governance/embedded-human-judgment), not bolted on afterward. Oversight is architectural — the system cannot operate without it.
This walkthrough follows Jordan as she sets up governance for Sam's \$50K campaign and watches it work.
**Regulated verticals.** Campaigns for credit, insurance, employment, or housing fall under GDPR Article 22 and EU AI Act Annex III — automated decisions affecting data subjects require human oversight. See [Annex III & Art 22 obligations](/docs/governance/annex-iii-obligations) for what AdCP provides and what the deployer is responsible for.
The AdCP policy registry ships seeded with regulatory policies across US (FHA, ECOA, EEOC, COPPA, FDA, FTC, TTB), EU (DSA, prescription DTC), and platform-specific categories — alongside GDPR Article 9 restricted-attribute definitions that governance agents evaluate programmatically. The seeded registry is a starting point, not an exhaustive list; deployers extend it for their own jurisdictions and brand rules.
## The three-party model
AdCP governance works because humans define the boundaries and no single party controls the full workflow:
| Party | Role | Cannot do |
| -------------------- | ------------------------------------------------ | ---------------------------------------------------- |
| **Orchestrator** | Proposes campaign plans, executes buys | Set its own spending limits or approve its own plans |
| **Governance agent** | Validates plans against policies, tracks budgets | Execute buys or modify campaigns |
| **Seller** | Fulfills media buys, reports delivery | Override governance decisions or modify budgets |
The agent that spends money isn't the agent that sets the rules. This isn't three agents checking each other — it's a structure designed so that human-defined policies govern every transaction, and no agent can act outside the authority a human granted it.
## Step 0: Sync governance agents
Before registering the plan, the buyer syncs governance agents with the seller via [`sync_governance`](/docs/accounts/tasks/sync_governance). This gives the seller the endpoints and credentials needed to call `check_governance` independently when processing media buys.
## Step 1: Register the plan
Before Sam's orchestrator executes any buy, Jordan's governance setup requires it to register the campaign plan:
```javascript theme={null}
const plan = await governance.syncPlans({
plans: [{
plan_id: "acme-q2-trail-pro",
brand: { domain: "acmeoutdoor.com" },
objectives: "Q2 Trail Pro 3000 launch across sports and outdoor lifestyle publishers",
budget: { total: 50000, currency: "USD", reallocation_threshold: 5000 },
flight: { start: "2026-04-01T00:00:00Z", end: "2026-06-30T23:59:59Z" },
countries: ["US", "CA"]
}]
});
```
The governance agent now knows about this plan. It resolves applicable policies — brand safety rules, budget limits, regulatory requirements for US and Canada, and Acme Outdoor's brand-specific restrictions from `brand.json`.
No money has moved. The plan is registered, not executed.
Notice `reallocation_threshold: 5000` — Jordan chose this setting. It means the orchestrator can reallocate budget up to \$5,000 on its own, but any larger move requires human approval. This boundary is a human decision, not a technical default. The agent cannot change it.
The governance agent pulls policies from multiple sources:
* **Budget limits**: Reallocation threshold caps how much budget the agent may move without human approval
* **Brand safety**: Acme Outdoor's `brand.json` specifies approved and excluded publisher categories
* **Regulatory**: US and CA jurisdictions trigger COPPA, PIPEDA, and state privacy rules
* **Industry**: AgenticAdvertising.org's policy registry provides standardized regulations
Jordan configured these policies once. They apply automatically to every campaign for this brand.
## Step 2: Check before spending
When the orchestrator is ready to buy, it calls `check_governance` before executing:
```javascript theme={null}
const check = await governance.checkGovernance({
plan_id: "acme-q2-trail-pro",
caller: "https://orchestrator.pinnacle-agency.example",
tool: "create_media_buy",
payload: {
seller: "https://streamhaus.example",
amount: 25000,
currency: "USD"
}
});
```
The governance agent evaluates the proposed action against every applicable policy:
| Check | Status | Detail |
| ----------------------------- | ----------- | -------------------------------------------- |
| Budget within plan limit | Passed | \$25K of \$50K available |
| Budget within agent authority | **Warning** | Agent authorized up to \$20K per transaction |
| Brand safety | Passed | StreamHaus on approved list |
| Regulatory compliance | Passed | Targeting meets US/CA requirements |
| Creative provenance | Passed | All creatives carry required metadata |
The response isn't pass/fail — it returns structured findings with severity levels (`must`, `should`, `may`) and confidence scores. The orchestrator knows exactly what passed, what failed, and why.
## Step 3: Escalation
The \$25,000 transaction exceeds the agent's \$20,000 authority limit. The governance agent flags it with `must` severity — the orchestrator cannot proceed without resolution.
This is not a failure — it is the system working as designed. The agent doesn't need to remember to check; the architecture requires it. Oversight is structural, not procedural.
Two options:
1. **Reduce the transaction** to \$20,000 or less
2. **Wait for human approval** — the governance agent handles this internally
The governance agent determines that human review is needed. It holds the `check_governance` request async — the orchestrator sees standard async task status (`submitted`, `working`) while Jordan receives the flagged plan with full context: what the agent wants to buy, why it was flagged, and which policy triggered it.
The `check_governance` task goes async. The orchestrator polls or receives a webhook when it resolves. Internally, the governance agent routes to Jordan for approval. Once she acts, the task completes with `approved` or `denied`.
```json theme={null}
{
"check_id": "chk-q2-ctv-001",
"verdict": "denied",
"plan_id": "acme-q2-trail-pro",
"explanation": "Budget authority exceeded. Transaction amount $25,000 exceeds agent authority limit of $20,000.",
"findings": [
{
"category_id": "budget",
"policy_id": "budget-authority-limit",
"severity": "must",
"explanation": "Transaction amount $25,000 exceeds agent authority limit of $20,000.",
"confidence": 1.0
}
]
}
```
If Jordan approves (potentially with conditions), the governance agent returns `approved` instead.
## Step 4: Human approval
Jordan reviews the plan and approves — with a condition: the agent must report delivery weekly instead of at flight end.
She isn't rubber-stamping. She reviewed the context, assessed the risk, and exercised judgment by adding a constraint the agent didn't request. This is the human remaining the locus of accountability — the agent proposed, the human decided.
This approval is recorded in the governance system. The governance agent updates the plan's delegation — the orchestrator now has temporary authority for this specific transaction, with the added reporting constraint. The governance agent records who approved, when, and under what conditions.
## Step 5: Campaign runs under watch
The campaign is live. Governance doesn't stop at purchase — it monitors delivery against the approved plan:
* **Budget tracking**: As `report_plan_outcome` data flows in, the governance agent tracks actual spend against committed budget
* **Drift detection**: If delivery diverges from the plan — wrong publisher, unexpected creative, budget overrun — governance flags it
* **Policy updates**: If a new regulation takes effect mid-flight, governance applies it to active plans. Content-standards versions follow a separate rule — pinned-at-buy by default, with a per-policy `evaluation_mode: continuous` opt-in for regulatory policies. See [content standards versioning](/docs/governance/content-standards/index#versioning-and-mid-flight-amendments).
First, the orchestrator reports that the seller accepted the purchase and committed budget:
```javascript theme={null}
await governance.reportPlanOutcome({
plan_id: "acme-q2-trail-pro",
governance_context: check.governance_context,
check_id: "chk-q2-ctv-001",
outcome: "completed",
seller_response: {
media_buy_id: "mb-streamhaus-001",
committed_budget: 25000
}
});
```
Then, as delivery data comes in, the orchestrator reports delivery outcomes so governance can track actual spend against the committed budget:
```javascript theme={null}
await governance.reportPlanOutcome({
plan_id: "acme-q2-trail-pro",
governance_context: check.governance_context,
outcome: "delivery",
delivery: {
media_buy_id: "mb-streamhaus-001",
reporting_period: {
start: "2026-04-01T00:00:00Z",
end: "2026-06-30T23:59:59Z"
},
impressions: 887000,
spend: 24850
}
});
```
The \$25,000 buy committed budget, and actual delivery came in at \$24,850. The governance agent updates the ledger — \$25,150 remains of the \$50K plan budget for the next buy.
## Step 6: The audit trail
Six months later, Acme Outdoor's procurement team asks: "Who approved that \$25,000 CTV buy?" Jordan pulls the complete decision history:
```javascript theme={null}
const audit = await governance.getPlanAuditLogs({
plan_ids: ["acme-q2-trail-pro"],
include_entries: true
});
```
Every event, in sequence:
1. **Plan registered** — orchestrator synced plan with \$50K budget
2. **Governance check** — \$25K buy flagged for exceeding agent authority
3. **Escalation** — Jordan reviewed, approved with weekly reporting condition
4. **Buy executed** — StreamHaus media buy created
5. **Delivery reported** — \$24,850 actual spend, 887K impressions
6. **Budget updated** — \$25,150 remaining
Every decision, every approval, every outcome — structured, timestamped, attributable. Accountability requires legibility. This isn't a log file buried in a server — it's a first-class audit record designed to answer the question "who decided this and why?" at any point in the future.
## Crawl, walk, run
Jordan didn't start with full enforcement. She configured the governance agent to start in audit mode — it evaluated every check fully but always returned `approved`, attaching findings for her to review. After two weeks she reviewed the logs, tuned policies to reduce false positives, and moved to advisory. In advisory mode, the governance agent returned real `denied` statuses but Jordan's team treated them as non-blocking. When she trusted the system, she switched to enforce.
The callers (orchestrator, sellers) never changed their code. They always acted on the status they received. The mode was entirely the governance agent's internal configuration.
Budget tracking has three phases:
1. **Proposed**: `check_governance` evaluates whether the amount fits within the plan. No money reserved — this is a hypothetical check.
2. **Execute**: The seller runs the campaign. The governance agent tracks the authorized amount as reserved, but actual spend may differ.
3. **Committed**: `report_plan_outcome` records the actual amount. The governance agent updates the ledger with real numbers.
A \$25,000 buy might deliver \$24,850. Governance tracks the difference and frees the remaining \$150.
**Embedded human judgment**
Every step in this walkthrough reflects a principle from the [Embedded Human Judgment manifesto](/docs/governance/embedded-human-judgment) — the framework that ensures humans remain accountable when AI agents operate autonomously. [Read the five principles →](/docs/governance/embedded-human-judgment)
## Protocol domains
The Governance Protocol covers six domains:
Community-maintained library of standardized advertising regulations and industry standards, consumed by all governance domains.
Control where ads can run with property lists, compliance filtering, and publisher authorization via adagents.json.
Control what content ads run in with collection lists — program-level brand safety for shows, series, and podcasts across platforms.
Privacy-preserving brand suitability through calibration-based content evaluation and validation.
Security scanning, creative quality, and content categorization through specialist agents via get\_creative\_features.
Automated validation of buy-side transactions against authorized plans, budgets, and brand compliance configuration.
### Sponsored Intelligence (Planned)
Full protocol-level governance integration for [Sponsored Intelligence](/docs/sponsored-intelligence/overview) is under development. When available, SI platforms will support:
1. **Campaign registration** via `sync_plans` — register SI campaigns with governance agents
2. **Session-lifecycle governance** via `check_governance` — validate actions during SI sessions
3. **Content standards for AI-generated content** — apply brand suitability to LLM-generated sponsored responses
4. **Property governance for AI assistant placements** — validate that AI platforms are authorized delivery surfaces
Today, SI platforms enforce governance at the application layer using [content standards](/docs/governance/content-standards/index) and [brand identity](/docs/brand-protocol/brand-json). The informal governance references in SI documentation reflect this application-layer integration, not protocol-level governance tasks.
## Go deeper
* **Safety model**: [Three-party trust in depth](/docs/governance/campaign/safety-model) — separation of duties, delegation, and escalation patterns
* **Campaign specification**: [Full data model](/docs/governance/campaign/specification) — plans, checks, outcomes, and policy resolution
* **Content standards**: [Brand suitability](/docs/governance/content-standards/index) — privacy-preserving calibration for content evaluation
* **Property governance**: [Where ads can run](/docs/governance/property/index) — property lists, adagents.json, and publisher authorization
* **Collection governance**: [What content ads run in](/docs/governance/collection/index) — collection lists for program-level brand safety across platforms
* **Policy registry**: [Community policies](/docs/governance/policy-registry) — standardized regulations and brand safety policies
* **Get certified**: [Specialist governance modules](/docs/learning/specialist/governance) teach the full governance system through interactive scenarios
* **RFC process**: [How to propose changes](/docs/governance/rfc-process) — lifecycle, proposal template, and decision-record format for protocol contributions