Every identity vendor now has an agent story: register your AI agent, give it a client ID, issue it a short-lived, narrowly scoped token, and log what it does. The story comes with clean diagrams, sensible standards and good demos.

There is just one problem: the whole model assumes the agent knocks on the front door and introduces itself, while most agents hitting banking and retail apps today do no such thing. They walk in wearing the customer’s face.

You can’t control what you can’t see, yet most of the industry is building controls for traffic it cannot see.

Why registration is the easy part

Issuing a token to a declared client is not new, as OAuth has done it for fifteen years. Dynamic client registration, scoped consent, token exchange and short expiry are well-understood building blocks. Wrapping them in an “agent” label is useful work, but it is not hard work.

That is exactly why every vendor can ship it: when a feature is easy to build, everyone builds it, and it stops being a differentiator. The hard question is not how to give an agent a token, but how you know you’re dealing with an agent in the first place.

An empty registry

Picture a bank that turns on agent registration, with the registry ready, the token policies tuned, and the audit dashboard live. Then the first month of data comes in, and the registry is nearly empty.

Meanwhile, agents are logging in, checking balances, moving money and filling carts through the same web and mobile flows customers use, with the customer’s own credentials and session. To the identity layer, they look like the customer.

That is the empty feature: a well-built control that governs only the traffic polite enough to opt in. Everything else, which is most of it, sails through unclassified, unscoped and unaudited.

How agents bypass registration

Look at how agents actually reach a bank or a retailer, and the registration model falls apart quickly:

• They drive a browser. Computer-use and browser agents click through the same pages a human does. There is no API call, so there is no moment where a client ID would even be presented.
• They borrow the user’s session. Many agents run inside the user’s own browser or reuse their cookies and passwords, so the request is, technically, the user’s request.
• They are built by anyone. A few lines of Playwright plus an LLM is an agent, and open-source frameworks put this in the hands of every developer, hobbyist and fraudster. None of them are going to file a registration form with your bank.
• There is no single standard to follow. Signing and identity proposals for agents exist, but they are early, fragmented and voluntary. Only a handful of large platforms implement any of them, and only for some of their traffic.

The result is predictable: the agents that declare themselves are the small minority run by big, well-behaved platforms, while the long tail is invisible.

Why agents may stay undeclared

The optimistic view is that standards will mature and agents will learn to identify themselves. Some will, but the incentives point the other way for most of the market:

• Declaring yourself invites friction. An agent that announces itself can be blocked, rate-limited, challenged or steered to a slower path, while an agent that blends in just works. Agent builders compete on “it just works.”
• Users often want it that way. A customer who asks an assistant to pay their bills wants the job done, not a new consent ceremony at every site, and many will happily hand over their credentials.
• Bad actors never will. Account takeover, scraping, promo abuse and credential stuffing are already automated, and adding an LLM makes them better at looking human. No fraud ring is going to opt into a registry.
• The web has run this experiment before. Bots were asked to identify themselves through user-agent strings and robots.txt for decades. The good ones complied, while the ones that mattered did not.

Registration will help with the cooperative minority, but it will never be the control plane for the whole population. Building only for agents that declare themselves is like building fraud prevention only for criminals who confess.

Detect, classify, then govern

The right order is the reverse of what most vendors are shipping: start with seeing, then decide what to control.

1. Detect. Recognize agent-driven sessions from the traffic itself, whether or not the agent says a word. Browser and app signals, interaction patterns and API behavior all carry fingerprints that automation cannot fully hide.
2. Classify. Know which agent it is and what it can do. A consumer assistant paying a utility bill is not the same as a scripted bot testing stolen credentials, and they should not get the same response.
3. Govern. Once you know an agent is present, registration and tokens become powerful tools for bringing it into the governed path: negotiate its scope and duration, get the user’s approval, issue a short-lived scoped token, and hold risky actions for a human. Agents that refuse can be slowed, challenged or blocked.

Detection is what fills the registry, turning agent registration from an optional courtesy into something you can actually enforce. This is the problem we are focused on at Transmit: accurate agent classification and deep research into how each agent platform behaves, so the controls have something real to act on.

Agent registration and short-lived tokens are worth having, and we support them too, but they are the last mile, not the foundation.

When a vendor shows you their agent registry, ask one question: what happens to the agents that never register? If the answer is “they look like normal users,” you are looking at a nice, empty feature.

You can’t control what you can’t see, so start by seeing.