AI-Powered Advertising Systems Security

AI-Powered Advertising Systems Security

Introduction

Modern advertising platforms make AI-driven financial decisions on every ad request: what to bid, which product to rank first, whether a page is brand-safe, whether traffic is real, which touchpoint gets credit for a conversion. This guide gives builders the specific controls that stop the AI itself from becoming the attack surface. It applies across every ad-serving mode: programmatic, search, retail media, CTV/OTT (Connected TV and over-the-top streaming ads), DOOH (Digital Out-of-Home: billboards and digital screens), direct-sold, native, and mobile mediation. It covers classical machine learning (ML) on the live serving path (bid, floor, rank, recommendation, quality-score, attribution, brand-safety, invalid-traffic (IVT) / fraud detection). Controls specific to large language models (LLMs) and generative AI are in the companion guide, LLM and Generative AI Security in Advertising.

Terminology

Acronyms and specialized terms used throughout this guide. Each is also glossed inline the first time it appears in the body.

Ad-Serving Architecture and AI Touchpoints

Advertising is not one system. It is a family of markets that share one property: an AI model sits between the user and the money. Common roles across every mode:

• Buyer: advertiser or their agent. A DSP (Demand-Side Platform, e.g. The Trade Desk, DV360, Amazon DSP) is software that buys ad slots on the advertiser’s behalf. Wants to reach a user at a price.
• Seller: publisher, retailer, streaming service, DOOH network, app developer. Owns the place the ad shows up: a web page, an app screen, a video-ad break, a search-results page, a product-listing page, a billboard slot.
• Middleman: SSP (Supply-Side Platform, e.g. Magnite, PubMatic, OpenX; software that sells the seller’s inventory), exchange, ad server, retailer ad platform, mediation network (routes app ad requests across multiple ad networks), attribution vendor (measures which ad drove which conversion). Runs the marketplace or the measurement.
• User: the person the ad reaches, or the query the ad answers.

Ad-serving modes and their AI touchpoints:

Three properties make securing AI in advertising distinctive, regardless of mode:

1. Your adversary is inside your permission perimeter. Whichever mode you run (programmatic, search, retail media, direct-sold), the entity probing your model is a paying customer with contracted access. The DSP watches your floor prices to reverse-engineer your bid-shading. The search advertiser games your quality score. The retail seller manipulates your product-rank model. You cannot block them like a scraper; the defense is to bound how much your model gives away per query.
2. Training data is adversary-writable participant traffic. In ad-tech, models learn from whatever the outside world sends you: bid requests, search queries, purchase events, viewer telemetry, publisher-supplied content, DOOH sensor feeds. Every participant in the market has write access to your next model refresh, right now, at line rate.
3. Every decision moves money on the live path. Every mode runs against a hard latency budget: the timeout the SSP declares in programmatic bidding, sub-second ranking in retail and search, playback deadlines for CTV ad-pod selection. Defenses that add compute per decision get expensive fast at scale, and a model that times out becomes a real denial-of-service vector.

Scope. Sections apply broadly across the modes above; individual bullets name programmatic, search, retail media, CTV, direct-sold, DOOH, or SDK examples where the manifestation differs. The companion guide covers the controls specific to large language models and generative AI: prompt injection, retrieval-augmented generation, cross-tenant isolation, agentic bidders, and generative creative provenance.

1. Gate Every Model Call on Consent

In an AI-powered stack, the model call is itself the regulated processing event. Running a personalization, targeting, ranking, recommendation, quality-score, or lookalike model on a user is profiling under GDPR Art. 4(4), regardless of whether the mode is programmatic, search, retail, CTV, or direct-sold. Traditional ad-tech gates run consent checks just before the system writes a tracking identifier (browser cookie, mobile ad ID, hashed-email), which is the point where identity gets persisted. That is too late for AI: the model has already read the user’s features and produced a scored decision by the time you get there. Run the consent check earlier, on the model call itself.

Controls:

• Treat consent as an authorization check, not a model feature. A model that receives consent as a feature learns to route around it via correlated auxiliary features. Applies to every AI touchpoint that reads user data: bid model, search intent model, retail recommender, CTV context classifier, DOOH audience predictor.
• Refuse the model call on child-directed traffic. Signals vary per mode: regs.coppa == 1 (the OpenRTB flag for a child-directed impression under the US Children’s Online Privacy Protection Act, as amended in 2025) for programmatic; child-account flag in retail media; kids-profile flag in CTV; safe-search-with-child-account in search. Stripping identifiers is not enough: a model with device, context, or content features still produces a personalized output. Route child-flagged traffic to a rules-based path with no AI invocation.
• Consent-scope the training corpus. A model must not train on rows where the user did not consent to the specific Purpose that model implements. (Under the Interactive Advertising Bureau (IAB) Europe Transparency & Consent Framework (TCF), whose stored Transparency & Consent (TC) strings are personal data under CJEU C-604/22 where they can reasonably be linked to an identifier, “Purposes” are numbered categories of processing; Purpose 4 = use profiles to select personalised advertising.) A model trained on non-consented data stays contaminated even if inference is gated later, so pair GDPR Art. 17 (Right to erasure) with a retraining or approved machine-unlearning cycle. The Purpose-scope rule also applies within a single participant: in retail media, a shopper’s purchase history is consented for order fulfillment, not automatically for advertising training. Treat those as separate Purposes with their own retention windows and training-admission flags.
• Honor real-time opt-outs at every AI touchpoint, not just at the ad-serving gate. Users can withdraw consent through several channels; each of them must gate the model call:
  • Browser. The Global Privacy Control Sec-GPC: 1 HTTP header, signaling do-not-sell / do-not-share under US state laws.
  • Bid request. State-law opt-out flags carried inside regs.gpp, the OpenRTB Global Privacy Platform string. The IAB GPP Section Information registry maps each Section ID to a state law.
  • Retailer. The shopper’s opt-out preferences on the retailer’s site.
  • Streamer. The viewer’s personalization-off setting on the streaming service.
  • Device OS. iOS App Tracking Transparency or Android’s Advertising ID reset / opt-out.

  Bind the check to the feature-fetch step, which runs before the model call. Pipelines that pre-fetch features and cache them for a batch run will otherwise keep serving pre-opt-out features minutes after the user withdrew consent; the ad-serving gate looks correct even though the model has already run on stale-consent data.

• Invalidate downstream materializations on opt-out: segment memberships, lookalike scores, cached embeddings, precomputed rankings, retail-recommendation caches, CTV audience-segment memberships. Clearing only the ad-serving cache is not enough. If the user’s identity still sits inside a lookalike segment, an audience-segment table, or a retail-recommendation store, the next ad decision reads it right back out and personalizes to them again. The serving-side cache is the wrong layer to invalidate.
• Test models for special-category inference, not just special-category inputs. GDPR Art. 9 defines special-category data (health, sexual orientation, religion, ethnicity, political opinion, biometrics, genetics) as data that carries extra restrictions. The EU Digital Services Act (DSA), at Art. 26(3), restricts ad targeting based on profiling that uses that data. A model that infers those categories from generic inputs is inside the restriction. Applies to every classifier: contextual, brand-safety, retail-recommendation (health-adjacent products), search-intent, CTV genre-preference. Score model outputs for special-category correlation and gate accordingly.
• Route high-stakes campaign categories through a stricter path. Employment, housing, and credit ads sit closest to EU AI Act high-risk uses. Under Art. 6 plus Annex III point 4(a), AI systems used to place targeted job advertisements are explicitly listed as high-risk. This applies across modes: a job ad delivered via search, retail media, or direct-sold is under the same obligation as one placed programmatically.
• Treat any consent signal you don’t recognize as “no consent”, and enforce that at the moment the request arrives, not later at the ad-decision boundary. Once a request is written to your training corpus, the next model refresh will learn from it even if the ad itself was blocked at serve time; silent admission is the poisoning path. The rule surfaces differently per mode. In programmatic, drop any bid request whose GPP Section ID your parser doesn’t recognize. Each Section ID maps to one jurisdiction’s consent rules (2 = TCF EU, 8 = California), and the registry grows every time a US state passes a new privacy law. In retail media, the equivalent is an unrecognized retailer consent flag; in CTV, an unrecognized platform consent state. Whatever the mode, the discipline is the same: reject at the door, log the reason code, and never let the row enter the corpus.

