RFC: seller acceptance criteria for campaign governance-agent bindings

[lukasz-pubx]

Successor to #6656 (closed) — the one mechanism from that RFC's triage that all three expert reviews converged on as spec-ready ("clean accepted_verifiers precedent, non-breaking") and that the follow-up split (#6749, #6750) did not carry. Filed standalone. This RFC makes no authority claim: campaign governance ("spend approval") remains the buyer's split-authority infrastructure; the ask is operational — acceptance criteria over an integration counterparty the seller is otherwise assigned without any say.

Amended 2026-08-22 per triage and review comments: declaration rehomed to adcp.governance_enforcement (the governance block is gated on governance protocol support); acceptance restructured as a typed any_of matcher union; the verification matcher fully specified (with URL-only V1 named as an acceptable resolution); account scoping resolved as advisory-capabilities / authoritative-sync_governance; rejected-binding hygiene and non-discrimination MUSTs added; the delegated-intervention recovery case added to Motivation.

Motivation

Grounding: citations from the repo at 17cb0f59776a0ecc68dd912dc43b640442002d74 (main, 2026-08-21); re-verify at implementation time.

The binding is buyer-initiated; the seller's role is to persist, call, and comply. docs/accounts/tasks/sync_governance.mdx:

"Sync the governance agent endpoint for specific accounts. The seller persists the agent and calls it via check_governance during media buy lifecycle events."

The task's Authorization section verifies the buyer's authority over the account; no surface exists for the seller to accept or decline the binding itself.

The seller is a forced integration counterparty, and sends it sensitive data. Under docs/governance/campaign/specification.mdx § Seller enforcement, a seller advertising governance enforcement MUST verify tokens against the bound agent and, for online_execution_check tasks, MUST call check_governance with its computed planned_delivery — its delivery parameters for the buy — and MUST NOT proceed on denial. Availability, latency, and data handling of the bound agent sit directly on the seller's execution path.

The bound agent controls recovery, not just checks. resumes_execution is a governed trigger (static/schemas/source/media-buy/control-media-buy-request.json, x-governed-commitment), and the unreachable-gate default is halt — docs/governance/campaign/specification.mdx:

"If the governance agent is unreachable (timeout, network error), the seller MUST NOT proceed with the media buy. … reject the media buy with a GOVERNANCE_UNAVAILABLE error if the agent remains unreachable."

The safe-by-design consequence: pausing is always possible, but un-pausing a media buy requires the bound agent to be reachable and responsive. An unavailable or slow agent leaves paused inventory stranded on the seller's books — in delegated or emergency-intervention scenarios, at exactly the worst moment — and the seller had no say in the counterparty whose availability determines when its inventory can resume delivering.

The spec already treats agent data-handling as a trust decision — for the buyer only. The same specification section:

"Operators who treat shopping intent as commercially sensitive SHOULD choose governance agents whose data-handling posture they trust."

The seller sends planned_delivery to the same agent and gets no equivalent choice. The trust advice exists; only one of the two parties transmitting sensitive data to the agent can act on it.

The precedent is exact. Creative governance already solves this shape: static/schemas/source/core/creative-policy.json (accepted_verifiers — "The seller is the verifier-of-record: it is the seller, not the buyer, that decides which agent it will call"), with the typed rejection PROVENANCE_VERIFIER_NOT_ACCEPTED in static/schemas/source/enums/error-code.json, and URL matching governed by docs/reference/url-canonicalization.mdx. There, the seller calls an agent chosen by the ecosystem and declares which it accepts; here, the seller calls an agent chosen by the buyer and declares nothing.

Problem

1. A buyer binds a governance agent to the account via sync_governance. The agent may be operated by anyone — including the buyer itself or a vendor whose data handling, availability record, or jurisdiction the seller cannot accept (e.g. for where its planned_delivery data lands, or whose uptime its paused inventory depends on).
2. The seller's choices are: integrate and transmit regardless, or refuse the account commercially — an off-protocol, all-or-nothing lever. There is no typed, auditable way to say "we accept AAO-verified operators" or "these endpoints".
3. Every future binding change repeats the same silent imposition: sync_governance re-syncs are processed, not negotiated, and the seller learns operational problems (an unreachable or slow agent stalling its execution checks — or its resumes) only in production.

