Take a bid request arriving at a demand-side platform. The buyer can fetch a text file from the site named in that request, resolve the seller ID against a second file published by the exchange, and read the full chain of intermediaries out of the bid object itself. Three lookups, all public, all machine-readable, all completed before a penny is spent. Now run the same check on a brand recommendation sitting inside a chatbot's answer. There is no bid object to inspect, no seller ID to resolve and no file to fetch, because every one of those lookups starts from a domain and the answer surface does not have one. The authorisation question that programmatic advertising spent a decade answering is, on this surface, unasked.
How does the open web answer the question today?
Three specifications do the work, and they only work together.
ads.txt, short for Authorized Digital Sellers, is a plain text file a publisher hosts at the root of its own domain. It lists the companies permitted to sell that publisher's inventory, each with an account identifier and a relationship label of DIRECT or RESELLER. IAB Tech Lab released version 1.0 in June 2017. Version 1.1, released in August 2022 and still the current version, added the OWNERDOMAIN and MANAGERDOMAIN values so a file can name who actually owns the property and who manages its sales.
sellers.json is the counterpart, hosted by the exchange rather than the publisher. It declares the identity of every seller and intermediary operating on that exchange, and it exists because ads.txt deliberately stopped short of revealing publisher account identities. IAB Tech Lab's OpenRTB working group finalised it, alongside the third piece, on 31 July 2019.
That third piece is the OpenRTB SupplyChain object, usually shortened to schain. It travels inside the bid request as a set of nodes, one per entity that participated in selling it, and it gives the buyer an audit trail of the path rather than a static declaration.
The architecture matters more than any individual file. A publisher declares who may sell. An exchange declares who it is. The bid request declares the route taken. A buyer can then triangulate: if a seller appears in the chain but not in the publisher's ads.txt, the inventory is not authorised and the bid can be dropped. IAB Tech Lab calls this dual verification, and in a post published on 17 September 2026 its senior director of programmatic product management, Hillary Slattery, put the consequence of removing it bluntly: "Without the dual-verification of ads.txt + sellers.json, Demand-Side Platforms (DSPs) lose their most effective tool for blocking unauthorized sellers."
It works reasonably well. In the same post, Slattery cites Jounce Media research finding that 98 per cent of the bid stream enables independent validation of directness.
What breaks when the ad moves inside an AI answer?
The domain is the unit of authorisation, and that assumption is load-bearing in every one of the three files.
ads.txt is discovered at domain.com/ads.txt. Its authority derives from the fact that only the domain owner can publish there. sellers.json resolves identities for entities transacting inventory attributed to a domain. The SupplyChain object traces money back to a seller who was authorised, in the end, by a file on a domain.
A recommendation generated inside a third-party assistant has none of that. The publisher whose reporting informed the answer does not control the rendering surface, cannot host a file on it, and has no identifier in any existing taxonomy that describes it. There is no property type for an answer, no placement ID for a conversation turn, and no domain for a buyer to crawl. If a brand pays to be named inside a synthesised response, the question of who was entitled to sell that mention has no file-based answer at all.
This is not a small gap dressed up. It is the difference between a supply chain that can be independently validated and one that can only be asserted by the party taking the money.
Does adagents.json close the gap?
adagents.json is the most serious attempt to modernise publisher authorisation, and it has become the fault line in the industry's agentic standards debate. Brian O'Kelley, co-founder and chief executive of Scope3, published the case for it on 30 March 2026 at the Agentic Advertising Organization, arguing that ads.txt lacks the vocabulary to describe how media is actually sold today. His formulation: "The future of supply-chain transparency is not a slightly longer text file. It is a publisher-declared model that reflects how inventory is actually sold."
The specification sits within the Ad Context Protocol, which launched on 15 October 2025 with six founding members including Scope3, Yahoo, PubMatic, Swivel, Triton Digital and Optable. Publishers host the file at /.well-known/adagents.json, following the RFC 8615 well-known URI convention. It is considerably more expressive than ads.txt. Each authorised agent entry carries a delegation_type of direct, delegated or ad_network, replacing the binary DIRECT and RESELLER labels. Authorisations can be scoped to named properties, to publisher-defined placement IDs, to countries by ISO 3166-1 alpha-2 code, and to date windows through effective_from and effective_until. An exclusive flag records whether a path is the publisher's only one for that slice of inventory. Publisher-attested signing_keys let buyers pin the public keys an agent must sign with, and the spec makes that mandatory where it matters: publishers must populate signing_keys for any authorised agent whose scopes include operations that write state on the publisher's behalf.
None of which reaches an AI answer. The property types the specification recognises are websites, mobile apps and connected TV apps. The identifier types are domains, iOS bundles, Android packages and store IDs. Placement identity is defined as the pairing of a publisher domain and a placement ID, which presumes the publisher controls the surface where the placement renders. The file itself lives on the publisher's own domain. adagents.json is a richer description of the same web, app and CTV inventory that ads.txt already covers, not an extension into a new surface.
It is also weaker than most coverage suggests as an enforcement mechanism. The specification's own guidance to buyers states that a 404 status means "No file present (not an authorization failure)", that "Absence of file does not mean agent is unauthorized", and that implementers should "Use adagents.json as verification, not requirement". A file nobody is obliged to publish, whose absence proves nothing, is a useful signal rather than a gate.
Why is IAB Tech Lab pushing back?
Slattery's 17 September post is a direct rebuttal, and the substance of it is worth separating from the tone. Her operational objection is that a new specification is "unverified and unverifiable" in a market where the existing ones are implemented by, as she puts it, "a little over 1,000 implementers". Her structural objection is sharper: "adagents.json doesn't contemplate a counterparty relationship. When you remove the counterparty requirement, you introduce a huge gap in verification."
That is the dual-verification point again. A publisher-hosted file declaring which agents may sell is one half of a claim. Without a seller-hosted file making the reciprocal declaration, a buyer is trusting an assertion rather than checking an agreement between two named parties. Slattery's alternative is not to do nothing but to point agents at the files that already exist, on the grounds that reading ads.txt and sellers.json at scale is exactly the sort of work agents are good at and humans never got round to.
It is worth noting that adagents.json does specify a counterparty file, brand.json, in which an operator declares its relationship to the properties it represents. Whether that amounts to the same verification guarantee, given adoption of both files is voluntary and their absence carries no penalty, is the live argument rather than a settled question.
Both sides are arguing about how to authorise the sale of inventory on surfaces the publisher controls. Neither is arguing about the surface where the publisher's content increasingly ends up.
Which standards do cover AI, and what do they actually authorise?
Three efforts get cited in this conversation. It is worth being precise about what each one governs, because none of them governs the sale of a commercial mention inside a generated answer.
CoMP, the Content Monetization Protocols initiative, is IAB Tech Lab's work on the relationship between publishers and large language models. Its stated purpose is to help publishers and brands work with LLMs to monetise content and ensure accuracy. That is access and licensing: who may crawl, on what commercial terms. It is not a declaration of who may sell advertising.
The IAB Tech Lab Agent Registry, launched in March 2026 with Equativ and PubMatic among the first entries and Amazon's MCP server added shortly after, lets companies register the buyer and seller agents they have brought to market, categorise them and publish their capabilities. It is a directory of agents, not of property rights. Tech Lab is candid about this: the published roadmap for the registry includes "Creating the ability to verify that seller agent actually represents a property (like ads.txt for agents)" as a future feature rather than a current one.
AAMP, the Agentic Advertising Management Protocols, named in February 2026, extends existing advertising standards to agent-to-agent execution. It inherits the domain-anchored authorisation model rather than replacing it.
So the honest state of play is this. There is a standard in development for who may read a publisher's content. There are two competing standards for who may sell a publisher's on-domain inventory. There is no standard, in draft or otherwise, for who may place a paid message inside somebody else's generated answer.
What should publishers do now?
The absence of a standard is not a reason to wait, because the files that do exist are the ones buyers check today.
Keep ads.txt accurate and current, and use the version 1.1 fields. OWNERDOMAIN and MANAGERDOMAIN exist precisely to disambiguate who owns and who sells, and an out-of-date file is a live commercial leak rather than a tidiness problem.
Audit your own supply chain from the buyer's side. Fetch your ads.txt, resolve each seller in the relevant sellers.json, and check that the relationships you believe you have are the ones a DSP would read. Tech Lab publishes a supply chain API for this, and several free services do the same.
Treat adagents.json as optional and reversible. Publishing one costs little and signals engagement with the agentic buying stack, but it does not replace ads.txt, its absence is not an authorisation failure, and the specification is moving quickly enough that anything you write today will need revisiting. If you do publish one, populate signing_keys for any agent permitted to transact on your behalf.
Ask any vendor selling you AI-answer inventory the authorisation question directly. If the commercial message is served on your own domain, it sits inside the ads.txt and sellers.json chain and can be validated like any other impression. If it is placed inside a third party's generated response, ask what record exists that you authorised it, who can verify that record, and what happens when you withdraw permission. There is currently no specification that answers those questions for you.
The place an ad is served turns out to be a commercial question here rather than a technical one. blankspace serves into the retrieval moment at the CDN edge, on the publisher's own domain, which means the resulting impression falls inside the existing authorisation chain rather than outside it and can be validated by the same three files a buyer already reads. That is a narrow claim and it should be read narrowly: it settles the authorisation question for inventory on a surface the publisher controls, and it says nothing about a paid mention appearing inside a third-party assistant, where neither we nor anyone else can currently point to a file that proves who was entitled to sell it.
Frequently asked questions
Does ads.txt cover ads shown inside AI assistants?
No. ads.txt is discovered and validated at a domain, and its authority comes from the fact that only the domain owner can publish a file there. An answer generated inside a third-party assistant has no domain the publisher controls, so there is nowhere for the declaration to live and nothing for a buyer to fetch. ads.txt continues to govern inventory served on the publisher's own site, including inventory served to AI agents visiting that site.
Should publishers publish an adagents.json file?
It is low cost and low risk, but it is not urgent and it does not replace ads.txt. The specification itself instructs buyers to treat a missing file as an absence of information rather than an authorisation failure, so publishing one adds a signal rather than closing a hole. Publishers who do publish should populate signing_keys for any agent permitted to transact on their behalf, since the specification requires pinned keys for agents with write scopes.
What is the difference between ads.txt and sellers.json?
ads.txt is published by the publisher and declares which companies are authorised to sell its inventory. sellers.json is published by the exchange and declares the identity of every seller and intermediary operating on it. They are designed to be read together: the publisher's file names the counterparty, the exchange's file identifies it, and the SupplyChain object in the bid request shows the route the money actually took. Checking one without the others gives a partial picture.
Why does IAB Tech Lab object to adagents.json?
Its published objection is that the specification drops the counterparty requirement that makes the existing system verifiable. A publisher-hosted file declaring which agents may sell is a one-sided claim unless a seller-hosted file makes the reciprocal declaration, and without that pairing buyers lose their main tool for identifying unauthorised sellers. Tech Lab's position is that agents should be grounded in the existing specifications rather than given a new vocabulary for the same concepts.
Who verifies that a brand mention inside an AI answer was legitimately sold?
At present, nobody outside the transaction. No published specification lets an independent party check that the entity which sold a mention inside a generated answer was authorised by the publisher whose content informed it. Buyers relying on such placements are accepting the seller's assertion rather than validating it, which is the position programmatic advertising was in before ads.txt.