2. Protect the Training Corpus

Your training data is being written by the outside world, live, in real time, in every ad-serving mode. Every bid request, search query, purchase event, viewer session, publisher content upload, sensor feed, and beacon is a potential training row, and every adversary who participates has write access.

Cross-mode training-corpus surfaces:

Controls:

• Sign dataset manifests with an offline key the data store cannot access, and include the participant-provenance tag per row. The OWASP Secure AI/ML Model Ops Cheat Sheet covers the generic model-artifact-integrity baseline: digital signatures on model artifacts and access-controlled registries. The ad-tech-specific requirement is that the signed manifest binds each row to its participant-provenance tag (partner ID, supply-chain hop, validation profile). That tag is what makes the scoped-rollback query (“exclude every row that came from partner X during window Y”) answerable without re-hashing the whole corpus. A generic signed manifest without provenance tagging still lets you detect whether rows changed, but not which partner’s rows to exclude on a compromise.
• Quarantine outcome feedback until adjudication concludes. The quarantine window must exceed the mode’s adjudication lag: fraud adjudication (programmatic, CTV, DOOH), return or refund adjudication in retail (a conversion’s label can flip weeks later), click-validity adjudication (search), engagement re-scoring (native). Rows admitted before adjudication cannot be un-trained without a full retrain or unlearning cycle.
• Reconcile outcome events against post-hoc validity verdicts before admitting them to training. When an event that passed verification at fire-time is later reclassified as invalid, the label it produced is poisoned. Exclude the row from training; do not just down-weight it. Concrete cases per mode:
  • Programmatic / CTV: a beacon that passed signature verification (HMAC) but referenced an impression later flagged as sophisticated invalid traffic (SIVT, defined in the MRC Invalid Traffic Detection and Filtration Guidelines).
  • Retail media: a purchase later reversed for fraud.
  • Search: a click later charged back as invalid.
• Exclude a compromised participant’s rows at the next retrain. When a participant is later found compromised or bad-acting (a spoofing SSP, a gaming retail seller, a fraudulent search advertiser, a compromised publisher feed, a gaming SDK partner), the participant-provenance tag from the signed manifest is the primary key: run the scoped exclusion query and retrain without their rows.
• Run trigger-scanning on every refreshed model to catch backdoor attacks; aggregate-based defenses miss them by design. Availability poisoning degrades a model’s overall accuracy and shows up in outlier detection such as median absolute deviation (MAD). Backdoors (NIST AI 100-2e2025 Section 2.3.3) work differently. An attacker plants a trigger (a specific input pattern, say a particular device.sua combination or a rare keyword) that forces the model to a wrong output whenever the trigger appears. On every other input the model behaves normally, so overall accuracy and aggregate distributions look clean, and aggregate-only monitors see nothing wrong. Neuron-activation clustering and spectral signatures are the two mature trigger-scanning techniques. Applies to every classifier: brand-safety, contextual, retail-recommendation, search-quality, IVT, CTV context.
• Normalize participant-supplied text before classifier inference. Apply Unicode NFC normalization, strip zero-width characters, and strip bidirectional-control characters on publisher pages (programmatic), seller product descriptions and reviews (retail media), landing-page snippets (search), and creative text (all modes). Attackers use homoglyphs (a Cyrillic а swapped in for Latin a) and adversarial-suffix payloads to slip content past classifier keyword filters.
• Reconcile crawler vs. rendered view. Server-side cloaking shows one page to your crawler and another to users. Refuse contextual segments derived from pages whose crawler view diverges from a headless-render view. Analogous concern in retail media: reconcile the API-returned product description with the customer-facing rendered product page.
• Run champion/challenger monitoring on clean holdout traffic. It catches drift and slow-burn poisoning across all modes. A challenger model runs beside the incumbent on the same traffic, and a gap between them that opens on one partner’s segment is the signal.