Scope

One mechanism — declaration plus binding-time enforcement. No change to check_governance, token verification, threading, or any check-time wire shape.

Acceptance declaration — on adcp.governance_enforcement

The seller declares acceptance criteria inside the existing cross-role adcp.governance_enforcement capability (static/schemas/source/protocol/get-adcp-capabilities-response.json — "Cross-role declaration that this agent enforces buyer-provided governance authorization when performing consequential tasks"). The acceptance declaration is a parameter of that enforcement claim — I enforce governance, against agents I accept — and, being cross-role, remains available to any seller role if governed commitments expand beyond media buying. It is deliberately not placed in the governance capabilities block, which is gated on governance in supported_protocols and therefore unavailable to ordinary sellers — the RFC's entire audience.

Acceptance is a typed any_of union of matcher objects — a binding is acceptable when any matcher accepts it:

{
  "adcp": {
    "governance_enforcement": {
      "accepted_governance_agents": {
        "any_of": [
          {
            "kind": "agent_url",
            "agent_url": "https://governance.neutral-operator.example"
          },
          {
            "kind": "verification",
            "registry": "https://registry.agenticadvertising.org",
            "role": "governance",
            "adcp_version": "3.2",
            "verification_modes": ["spec"],
            "max_age_seconds": 86400
          }
        ]
      }
    }
  }
}

Normative semantics:

• The union is permissive by construction: a binding satisfying any one matcher MUST be accepted. NOTE: adding matchers widens acceptance — an agent_url entry plus a verification entry accepts more agents than either alone. Implementers wanting conjunctive restriction express it inside a single matcher, not across entries. The discriminated kind union makes this composition visible to validators and SDKs and is the extension point for future matcher kinds.
• agent_url matcher (V1 floor): exact-match allowlisting under the canonicalization rules of docs/reference/url-canonicalization.mdx — the same rules that already govern accepted_verifiers comparisons.
• verification matcher: deterministic contract — registry (authoritative lookup endpoint), role (required agent role in the registry), adcp_version (applicable version), verification_modes (accepted modes), max_age_seconds (freshness bound on cached verification state). If verification cannot be resolved (registry unreachable, stale beyond max_age_seconds with no refresh), the binding attempt fails with GOVERNANCE_UNAVAILABLE-class retryable semantics — the same principle the spec already applies to an unreachable agent at check time — and MUST NOT be reported as a definitive GOVERNANCE_AGENT_NOT_ACCEPTED. Acceptable alternative resolution: land V1 with the agent_url matcher only and sever the verification matcher to a follow-up RFC once registry governance is settled; either outcome satisfies this RFC.
• Non-discrimination: declared acceptance criteria MUST reflect objective, non-discriminatory eligibility standards (operator verification status, data-handling certification, availability commitments) — not commercial leverage over particular counterparties.

Enforcement at sync_governance

A sync_governance call naming an agent outside the seller's acceptance fails with the typed error GOVERNANCE_AGENT_NOT_ACCEPTED (mirroring PROVENANCE_VERIFIER_NOT_ACCEPTED), carrying the applicable acceptance criteria in error.details so the buyer can select a compliant agent without out-of-band discovery.

