Picture the most exclusive club in town. Velvet rope, clipboard, a bouncer who checks every name against the guest list. Now ask yourself who’s actually going to cause trouble tonight. It isn’t the people politely waiting to be checked in. It’s the guy who came through the kitchen.
Agent protocols are a beautifully designed guest list. They tell you who the invited agents are, what they’re allowed to buy and whose card they’re carrying. That’s genuinely useful. It just isn’t fraud prevention, and here’s why.
1. Fraudsters don’t RSVP
Every protocol in Post 1 is opt-in. An agent signs its requests because its operator chose to. A merchant supports UCP because it enrolled. A user binds an agent to their identity because they went through the flow.
A fraudster running a browser-use script on a rented residential proxy will opt into exactly none of this. Neither will the account-takeover crew, the card tester or the scalper. The protocols carve out a well-lit lane for good agents, which is great, and leave everything else exactly where it was.
That would be fine if the unsigned traffic were a small, weird minority. It isn’t. More than 95% of agent sessions detected by Transmit have no protocol signal at all.
2. A valid ID is not a good intention
Suppose every agent signed every request tomorrow. You’d know it’s ChatGPT’s browser knocking. You still wouldn’t know:
- Whether it’s been hijacked. Prompt injection turns a perfectly legitimate, perfectly signed agent into someone else’s employee. A hidden instruction on a web page or in an email, and the agent is now “helpfully” updating a payee.
- Whether the human was conned. A verifiable intent mandate proves the user approved the purchase. It does not prove the user wasn’t on the phone with a “bank fraud department” telling them exactly what to approve. Authorized push payment fraud just got an API.
- Which user is behind it. A platform signature identifies the platform, not the person. One key, millions of users.
- Whether the token is still in the right hands. Delegated credentials are bearer assets. Steal the token, inherit the agent.
Protocols answer “is this agent who it says it is?” Fraud lives in a different question: “is what’s happening right now what the real customer wants?”
3. The agent is wearing your customer’s browser
Here’s the plot twist most protocol discussions miss. The fastest-growing class of consumer agents doesn’t run in a data center at all. Comet, Claude in Chrome, Gemini in Chrome and a growing list of extensions run inside the user’s own browser, with the user’s cookies, IP and fingerprint.
No protocol covers this. There’s nothing to sign, because from the network’s point of view there’s no separate agent, just your customer, suddenly typing very fast and very politely. It’s also why the controls you already have struggle: IP and ASN reputation sees a home connection, and behavioral biometrics sees an increasingly convincing human.
4. Login is a door, not a hallway
“We’re fine, our app requires biometrics.” We hear this a lot. Agents don’t need to beat your login. They wait at the door, let the human scan a face or approve a QR code, then walk through and do the rest of the session themselves. Strong authentication proves a human was present at the start. It says nothing about who’s driving at minute four, when the beneficiary gets changed.
So are protocols useless?
No, and it’s worth being fair here. Protocols are good at three things:
- Removing friction for good agents, so you can welcome legitimate ones instead of blocking everything that moves.
- Allocating liability, which is exactly why the card networks are all in. Someone has to own the dispute.
- Producing evidence, since a signed mandate makes for a much better investigation than a guess.
Those are real benefits. They make protocols a strong input to your security decisions. They don’t make protocols the decision.
The guest list is worth having. Just don’t fire the bouncer.
Next time: what banks and merchants should actually do, without chasing every acronym.
