​

Campaign Governance Protocol

Campaign Governance provides automated validation for buy-side advertising transactions. When AI agents buy media autonomously, Campaign Governance acts as an independent review layer — validating every action against authorized plans, brand policies, budget limits, and compliance requirements.

​

The problem

An AI agent interprets a brief, picks a seller, negotiates a media buy, and takes it live — all without a human watching. This is the “no eyes” problem: autonomous agents making real financial commitments with no independent check that the purchase matches what was authorized. The existing AdCP governance domains solve where ads run (Property Governance), what content is adjacent (Content Standards), what creatives are safe (Creative Governance), and who the brand is (Brand Protocol). None of them govern what gets bought and why. Without a governance layer on the buy side:

• An agent could exceed authorized budgets or reallocate spend outside approved parameters
• The agent could misinterpret a brief — buying in New Mexico when the brief said Mexico
• Targeting could drift in ways that violate brand policy or create discriminatory patterns
• Seller responses could differ from what was requested, with no automated verification
• Compliance policies are fragmented — copy-pasted as natural language strings into every campaign plan, with no standard library and no separation between who defines policies and who executes campaigns

Campaign Governance fills this gap with three mechanisms: plans that define what’s allowed (independent of the agent), seller-side governance checks that verify purchases independently of the buyer, and a policy registry that standardizes compliance rules across governance agents. Governance supports incremental adoption — organizations configure their governance agent to start in audit mode (log everything, approve everything), move to advisory (flag violations without blocking), and eventually enforce (block on violations). See the safety model for the adoption path. Mode is internal to the governance agent, not a protocol field.

​

Industry precedent

Campaign Governance formalizes patterns that exist in ad tech today as manual processes:

​

How it works

The orchestrator pushes campaign plans via sync_plans, then calls check_governance before commitment-bearing operations. Every enforcing service verifies the approved governance_context; media-buy services that claim online execution checking additionally validate planned_delivery before commit. After the response, the orchestrator calls report_plan_outcome to close the loop. Three parties participate in campaign governance:

• The orchestrator validates actions against the plan before sending them to sellers (buyer-side governance loop).
• The seller independently checks purchases by calling the buyer’s governance agent with its planned delivery parameters (seller-side governance check).
• The governance agent validates both the orchestrator’s intended actions and the seller’s planned delivery against the same campaign plan.

This creates a trust model where neither the buyer nor the seller can unilaterally misrepresent what was approved. The orchestrator cannot skip governance (the seller checks independently), and the seller cannot deliver something different from what was approved (the governance agent has a record of the planned delivery).

​

Separation of duties

Campaign Governance enforces an automated separation between who defines policies and who executes campaigns:

• The policy team selects applicable compliance policies from the policy registry, configures brand-specific rules, and maintains the brand’s compliance profile. This configuration lives at the brand level (in brand.json), not in individual campaign plans.
• The buying team (or agency) operates the orchestrator, creates campaign plans, and executes media buys. Plans specify campaign context — budget, channels, flight dates, authorized markets — and can reference additional registry policies or campaign-specific rules when needed.
• The governance agent resolves applicable policies from the brand’s compliance configuration and validates every orchestrator action against them.

The orchestrator cannot bypass or modify the brand’s compliance policies — those are resolved from the brand configuration by the governance agent. Plans can layer on additional policies via policy_ids and custom_policies, but the brand’s baseline always applies. When a regulation changes, the policy team updates the brand configuration once and all active campaigns pick up the change automatically.

​

Policy resolution

The governance agent resolves applicable policies through the brand reference in the plan:

1. The plan includes brand.domain (required) and optionally countries/regions (authorized markets for this campaign)
2. The governance agent resolves the brand via the Brand Protocol and retrieves its compliance configuration
3. The brand configuration references standardized policies from the policy registry by ID and includes any custom brand-specific policies
4. The governance agent intersects these policies with the plan’s authorized markets — only policies applicable to those markets are active for this plan
5. The resolved policy set is what gets evaluated during check_governance
6. Media buys targeting outside the authorized markets are denied regardless of policy compliance

The policy registry is a community-maintained library of standardized, machine-readable advertising compliance policies — covering jurisdictions (UK HFSS restrictions, US COPPA, EU GDPR), policy categories (children directed, pharmaceutical, fair housing, fair employment), and brand safety baselines. Brands select applicable policies from the registry rather than writing their own.

​

The governance loop

Every seller interaction follows a before/after pattern:

1. Before: The orchestrator calls check_governance with tool and payload — the action it intends to send. The governance agent returns a status.
2. Execute: If approved, the orchestrator sends the action to the service with governance_context on the protocol envelope. The service does not need the plan ID.
3. Check: A governance-enforcing service prepares what it will deliver without committing, calls check_governance with governance_context and planned_delivery, and commits only if the governance agent approves.
4. After: The orchestrator calls report_plan_outcome with the seller’s response. The governance agent updates its state and flags any discrepancies.

This pattern applies to request schemas carrying an x-governed-commitment annotation, including media purchases, rights, paid signal activation, and creative services. Discovery and read-only tasks do not create commitments and are outside the gate.

​

Planned delivery

When a seller confirms a media buy, it returns a planned_delivery object describing what it will actually deliver — the geographic targeting, channels, flight dates, frequency caps, and budget it will use. This may differ from what the buyer requested (e.g., the seller may apply additional frequency caps or adjust geo to match available inventory). planned_delivery serves two purposes:

1. Governance check: The seller sends planned_delivery to the buyer’s governance agent, which confirms it matches the campaign plan. This prevents the seller from delivering something the buyer didn’t approve.
2. Discrepancy detection: The buyer can compare planned_delivery against the original request and flag differences via report_plan_outcome, catching configuration drift before delivery begins.

​

Seller-side governance checks

Buyer-side governance has a trust limitation: the orchestrator attests to its own compliance. An LLM agent could hallucinate governance approval, skip validation, or misrepresent what was validated. You can’t trust the agent that’s spending money to also be the one that checks whether spending that money is OK. Service-side governance checks solve this. The buyer syncs governance agents (URLs with credentials) via sync_governance. When a service receives a governed commitment, it prepares what it plans to deliver and calls the governance agent before committing. The execution decision is binary: approved or denied. This also catches misinterpretation. If the brief says “Mexico” and the seller interprets it as “New Mexico,” the governance agent sees the geo mismatch against the plan and denies the buy — before it goes live. The webhook covers the full media buy lifecycle:

• Purchase: POST before confirming create_media_buy — is this buy approved?
• Modification: POST before confirming update_media_buy — is this change OK?
• Delivery: POST periodically during delivery — is delivery still on track?

The governance agent maintains all state. The seller just posts what’s happening — no chaining, no conversation history, no state to track across servers. Seller-side lifecycle checks are optional unless the task advertises online_execution_check; that mode makes the purchase/modification pre-commit check mandatory for the claimed task. Delivery monitoring remains separately opt-in. Sellers can otherwise start with signed-context verification and add online phases incrementally. See the specification for the full protocol. Sellers that implement governance checks gain a competitive advantage: they can prove to buyers that purchases were independently verified before execution. This reduces dispute risk, automates compliance verification, and signals trust to buyers with strict oversight requirements.

​

Adoption path

Governance agents support incremental adoption through their internal mode configuration. The protocol surface is the same regardless of mode. Intent checks may return approved, denied, or conditions; execution checks return approved or denied. How the governance agent arrives at that decision is its own concern. In practice, organizations configure their governance agent to progress through three stages:

1. Audit — Log everything, approve everything. The governance agent evaluates fully but always returns approved with findings attached. The organization reviews findings to assess false positive rates and calibrate policies.
2. Advisory — Approve with prominent findings and recommended corrections. The decision is still unambiguously approved; humans review findings post-hoc.
3. Enforce — Block on violations. The default for production governance.

This works the same way for a single brand buying direct and for a holding company with 35 brands and multiple agency partners.

​

For small brands

A brand buying direct (no agency, no policy team) still gets:

• Automated budget limits and geo enforcement from the campaign plan
• Compliance coverage from the policy registry — registry policies are community-maintained, no per-brand configuration required
• Seller-side verification via governance checks
• Full audit trail via get_plan_audit_logs

Set a budget.reallocation_threshold to define guardrails on how much the agent may reallocate without human approval. The governance agent handles the rest.

​

For multi-agency and holding company setups

Plans support delegations that scope which agents can execute against a plan — by authority level, budget limit, market, and expiration. A brand can delegate full authority to one agency for European markets and execute_only authority to another for North America. For holding companies managing multiple brands, portfolio governance defines cross-brand constraints: total portfolio spend caps, shared policy enforcement, and corporate-level exclusions that no individual brand plan can override.

​

Finding confidence

Governance findings include optional confidence scores (0-1) that distinguish “this definitely violates GDPR” (0.95) from “this might violate depending on how audience segments resolve” (0.6). This helps brands respond appropriately — high-confidence findings can be auto-resolved, medium-confidence findings get flagged for human review.

​

Drift detection

The audit log includes aggregate metrics — human review rate, auto-approval rate, human override rate — with trend indicators. A declining human review rate may mean the system is well-calibrated or that oversight is eroding. Surfacing the trend lets the organization make that call.

​

Lifecycle phases

Campaign Governance is stateful across three phases: Each phase builds on context from earlier phases. During purchase, the governance agent knows which products were discovered (and approved) during discovery. During delivery, it monitors execution against what was purchased.

​

Validation categories

The labels below are common agent-internal vocabulary for governance response and audit output. They are illustrative, not a protocol-level enum or a capability declaration. Consumers display them with their human-readable findings and MUST NOT pattern-match them as machine-level contracts. accessibility_compliance is documented response/audit vocabulary, not a policy-activation mechanism. Its presence does not make an agent evaluate accessibility, activate a policy, or establish a typed accessibility requirement on canonical formats or creative assets. The canonical 3.2 format schemas do not yet define that typed contract; legacy format accessibility hints do not fill that gap. A future protocol slice must define discovery, policy activation, typed requirements, and structured per-asset failures before clients can rely on accessibility enforcement. This label belongs to governance rather than Content Standards: Content Standards evaluates creative-content suitability, while a governance finding records the agent’s evaluation of an applicable technical or policy obligation. An agent may surface accessibility_compliance only when its own policy model actually performed that review.

​

Statuses

Every governance check returns a structured status: Finding severity levels indicate urgency:

• info — Logged for audit. Used on approved responses for informational findings.
• warning — Human should review. Used on approved responses when action is allowed but attention is needed.
• critical — Action is blocked. Used on denied responses.

When the governance agent determines that human review is required (e.g., a reallocation exceeds the plan’s reallocation_threshold, or the plan has human_review_required: true), the task goes async — it returns standard async task lifecycle statuses and eventually resolves to approved or denied once the human acts. This integrates with the existing AdCP async task mechanism. The caller does not need special handling beyond supporting async tasks (see task lifecycle).

​

Relationship to other governance domains

Campaign Governance composes with the existing domains — it does not duplicate them:

​

Next steps