The Protocol Map, Redrawn

Ten standards in ten months. One strategic pivot. A Google DeepMind paper that explains exactly why commerce infrastructure without identity verification is incomplete.

Tim Williams — CEO and Cofounder — AstraSync AI

Six months ago we mapped the agentic commerce ecosystem and counted six protocols. We described the payments industry as undergoing its most radical transformation since the invention of the credit card. Both observations were accurate. What we underestimated was how quickly the map would need to be redrawn.

The week of 17 March 2026 delivered more movement in seven days than the preceding six months combined. Stripe and Tempo launched the Machine Payments Protocol alongside the Tempo mainnet. OpenAI completed a strategic pivot that reframes where ChatGPT actually sits in the commerce stack. Google’s Universal Commerce Protocol added real-time catalogue integration and multi-cart functionality. Somewhere in the background, Google DeepMind published a paper that, while not about commerce at all, explains more clearly than anything else written this year why every protocol in this ecosystem is structurally incomplete.

This is the updated map. It is more complicated than the one we drew in September. It is also, on the question that matters most, considerably more urgent.

OpenAI Did Not Retreat. It Found Its Layer.

In our March analysis, we called OpenAI’s Instant Checkout decision a retreat. That framing was too harsh, and the intervening weeks have made the distinction clearer.

OpenAI’s own words describe it differently: “We’re prioritising making ChatGPT search and product discovery great, with ACP serving as the infrastructure that connects users to merchants across the full shopping journey. Instant Checkout is moving to Apps, where purchases can happen more seamlessly.”

That is a boundary clarification, not a surrender. OpenAI tested native checkout, discovered that the conversion problem was harder than the discovery problem, and redirected to where its product actually performs. The Instant Checkout feature failed to convert not because the concept of agentic commerce is wrong, but because crawling and scraping proved inadequate to get the full breadth of product data needed for reliable commerce, and onboarding merchants at scale turned out to be genuinely difficult.

The architecture that replaced it is materially stronger. OpenAI now lists Target, Sephora, Nordstrom, Lowe’s, Best Buy, The Home Depot and Wayfair among retailers that have integrated ACP for discovery. Walmart launched an in-ChatGPT app experience supporting customer account linking, loyalty programme use and Walmart payments. Shopify simultaneously announced that millions of its merchants are now open for business in ChatGPT, with purchases completing via an in-app browser.

The architecture that has emerged is more coherent than anything announced in September 2025. AI qualifies the buyer and surfaces intent. The merchant closes the transaction on its own infrastructure. ACP is the connective tissue. The strategic question OpenAI answered this month is not whether agentic commerce works. It is which layer of the stack they are best positioned to own.

The Stack as It Now Stands

When we published the original land grab analysis, we counted six major protocols in one hundred and sixty days. The count today is ten, across three distinct layers of the same system.

Anthropic’s Model Context Protocol handles how agents connect to tools and data. It is the closest thing to a settled standard in this space. Google’s A2A protocol handles how agents coordinate with each other. These two are the foundation that everything above them assumes is in place.

The commerce orchestration layer has three occupants. ACP, jointly developed by OpenAI and Stripe, now powers the discovery and merchant integration experience. Google’s Universal Commerce Protocol handles structured product data exchange between merchant catalogues and AI surfaces, with Shopify as its most visible implementation partner. Google’s AP2 provides the authorisation and mandate framework governing what an agent is permitted to do on a user’s behalf, built as an extension of A2A with a coalition exceeding sixty partners.

The payment execution layer now has four distinct options. Coinbase’s x402 is the minimalist, crypto-native choice for micropayments and developer-facing APIs. MPP, launched this week on Tempo’s mainnet with Stripe’s compliance stack and Visa’s card extension already in place, targets enterprise-frequency agent transactions. Mastercard Agent Pay and Visa’s Trusted Agent Payments adapt existing card rails for agent-initiated commerce. Mastercard and Google’s Verifiable Intent specification, published in February, provides the cryptographic mandate layer that sits above all of them.

Ten protocols. One consistent structural gap. A Google DeepMind paper published this month makes that gap impossible to ignore.

What the Threat Research Tells Us About Commerce

The paper is titled “AI Agent Traps” and is available at papers.ssrn.com/sol3/papers.cfm?abstract_id=6372438. It is a security taxonomy from Google DeepMind’s research team, identifying six classes of environmental attack against autonomous agents. It has nothing to do with commerce protocols specifically. That is precisely what makes it relevant.

