Skip to content

Why this exists

Every SaaS product has an API, and every API works the same way. You sign up, you are issued a key, and you put that key in your code. The key is your identity. Whoever holds it is you.

For a world of servers calling servers, this was tolerable. The number of integrations was small, the keys were held by systems your team operated, and a human decided when each one was created. OAuth extended it: a person could click allow, and an application could then act for them within a scope, with a token that expires.

The whole arrangement rests on one assumption — that a human is present at the moment trust is granted, and that what runs afterwards is code you deployed.

An agent breaks both halves of that assumption.

It runs without a person present. It acts for someone who is not there. It decides what to do next on its own, calls other agents, and reaches whatever tools it has been given. And increasingly it is not code you wrote — it is a framework, a model, and a prompt.

Now look at what we have handed it.

Every credential it might need, up front. An agent that can read your files, query your database, and send email holds keys to all three, permanently, because nobody is around to approve each use. The blast radius of one compromised agent is the union of everything it was ever given.

No way to say who it is acting for. An agent holding a user’s token is that user, as far as every downstream system can tell. Ten users’ work flows through one agent and arrives wearing one identity. When agents call other agents, the original requester disappears entirely by the second hop.

No idea what is actually running. An API key proves someone was trusted once. It says nothing about whether the binary presenting it today is the one you approved, or a modified copy on a machine you have never seen.

A model in the middle of it. The agent is driven by something that can be talked into changing its mind. Everything above stops being theoretical the moment an instruction arrives inside data the agent was asked to process.

And every vendor building their own. Each platform ships its own agent framework, its own tool protocol, its own credential model. None of them interoperate, so an agent in one cannot prove anything to an agent in another.

Not for lack of quality — these are mature systems solving a different problem.

Why it does not fit
OAuthAssumes a browser redirect and a human to click allow. An agent working at 3am has neither.
API keysA bearer secret. Cannot express “this agent, acting for this person, right now” — only “someone has the string”.
mTLS / certificatesIdentifies a connection, not a message or a party. Says nothing about what is acting behind it, and carries a CA, renewals and revocation.
Service meshesTrust stops at the edge. Inside the boundary everything is assumed friendly — which is precisely where an agent operates.
All of themIdentify who. None identify what — which build, which binary, which origin.

The common thread: they secure a connection and hand out a secret that stands in for you. That model was built for a world where trust was granted once, by a person, to software that did not make its own decisions.


That is the problem. Next: the components that answer it, and then how they fit together.