RFC: augment_creative — Operator-Controlled Runtime Creative Augmentation via Governance Agent with Signed Attestation

[bryanSigma]

Motivation

The IAB Open Measurement SDK (OMSDK) demonstrated that injecting scripts into creatives at render time is a valid, valuable pattern in ad tech. OMSDK applies this for buyer-side verification — measurement and brand protection vendors inject code that runs when the creative renders in the user's browser.

That pattern is powerful. This RFC proposes an open architecture inspired by it — but operator-controlled, not buyer-controlled, and not limited to any single use case. The sales agent operator decides which governance agents are called, for which publishers, and with what failure behavior. The protocol provides the mechanism; the operator provides the policy.

The immediate use case is runtime security protection. Other applications — render pixel counts, viewability instrumentation, and similar seller-side augmentation — follow naturally from the same architecture.

Problem

AdCP currently supports security scanning via get_creative_features, which detects malicious patterns and rejects creatives before trafficking. This is valuable but insufficient — it only addresses known-bad creatives at submission time.

It does not address:

• Zero-day payloads that evade static scanning
• Creatives that pass scanning but are later compromised at the CDN level
• Runtime behavior that only manifests at render time in the user's browser
• Security scanning is detection. Runtime augmentation is protection. Both are needed; neither replaces the other.

Architecture

Buyer             Sales Agent         Governance Agent     Ad Server
  |                   |                     |                  |
  |--sync_creatives-->|                     |                  |
  |                   |--get_adcp_capab.--->|                  |
  |                   |<-creative-augment.--|                  |
  |                   |--augment_creative-->|                  |
  |                   |  (creative manifest)|                  |
  |                   |                     |[generate script] |
  |                   |<-augmented artifact-|                  |
  |                   |  + augment_receipt  |                  |
  |                   |--traffic augmented artifact----------->|
  |                   |[store augment_receipt]                 |

Key properties:

• The original creative manifest is never modified — the buyer's creative is preserved untouched
• The augmented artifact is a new object produced by the governance agent
• The governance agent generates the payload dynamically — context-aware scripts per creative, placement, or campaign
• The sales agent stores the signed receipt alongside the creative for audit
• The buyer has no role in this flow — augmentation is entirely operator-side

Proposal

1. A new augment_creative task on the governance agent

A vendor builds and operates a governance agent exposing augment_creative. The task accepts a creative manifest and returns an augmented artifact with the vendor's script prepended, plus a signed augment_receipt.

Capability declaration via get_adcp_capabilities:

{
  "supported_protocols": ["governance"],
  "specialisms": ["creative-augmentation"]
}

creative-augmentation is a specialism within the governance domain — same domain as get_creative_features. Declaring it without governance in supported_protocols is invalid and MUST be rejected.

2. Sales agent operator configuration

The sales agent operator configures which governance agents to call per publisher entirely within the sales agent's operator configuration. Opt-in — no publisher declaration required, no buyer involvement. Commercial arrangements between operator, vendors, and publishers are out of scope.

Multiple agents can be registered per publisher, called in declaration order, each prepending its payload sequentially.

3. A mandatory hook point in the creative trafficking flow

If a governance agent supporting creative-augmentation is registered in the sales agent's operator configuration for a given publisher, the sales agent MUST call augment_creative before trafficking.

The spec's consistent pattern is that declared or registered capabilities are enforced, not suggested — accepted_verifiers[] on creative_policy and check_governance on campaign plans both follow this model. A MAY requirement would leave publishers exposed and remove the audit trail. MUST is the only posture consistent with operator accountability.

Failure handling — per-agent mode field:

Mode	Behavior on failure
required	Trafficking blocked. Error surfaced to operator. Creative held until augmentation succeeds or operator reconfigures.
best_effort	Trafficking proceeds without augmentation. Warning logged. Operator notified.

required is recommended for security use cases. best_effort for non-critical augmentation where continuity matters more than guaranteed injection.

Attestation: signed augment_receipt

Each augment_creative response includes a signed receipt composing with creative_policy.accepted_verifiers[] — a single provenance chain, not a parallel one.

{
  "augment_receipt": {
    "agent_url": "https://augment.securityvendor.example.com",
    "creative_id": "abc123",
    "payload_hash": "<sha256 of prepended script>",
    "timestamp": "2026-05-01T12:00:00Z",
    "signature": "<vendor private key signature>"
  }
}

Vendors manage their own signing keys. Any party holding the artifact can verify it was augmented only by declared agents.

What this is not

• Not buyer-controlled (augmentation is operator-configured; buyer's manifest is never modified)
• Not publisher-controlled (operator decides which agents run; publisher awareness is commercial, out of scope)
• Not a change to adagents.json (operator-side orchestration only)
• Not a replacement for get_creative_features (complementary layers — scan at submission, augment at trafficking).

Open questions for the working group

• Should the spec cap the number of registered augmentation agents per publisher to bound latency?
• Should augmentation agents declare max_latency_ms in get_adcp_capabilities?
• Should a future RFC add a seller-readable section to adagents.json for publisher-declared augmentation agent preferences?
• Should the hook apply to already-trafficked creatives when a new augmentation agent is registered?

Relevant working groups

Creative (creative-wg)
Governance Protocols (brand-standards-wg)

Related spec

get_creative_features
Creative Governance
Provenance Verification
adagents.json Tech Spec

[bokelley]

Triage

Classification: RFC / Proposal
Bucket(s): spec / protocol, governance
Status: deferred — out of current cycle

My take: This is a well-motivated RFC proposing a new augment_creative task type on governance agents — complementing static get_creative_features scanning with operator-controlled runtime injection and signed attestation. It's not in the active 3.1 scoping window, and the open questions the author flags (latency caps, max_latency_ms capability declaration, adagents.json seller-readable preferences, retroactive application to already-trafficked creatives) are exactly the kind of WG-track questions that need creative-wg and brand-standards-wg input before a spec PR can take shape — flagging to those groups for their next cycle.

---

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

---

Generated by Claude Code

[pkras]

note from governance summit:

The RFC currently defines augmentation as purely operator/seller-controlled, which is the right default. However, it doesn't address the case where a brand has a preferred augmentation vendor. Suggesting the following resolution model:

If the seller has a required vendor → that vendor runs, full stop. Buyer preference is not considered. Augmentation is a condition of transacting on that inventory, analogous to a publisher-required viewability tag today.
If the seller has no requirement → both the seller's and brand's preferred vendors wrap independently. This reflects how tag-stacking works in practice today, and avoids forcing a priority decision when neither party has a hard requirement.