Load a typical publisher page today and the browser does most of the commercial work. Dozens of third-party scripts fire from the reader's device to collect signals, run an auction, resolve an identity and render a creative, and every one of those calls depends on a browser that is progressively withdrawing permission to make them. Trusted Server inverts that arrangement. It is a publisher-controlled edge cloud middleware layer that collects page signals, routes ad requests, reconciles direct-sold against programmatic, and stitches the finished creative into the page, all inside the publisher's own first-party domain before the response ever reaches the reader. IAB Tech Lab describes it as the new execution layer for the open web. The plainer description is that it moves the ad stack from a place the publisher does not control to a place the publisher does.
What is Trusted Server?
Trusted Server is an open-source, cloud-based orchestration framework and runtime for publishers, announced by IAB Tech Lab at its Signal Shift event in March 2025 and developed since through a public task force and a GitHub repository.
Technically, it moves code and ad-stack execution that traditionally runs in the browser through third-party JavaScript into verifiable, zero-cold-start WebAssembly binaries running in WASI-supported environments at the edge. Practically, it does five things: it collects on-page signals such as context, user behaviour and consent strings; it rewrites third-party ad tech calls as first-party calls under the publisher's own domain; it routes requests between direct-sold and programmatic demand according to publisher rules; it receives auction results and reconciles them against the publisher's ad server; and it stitches the winning creative into the page DOM.
It is worth being precise about one thing that is widely misunderstood. Trusted Server does not run auctions. It is the signal and rendering layer around the auction, not the auction itself.
What problem is Trusted Server actually solving?
The browser is running out of signal, and the loss is measurable rather than theoretical.
A field experiment published in the Proceedings of the National Academy of Sciences in 2026 by Zhengrong Gu, Garrett Johnson and Shunto Kobayashi, run as an open industry-wide test overseen by Google and the UK Competition and Markets Authority, randomly assigned Chrome users to browse with third-party cookies enabled, with cookies disabled, or with Privacy Sandbox substituted for cookies. Across more than 200 million ad impressions and over 5,000 publishers, removing third-party cookies reduced publisher revenue by 29.1 per cent. Browser-based privacy-enhancing alternatives recovered only 4.2 per cent of that loss.
That is the cleanest number the industry has on what client-side signal is worth, and it only describes cookies. Layered on top are the browsers that already block third-party cookies by default, and ad blocking, which industry estimates put at roughly a third of internet users globally and higher across much of Europe.
IAB Tech Lab's own framing of the rationale is blunt: browser-based telemetry is tending to zero, publishers need better control and security over user data, and ad blocking is not going anywhere. Trusted Server is the architectural response to all three at once. If the signal cannot survive the trip through the browser, do the work before the page is served.
How does Trusted Server work with Prebid Server?
They are complementary, not competing, and the confusion has been common enough that IAB Tech Lab published a dedicated explainer on it, written by Trusted Server technical architect Jason Evans.
Prebid Server is a server-side auction engine. It collects bid requests from demand partners, scores bids and selects winners. It operates mainly with impression-level information and has limited visibility into the wider page context or the ongoing user session.
Trusted Server sits around that. On the request side it collects and packages the signals, including contextual data, consent strings and synthetic IDs, then passes them to Prebid Server to run the auction. On the response side it ingests the auction result, reconciles it against direct-sold priority in the publisher's ad server, and stitches the creative into the DOM.
The distinction that matters commercially: Prebid Server owns auction execution, Trusted Server owns auction results interpretation, creative stitching, request routing by rule set, server-side cookie and synthetic ID setting, and the ability to rewrite content and header responses. Trusted Server also works without Prebid.js, which Prebid Server does not comfortably do.
What results has Trusted Server shown so far?
IAB Tech Lab CEO Anthony Katsur presented initial testing results in his keynote at Signal Shift NYC on 19 March 2026: up to 70 per cent faster page loads, reduced data leakage, and the ability to monetise audiences on low-signal browsers.
Those are the standards body's own figures for its own project, from prototype testing rather than production deployment, and should be read that way. But the direction is unsurprising. Removing dozens of client-side script calls from a page tends to make the page faster, and executing under a first-party domain tends to reduce what leaks to third parties. The genuinely interesting claim is the third one, because monetising low-signal browsers is the part that converts an infrastructure project into a revenue argument.
Who is testing Trusted Server, and when does it go live?
The proof of concept has been available for publisher testing since February 2026, covering the core loop: send an ad request to an exchange, receive and process the response, stitch the ad into the page, serve the page and ad. The MVP phase, which is what publishers need before they can run a meaningful share of inventory through it, is in progress. Later phases cover ad fraud signals, brand safety evaluation and server-side measurement.
On adoption, the picture is real but early. Three large publishers had committed to testing the prototype as of early 2026, without being named publicly. Equativ integrated its ad server into the prototype, which its end-to-end stack made straightforward. Anthony Katsur told Digiday in December 2025 that at least half a dozen US, UK and German publishers were waiting to pilot.
The most useful public timing marker came from Stephanie Mazzamaro, The Arena Group's head of programmatic, addressability and operations, on a Signal Shift panel moderated by Scott Messer in March 2026: publishers expect live-production testing late in 2026 or early in 2027. She also urged publishers to talk to the Trusted Server team about whether it fits, which is a fair summary of where the project sits. It is testable now and deployable later.
What are the criticisms of Trusted Server?
The framework attracted vocal opposition almost immediately, and the objections are worth understanding because they have not been fully resolved.
The first is redundancy. Critics argued the prototype looked naive given that most server-side Prebid deployments are run by SSPs rather than publishers, so adding a layer could increase complexity and SSP control, which is the opposite of the stated aim. Gareth Glaser, co-founder of Gamera, put the position to Digiday directly: publishers should work with Prebid Server, and he did not understand why the additional apparatus was needed.
The second is that the specifications could enable behaviour the industry has spent years trying to stamp out, including bid caching, ID bridging and misdeclarations, and could open a door to fingerprinting.
The third is infrastructure concentration. If publisher monetisation moves to the edge, the edge providers gain leverage. Glaser raised the prospect that a hyperscaler could, in principle, auction ads on websites before the sites even load.
Katsur has pushed back on each. He noted that ad tech firms and publishers both helped build the prototype, described the fingerprinting concern as overblown on the grounds that there is no legal definition of fingerprinting to the Tech Lab's knowledge, and argued that the identity module reflects what publishers already do when they append a user agent and IP address to a first-party cookie. He invited critics into the task force.
A publisher evaluating this should take the criticisms seriously without treating them as disqualifying. Two of the three are arguments about governance rather than architecture, and governance is decided by who joins the task force.
What does Trusted Server mean for AI and agent traffic?
This is the part that gets least attention and matters most over a three-year horizon.
Trusted Server was designed for a human-traffic problem: browsers withdrawing signal. But the architecture it lands on is the only one that works for the traffic that has no browser at all. The major AI crawlers and retrieval bots do not execute JavaScript. They fetch raw HTML and parse it. Anything a publisher's monetisation depends on running client-side is invisible to them by construction, not by accident.
That means a publisher who moves ad execution server-side to defend against Safari and ad blockers has, as a side effect, built the only layer capable of doing anything commercial with AI retrieval traffic. The two problems have different causes and the same solution.
IAB Tech Lab has been explicit that this is where its roadmap is heading. Katsur has described the 2026 shift as sell-side decisioning, with smarter sell-side partners using AI to curate audiences, content and supply closer to the user and the content. He has separately pointed to publishers substituting server-side decisioning as standard ad calls decline on AI-driven visits. The Tech Lab's agentic roadmap for 2026 extends its standards into the agentic execution layer, with open-source buyer and seller agent reference implementations, standardised agent profiles, a neutral Model Context Protocol reference server, and gRPC mappings for existing specifications.
There is a measurement consequence too. Agent traffic is currently classified as general invalid traffic by the major verification vendors, which means the impressions cannot be sold through the conventional display path even when the visit is real and intent-bearing. Server-side decisioning is what allows a publisher to treat that traffic as something other than a write-off.
What should publishers do about Trusted Server now?
Five things, none of which require committing to the framework.
Find out what share of your traffic is already low-signal. Split your inventory by browser, by ad-block status and by declared bot user agent. The size of that combined bucket is the size of the problem Trusted Server is proposing to solve for you, and it is usually larger than adops assumes.
Establish whether you have edge compute at all. Trusted Server assumes a CDN edge you can run code on. Publishers already on Fastly, Akamai, Cloudflare Workers or equivalent are a configuration away. Publishers on a plain origin stack are a procurement cycle away, and that lead time is the real gate.
Join the task force rather than watching it. The governance objections above get settled by whoever turns up. Publisher representation is the cheapest influence available on this project.
Test the proof of concept on a non-critical template. The POC covers the full request-to-render loop. A single low-traffic section is enough to find out whether the integration effort is measured in weeks or quarters for your stack.
Ask your SSPs where they stand. If your server-side Prebid is run by an SSP today, the practical question is not whether Trusted Server is a good idea in the abstract. It is whether your existing partners will integrate with a publisher-controlled layer sitting above them, and what they want in exchange.
Where blankspace fits
blankspace operates at the same architectural layer for a different traffic type. Where Trusted Server moves human-traffic ad execution to publisher-controlled edge infrastructure, blankspace detects Live Search Agent and LLM retrieval traffic at the CDN edge and injects contextual brand mentions into the response the agent actually reads, with attribution reported back to the publisher.
The two are complementary rather than alternative. Trusted Server is being built to recover the value of human impressions that browsers are making harder to monetise. Edge injection addresses the traffic that never had a browser and therefore never appeared in the ad stack in the first place. Both rest on the same argument, which is that the origin response is now the only reliable place to make a commercial decision. That argument holds regardless of which vendor a publisher ends up using.
Frequently asked questions
Is Trusted Server free to use?
Yes. Trusted Server is an open-source project, with the code available in IAB Tech Lab's public GitHub repository and feature requests and issues logged there. Publishers should budget for edge compute costs and integration engineering rather than licence fees. IAB Tech Lab membership is not a stated requirement for accessing the proof of concept.
Does Trusted Server replace my ad server?
No. Trusted Server sits between the auction and the page and reconciles auction results against your existing ad server's direct-sold priority. It is middleware and a rendering layer, not a replacement for Google Ad Manager or whatever else runs your direct business.
Will Trusted Server stop ad blockers?
It mitigates rather than defeats them. Because calls are rewritten as first-party and creatives are stitched server-side, the client-side signatures that most blocklists match against are largely absent. Blocker vendors adapt, so this is a moving target rather than a permanent fix, and publishers should treat significant recovery claims as testable rather than guaranteed.
Is Trusted Server relevant if most of my traffic is from AI assistants?
Increasingly, yes, though not in the form it currently ships. Trusted Server's value to AI traffic comes from the architectural decision it embodies, which is that ad decisioning happens before the response leaves the origin. AI crawlers do not run JavaScript, so a server-side stack is a precondition for monetising them at all. The specific agentic standards sit elsewhere in IAB Tech Lab's 2026 roadmap.
How is Trusted Server different from server-side tagging?
Server-side tagging moves analytics and marketing tag execution to a server container, usually to improve performance and control data flow. Trusted Server is broader: it covers signal collection, ad request routing, auction result reconciliation, creative stitching and third-party module execution, all under the publisher's first-party domain. Server-side tagging is a feature within the Trusted Server MVP scope, not an equivalent to it.