On October 20, 2026, at the Money20/20 conference in Las Vegas, the payments-security company Evervault launched Browser Tokens, a product that lets AI agents and browser automations complete purchases, logins and other sensitive online tasks without ever holding the card numbers, passwords or personal data those tasks normally require. The headline claim is the interesting one: agents can check out on any merchant web page, with no merchant-side protocol adoption required, and the underlying sensitive card data stays out of reach of both the agent and the browser provider. For anyone building agentic commerce this fall, this is a serious answer to the question that has hung over agent checkout all year: how do you let an agent pay without handing it the keys?
This piece explains the two bad options Browser Tokens is designed to replace, how the product works in plain language, where it fits in the agentic payments stack, and what non-engineers should do with the information.
The two bad options Browser Tokens replaces
Until now, letting an agent complete a purchase has mostly meant one of two designs:
- The agent holds your credentials. You give an agent your login and your card, and it operates as you. It works everywhere, which is precisely why it is dangerous: one leaked session store and a thousand checkout flows swing open. Most of the agent-security incidents we have covered this fall, from CERT-In's disclosure that testing agents reached live production systems undetected to OpenAI's own misalignment reports, trace back to designs where someone handed an autonomous system reusable secrets.
- The merchant adopts a protocol. Protocol rails such as Shopify's WebMCP checkout or platform wallets put verification and authorization in a governed channel, but they require each merchant to build support. Adoption is the bottleneck: the open web has millions of checkout pages, and a protocol has to be present on every one of them before it is the default anywhere.
Browser Tokens proposes a third lane: sensitive data isolated from the agent entirely, with no merchant integration needed.
How Browser Tokens work, in plain language
Evervault's model extends the tokenization pattern the card networks already run: a token stands in for the card number, scoped to a use, so the raw credential does not have to be present when the payment happens. Per the October 20 launch announcement (Business Wire, with Finextra reporting) and early analysis, Browser Tokens are built for three kinds of sensitive activity: making purchases, logging in to accounts, and completing other sensitive online workflows, while keeping card details, credentials and personal information out of reach of both the agent and the browser provider. The pitch to developers is equally blunt: agentic payments that keep your systems out of PCI scope.
Note precisely who is protected and from whom. It is not only the user being protected from the agent; it is the agent platform itself never touching the sensitive material. That separation matches the direction regulators, card networks and identity vendors have been pushing all autumn: authorization should live on verifiable rails, so the agent executes a bound, tokenized approval rather than holding reusable secrets you hope it never loses. It rhymes with the "know your agent" trust frameworks being built for the payments side of this stack.
Protocol-independent by design
The launch positions Browser Tokens as independent of all agentic commerce protocols: the agent transacts on any merchant web page as it exists today. That is a bigger claim than it sounds. Protocol-based agent commerce decides which ecosystems may transact, which makes it a retail strategy; tokenized browser actions interoperate with the web as it is, which makes it an infrastructure strategy. A simplified comparison:
| Approach | Sensitive data visible to the agent? | Merchant work required? | Main failure mode |
|---|---|---|---|
| Agent with stored credentials | Yes (passwords, cards) | None | Credential leak; account takeover |
| Protocol-based wallets and agent APIs | No | Platform or merchant integration, per ecosystem | Coverage gaps; ecosystem lock-in |
| Browser Tokens | No (isolated from agent and browser provider) | None; works on any page | Token issuer becomes a dependency; new trust point to evaluate |
The comparison is ours, condensed from the launch materials and standard industry designs; implementation details will evolve, and the precise boundaries deserve a technical review before you rebuild anything around them.
Where this fits in the agentic payments stack
The autumn of 2026 has been crowded with rails, and Browser Tokens slots into a specific layer. Agents need three things before a merchant should trust a transaction: an identity story (who or what is this agent, the trust-framework problem), an authorization story (what may it spend, the spending-cap and approval pattern Walmart is shipping with its Agent Gateway in November), and an isolation story (does the agent ever touch the credentials at all). Wallets and payment protocols mostly attack the first two. Browser Tokens attacks the third, and pairs naturally with the others rather than replacing them.
What it does not do is answer trust at the merchant's edge: a merchant receiving an order still cannot yet tell, from this alone, that the authorized human actually authorized this specific purchase. Expect the isolation layer and the identity layer to keep being sold separately, and expect whoever bundles them cleanly to win the checkout wars of 2027.
What to do with this if you are not a payments engineer
- If you build software with automation inside it: audit what your product's automated flows touch versus what they hold. Browser Tokens is a de-risking pattern for any checkout journey inside your software, and the PCI-scope reduction is a compliance budget argument your CFO will understand.
- If you are a merchant: there is nothing to adopt today. But expect the next generation of shopping agents to arrive holding tokenized credentials rather than passwords, and expect conduct-rules templates (Walmart just published one) to become the standard way merchants state what agents may do.
- If you are buying an agent product: add "what can the agent see?" to your procurement questions, and get the vendor's isolation model in writing. That single question would have flagged most of the agent-fraud blind spots we catalogued earlier this fall.
If you sell online, build software or automate business workflows and want help thinking through which parts of your stack should ever touch credentials and card data, that is a conversation we run with operators every week. Start one at our contact page.
