Standards & Protocols Reference

Privacy & Consent Standards.

The consent strings, deletion frameworks, taxonomies, browser APIs, and OS-level constraints that govern what advertising systems can do.

Agentic advertising needs more than task protocols. It needs permission boundaries. Consent, regional privacy strings, deletion requests, platform APIs, browser controls, operating-system rules, and output policy all define what agents and platforms are allowed to execute.

The permission and policy layer — seven inputs resolve into six decisions about what an advertising system may do. THE PERMISSION AND POLICY LAYER SIGNALS IN DECISIONS OUT User choice — opt-ins, opt-outs, and tracking permissions expressed by the person. User choice Regional law — GDPR, US state privacy laws, Quebec Law 25, and other jurisdiction rules. Regional law Browser APIs — what the browser still exposes; several Privacy Sandbox ad APIs have retirement announced. Validate current status. Browser API OS APIs — SKAdNetwork, AdAttributionKit, and App Tracking Transparency constraints on mobile. OS API Platform policy — store, browser, and platform rules that bound what advertising systems may do. Platform policy Deletion requests — Right-to-Delete signals propagated through the supply chain. Deletion request Consent strings — GPP and TC strings carrying purpose-level and vendor-level permissions. Consent string The permission and policy layer — every action is evaluated against consent, law, platform rules, and output policy before it executes. THE GATE Permission and policy layer consent, law, platform checked before action allowed is not the same as possible Targeting allowed — the permission signals support this audience use. Targeting ALLOWED Measurement allowed — the permission signals support this measurement use. Measurement ALLOWED Activation blocked — a consent, law, or policy check failed, so the action does not run. Activation BLOCKED Deletion propagated — the deletion request is forwarded to every connected system. Deletion PROPAGATED Aggregate-only output — results leave the system at aggregate granularity only. Output AGGREGATE-ONLY Human approval required — high-stakes actions wait for a person before executing. Sensitive action HUMAN APPROVAL
Seven permission inputs resolving through one permission-and-policy layer into six possible decisions — from targeting allowed to human approval required.

If the protocol says the agent can act, privacy and platform rules decide whether it should.

Fast read

What it is
A guide to the privacy, consent, deletion, browser, OS, and platform rules that constrain what advertising systems — and agents — are allowed to do.
What it covers
GPP, TCF, the Privacy Taxonomy, the Data Deletion Request Framework, the Accountability Platform, Privacy Sandbox status, SKAdNetwork, AdAttributionKit, and ATT.
What it is not
It is not legal advice and not a full compliance manual. It is a map of the standards that make permission machine-readable.
Why it matters
Agents can execute faster than governance can react. Permission boundaries have to be machine-readable before activation scales.
Best for
AdTech, MarTech, media, data, AI, agency, publisher, and brand leaders designing activation and measurement under privacy constraints.
Best next read
Core AdTech Standards, IAB Agentic Standards, and Enterprise Data Collaboration.
Why it belongs here

Why privacy belongs in the standards stack.

Agentic advertising will still depend on the old rails. Agents need workflow protocols, runtime standards, transaction objects, privacy constraints, measurement trust, and research evidence. This page covers the constraint layer: the consent, deletion, browser, OS, and policy rules that decide whether a permitted action is also an allowed one.

  • 01

    Protocols define the action

    AdCP and the agentic standards describe what an agent can request and execute.

  • 02

    Consent defines the permission

    GPP and TC strings carry what a person allowed — purpose by purpose, jurisdiction by jurisdiction.

  • 03

    Deletion defines the obligation

    Right-to-Delete requests must propagate to every system that holds the data.

  • 04

    Platforms define the rails

    Browsers and operating systems decide what advertising code can observe and measure.

  • 05

    Policy defines the output

    Output rules decide what leaves a system: person-level, cohort, or aggregate-only.

  • 06

    Humans define the threshold

    Some actions should require a person, no matter what the protocol allows.

The principle

Permission boundaries must be machine-readable before agentic activation scales.

IAB privacy frameworks

Five frameworks that make permission machine-readable.