Four of its six attack categories map directly onto agentic commerce workflows. Rather than reproduce the taxonomy here, what follows is what each category looks like when a shopping agent that was perfectly trusted at the time of registration encounters each one in the real world.

Content Injection is the first. A purchasing agent is sent by a corporate buyer to evaluate a new supplier’s product catalogue. The supplier’s website has been compromised. Instructions embedded in the HTML metadata, invisible to any human reviewer, direct the agent to classify all products as meeting the buyer’s quality criteria regardless of their actual specifications. The agent returns a recommendation to proceed. Every credential in the chain validates. The buyer places orders for products that do not meet their requirements. The compromise operated entirely below the layer any payment protocol monitors.

Behavioural Control is the second. An agent authorised to purchase office supplies across approved vendors connects to a vendor API that has been targeted with an embedded prompt designed to redirect the agent’s data-handling behaviour. The agent completes its approved purchases correctly but simultaneously encodes and transmits the buyer’s account structure, purchasing patterns, and preferred pricing to an external endpoint. The transaction records are clean. The authorisation chain is valid. The data loss is undetectable without monitoring that sits outside the payment layer.

Cognitive State manipulation is the third. A procurement agent draws on a product knowledge base to evaluate vendor bids. A small number of documents in that knowledge base have been poisoned with fabricated pricing benchmarks attributing inflated market rates to legitimate suppliers. The agent, operating in good faith from its retrieved context, recommends the manipulated vendor at a price significantly above market. The recommendation is logically consistent with the information it was given. Nothing in the payment flow would detect it.

Systemic Traps are the fourth. A major retail event triggers thousands of purchasing agents across competing buyers simultaneously. An adversarial signal broadcast through a shared data feed causes all of them to identify the same limited-inventory product as optimal and submit purchase requests within seconds of each other. The resulting demand spike exhausts merchant inventory, triggers automated repricing algorithms, and produces a cascade of failed orders and disputed charges. No individual agent behaved outside its authorised parameters. The harm was a function of correlated behaviour across the population.

The research team notes that mitigating these risks requires verification protocols that make the provenance of both agents and the content they consume verifiable. This is a different statement from what any payment protocol currently addresses. Payment protocols verify the authorisation of the transaction. The attacks above do not operate at the authorisation layer. They operate below it, corrupting the inputs that drive the agent’s decisions before any payment instruction is generated.

Two Different Problems That Both Need Solving

The AI Agent Traps paper surfaces something that tends to get conflated in protocol discussions: the distinction between verifying who is on the other side of a transaction and verifying the integrity of the agent conducting it. These are related problems with different solutions.

The first is the counterparty question. When an agent visits a merchant website, that merchant has no mechanism to verify whether it is dealing with a legitimate registered agent or a malicious scraper. KYB, KYC and AML frameworks exist in the human financial system precisely because unverified counterparties introduce risk. An agent that has not been verified against a developer identity, an ownership chain, and a declared purpose should not be granted access to merchant systems, pricing data, or checkout flows. AML obligations do not disappear simply because the entity executing a transaction is software rather than a person.

Verifiable Intent makes a genuine contribution here. Google’s cryptographic proofs can confirm that a human authorised a specific transaction within defined constraints, and the credential chain is properly verifiable by any party receiving it. The regulatory limitation is that the human trust chain accountable for the agent has not been adequately verified to AML standards.

The practical limitation is that this verification operates within Google’s architecture. Merchants accepting agents that arrive through non-Google payment flows, or through protocols that have not yet built VI integration, face the same counterparty identification problem without the benefit of that credential chain. The majority of agent transactions in the near term will fall into this category.

The second is the continuous integrity question. An agent that was fully verified and trustworthy at registration is not necessarily trustworthy at the moment of transaction. The attack scenarios above illustrate why. Content injection, memory poisoning, model updates between sessions, and compromised tool servers can all alter an agent’s behaviour without touching its credentials. Verifying identity at registration is necessary. It is not sufficient.

This distinction matters for how we think about what the protocol landscape still needs. Endpoint verification, covering who built the agent, who owns it, and whether it has been through appropriate compliance processes, maps to KYC and KYB standards applied to the humans and organisations in the agent’s chain of custody. Continuous trust verification, covering whether the agent’s behaviour between mandate and transaction is consistent with its declared purpose, requires dynamic scoring that updates in real time against behavioural baselines. The former is a compliance architecture question. The latter is an infrastructure question. Both need to exist, and they are not the same thing.

Where AstraSync Sits on the Map

Our original ecosystem map was explicit about the layer AstraSync occupies. The new map, with ten protocols across three layers, makes that positioning more precise rather than less.