3. Protect Models at Inference

In ad-tech, model inference is a public-facing product. Every scoring surface you expose to a paying partner is an oracle they can query legitimately, at contracted volume, for years. The DSP watches the price on your bid response, the search advertiser observes where their ad ranked, the retail seller measures how your sponsored-rank model treated their listing. Each observation is legal traffic under your contract, and each one gives them a data point about your model. In a normal API-security setting you would rate-limit or block a client that queried a model this heavily; in ad-tech that client is your paying customer, and cutting them off is not an option. The defense is architectural: bound how much your model reveals per query, detect the query patterns that signal extraction intent, and cap the compute spent per query so an adversary cannot exhaust your latency or cost budget.

In this section, inference means running the model to produce an output: the model call, seen from the model’s side of the boundary.

Cross-mode inference oracles:

Threats a participant runs against you at inference (same taxonomy, every mode):

Controls:

• Coarsen output tiers on every scoring surface exposed to partners. Bucket segment scores into a few tiers; jitter ranks; expose tier labels (“high / medium / low”) rather than raw probabilities. This does not apply to money fields required by the protocol: seatbid.bid.price in OpenRTB (the bid amount the buyer submits for the impression), ad-rank values in search API responses, sponsored-rank position in retail-media reporting. Coarsening the money field breaks the market. Protect the money path with probing detection and query budgets instead.
• Enforce contractual query budgets technically. A partner querying your models at volumes disproportionate to their legitimate transaction volume is doing extraction. This applies whether the partner is a DSP, a search advertiser using a bulk API, a retail seller, or an SDK partner running mediation.
• Detect probing patterns. Single-feature perturbation at volume from one partner is adversarial exploration. Watch for near-identical requests with one feature varied. The signature looks the same in programmatic (bid requests), search (query variations), and retail (product-listing probes).
• Bound feature values at inference; reject rather than coerce. Reject out-of-domain feature values outright: future timestamps, negative money fields, physically impossible device combinations, product IDs that do not exist, query strings past length caps. This blocks a large class of evasion inputs before they reach the model.
• Cap inference cost per call. Bound decode, hop, and iteration counts inside the model call. Detect per-partner inference-latency and cost outliers; feed sustained outliers into the rate limiter.
• Add differential-privacy (DP) noise during training where per-user scores must be exposed. DP is a mathematical technique that adds calibrated random noise so outputs cannot be traced back to any single user. The cumulative privacy loss is measured by a budget called epsilon; the larger the accumulated epsilon, the weaker the protection. Fix the training-time epsilon per model version. Where a reporting or overlap interface answers per-user or small-cohort queries through a DP mechanism, track per-partner and per-model epsilon spend across sessions; repeated queries compose.
• Enforce a per-partner cost budget on any paid third-party AI API call (dollars per minute, not just requests per minute). Any mode that routes brand-safety, contextual, or recommendation decisions through a third-party LLM or vision API is exposed to economic denial-of-wallet.
• Monitor score-vs-realized-outcome divergence per partner. An extraction adversary stops caring about realized outcomes; their pattern optimizes for the model’s score, not the conversion, purchase, or click. Applies across modes: DSP behavior vs. actual click-through, search-advertiser behavior vs. actual quality-score outcomes, retail-seller behavior vs. actual purchase rate, SDK-partner behavior vs. actual LTV.

4. Protect Outcome Events and the API Boundary

Every outcome callback your infrastructure receives is money and a training label in the same packet. A forged conversion beacon is payment fraud and a poisoned training row, in every ad-serving mode. A compromised API boundary is the fastest route into your training pipeline: whatever an attacker writes across that boundary becomes tomorrow’s training data before you can rotate the credential that let them in.

This section uses two working terms. Outcome event covers any callback a partner fires when something happens on the ad-serving path: impression beacons, click pings, conversion beacons, retail purchase confirmations, CTV completion events, attribution postbacks. (the training-surface table in Section 2 lists mode-specific examples of these; the general term extends the same idea to retail and search cases.) API boundary covers every server-to-server integration point where those callbacks (plus bid requests, retail-media API calls, search-partner API calls, DOOH scheduling calls, mediation SDK traffic) reach your infrastructure.

