Brand safety is a pre-render check, not a post-hoc audit.

Why post-hoc verification fails on agent surfaces

Post-hoc verification was designed for an environment where ads loaded fast, in volumes too high to inspect each one, into pages with stable, long-lived content. None of those assumptions hold on agent surfaces:

• Volume is decision-bound, not impression-bound. An agent makes one placement decision at a time, with milliseconds-to-seconds to think; it can afford to verify before placing.
• Content is just-generated, not long-lived. There is no archived page to scan after the impression; the surface is the conversation moment, and that moment is gone after render.
• The impression is the brand association. By the time a post-hoc verification vendor flags a problem, the user has already seen the ad next to whatever content the agent surfaced.

Post-hoc verification arrives too late on a surface that exists for an instant.

What "pre-render verification" actually checks

Before the agent renders an ad, the verification step answers four questions:

1. Is the sponsor real? Fetch the sponsor's manifest at /.well-known/agent-ad.json. Confirm it parses, matches the advertiser identity in the candidate, and is active according to the manifest/feed status.
2. Is the declaration verifiable? Check the attestation method declared in the manifest (signature, watermark, or other). Verify against the public attestation surface the manifest references.
3. Is this signal currently eligible? Fetch the broadcast feed (/.well-known/abf.json + /.well-known/abf-index.json). Confirm the candidate ad is in the current eligibility window, with the expected ranking signals intact.
4. Is the placement context appropriate? Read the FCS provenance headers on the surrounding content (where the ad would render). Confirm content provenance matches the sponsor's declared category and placement constraints.

If all four return true, the placement is safe to render. If any returns false, the agent rejects the placement and moves to the next candidate or to no-ad.

The whole check is mechanical, takes one round of fetches against stable known paths, and runs before the ad is rendered.

The artifacts the check reads

Path	What the check reads from it
/.well-known/agent-ad.json	Sponsor identity, attestation method, declared category and placement constraints
/.well-known/abf.json	Current eligibility of the candidate ad signal
/.well-known/abf-index.json	Index of currently-active signals, for fast lookup
Response headers of surrounding content	FCS provenance — what model, what publisher, what signature

All four are public. None require an account, an API key, or a per-request authentication step. The verification flow is symmetric across implementations.

Where this fits relative to OpenAI Ads

OpenAI Ads enforces its own ad policies before ads enter the system, and provides brand-safety controls in the Ads Manager dashboard. That is buyer-side policy enforcement on a single platform.

Pre-render verification, as described here, is the runtime check on the agent's side, independent of which ad system the candidate came from. It runs against public artifacts the candidate exposes, so it does not require a per-platform integration — an agent runtime that adopts ABF-style verification can apply the same check to candidates from any ad system that publishes the necessary artifacts.

OpenAI Ads handles policy enforcement on its surface. Pre-render verification handles runtime check on agent surfaces. They are complementary, not competing.

What pre-render verification is not

• Not a content-classification system — it does not score content for "safety"; it checks declared eligibility against the sponsor's declared category and placement constraints.
• Not a replacement for ad policies — policies define what may exist; verification checks whether a specific instance is real, eligible, and contextually permitted right now.
• Not a brand-safety guarantee — it reduces a class of failure modes (rendering inactive, expired, or misdeclared ads), it does not eliminate all of them.
• Not a tracking system — no user identifier participates in any of the four checks.
• Not a partnership with any ad platform.

How the relevance function feeds in

The verification step does not select ads — that is the relevance function's job (see sister page). The relevance function produces a ranked candidate set; verification runs against the top candidates in order, accepting the first one that passes all four checks.

• Relevance (sister) answers: which ads could appropriately match this moment?
• Verification (this page) answers: for the top candidate, is it safe to render right now?

If the top candidate fails verification, a conservative runtime can move to the next candidate or render no ad. This is a recommendation, not a normative rule of the ABF spec — it lets pre-render verification be conservative without breaking the agent's response.

How to adopt the verification flow

Three things an agent runtime does:

1. Fetch the sponsor manifest for each top candidate and verify the attestation method declared.
2. Fetch the broadcast feed and confirm eligibility/ranking for the candidate.
3. Read FCS provenance on the content where the ad would render; check category compatibility.

A reference verification flow, including failure-mode handling and retry policy, will live in the ABF integration guide at /docs/abf/ (dedicated brand-safety docs to be drafted separately).