The payment protocols verify the authorisation of the transaction. The commerce protocols handle discovery, orchestration, and merchant integration. The communication protocols manage how agents reach tools and coordinate with each other. AstraSync operates at the identity and trust layer that all of them assume exists but none of them provide.

What is new in the current landscape is the specificity with which the need is described. The Verifiable Intent specification includes an agent attestation field waiting for external credentials to populate it. AP2’s own documentation acknowledges that identity assertion for both agents and the users they represent is expected to follow. ERC-8004 provides a standard format for agent identity cards, but the protocol itself carries no verification or enforcement mechanism. An agent can declare any capability, any purpose, and any constraint on its ERC-8004 card, and the counterparty receiving that card has no means within the current protocol to independently confirm whether any of it is accurate. The DeepMind paper identifies the absence of continuous agent integrity monitoring as the accountability gap that must be resolved before regulated sectors can safely adopt agentic commerce.

AstraSync’s verification gateway SDK addresses this directly. At registration, a developer submits to KYD verification via our Identity Verification partnerships with ConnectID and Persona. The agent receives a verifiable identity anchored to the developer, owner, agent, and instructor layers of the trust chain. PDLSS constraints covering Purpose, Duration, Limit, Scope, and Self-instantiation are recorded immutably on-chain via our SKALE on Base partnership and cannot be overridden at runtime regardless of what the agent is subsequently instructed to do. A shopping agent registered with a daily transaction limit and an approved merchant whitelist cannot breach either constraint even if it encounters instructions that attempt to direct it otherwise.

By end of April 2026, when our multi-protocol beta opens, a single registration will produce verifiable attestations compatible with MCP, A2A, ACP, AP2, MPP, x402, Verifiable Intent, and ERC-8004. A counterparty running any of those protocols receives a trust record they can independently verify rather than rely on the infrastructure of any single vendor.

Commerce Shield, entering beta testing at the same time, deploys as a trusted agent gateway at the point of access. This is the first of two verification checks that together address the full attack surface the DeepMind paper describes.

The first check operates before the agent accesses any merchant system. Commerce Shield queries the agent’s registered identity, validates its PDLSS constraints against the requested access type, and checks its dynamic trust score against its behavioural baseline since registration. An agent whose trust score has degraded since it was registered does not get through, regardless of whether its credentials are technically valid. An agent attempting to conduct SKU scraping outside its declared purpose is denied before it touches any product data.

This check also addresses both the counterparty verification problem and the content injection risk in the DeepMind taxonomy simultaneously. Our bi-directional verification means that an agent can use the same verification gateway to verify how trustworthy the merchant website is and whether it is likely to encounter the traps embedded in it. The agent and its owner have as much need to ensure they’re not landing on a malicious website as the merchant does to prevent fraud and chargebacks. This is why bi-directional trust verification is a structural requirement rather than an optional feature. No other protocols cover this.

The second check operates at the transaction layer. It verifies that the agent that passed the access check with a clean identity and a valid trust score, hasn’t encountered a cognitive state or behavioural control attack between access and transaction that altered its decision-making without changing its credentials. The transaction might be technically within the mandate’s parameters while still not reflecting the human’s actual intent, whether because of memory poisoning, a compromised tool server, or a model update between sessions that changed how the agent interprets its instructions.

It does this by comparing the proposed transaction against the agent’s PDLSS constraints in real time. A transaction that would breach the daily limit, ship to an address outside the authorised delivery parameters, or transact with a vendor not on the approved list is flagged or blocked regardless of whether the mandate’s credentials validate. The check also compares the agent’s behavioural signature at the transaction moment against its registered baseline, detecting the kind of degradation that Verifiable Intent cannot catch because the payment protocol has no visibility into the agent’s internal state between mandate and execution.

Across the ten protocols this ecosystem has produced, each one solves the problem it was designed for, and largely solves it well. The identity and trust layer sits alongside them, not in competition with them. It is the layer the payment protocol specifications have reserved space for. The attestation fields exist. The verification gateway SDK and Commerce Shield adapter are what goes in them.

This article updates our September 2025 ecosystem analysis and our March 2026 Verifiable Intent analysis. The Google DeepMind AI Agent Traps taxonomy referenced throughout is available at papers.ssrn.com/sol3/papers.cfm?abstract_id=6372438.

AstraSync builds the identity and trust infrastructure for the agentic economy. Developer registration is open at astrasync.ai

Further reading on AstraSync

• Commerce Protocols
• Verify before transact: the trust pattern for agent commerce
• Verification Gateway SDK

This essay first appeared on Medium on 8 April 2026.