Outcome-event signing

Generic signed-webhook hygiene (HMAC construction, freshness bounds, replay protection, constant-time comparison) is well-covered in the OWASP crypto guidance and shared-secret patterns; the ad-tech-specific requirements on top of that baseline:

• Bind event_type into the signature, not just the event ID. Ad-tech outcome events are polymorphic in a way generic webhooks are not: the same impression_id can validly appear in an impression callback, a viewability callback, a click callback, and a conversion callback. If event_type is not in the signed set, a captured impression beacon can be replayed as a conversion (and become a poisoned training label as well as payment fraud). Sign at minimum: key_id, event_type, event ID (impression_id, order_id, or click_id), timestamp, monetary value (payout_micros or currency-amount), and the receiving endpoint. Use HMAC-SHA256 over a length-prefixed canonicalization, or use RFC 9421 HTTP Message Signatures. If you use RFC 9421, the receiver must enforce a required-minimum covered-components set (RFC 9421 Section 3.2.1 Enforcing Application Requirements; Section 7.2.1 Insufficient Coverage explains why).
• Dedup on the event ID alone within a TTL window, never on (event_id, timestamp). This is ad-tech-specific: a partner-side signer that holds a valid key can otherwise re-sign the same impression_id with fresh in-window timestamps and credit the same impression many times. That is different behavior from a generic webhook, where the sender is trusted not to re-sign.
• Verify the HMAC first, before any payload field influences a control-flow decision. Ad-tech outcome flows chain freshness → endpoint-match → dedup → credit; running any of those on an unauthenticated timestamp or endpoint value is trusting adversary input.

Label integrity for training

• Separate financial settlement from training-label materialization. Billing may credit immediately on freshness+HMAC; the training corpus should not admit the row until adjudication concludes (fraud in programmatic and CTV; return/refund in retail; click-validity in search).
• Weight training samples by per-partner label credibility. Score partners on historical clawback, refund, and invalid-click rates, and feed that score as a sample weight in the next training cycle.
• Cap per-user influence in training (per-user gradient clipping). Bounds the damage from a burst of forged conversions.
• Protect attribution-model integrity. MMM and MTA models train on the outcome events above. Poisoned outcome events poison every attribution decision downstream, which in turn poisons budget allocation across every ad-serving mode. Sign attribution inputs the same way; version the attribution model per participant-provenance window so scoped rollback is possible.

API-boundary authentication

Generic JWT hardening (algorithm confusion, signature verification, key trust) is covered in the OWASP JSON Web Token Cheat Sheet; the two ad-tech-specific requirements on top of that baseline, plus the mTLS pinning below:

• Pin the certificate identity to a specific partner_id, not just to a trusted issuer. Chain-to-trusted-issuer alone lets any cert issued by the same shared CA authenticate as any partner, which is a real problem in ad-tech because many DSP, SSP, and retail-media partners buy certificates from the same handful of enterprise CAs. Pin the SAN, CN, or SPKI hash to the concrete partner_id your rows are tagged with, so an attacker cert cannot silently become a different partner in your training-corpus provenance.
• Auth incidents are data incidents in an AI stack. On credential rotation or partner compromise, three things happen in lockstep: (1) mark training rows attributed to that partner during the exposure window as suspect, retrain or exclude on the next refresh; (2) invalidate per-partner sample weights, credibility scores, and fraud-model features derived from that partner’s traffic during the window; (3) invalidate signed model artifacts whose training set overlapped the window. Rotating the credential ends the auth incident; leaving the poisoned rows in the corpus does not end the data incident.

5. Protect the AI Supply Chain

An attacker can compromise your models without touching a single user request. Model files, feature stores, audience data stores, and classifier pipelines are all reachable through paths that never cross the ad-serving surface: a poisoned artifact loaded at deploy time, an unauthorized write to a feature store, a vendor-supplied classifier that arrives with a backdoor already baked in. This section covers the five supply-chain surfaces specific to AI in ad-tech: model artifacts, the feature and audience-data stores, the fraud and quality classifiers, the creative pipeline those classifiers review, and the participant-provenance verification that decides which rows become training data at all.

