There are two ways to handle a protocol explosion. One is to build a spreadsheet of every standard, assign an engineer to each, and implement them in order of press-release volume. We call this the Pokémon strategy, and it ends with a team that has caught them all and still can’t tell you what agents did in your app last Tuesday.
The other is to let your traffic decide. Here’s how.
Step 1: Turn the lights on
You can’t manage what you can’t see, and right now most institutions can’t see agents at all. Before any protocol work, put a visibility layer across web and mobile that answers four questions for every session: is this an agent, which platform, running where (cloud or the customer’s own browser), and doing what?
This comes first because every later step depends on it. A policy without visibility is a guess. A protocol without visibility is a bet.
Step 2: Start investigating, together
Once agents are visible, fraud and security teams should treat agentic signals as a new evidence type. Pull them into investigations of account takeovers, disputed transactions, profile changes and scraping. Within a few weeks you’ll stop debating whether agents are a risk and start knowing which agents, which flows and how much it costs.
One organizational tip: make it a joint practice. Agent risk sits exactly on the seam between the fraud team (“was this the customer?”) and the security team (“was this an attack?”), and seams are where things fall through.
Step 3: Write the rules of the house
Now decide what agents may do, flow by flow:
| Flow | Example policy |
|---|---|
| Browse products, check rates | Allow |
| View balances, order history | Allow, if the customer authorized the agent |
| Make a purchase within limits | Allow with scoped, time-bound access |
| Add a payee, change contact details | Hold, and ask the human in real time |
| Anything from an unidentified agent on a sensitive flow | Step up or block |
Then enforce it. A policy nobody enforces is a blog post.
Step 4: Track categories, not names
The protocol names will keep changing. The questions won’t. Keep a light watch list organized by category, and review it quarterly:
- Agent identity and signing: Web Bot Auth, Visa Trusted Agent Protocol
- Authorization and delegated consent: MCP authorization, OAuth extensions for agents, CIBA, Personal Agent Protocol
- Binding to a human and verifiable intent: Verifiable Intent, Know Your Agent tokens
- Agent payment credentials: AP2 and the card networks’ agent programs
- Tool and API exposure: MCP, WebMCP
- For retailers, agent checkout: ACP, UCP
Step 5: Adopt what your traffic adopts
Here’s the rule of thumb: implement a protocol when you see meaningful agent traffic using it, not when it’s announced. Your visibility layer from Step 1 tells you exactly when that moment arrives, with numbers instead of headlines.
By that test, two things are worth doing now. Verify Web Bot Auth signatures, because signed agents are already arriving and it costs little. And if you expose APIs or MCP servers to agents, put proper OAuth authorization in front of them, with scoped, revocable, human-approved tokens. Everything else goes on the watch list.
And the agents that never adopt anything? Step 1 is still watching them. That’s the point.
