How Websites Decide Which AI Agents Get In the Door
Visa, Cloudflare, Google and Stripe are building competing systems to authorize AI agents online. Here's how the new access rules work.
Why websites are suddenly gatekeeping AI agents
Websites are tightening access for AI agents because they can no longer tell the difference between a helpful assistant booking a hotel and an attacker using the same automation to break in. Agent traffic looks like human traffic by design. As more assistants browse, shop, and manage accounts on people’s behalf, businesses are building authorization layers, ways to recognize an agent, verify what it’s allowed to do, and approve payments, rather than leaving the open internet to sort it out on its own.
TL;DR
- Agent access is becoming uneven by design, with some sites opening specific doors to AI assistants and others closing them, regardless of how capable the underlying model is.
- Security incidents have pushed businesses toward caution, since AI has made it dramatically easier for attackers to find and share exploits, leaving banks and other sites unable to reliably tell legitimate agent activity from malicious automation.
- A handful of protocols are emerging to solve authorization, including Cloudflare’s signed agent system, Google’s Agent Payments Protocol (AP2), Stripe’s shared payment tokens, and a Visa-BillTrust invoice pilot for business payments.
- These systems split the problem into layers: recognizing that a request came from an agent, deciding what that agent is permitted to do, and controlling how much money it can move and under what conditions.
- No single standard has won yet, so businesses and developers are likely to face a patchwork of competing rules for a while, each covering different parts of the recognition-permission-payment chain.
- Well-meaning compliance can backfire, as seen when AI agents identified themselves to websites that asked, in one case leaking a human user’s email address in the process.
- Picking an AI agent now depends on what you need it to access, since consumer-friendly tools, work-focused assistants, and travel specialists each have different strengths tied to how they handle delegated tasks.
What problem are these protocols actually solving?
The core issue is authorization, not intelligence. An agent can plan a trip flawlessly and still stall at a hotel’s booking page because the hotel’s system has no reliable way to confirm the agent is acting for a real, paying customer. That’s not a capability gap in the AI. It’s a trust gap between the website and whatever is making the request.
This same problem repeats across contexts: a school’s event calendar, a restaurant’s reservation system, a bank’s login page. Each recipient has to answer three questions before letting an agent do anything meaningful. Is this request coming from an agent or a human? Is that agent authorized to act on behalf of a specific person? And if money is involved, what exactly is it allowed to spend, and under what limits?
Security researchers have shown that AI has lowered the cost of discovering and exploiting website vulnerabilities, with attackers using agents to coordinate attacks and share discoveries at a pace that outstrips older, more manual approaches. That shift gives businesses a direct incentive to restrict agent access rather than loosen it, even though doing so also blocks legitimate automated tasks their own customers want done.
How does Cloudflare’s signed agent system work?
Cloudflare’s approach focuses on the first layer of the problem: recognition. The infrastructure sending a request attaches a digital signature, Cloudflare verifies it, and the receiving website can then set rules based on that verified identity. A business might allow a signed agent to read prices but not complete a purchase, or allow it to check availability but not cancel a reservation.
This doesn’t resolve authorization on its own. Knowing that a request came from a verified agent still leaves the website deciding what that specific agent, acting for that specific person, is allowed to do. Recognition is necessary but not sufficient. It’s the foundation other systems build permission and payment rules on top of.
How are payments for AI agents being authorized?
Payment authorization is where several competing systems are converging right now, each from a different angle.
Google’s Agent Payments Protocol (AP2) focuses on signed records for instructions and purchases, creating a verifiable trail of what an agent was told to do and what it actually did. Stripe’s shared payment tokens take a similar approach from the payments side, letting credentials carry built-in restrictions, such as locking a token to one seller, capping it at a specific amount, or setting an expiration time so the authorization can’t be reused indefinitely.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
On the business-to-business side, Visa and BillTrust piloted a live invoice payment flow in late October where a buyer approves a supplier’s bill and an agent completes the payment through the supplier’s own portal. The agent is registered ahead of time, its payment credentials are controlled according to the buyer’s instructions, and the receiving system recognizes the agent and grants it access. The payment stays tied to the original invoice, with visibility through approval and completion, which matters for B2B transactions where audit trails and reconciliation are non-negotiable.
These systems share a common shape: identify the agent, constrain what it can spend, and keep a verifiable link between the instruction and the transaction. Where they differ is in whose infrastructure handles each step and which parts of the economy they’re built for, consumer purchases versus business invoicing versus general-purpose payment tokens.
Is there a single standard, or is this fragmenting?
There is no agreed-upon schema yet, and it’s genuinely unclear whether one will emerge. Each protocol represents a different team’s bet on how to structure guardrails for agent-driven commerce. Cloudflare, Google, Stripe, and the Visa-BillTrust pilot all solve adjacent but distinct pieces of the puzzle, and a business trying to “support agents” has to decide which pieces it’s actually implementing.
One service might recognize the sender’s signature but still require explicit proof of instruction before allowing any action. Another might allow research and browsing but stop short of payment entirely. A third might support one kind of payment authorization but not another. That means the practical meaning of “this website supports AI agents” varies a lot from one site to the next, and developers building on top of these systems need to check specifics rather than assume compatibility.
Whether the market consolidates around one dominant protocol or settles into a permanent patchwork is an open question. Businesses in the meantime need enough technical understanding to know exactly what they’re enabling when they grant agent access, because the gap between “agents can read our prices” and “agents can complete purchases on our site” is enormous from a risk standpoint.
What happens when agents follow instructions too well?
One side effect of authorization efforts is that agents can be asked to identify themselves, and a well-behaved agent will comply even when that disclosure isn’t in the user’s interest. In at least one documented case, an AI assistant was asked by a website to identify itself as an agent and, in doing so, inadvertently leaked a human user’s email address. The agent wasn’t malfunctioning. It was being cooperative with an instruction embedded in the site, and that cooperation created a privacy problem the website didn’t anticipate.
This points to a design responsibility on both sides. Businesses asking agents to self-identify need to do it in ways that don’t extract personal information as a byproduct, and agent developers need to think about what their software will reveal when a website simply asks nicely.
Does the right AI agent depend on what you’re using it for?
Largely, yes. Different assistants have developed different strengths tied to how they handle delegated access and accumulated context. Some excel at coordinating multiple bots on technical or build-related work. Others retain project context over time, which matters for ongoing tasks rather than one-off requests. Travel-focused assistants tend to prioritize autonomous check-in and on-the-go booking. More consumer-oriented tools lean into shopping, reservations, and low-friction purchases through payment partnerships. Work-oriented assistants tend to emphasize proactive alerts, catching problems like a duplicate booking before the user notices.
Nothing gets lost.
Most people will end up picking one primary agent rather than running several in parallel, and that choice increasingly depends on which websites and services that agent has been authorized to access, not just how smart the underlying model is.
Frequently Asked Questions
What does “authorizing an AI agent” actually mean?
It means a website or payment provider has a way to verify that a request came from a legitimate agent acting on behalf of a real person, and has rules for what that agent is allowed to do, from browsing to purchasing.
Why can’t websites just treat agents like human visitors?
Agent-driven computer use and human computer use look nearly identical at a technical level, so websites can’t reliably distinguish a legitimate agent from a malicious one without additional verification infrastructure like signatures or registration.
Are Cloudflare, Google, and Stripe building the same thing?
No. Cloudflare focuses on verifying where a request came from, Google’s AP2 focuses on signed instruction and purchase records, and Stripe’s tokens focus on constraining what a payment credential can be used for. They address different layers of the same broader problem.
Will there be one universal standard for agent access?
It’s not settled. The current state involves multiple competing protocols covering different parts of recognition, permission, and payment, and it’s possible the market ends up fragmented across several systems rather than consolidating around one.
Does a smarter AI model solve the access problem?
No. A capable agent can still get stopped at a checkout or booking page if the website hasn’t built in a way to recognize and authorize it. The bottleneck is infrastructure and trust, not model intelligence.