Model artifacts

Generic model-artifact hygiene (preferring inert file formats, signing artifacts before deploy, keeping an ML bill of materials) is covered by the OWASP Secure AI/ML Model Ops Cheat Sheet. Two ad-tech-specific rules go on top of that baseline:

• Trigger-scan every externally sourced classifier before it reaches the serving path. Vendor-supplied brand-safety and IVT classifiers are the highest-risk artifact class in ad-tech: they arrive pre-trained on a corpus you did not control, and signing them (via OpenSSF Model Signing) verifies who trained the model but not what it learned. Pair signing with the trigger-scanning behavioral test from Section 2 for every vendor artifact. Ad platforms routinely swap in third-party brand-safety and IVT classifiers, unlike most other industries.
• Bind ML-BOM entries to the participant-provenance tag from Section 2. A CycloneDX 1.7 ML-BOM that lists datasets by name only cannot answer the operational question “which training rows came from partner X during window Y?” when that partner is later compromised. Treat the ML-BOM as the primary key for scoped retraining, not just an audit deliverable.

Feature store and audience data store

• Purpose-scope namespaces. A fraud model must not read features materialized for personalization. A retail sponsored-rank model must not read features materialized for organic recommendation. A search quality-score model must not read features materialized for retargeting. Different Purpose, different namespace, different access grant.
• Version-pin feature schemas per model version in the model registry.
• Feature-store and audience-store outputs are personal data. Segment memberships, lookalike scores, predicted attributes, retail-audience assignments, CTV cross-device linkages, and search-user-cohort assignments are all model outputs regulated as personal data under GDPR and multiple US state laws. The consent gate applies to reads, not only to model calls.
• Write access is a persistent poisoning surface. Rotate materialization-write credentials with the same cadence as production secrets. Applies to every audience data store: retail 1P data (first-party data, meaning information a company collects directly from its own customers), publisher 1P data, DMPs (Data Management Platforms, third-party audience-data warehouses that ingest data from many sources), CDPs (Customer Data Platforms, first-party equivalents that a brand runs against its own customers), and mobile stores fed by MMPs (Mobile Measurement Partners, attribution vendors like AppsFlyer or Adjust).

Fraud / IVT and quality classifiers

• These classifiers are themselves attack targets, on both the evasion and poisoning axes: programmatic IVT and SIVT classifiers; search click-fraud classifiers; retail fake-review and gaming-seller classifiers; CTV viewer-fraud classifiers; DOOH crowd-count spoofing detectors; SDK install-fraud classifiers.
• Train exclusively on verified-clean traffic. If adversaries can write to the training data, they teach the classifier that adversarial behavior is legitimate.
• Run champion/challenger comparisons on a clean holdout per partner. A detection model that degrades only on one partner’s traffic is a poisoning or evasion signal.
• Refresh training corpora with generative-AI-driven traffic samples. Behavioral classifiers trained before 2024 rarely include synthetic-interaction distributions.
• Verify request authenticity in two tiers. Where the platform offers device attestation, require a token bound to a challenge your own server just issued; accept only fresh attestations, never relayed ones. Examples: Google Play Integrity, Apple App Attest. Where the platform does not offer device attestation (most Smart-TV OSes and set-top boxes today), fall back to authenticating the supply path itself with cryptographic server-to-server auth like ads.cert 2.0 in programmatic, or equivalent partner-auth mechanisms in retail media and search, combined with behavioral-signal scoring on the request itself.

Ad creative and content validation

Creative reaches three AI consumers regardless of mode: LLM/classifier review (see the companion guide, LLM and Generative AI Security in Advertising), the renderer (defer to the CSP and XXE Prevention cheat sheets), and the provenance chain (also the companion guide). For the classifier-hygiene rules that belong in this guide:

• Normalize creative text to NFC and strip zero-width and bidi-control characters before review and rendering. Applies to programmatic display creatives, search ad copy, retail product descriptions and titles, CTV VAST creative metadata (Video Ad Serving Template, the IAB standard XML format for video ads), native content copy, and DOOH creative captions.
• Two-tier review. Deterministic filters (denylists, landing-page checks, the normalization above) run first, LLM semantic review runs second, with confidence thresholding between them.
• Reject VPAID creatives outright in video-programmatic and CTV. VPAID (Video Player-Ad Interface Definition) was a VAST extension that let a video ad ship its own JavaScript to run inside the player (the source of most malicious-video-ad incidents). VPAID was deprecated in VAST 4.1 and replaced by SIMID (Secure Interactive Media Interface Definition, a locked-down interactivity API) in VAST 4.2. Sandboxing VPAID is not viable; reject.

Supply / participant provenance for training-data admission

• Programmatic: verify ads.txt and app-ads.txt on every request, walk the full OpenRTB SupplyChain object, and exclude training rows from spoofing sellers on the next retrain. ads.txt is a public file at a website’s root listing which sellers may sell its ad inventory; app-ads.txt is the mobile-app equivalent, which lives on the app developer’s website domain and is resolved through an app-store lookup of the OpenRTB app.bundle (the app’s store package ID). The SupplyChain object is the ordered list of intermediaries that touched a bid request, letting the buyer verify every hop back to the publisher.
• Retail media: verify seller-ID authorization for product-catalog uploads; enforce provenance of purchase-history joins; exclude gaming-seller training rows on retrain.
• Search: verify advertiser-domain ownership for landing-page-quality signals used in training.
• Direct-sold: verify first-party audience-data provenance from publisher partners; sign the audience-file manifest at ingress.
• CTV / OTT: verify device-attestation origin for viewer telemetry; treat unattested telemetry as lower-credibility training signal.
• All modes: every training row carries its participant-provenance tag; when a participant is compromised or excluded, the tag is the primary key for scoped retraining.

References

Regulations:

• GDPR (Regulation 2016/679): profiling under Art. 4(4); erasure under Art. 17
• EU AI Act (Regulation 2024/1689): high-risk classification under Art. 6; Annex III point 4(a) (targeted job advertising); Art. 50 transparency
• DSA (Regulation 2022/2065): Art. 26(1), 26(3), 28(2)
• COPPA Rule 90 FR 16918: compliance date 22 April 2026
• CJEU C-604/22 (ECLI:EU:C:2024:214, 7 March 2024): TC string is personal data

Ad-tech specifications:

• OpenRTB Specification (IAB Tech Lab)
• ads.txt and sellers.json
• OpenRTB SupplyChain Object specification
• IAB Europe TCF
• IAB Tech Lab GPP Section Information registry
• VAST, SIMID
• ads.cert 2.0

Standards and frameworks:

• RFC 8725: JSON Web Token Best Current Practices
• RFC 9421: HTTP Message Signatures
• OpenSSF Model Signing
• CycloneDX 1.7 ML-BOM
• safetensors
• Google Play Integrity, Apple App Attest

Adversarial ML anchors:

• NIST AI 100-2e2025: Adversarial Machine Learning Taxonomy
• MITRE ATLAS
• Tramèr et al. 2016, USENIX Security: model extraction
• Shokri et al. 2017, IEEE S&P: membership inference
• Fredrikson et al. 2015, ACM CCS: model inversion
• Shumailov et al. 2021, EuroS&P: sponge examples

Companion pages:

• LLM and Generative AI Security in Advertising, the companion guide covering the LLM input boundary, retrieval trust, cross-tenant isolation, agentic ad management, and generative provenance
• AI-Powered Advertising Systems Security Cheat Sheet, the concise checklist covering both guides, in the OWASP Cheat Sheet Series

Related OWASP cheat sheets:

• Secure AI/ML Model Ops Cheat Sheet
• AI Agent Security Cheat Sheet
• LLM Prompt Injection Prevention Cheat Sheet
• JSON Web Token Cheat Sheet
• Content Security Policy Cheat Sheet
• XML External Entity Prevention Cheat Sheet
• Denial of Service Cheat Sheet