• Scoping — advisory declaration, authoritative response. get_adcp_capabilities has no account input, so the capabilities declaration is a seller-wide advisory default for discovery. The sync_governance response is authoritative per account: a seller MAY reject a binding on account-specific grounds (e.g. a regulated-category account requiring stricter criteria), carrying the account-applicable criteria in the error details. This mirrors the discovery-advisory / response-authoritative pattern RFC: structured seller acceptance-policy discovery backed by the policy registry #6749 establishes for acceptance policies.
• Rejected-binding hygiene. A rejected binding MUST NOT be persisted, MUST NOT be contacted, and its credentials MUST NOT be echoed in any response or log surface.
• Stability. Absent declaration = accept any (today's behavior, unchanged). An already-synced binding is unaffected by a later declaration change until the next sync_governance — no retroactive invalidation, the same stability rule as other capability declarations.

Non-goals

• No bilateral selection, negotiation rounds, leader election, or propose/accept handshake (that territory belongs to RFC: unify governance behind a jointly-selected agent layer across domains (4.0 direction) #6657 if the WG ever takes it).
• No seller authority over spend approval: the buyer still chooses the agent; the seller's declaration only bounds which choices it can integrate with — exactly as accepted_verifiers bounds creative verifiers.
• No new obligations for sellers that declare nothing.

Alternatives considered

1. Do nothing. The seller's only lever over an imposed integration counterparty remains refusing the account commercially; data-handling trust stays a one-sided SHOULD; recovery availability stays an unpriced dependency.
2. Parallel agents[] / criteria[] fields with prose-defined OR (this RFC's originally filed shape). Rejected per review: the permissive composition is invisible in the schema, and implementers expecting additive restriction would misconfigure silently. The any_of matcher union expresses the same semantics structurally.
3. Criteria-only (no URL allowlist). More neutral — avoids sellers hard-pinning vendors — but blocks the legitimate "we have an integration/DPA with these two operators" case, and a bare criteria string is not deterministic without the full verification contract. Both matcher kinds are specified instead.
4. Handle out-of-band (commercial contracts). Where it lives today; leaves no typed error, nothing in capabilities for buyers to discover before attempting a binding, and no interoperable vocabulary across sellers.
5. Full mutual agreement on the binding. The heavyweight form; deliberately out of scope per the spend-approval framing — the buyer's approval infrastructure is the buyer's to choose within the seller's declared acceptance bounds.

Compatibility impact

Non-breaking; changeset class MINOR. New optional object on the existing cross-role adcp.governance_enforcement capability; one additive error-code enum entry (GOVERNANCE_AGENT_NOT_ACCEPTED — visible to strict validators); the unresolvable-verification path reuses GOVERNANCE_UNAVAILABLE-class semantics rather than adding a code (final code choice per maintainers). sync_governance behavior changes only for sellers that declare acceptance; defaults are unchanged for everyone else.

Files affected (as of 17cb0f5 — re-verify at implementation)

• static/schemas/source/protocol/get-adcp-capabilities-response.json — accepted_governance_agents on adcp.governance_enforcement
• static/schemas/source/account/sync-governance-response.json — typed rejection path with criteria in details
• static/schemas/source/enums/error-code.json — GOVERNANCE_AGENT_NOT_ACCEPTED
• docs/reference/url-canonicalization.mdx — new row for accepted_governance_agents.any_of[].agent_url vs bound agent URL
• docs/accounts/tasks/sync_governance.mdx — acceptance semantics, hygiene rules, advisory/authoritative scoping
• docs/governance/campaign/specification.mdx / safety-model.mdx — one-paragraph updates where the binding is described
• Schema index, changeset file, compliance symbol registry entries; compliance storyboards as follow-up scope

Reviewer checklist

• Motivation is clear and not redundant with existing functionality
• Scope is specific enough to implement without further clarification
• Alternatives section covers at least one non-obvious alternative
• Compatibility impact accurately states breaking vs. non-breaking
• Wire-format or schema snippet included (for schema or task changes)

Related

• RFC: sell-side governance — seller-authored policies and governance-agent acceptance in campaign governance #6656 (closed) — predecessor; this mechanism was its "Tier 2 / Mechanism 3", assessed spec-ready by all three expert reviews in that issue's triage.
• static/schemas/source/core/creative-policy.json accepted_verifiers / PROVENANCE_VERIFIER_NOT_ACCEPTED — the exact precedent; docs/reference/url-canonicalization.mdx — the matching rules reused here.
• RFC: structured seller acceptance-policy discovery backed by the policy registry #6749 — the discovery-advisory / response-authoritative pattern this RFC's scoping mirrors.
• RFC: typed seller dispositions in the campaign-governance audit record #6757 — sibling successor RFC (typed seller dispositions); independent mechanisms.
• RFC: unify governance behind a jointly-selected agent layer across domains (4.0 direction) #6657 — bilateral/consolidated selection as a 4.0 direction; this RFC is the minimal 3.x-compatible step and does not depend on it.

[bokelley]

Triage

Classification: Feature request (RFC)
Bucket(s): spec / protocol, governance, schema
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: agents URL-allowlist maps cleanly to the accepted_verifiers / PROVENANCE_VERIFIER_NOT_ACCEPTED precedent — same trust principle, same reject-at-submission-time model. Schema-placement blocker: the governance capabilities block is gated on governance being in supported_protocols; a media-buy seller that is not itself a governance agent cannot declare this field, which silently excludes the majority of the proposal's target audience. Correct home is the media_buy block (per governance_enforcement at lines 445–591), not governance. criteria concept has no existing schema precedent — needs a normative definition of valid values. Wire surface (GOVERNANCE_AGENT_NOT_ACCEPTED in per-account errors[]) is clean.
• adtech-product-expert: Seller pain is real and well-precedented (Prebid vendor allowlists, GAM approved-third-party lists, Magnite DPA gating). OR semantics footgun: declaring both agents and criteria makes acceptance more permissive, not more restrictive — implementers expecting additive restriction will misconfigure silently; needs a MUST-level normative statement and a NOTE. Criteria evaluation model (static registry vs. runtime lookup) needs resolution before adoption cost is predictable. Non-discrimination text needed to prevent URL allowlist from becoming a commercial lever.

My take: The mechanism is the right design — binding-time acceptance declaration with a typed rejection fills a genuine trust asymmetry that the accepted_verifiers / PROVENANCE_VERIFIER_NOT_ACCEPTED pattern already established on the creative surface. Two items need resolution before WG ratification: (1) move the field out of the governance capabilities block (gated on governance protocol support) into media_buy or a protocol-level block accessible to all sellers; (2) give the criteria array a minimum normative definition of valid values.

---

Decision Memo — DR-0015 (draft, pending WG ratification)

---
id: DR-0015
title: Sellers may declare acceptance criteria for buyer-bound governance agents at binding time
class: normative
status: recorded
date: 2026-08-21
decided: ~2026-08-21
decided_by: WG ballot (pending)
refs: ["#6758", "#6656"]
dissent: none recorded
---

Decision

Sellers may declare accepted_governance_agents — an optional URL allowlist and/or criteria set — in their seller-side capabilities. A sync_governance binding naming an agent outside the declared acceptance MUST fail with GOVERNANCE_AGENT_NOT_ACCEPTED, carrying the declared criteria in error.details so the buyer can select a compliant agent. Absent declaration = accept any (today's behavior unchanged). An already-synced binding is unaffected by a later declaration change until the next sync_governance. The field MUST be placed in the media_buy capabilities block (or a protocol-level block accessible to sellers that do not support the governance protocol), not in the governance block, which is gated on governance in supported_protocols.

Rationale

sync_governance currently gives sellers no typed mechanism to decline a binding. The seller must call check_governance against any buyer-bound agent — transmitting sensitive planned_delivery data — with no protocol-level lever short of refusing the account commercially. The accepted_verifiers / PROVENANCE_VERIFIER_NOT_ACCEPTED pattern already establishes that sellers are the agent-of-record for third-party calls on their execution path; this RFC applies the same trust principle to the governance-agent binding surface. The OR semantics (a binding satisfies the declaration when the agent matches ANY declared condition) must be stated normatively, with a note that declaring both agents and criteria makes acceptance more permissive than either condition alone. Criteria declarations MUST reflect objective, non-discriminatory eligibility standards to prevent allowlist-as-commercial-lever usage. Criteria values (e.g., aao_verified) require a published registry or normative definition.

Implications

Settles: sellers have typed, auditable acceptance authority at binding time, parallel to their creative-verifier authority. Does not settle: criteria registry governance, multi-agent bindings, bilateral governance-agent selection (deferred to #6657). Pre-ratification items: (1) field placement in media_buy or protocol-level block; (2) criteria normative definition or registry reference; (3) OR-semantics MUST statement and non-discrimination text.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_0151CpSfBdu2EuFYpW7T43Hf

---

Generated by Claude Code

[bokelley]

I support the binding-time acceptance mechanism. A few changes would make the wire contract safer and more general.

1. Put it on the existing cross-role enforcement capability

The best home appears to be adcp.governance_enforcement, not the top-level governance block and not a media-buy-only block. Its current description is already exact: an agent can enforce governance on consequential tasks without implementing the governance protocol itself.

This also keeps the declaration available to other seller roles if governed commitments expand beyond media buying.

2. Make OR semantics structural

Rather than parallel agents[] and criteria[] fields with prose-defined OR behavior, use one typed any_of list of matchers. For example:

{
  "accepted_governance_agents": {
    "any_of": [
      {
        "kind": "agent_url",
        "agent_url": "https://governance.neutral-operator.example"
      },
      {
        "kind": "verification",
        "registry": "https://registry.example",
        "role": "governance",
        "adcp_version": "3.2",
        "verification_modes": ["spec"]
      }
    ]
  }
}

Any matching entry accepts the binding. A discriminated union makes the permissive composition visible to validators, SDKs, and operators and gives future matcher types a compatible extension point.

3. Either define verification precisely or defer it

I would land exact URL allowlisting in V1 and defer aao_verified unless the criterion defines:

• authoritative registry and lookup;
• required agent role;
• applicable AdCP version;
• accepted verification modes;
• freshness/cache rules; and
• behavior when verification cannot be resolved.

A bare aao_verified string is not deterministic enough for a binding decision. Registry unavailability should also not be reported as a definitive GOVERNANCE_AGENT_NOT_ACCEPTED.

4. Resolve scope and endpoint handling

sync_governance is account-scoped, while get_adcp_capabilities has no account input. The RFC should state whether the declaration is a seller-wide guarantee, a default subject to account-specific rejection, or whether an authoritative account-scoped projection is needed.

URL entries should reuse the existing canonicalization rules from accepted_verifiers. A rejected binding must not be persisted, contacted, or have its credentials echoed. Absent declaration and non-retroactive updates should retain the proposed semantics.

With those points resolved, this is a small, well-precedented addition.

[lukasz-pubx]

Supporting use case from the delegated/emergency-intervention side — we operate a buying intermediary and have hit this in practice.

When the owning buyer agent is down and a delegated caller (plan delegations[]) performs break-glass changes, the bound governance agent sits on the seller's critical path at exactly the worst moment. The emergency stop is safe by design — pause/cancel are exempt from the gate — but recovery is not: resumes_execution is a governed trigger (static/schemas/source/media-buy/control-media-buy-request.json, x-governed-commitment), and "when the gate is unreachable, the default is halt." An unavailable or slow bound agent therefore means paused inventory stays stranded on the seller's books, with the seller having had no say in the counterparty whose availability determines when it can resume delivering. That is the operational-stake argument of this RFC in its sharpest form: binding-time acceptance criteria are the seller's only lever over an agent that later controls whether its inventory can be un-paused.

One forward-looking note: since the plan itself is unreadable by sellers ("there is no plan-retrieval mechanism in 3.x and none is planned", docs/governance/campaign/specification.mdx), a binding-time acceptance surface is also the natural future hook if sellers ever need attestable expectations about plan contents — e.g. that an active intervention delegation exists — with the governance agent, not the buyer, doing the attesting. Not asking to widen this RFC's scope; just noting the mechanism composes in that direction.

[lukasz-pubx]

Author response — accepting all four refinements; amending the body to match (diff summary will follow).

1. Placement — accepted, and adcp.governance_enforcement over media_buy. The governance-block placement in the filed draft was a genuine defect (gated on governance in supported_protocols, silently excluding the RFC's entire audience — thanks to the triage for catching it). Between the two proposed fixes, adcp.governance_enforcement is verified as the better home: its description — "Cross-role declaration that this agent enforces buyer-provided governance authorization when performing consequential tasks" — makes the acceptance declaration a natural parameter of the enforcement claim itself ("I enforce governance, against agents I accept"), and it stays available to other roles if governed commitments expand beyond media buying.

2. Structural any_of — accepted. The discriminated union of matcher objects is adopted as proposed. It resolves the OR-semantics footgun structurally (the permissive composition is visible to validators and SDKs, not buried in prose), and gives future matcher kinds a compatible extension point. The amended body still carries the MUST-level normative statement and the permissive-composition NOTE per the triage.

3. Verification matcher — determinism critique accepted; two named resolutions. Agreed that a bare aao_verified string is not a deterministic binding predicate. The amended body ships the agent_url matcher as the V1 floor (canonicalization per the existing docs/reference/url-canonicalization.mdx rules that already govern accepted_verifiers), and specifies the verification matcher with the full determinism contract your comment outlines: authoritative registry + lookup, required agent role, applicable AdCP version, accepted verification modes, freshness/cache rule, and — reusing an existing convention — unresolvable verification fails with GOVERNANCE_UNAVAILABLE-class retryable semantics (the same principle specification.mdx already applies to an unreachable agent at check time), never with a definitive GOVERNANCE_AGENT_NOT_ACCEPTED. If the WG prefers to land URL-only and sever the verification matcher to a follow-up, the RFC is satisfied either way — but a URL-only V1 sharpens the allowlist-as-commercial-lever concern, so the non-discrimination MUST from the draft decision memo is in the body under both resolutions.

4. Scope and hygiene — accepted, with the advisory/authoritative split. The capabilities declaration is a seller-wide advisory default for discovery; the sync_governance response is authoritative per account and MAY reject a binding on account-specific grounds, carrying the applicable acceptance criteria in the typed error's details. This mirrors the pattern #6749 establishes for acceptance policies (discovery is advisory; the structured response is authoritative). Hygiene rules added as stated: a rejected binding MUST NOT be persisted, MUST NOT be contacted, and its credentials MUST NOT be echoed; absent-declaration and non-retroactivity semantics unchanged.

The amended Motivation also folds in the operational-stakes case from the delegation comment above: with resumes_execution a governed trigger (control-media-buy-request.json x-governed-commitment) and the unreachable-gate default being halt (specification.mdx), the bound agent controls not just checks but recovery — paused inventory stays stranded until an agent the seller never chose becomes available. Binding-time acceptance is the seller's one lever over that counterparty.

[lukasz-pubx]

Body amended per the comment above. Diff summary:

• Amendment note added at top with change provenance.
• Motivation: new block on recovery stakes — resumes_execution is a governed trigger (control-media-buy-request.json x-governed-commitment) and the unreachable-gate rule is normative halt (specification.mdx: "MUST NOT proceed … GOVERNANCE_UNAVAILABLE") — so the bound agent controls when paused inventory resumes, and the seller never chose it.
• Scope / placement: declaration rehomed from the governance capabilities block (gated on governance protocol support — a defect) to the cross-role adcp.governance_enforcement capability.
• Scope / structure: parallel agents[]/criteria[] replaced by a typed any_of matcher union; permissive-union MUST + misconfiguration NOTE; agent_url matcher reuses url-canonicalization.mdx rules (V1 floor); verification matcher fully specified (registry, role, adcp_version, verification_modes, max_age_seconds) with unresolvable verification failing retryable (GOVERNANCE_UNAVAILABLE-class), never as definitive GOVERNANCE_AGENT_NOT_ACCEPTED; URL-only V1 named as an acceptable alternative resolution.
• Scope / enforcement: scoping resolved as advisory capabilities declaration / authoritative per-account sync_governance response (mirroring RFC: structured seller acceptance-policy discovery backed by the policy registry #6749's discovery-advisory pattern); rejected-binding hygiene MUSTs (never persisted, contacted, or credential-echoed); non-discrimination MUST added.
• Alternatives: the originally filed parallel-fields shape recorded as considered-and-rejected per review.
• Files affected: added url-canonicalization.mdx row; schema index/changeset/compliance registry entries retained.