Public documentation describes these five IAB Tech Lab frameworks as one interlocking privacy portfolio: GPP and TCF carry the consent signals, the Privacy Taxonomy labels the data, the Data Deletion Request Framework propagates deletion requests, and the Accountability Platform specifies how to audit whether signals were honored.

  • Signal transport

    GPP — Global Privacy Platform

    An IAB Tech Lab protocol for transmitting privacy, consent, and consumer-choice signals from sites and apps to ad tech providers. Spec v1.0 was finalized September 28, 2022, and carries jurisdiction-specific sections — IAB Europe TCF, IAB Canada TCF, the MSPA US National string, and individual US state strings. The agentic question: which privacy signal applies to this person, in this jurisdiction, right now?

  • Consent and legal basis

    TCF — Transparency and Consent Framework

    IAB Europe’s consent framework, with technical specifications stewarded by IAB Tech Lab. The operating version is TCF v2.2 — CMP API v2.2 plus the TC String with Global Vendor List format v3.0. A v2.3 draft completed public comment in May 2025 but is not the operating version, and further updates were in public comment as of mid-2026 — validate current status. The agentic question: did the person grant a basis for this purpose and this vendor?

  • Common language

    Privacy Taxonomy

    A classification language for data elements, data uses, and data subjects, so systems can label data the same way for rights handling and partner exchange. Released for public comment in September 2024, with implementation guidelines in comment through April 2025; public documentation does not assign it a version number. The agentic question: can the agent describe what the data is, how it is used, and whose it is?

  • Deletion propagation

    DDRF — Data Deletion Request Framework

    A standardized mechanism for transmitting Right-to-Delete signals through the ad supply chain — request packets, propagation sequence, signatures, response codes, and discovery. Finalized in 2024, with no version number in the public spec. It addresses deletion rights under GDPR, US state privacy laws, and Quebec Law 25. The agentic question: when a person asks for deletion, does the request reach every system the agent touched?

  • Signal accountability

    Accountability Platform

    A specification — not a live service — for open, auditable data structures that detect miscommunication of privacy preference signals such as GPP and TC strings across the supply chain. Version 1.0 of the spec was finalized November 5, 2024. The agentic question: can the ecosystem prove the consent signal was honored downstream?

Version and status details above reflect official sources as of June 2026. Public-comment drafts are not operating versions; validate current status before implementation.

Browser privacy APIs

Browser privacy APIs: check the status before the architecture.

This is the part of the stack where assumptions age fastest. In April 2025, Google announced that Chrome would keep third-party cookies under the existing user-choice settings, with no standalone prompt. In October 2025, it announced the retirement of most Privacy Sandbox ad APIs — including Topics, Protected Audience, and Attribution Reporting — citing ecosystem feedback and low adoption, with no concrete removal dates published. Public documentation describes CHIPS, FedCM, and Private State Tokens as continuing.

  • Interest signals — retiring

    Topics API

    Designed to support interest-based advertising without sharing the specific sites a person visited. Google announced retirement of the API in October 2025, citing ecosystem feedback and low adoption; no concrete removal date has been published. Validate current status before any dependency.

  • On-device auctions — retiring

    Protected Audience API

    Designed to run on-device ad auctions in the browser for remarketing and custom audiences without cross-site tracking. The same October 2025 retirement announcement applies, with phase-out following standard browser deprecation processes and no published end date.

  • Conversion reports — retiring

    Attribution Reporting API

    Designed to connect ad interactions to conversions through browser-generated reports rather than cross-site tracking. Also covered by the October 2025 retirement announcement; official sources indicate Google intends to collaborate on interoperable attribution work at the W3C. Validate current status.

The framing

Privacy Sandbox APIs should be treated as browser-platform constraints and capabilities with retirement announced — not replacements for cookies.

