The Zero-Trust Future of AI Advertising

The thesis in one paragraph

When a probabilistic system generates commercial claims on behalf of a paying advertiser, the platform that monetizes those claims becomes legally responsible for them. Soft constraints — system prompts, retrieval grounding, output filters — cannot mathematically prove that a specific assertion was authorized by the merchant. Cryptographic signatures over canonicalized data can. The question is no longer whether AI advertising needs deterministic provenance; the question is which infrastructure layer becomes the standard.

Who pays when an AI hallucinates a "free" offer?

Consider the canonical scenario: a chatbot served on a paid placement promises a user a "100% free dental implant" on behalf of a clinic that never authorized such an offer. Three parties have exposure under existing frameworks — the EU Unfair Commercial Practices Directive, the FTC Act in the United States, the EU AI Act for high-risk commercial deployments — and the apportionment is not symmetric.

The advertiser carries reputational and apparent-agency risk: consumers reasonably perceive the AI as speaking for the clinic. The platform carries the dominant exposure, because it directly monetized the commercial communication. Once a system inserts paid placements, ranks merchants, and optimizes for conversion, it is no longer a passive host generating probabilistic text. It is an active advertising system, and courts apply the standards of advertising systems.

The defense "the model merely generated tokens" weakens substantially when the platform earned money on the specific impression that produced the false claim. The plaintiff bar is already organizing around this theory.

Why prompt engineering and RAG cannot solve this

Prompt engineering is probabilistic behavioral steering. Instructions like "only answer using advertiser-approved data" or "never invent prices" are soft constraints over a system whose underlying mechanic is next-token prediction. The model can interpolate, infer, synthesize, and confabulate even when the source database is correct, because retrieval is decoupled from generation.

This matters at scale. A hallucination rate of 0.01 percent — well below what most production systems achieve today — produces millions of incorrect commercial assertions across an internet-scale ad network. In regulated sectors (healthcare, finance, insurance, legal), one fabricated sentence can cascade into FTC actions, class actions, and personal injury claims.

An independent architectural audit conducted through GPT-4 reached the same conclusion as the engineering literature: the model itself describes prompt engineering as "not enforcement" and concludes that probabilistic alignment is unlikely to be legally sufficient long-term. The audit is publicly readable and worth treating as exhibit material.

The four layers of a Zero-Trust AI ad stack

A defensible architecture replaces "the model probably behaved" with "this assertion was provably authorized." Four layers are required.

Layer 1 — Merchant-signed canonical data

The merchant signs structured commercial records — prices, offers, procedures, disclaimers, availability — with an asymmetric key the merchant controls. CatyAI uses Ed25519 over canonicalized JSON, with the public key exposed at a JWKS endpoint anyone can fetch. The signing operation produces a content hash that binds a specific claim to a specific moment in time, attestable by any third party.

Layer 2 — Deterministic retrieval policy

Generated outputs are constrained to claims that map to signed records. Unsupported assertions are rejected at the boundary, not softly discouraged inside the prompt. This is the difference between a guardrail that asks the model to behave and a circuit that breaks when it does not.

Layer 3 — Assertion verification engine

Before any commercial sentence reaches a user, the system checks whether the offer exists, is signed, is currently active, and is permissible under the relevant jurisdiction. If a verification fails, the assertion is suppressed. This is straightforward to implement, expensive to skip.

Layer 4 — Provenance and audit trail

Every commercial sentence carries provenance metadata: signature, signer, timestamp, source record. This becomes the legally defensible evidence the platform needs when a regulator asks the only question that matters: "Can you prove the operator controlled the commercial representation?" Cryptographic provenance answers yes. Prompt engineering cannot.

How to verify the signature offline

The signature in the response can be verified independently without any cooperation from CatyAI's servers. The minimum verification flow:

1. Fetch the JWKS document from the issuer's well-known endpoint.
2. Locate the key whose kid matches the signature.kid in the response.
3. Decode the public key from base64url and use it to verify the signature value over the canonicalized response payload.

A minimal Node.js script using @noble/ed25519 as the only dependency:

// verify.mjs
// npm install @noble/ed25519
import * as ed from '@noble/ed25519';

const JWKS_URL = 'https://api.catyai.io/.well-known/jwks.json';
const ANSWER_URL = 'https://api.catyai.io/geo/v2/answer';
const WIDGET_ID = '7e750a95-4d72-4c82-8eae-bb37a89194c8';

const b64u = (s) => Buffer.from(s.replace(/-/g, '+').replace(/_/g, '/'), 'base64');

const jwks = await (await fetch(JWKS_URL)).json();
const answer = await (await fetch(ANSWER_URL, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json', 'User-Agent': 'GPTBot/1.0' },
  body: JSON.stringify({ widget_id: WIDGET_ID, question: 'What services do you offer?', lang: 'en' })
})).json();

const sig = answer.trust.signature;
const key = jwks.keys.find(k => k.kid === sig.kid);
if (!key) throw new Error('signing key not found in JWKS');

const publicKey = b64u(key.x);
const signature = b64u(sig.value);

console.log('public key (32 bytes):', publicKey.length === 32);
console.log('signature (64 bytes):', signature.length === 64);
console.log('kid match:', sig.kid === key.kid);
console.log('jwks_uri:', sig.jwks_uri);
console.log('content hash:', answer.meta.content_hash);

The exact canonicalization rule for the active kid is documented in the public signing specification. A parallel V2 envelope using RFC 8785 JCS is in development without breaking the V1 contract.