Browser and OS privacy APIs — two platform rails, one shared constraint on what advertising systems may do. PLATFORM PRIVACY APIS BROWSER — PRIVACY SANDBOX retirement announced Topics API — designed for interest-based advertising without sharing the specific sites a person visited. Google announced retirement in October 2025; no removal date published. Topics interest-based signals RETIRING Protected Audience API — designed to run on-device ad auctions in the browser for remarketing without cross-site tracking. Retirement announced October 2025; no removal date published. Protected Audience on-device auctions RETIRING Attribution Reporting API — designed to connect ad interactions to conversions via browser-generated reports. Retirement announced October 2025; no removal date published. Attribution Reporting conversion reports RETIRING OS — APPLE ATTRIBUTION frameworks coexist SKAdNetwork — Apple install-validation attribution; documented version 4 supports up to three conversion windows starting iOS 16.1. The framework remains documented and in use. SKAdNetwork 3 conversion windows VERSION 4 AdAttributionKit — Apple newer attribution framework; install and re-engagement attribution across the App Store and alternative marketplaces, interoperable with SKAdNetwork. AdAttributionKit install, re-engagement iOS 17.4+ App Tracking Transparency — apps must request authorization before accessing app-related data for tracking across apps and websites. ATT tracking authorization iOS 14.0+ The shared constraint — platforms set what advertising systems may observe, target, and measure. Protocols request; platforms permit. THE SHARED CONSTRAINT Platforms set what advertising systems may observe, target, and measure. Protocols request — platforms permit. Validate current status before building.
Browser APIs with retirement announced and Apple’s OS attribution frameworks feed one shared constraint: platforms set what advertising systems may observe, target, and measure.
Apple and mobile attribution

Apple and mobile attribution.

On mobile, the operating system is the permission layer. Apple’s attribution and tracking frameworks define what app advertising can measure, at what granularity, and with whose authorization.

  • Install attribution

    SKAdNetwork

    Apple’s privacy-preserving install-validation API for ad networks and apps. The current documented version is version 4: up to three conversion windows starting iOS 16.1, up to three postbacks, and a winning postback plus up to five runner-up postbacks. Two older methods are deprecated — the framework itself remains documented and interoperable with AdAttributionKit.

  • Newer framework

    AdAttributionKit

    Apple’s newer attribution framework, available from iOS, iPadOS, and Mac Catalyst 17.4. It supports install and re-engagement attribution, works in the App Store and alternative app marketplaces, requires no App Tracking Transparency authorization, and sends cryptographically signed postbacks with no user- or device-specific data. Apple documents formal interoperability with SKAdNetwork and recommends AdAttributionKit for new ad campaigns.

  • Tracking authorization

    ATT — App Tracking Transparency

    The framework that gates tracking across apps and websites: apps must declare a usage description and request user authorization before accessing app-related data for tracking. Available from iOS and iPadOS 14.0, with equivalents on macOS, tvOS, and visionOS. Public documentation shows no deprecation notes — ATT remains in force.

For app-growth teams, DSPs, and MMPs, the practical point is that postback windows, conversion granularity, and re-engagement support are implementation-sensitive and version-dependent. Validate current platform behavior before committing a measurement design to it.

Agentic implications

What this means for agents.

An agent that can transact is not an agent that may transact. Each constraint below is a runtime question the system should be able to answer before it acts — and a failure mode if it cannot.

ConstraintAgentic questionRisk if ignored
Consent stringDoes the GPP or TC string permit this purpose, this vendor, this jurisdiction?Activation without a legal basis, executed at machine speed.
Deletion requestHas the deletion request propagated to every system the agent touches?Deleted data resurfacing in targeting, enrichment, or training.
Browser APIIs the capability the workflow relies on still supported by the browser?Pipelines built on retiring APIs that quietly stop returning data.
OS attributionDoes the measurement design respect SKAdNetwork and AdAttributionKit constraints?Attribution claims the platform cannot actually support.
Output policyIs the output aggregate-only where required, with no person-level leakage?Person-level data leaving a system that promised aggregates.
Human approvalDoes this action cross a threshold where a person must approve?Privacy-sensitive actions executed without accountability.
From signal to action — consent check, then policy check, then allowed, human approval, or blocked. CONSENT TO ACTIVATION consent OK within policy needs review out of policy no consent A signal arrives — a brief, a bid request, an audience instruction, or any agentic task. Signal arrives brief, bid, audience Consent check — does the GPP or TC string permit this purpose, this vendor, this jurisdiction? Consent check GPP / TC string Policy check — platform rules and output policy: granularity, destination, and allowed use. Policy check output + platform Allowed — the action executes and the permitting signals are logged. Allowed execute and log Human approval — high-stakes actions wait for a person before executing. Human approval person decides Blocked — the action stops; the system logs the reason and responds. Blocked stop and log The default: if a check cannot be evaluated, the system should not act. THE DEFAULT If a check cannot be evaluated, the safe default is not to act.
Every agentic action passes a consent check and a policy check before it is allowed, escalated to a human, or blocked.
No Fluff POV

No Fluff POV.

Privacy cannot be bolted onto agentic advertising later. The permission layer has to be designed in from the start — consent checked before action, deletion propagated by default, outputs constrained by policy, and people in the loop where the stakes are high.

  • Treat consent and policy as runtime inputs, not legal paperwork.
  • Encode permission boundaries where the agent executes — not only in a contract.
  • Design deletion propagation before the first record is collected.
  • Assume browser and OS rails keep moving; validate current status before building on them.
  • Default to aggregate-only outputs and escalate exceptions to humans.
  • Log which signal allowed each action, so the decision can be audited later.

The point

An agent that cannot show it was allowed to act should not act.

Validate, don’t assume

Primary sources to validate.

Standards references last validated: June 2026. Specifications, APIs, public-comment status, release candidates, certification programs, and implementation guidance change. Validate against official documentation before implementation.

Primary sources to validate 20 sources
  • IAB Tech Lab · checked 2026-06-12 · Primary

    GPP is the protocol for transmitting privacy, consent, and consumer choice signals from sites and apps to ad tech providers across jurisdictions. Spec v1.0 finalized September 28, 2022; CMP API v1.1 (June 2023); jurisdiction sections include TCF EU, TCF Canada, the MSPA US National string, and US state strings. Supports: GPP definition, GPP v1.0 finalization (Sept 28, 2022), Jurisdiction sections.

  • IAB Tech Lab (GitHub) · checked 2026-06-12 · Primary

    Hosts the GPP Consent String Specification, Consent Management API Specification, and Supported Sections docs; maintained by IAB Tech Lab's Global Privacy Working Group, with ongoing releases for new US state sections. Supports: GPP technical spec documents, Governance, Active per-state section releases.

  • IAB Tech Lab · checked 2026-06-12 · Primary

    Current operating version is TCF v2.2 (CMP API v2.2, TC String with Global Vendor List format v3.0). A TCF v2.3 draft completed public comment May 19, 2025 — not verified as final; further TCF updates were in public comment as of mid-2026. IAB Europe contributes policy; IAB Tech Lab maintains the technical specs. Supports: TCF operating version (v2.2), v2.3 public-comment status (not final), Policy/technical split.

  • IAB Tech Lab (GitHub) · checked 2026-06-12 · Supporting

    Hosts the TCF technical specifications (CMP API, consent string and vendor list formats, implementation guidelines). The top-level README's version narrative is dated — use the iabtechlab.com page for current-version claims. Supports: TCF spec document inventory.

  • IAB Tech Lab · checked 2026-06-12 · Primary

    The Privacy Taxonomy is a classification language for data elements, data uses, and data subjects, supporting privacy compliance and data subject rights. Public comment opened September 2024; Implementation Guidelines comment ended April 17, 2025. No formal version number verified — avoid assigning one. Supports: Privacy Taxonomy definition (data / uses / subjects), Public-comment timeline.

  • IAB Tech Lab · checked 2026-06-12 · Supporting

    September 2024 announcement of the Privacy Taxonomy for 30-day public comment, developed under the Privacy Implementation & Accountability Task Force (PIAT). Supports: Privacy Taxonomy launch (September 2024), PIAT attribution.

  • IAB Tech Lab · checked 2026-06-12 · Primary

    The standardized mechanism for transmitting data deletion ('Right to Delete') request signals through the ad supply chain — request sequence/propagation, request packets, signatures, response codes, identifiers, and discovery. Finalized 2024; no version number published. Supports: DDRF definition and components, Finalized 2024 (no version number), Right to Delete scope.

  • IAB Tech Lab · checked 2026-06-12 · Supporting

    Press release (dated June 5, 2024 on the page) announcing the finalized framework: validation of request origins, requester authenticity, receipt confirmation, and cryptographic signatures. Supports: DDRF finalized status (2024), Framework capabilities.

  • IAB Tech Lab · checked 2026-06-12 · Primary

    A specification for open, auditable data structures and standard logging practices to detect miscommunication of user privacy preference signals (e.g., GPP/TC strings) across the ad supply chain. Version 1.0 spec finalized November 5, 2024 — a specification, not a verified live operated service. Supports: Accountability Platform definition, v1.0 spec (Nov 5, 2024), Spec-not-service framing.

  • IAB Tech Lab · checked 2026-06-12 · Context only

    Umbrella page for IAB Tech Lab's privacy standards portfolio, linking GPP, TCF, Privacy Taxonomy, Data Deletion Request Framework, and Accountability Platform materials. Supports: Framing the five frameworks as one privacy portfolio.

  • Google Privacy Sandbox · checked 2026-06-12 · Primary

    Google's October 17, 2025 announcement retiring most Privacy Sandbox ad APIs — including Topics, Protected Audience, and Attribution Reporting (Chrome and Android) — citing ecosystem feedback and low adoption. CHIPS, FedCM, and Private State Tokens continue. No concrete removal dates published. Supports: Current Privacy Sandbox status, Which APIs are retired vs continuing, Why Google retired the ad APIs.

  • Google Privacy Sandbox · checked 2026-06-12 · Primary

    Google's April 22, 2025 announcement that Chrome will keep third-party cookies under the existing user-choice settings and will not roll out a standalone cookie prompt — reversing earlier deprecation plans. Supports: Third-party cookie status in Chrome, Cookie-deprecation reversal (April 2025).

  • Google Privacy Sandbox · checked 2026-06-12 · Primary

    Per-API status table (last updated October 17, 2025): Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage/SelectURL, and Related Website Sets marked 'Deprecate and remove'; CHIPS, FedCM, and Private State Tokens continue. The live tracker for validating current status. Supports: Per-API deprecation status, Live phase-out tracker.

  • Google Privacy Sandbox · checked 2026-06-12 · Primary

    Canonical Topics API docs: interest-based advertising without sharing the specific sites a user visited. Carries a phase-out banner — historically important, being retired; validate current status before building on it. Supports: What the Topics API does, Phase-out caveat.

  • Google Privacy Sandbox · checked 2026-06-12 · Primary

    Canonical Protected Audience (formerly FLEDGE) docs: on-device ad auctions run by the browser for remarketing / custom-audience ads without cross-site third-party tracking. Carries the same phase-out banner — validate current status. Supports: What Protected Audience does, Phase-out caveat.

  • Google Privacy Sandbox · checked 2026-06-12 · Primary

    Canonical Attribution Reporting docs: browser-generated reports matching ad interactions to conversions without cross-site tracking. Carries the same phase-out banner — validate current status. Supports: What Attribution Reporting does, Phase-out caveat.

  • Apple Developer · checked 2026-06-12 · Primary

    Apple's privacy-preserving install-validation API. Documents version 4: up to three conversion windows (starting iOS 16.1), up to three postbacks, and a winning postback plus up to five runner-up postbacks. Only two methods are deprecated — not the framework; Apple recommends AdAttributionKit for new ad campaigns. Supports: What SKAdNetwork does, SKAdNetwork version 4 specifics, Apple's AdAttributionKit recommendation.

  • Apple Developer · checked 2026-06-12 · Primary

    Apple's newer attribution framework (iOS/iPadOS/Mac Catalyst 17.4+): install and re-engagement attribution for ads in the App Store and alternative marketplaces, no ATT authorization required, cryptographically signed postbacks containing no user- or device-specific data. Supports: What AdAttributionKit does, OS availability (17.4+), Re-engagement and alternative-marketplace support.

  • Apple Developer · checked 2026-06-12 · Supporting

    The authoritative reference for how AdAttributionKit and SKAdNetwork interact when delivering ad impressions — the two frameworks coexist and interoperate; neither has fully replaced the other. Supports: AdAttributionKit–SKAdNetwork relationship.

  • Apple Developer · checked 2026-06-12 · Primary

    ATT requires apps to declare NSUserTrackingUsageDescription and request user authorization (ATTrackingManager.requestTrackingAuthorization) before accessing app-related data for cross-app/website tracking. Available iOS/iPadOS 14.0+; no deprecation notes — ATT remains in force. Supports: What ATT does and requires, OS availability.

Platform capabilities and naming change quickly. Last validated: June 12, 2026. Check current documentation before implementation.Standards references last validated: June 2026. Specifications, APIs, public-comment status, release candidates, certification programs, and implementation guidance change. Validate against official documentation before implementation.

Next step

Designing activation or measurement around privacy constraints?

The operating work is to encode consent, deletion, platform constraints, and output policy into the activation path before agents scale it.