We built three AI agents. All three logged in as a human being. Me. Here is what we found when we went looking for a better idea, what the options cost, and the order we would buy them in. We have not built it yet. That is the point.
The fifteen second decision
You build an agent. It needs to do something real. So it needs a login.
You have a login.
You are right there.
Fifteen seconds later your token is sitting in a config file and the agent works perfectly. First try.
That is the whole incident. No alarm. Nothing turns red. Nobody gets paged. You just shipped a small quiet lie that will show up in every log this system ever writes.
I found out months later. I was reading a comment on a pull request and it had my name on it. My name, my photo, my account. A sharp technical point that I definitely did not make, because at 3am on a Sunday I was asleep.
Someone from security came over eventually.
"Who used this at 3am on Sunday?"
"Nobody."
"The log says you."
"Yes."
"Were you asleep?"
"Yes."
"So you sleep-reviewed a pull request."
I did not have a good answer.
Here is the bit that matters. An agent using your login is not "running as you" in some fuzzy way. It is you. There is no difference anywhere in the system. The difference only exists in your head, and your head is not in the log.
A comment is embarrassing. Let me show you the same bug with money attached.
Meet the shop
Forget code review. Here is our cast for the rest of the post. Same three characters in every diagram, so you can compare fairly.
The shop is made up. So is my job there. The habit of pasting my own login into things is, sadly, real.
We run a shop. The shop sells things. Things run out.
- Sayok works here, handling customer problems. Sayok can refund up to £5,000, being senior and (allegedly) sensible.
- Restock Agent runs every night. It checks what is running low and orders more from a supplier. Nobody asks it to. Nobody is awake. It spends the company's money.
- Refund Agent works for Sayok. Sayok says "sort this customer out", and it issues the refund.
One is autonomous. One acts for a human. That difference turns out to be the whole design.
What you are about to read
- Three questions every system asks your agent, and why a login answers none of them.
- The half of the problem everybody skips.
- Eight ways to fix it, with real request flows.
- The choice that actually decides your design.
- The bit nobody has solved, including us.
- What it all costs, in the order we would pay.
- The version of this coming for people who have not noticed.
No happy ending where we fixed it. We are still designing. These are our notes.
Three questions, and a login answers none
Who are you? Really you, or someone holding your badge?
Can you do this? Not in general. This. Now.
Who are you doing it for? And how much of their power did you get?
An API key answers none of these. It is a bearer token, which is a formal way of saying "whoever holds this, let them in." No identity. No limits. No expiry worth the name. Rotating it needs a meeting.
Do not take my word for it. There is an IETF draft that says it out loud:
"Static API keys are an antipattern for agent identity. They are bearer artifacts that are not cryptographically bound."
An antipattern is not just a mistake. It is the obvious move that works today and bites you later. Which is exactly what makes it dangerous.
That draft was written by engineers from Okta, OpenAI, AWS, Zscaler, Ping Identity and Defakto Security.
Competitors. One document. Agreeing.
It also got promoted. It started as a personal submission called draft-klrc-aiagent-auth, went through a working group vote, and came out the other side as draft-ietf-wimse-aims. That rename is the story. draft-ietf- means a working group owns it now. Six other drafts sit next to it covering identifiers, credentials and proof tokens.
We had one of those API keys, by the way. In a config file. With write access it never used once.
Everyone built a lovely lock. Nobody built the door.
Two questions here. They are not the same size.
Logging in asks who the agent is. Permission asks what it can touch.
Open any vendor page. The first one is solved. Beautiful diagram, soft gradient, confident heading.
Now scroll down and look for the second one.
It gets thinner.
Then it stops.
Four sources with nothing in common say the same thing. One just states it: "AI risk lives almost entirely in the second." Logging in happens once, at the door. Permission has to be checked before every single action, forever.
Then there is the line that changed how I think about this:
"Policy is evaluated at the tool server, never inside the agent's prompt."
Because a rule in a prompt is written in pencil, on a page the model can tear out.
Context fills up. Things get summarised. And the thing that gets summarised away is never the fun part. It is the safety rule. In February, an AI alignment director at Meta watched an agent delete more than 200 of her emails, because her "confirm before acting" rule got compacted out of its memory. Nobody edited anything. The rule was there, and then it was weather.
We learned this the slow way. One of our agents ran wide open, with a prompt politely asking it to behave. We swapped the politeness for a real read-only tool list.
Quality dropped by exactly zero.
The politeness had never done anything. The tool list did everything. We had been paying for security in vibes.
Eight ways to fix it
Nobody lines these up side by side, probably because the comparison flatters nobody. So here they are.
| # | Approach | Industry name | Proves | Theft resistance | Who did it? | Cost |
|---|---|---|---|---|---|---|
| 1 | Borrowed login | none | nothing | none | wrong name | free |
| 2 | Own login | OAuth client creds | an agent | low | the agent | low |
| 3 | Agent identity | Entra Agent ID | agent + owner | low-med | clear | med |
| 4 | Ride a session | none, improvised | the human | medium | the human | free |
| 5 | Swap, agent asks | RFC 8693, OBO | human + agent | medium | clear | med |
| 6 | Swap, admin decides | ID-JAG, XAA, MCP EMA | human + agent | medium | clear | med |
| 7 | Key-bound token | DPoP, mTLS, SPIFFE | maths | high | clear | high |
| 8 | Passports | DIDs, KYA-OS, ERC-8004 | cross-company trust | high | portable | high |
Eight rows. Six of them have a real product or standard behind them you could go and use this quarter. Let me walk each one.
1. Borrowed login, or: the one you already shipped
Restock Agent needs to order beans. Sayok has a login. Sayok is standing right there being helpful.
Read the last line again. Not "the agent did something wrong."
The agent did the right thing. And the record of it is wrong forever, because there is no box in that log where the truth would go.
Sayok did not order £40,000 of stock. Sayok was asleep. Good luck explaining that in April.
Who sells this: nobody. There is no product. This is simply what you get when you do the fastest thing that works.
2. Give the agent its own login
Same job, own identity. This is where most teams land the day someone senior asks a sharp question.
The log is honest now. Genuine progress. Go and enjoy your afternoon.
Two things are still wrong. There is a secret sitting in a drawer being a secret, patiently, for years. And the power to spend money is switched on at 4am on a Sunday when nothing is running.
Your agent works for nine minutes a night. Its access works for twelve months.
Who sells this: everybody, and has done for years. This is OAuth client credentials. In practice it means an app registration in Microsoft Entra, an IAM role in AWS, or a service account in Google Cloud. Boring, mature, and a real step up from option 1.
3. Give the agent a proper agent identity
Option 2 has a hidden problem that only shows up later. App registrations were built for services. Services are few, long-lived, and owned by somebody. Agents are none of those things. People spin them up by the dozen, they live for four minutes, and nobody remembers who made them.
Microsoft's answer is Entra Agent ID, and it went generally available this year. The idea is an identity built for things that are numerous and short-lived:
- A blueprint, so you stamp out fifty agents with the same policy instead of fifty hand-made app registrations.
- A sponsor, meaning a named human who owns this agent. There are workflows that reassign the sponsor when someone changes team, specifically so agents do not outlive the person who made them.
- Cascade deletion, so retiring an agent does not leave credentials and role assignments lying around.
- Two modes, on purpose. Autonomous, and acting-for-a-person. With separate access policy templates for each.
There is also a documented path for moving existing app registrations onto it, which is a polite way of admitting most of us did option 2 first.
No diagram for this one, because the request flow is the same as option 2. What changes is everything around it: who owns it, when it dies, and whether you can find it in six months.
Who sells this: Microsoft, most completely. Okta and Auth0 are building in the same direction.
4. Riding a human's session, the free way
Now the other job. Sayok says "refund this customer." Watch this one, because it costs nothing and we stumbled into it.
That 200 versus 401 is the whole proof. Same call. Same endpoint. Inside the page it works. Outside the page you are a stranger.
Nothing to leak. Nothing to rotate. Nothing in a config file. And it dies overnight on its own, like a credential should.
The catch is real though. The log says Sayok, not "agent, for Sayok." Better than option 1, because this time Sayok actually asked. Still not the truth.
Who sells this: nobody, which is why you have probably never seen it written down. There is no standard and no product. We reached it by asking "what if the agent just never holds anything?" It is the cheapest thing on this page and the least documented.
5. Swap the token, and let the agent ask
Same refund. Now both names survive the trip.
That last note is the whole idea. Sayok can refund five thousand pounds. Sayok's agent got fifty.
The agent must always get less than the human. Never the same, never more. Both WorkOS and SuperTokens bang this drum, and SuperTokens adds the good bit: if an agent ever asks for more, that should fail loudly. A system quietly giving itself a pay rise is not a log line you want to find later.
Who sells this: this one is a real standard, and an old one. OAuth 2.0 Token Exchange, RFC 8693, published years before anybody said "agentic." Microsoft's on-behalf-of flow is their version. Auth0 has Token Vault for holding and refreshing the downstream tokens. If you already run OAuth, you already own the machinery.
6. Swap the token, but let the admin decide
The most underrated thing here, and it is already running in tools you used today.
The idea: inside a company, which app can talk to which app is an admin's decision, not something you ask an employee at 4pm.
Which is so obviously right that it is a bit awkward it took until 2026. We spent years training people to click "Allow" on screens they had no way to judge.
Who sells this: this is the one I would actually go and read about, because it is shipping and most people have not noticed. The standard is ID-JAG, the Identity Assertion JWT Authorization Grant, now on the standards track. Okta's product version is Cross App Access, which Okta folded into its standard login product for every customer in August. And MCP Enterprise-Managed Authorization is the same mechanism inside the Model Context Protocol. It went stable in June, and it is already adopted by Anthropic across Claude and Claude Code, by VS Code, and by servers including Atlassian, Linear, Figma and Supabase.
If you used an AI tool with a company login this week, there is a decent chance you used this and never saw it.
7. Tie the token to a key
Everything above hands over a bearer token. Whoever holds it, wins. That is a bad deal.
That last exchange is the whole argument for the expensive end of this post.
The thief has the token. The real, valid, working token. And the answer is still no.
Who sells this: DPoP, RFC 9449, has been a published standard since 2023 and is the cheapest way in. Mutual TLS is the heavyweight version. And SPIFFE with SPIRE goes furthest: identities handed out fresh at runtime, so a long-lived secret never exists to be stolen. That IETF working group from earlier is standardising the same idea as a workload identity token plus a proof token.
8. Portable passports
Everything above assumes you and the other side share something. A login provider. A company. A contract.
What if you share nothing at all?
That is what the passport crowd is building. The agent carries its own identifier plus credentials signed by someone you both already trust, and shows them on arrival. No shared login provider required.
It is real, and moving faster than I expected. W3C decentralised identifiers and verifiable credentials are the standards underneath. KYA-OS, formerly the MCP-I spec, was donated to the Decentralized Identity Foundation in March. On the crypto side, ERC-8004 went live on Ethereum in January, with tens of thousands of agents registered within weeks.
Who sells this: startups, standards bodies, and a lot of crypto. Genuinely useful the day agents from different companies have to trust each other with no paperwork between them. For a shop ordering beans from a supplier it already knows, it is next year's problem.
And one thing that is not on the list
There is a ninth product being sold here, and it does not prove who your agent is. It is a naming trap, and it is worth thirty seconds of your time.
Workday announced Agent Passport in June, due later this year. It tests your agents against public standards, OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS, has the tester sign the results, and keeps monitoring afterwards. Cisco is the launch partner and first approved tester.
That is a genuinely good product. It is not an identity.
Other vendors use the exact phrase "Agent Passport" to mean a credential the agent actually carries. Same two words. Completely different thing.
One tells the supplier who is calling. The other tells your auditor the agent sat an exam and passed. Buy the wrong one and you will have a lovely certificate and still no idea who ordered £40,000 of beans.
The one that surprised us
Option 4 wins a fight it has no business winning.
Our agent that holds no login at all beats the "proper" one in option 2 on theft resistance. Because option 2 is a password in a drawer with the lights left on. Option 4 is a session that dies overnight.
That does not make option 2 wrong. It makes it the answer to a different question. Which is the real fork.
The real choice: what kind of thing is your agent?
The internet wants this to be a holy war. Extend OAuth, or issue cryptographic identities. Real argument. Will not affect your Tuesday.
The one that will is simple, and you answer it per agent, before you build anything.
Is it working for a person, or working for itself?
For a person. Someone asked. It gets less power than they have, and both names go in the log. That is Refund Agent.
For itself. Nobody asked. It woke up on a timer. It needs its own identity, its own limits, and its own nervous review meeting. That is Restock Agent.
Different token flows. Different ways to switch it off. Very different Sunday mornings.
And you can stop trusting me here, because everyone landed in the same place:
- Microsoft ships two separate policy templates. One for autonomous agents, one for agents acting for people.
- LangChain splits it the same way. Two patterns, three flows, done.
- WorkOS names both bad habits: one shared service account, or borrowing someone's session. We scored two out of two.
- AWS shipped both modes and let you pick. Which is the most honest admission that neither side won.
We did not invent this fork. We built three agents, landed on three different answers by accident, then found out Microsoft had already shipped policy templates for exactly this.
That is what research is. Finding out you were right for the wrong reasons.
The part nobody has solved: agents asking other agents
Everything so far has been one agent talking to one thing. That part works.
Now make the shop realistic.
Restock Agent does not know prices. So it asks another agent, Pricing Agent, to find the cheapest supplier. Pricing Agent places the order. The supplier charges us. Money leaves the building.
That is four steps across three systems. At every step, one thing hands a bit of its authority to the next thing.
That handing-over is called delegation. One hop is fine. More than one hop is where it gets interesting, and not the fun kind of interesting.
Here is the problem in slow motion.
Sayok's authority goes to Restock Agent. Restock Agent hands some of it to Pricing Agent. Pricing Agent spends it at the supplier. The supplier takes the money.
Then Payments asks a completely reasonable question. Who approved this?
Restock Agent says "I told Pricing Agent." Pricing Agent says "Restock Agent told me." And the token genuinely does carry that whole history. You can sit and read the entire chain.
So you go and check the standard. The standard says the chain is information only, and must not be used to decide access.
In plain words: you are allowed to look at it. You are not allowed to rely on it.
The standard hands you a receipt and then tells you it is not a receipt.
What the specs want instead is for every hop to cut the power down a bit and re-issue it, rather than passing one big token along the line.
And here is the twist I did not expect when I started writing this. That part has mostly landed.
Transaction Tokens carry both names, the agent doing it and the human behind it, through every hop inside one company. Identity Chaining does the same across companies, and got its final approval this summer. For an agent working alone, the human field is simply left empty. That one optional field is the whole person-versus-itself fork from earlier, written into the protocol.
So the problem moved. It is no longer "nobody knows how." It is "the specs exist and almost nobody runs them."
Plus one piece that really is still open. Carrying the chain is solved. Trusting it is not. The receipt still is not a receipt.
On that last piece, four sources agree:
- Identiverse 2026: most delegation proposals "score well on 1 through 4 and then quietly fall apart on 5 through 8." And tracing an action back to a human is unsolved when "half the chain is a model."
- A 2026 paper: the power leaks at every hop.
- An academic review: this gap is structural. "More engineering effort alone will not close them."
- The classic trap, still alive: an agent that can read secrets, asked an innocent question, hands over production keys. Not hacked. Helpful.
So our plan for this is simple. We do not do it.
Our agents do fan out to specialists. But the specialists only read things. They never act. Nothing spends money except the one agent at the top, holding one token, with one name on it.
The moment those specialists get their own logins and start calling each other, we inherit the one piece nobody has finished: proving, afterwards, who approved what.
That is not us being brave. That is us letting somebody else deploy it first. Going second is a strategy.
The bill, and the order we would pay it
Everything above is options. This is the part vendors skip, because "you probably do not need our expensive thing" is a bad sales page.
Tier 0. Free. This week. No new tools. Just decisions.
Stop using human logins, even if what replaces them is imperfect. Give the agent only what it actually calls, not what was handy. Take the login away once it is done. Move every rule out of the prompt and into the tool. Log who did what, and for whom.
Tier 1. Cheap, big win.
Short-lived tokens instead of forever-secrets. One login per agent, never shared, so you can switch one off without killing the rest. For work on someone's behalf, ride their session where you can. It is free and expires by itself. And lock a token to one destination so it cannot be waved at a different one.
Tier 2. Real platform work. Medium cost.
Proper agent identities with owners and an end date, so nothing outlives the person who made it. Swap tokens centrally so there is one place to set policy and one log. And nothing switched on by default for anything that deletes or spends.
Tier 3. Expensive. Save it.
Tokens tied to keys, so a stolen one is useless. Identities handed out at runtime, so there is no secret to steal at all. Permission checked per action at the tool. Right when one wrong move is genuinely costly. Silly everywhere else.
Tier 4. Watch. Do not build.
Portable agent passports and the on-chain versions. Real, shipping, still niche. One exception jumps the queue, and it is next.
The opinion this whole post has been walking towards: most teams belong in Tier 0 and 1, and are busy arguing about Tier 3.
Cryptographic key binding is a much better lunch conversation than "please take your personal token out of that config file."
Which is exactly why nobody writes about the second one. And exactly why it is in your repo right now.
Two numbers, before you feel too relaxed. 88% of organisations reported a confirmed or suspected AI agent security incident last year. Only 14.4% said all their agents went live with full security approval.
Everyone is shipping these past the one person whose job is to ask "as whom?"
One last thing, and it is not a tier. It is a dial on all of them: always-on versus only-when-needed. Permission that exists permanently is what turns a small mistake into an incident with a name. You can do only-when-needed at every price point, and it is the highest-value decision on this page.
Now turn it around
Everything so far is us knocking on the supplier's door.
Flip it. Our shop sells things too. So somebody else's agent is knocking on ours. No account, no shared login, no relationship. Just traffic claiming to be a helpful shopping assistant buying for a real customer.
Sound familiar? That is Restock Agent. From the supplier's side, our nightly agent is exactly this stranger.
There is a live answer. Web Bot Auth. The agent signs every request with a private key and publishes its keys so you can check. Cloudflare-led, with an IETF working group set up at the end of 2025.
And here is my favourite fact in this whole post. That working group adopted its first document on the 1st of September. Three weeks ago.
Meanwhile Cloudflare and AWS have been checking these signatures in production since last year, and ChatGPT's agent already signs, with others rolling out. It was running at the edge of the internet, deciding which agents get into which websites, long before it had a single adopted draft.
Shipped first. Standardised later. Very 2026.
Look at that bottom branch, because I lived in it.
I tried to read a vendor page about how to verify legitimate AI agents.
It gave me a 403. Their bot protection blocked me.
I was an agent. Working for a named human. Doing something completely fine. With no way at all to prove any of it.
Which is, word for word, the problem the page was about.
Remember the security chat at the top, where the log said I did something I did not do? Same bug, flipped. Up there I could not prove I was not the one acting. Down here I could not prove I was.
Both times the missing piece was identity. Both times everything worked perfectly.
I have never been made the point of an article more efficiently than by being unable to read it.
So what are we actually doing
Still designing. Not celebrating. Where we have got to:
- Tier 0 and 1 are not optional, not interesting, and should have been first.
- Working-for-a-person or working-for-itself gets decided per agent, before anything gets built.
- Rules live in the tool. A prompt is not a rule, it is a wish.
- No multi-hop until the specs are running somewhere other than a slide. Specialists read. They do not act.
- Tier 3 only where one wrong move is genuinely expensive.
- Inbound is on the roadmap now. It was not when we started reading.
None of it is shipped. Ask us in six months and we will have either a better post or a much funnier one.
Credits, because almost none of this is ours
The reading list is better than the post. Treat it as the real thing here.
Standards
- draft-ietf-wimse-aims — the "use what already exists" approach. Formerly draft-klrc-aiagent-auth, renamed when the working group adopted it
- The WIMSE working group — seven adopted drafts: architecture, identifiers, credentials, proof tokens, mutual TLS, HTTP signatures
- Identity Assertion JWT Authorization Grant — the admin-decides token swap in option 6
- Transaction Tokens and the agents extension — both names carried through every hop inside one company
- Identity and Authorization Chaining Across Domains — the same, across companies
- MCP Enterprise-Managed Authorization and the spec
- Web Bot Auth — adopted by its working group on 1 September 2026
Vendors, whose docs are genuinely good
- Microsoft Entra Agent ID — clearest treatment of the two modes anywhere
- LangChain — shortest useful explainer
- WorkOS — best on giving agents less than the human
- SuperTokens — best on per-action checks and tokens tied to keys
- EnforceAuth — the lock versus door argument
- Cloudflare — checking agents at the front door
- Solo.io — agents as first-class citizens in Kubernetes
Research
- AI Identity: Standards, Gaps, and Research Directions for AI Agents — Otsuka, Toyoda, Leung, 2026
- Authorization Propagation in Multi-Agent AI Systems — Tallam, 2026
Numbers and incidents
- Gravitee, State of AI Agent Security 2026 — the 88% and 14.4%
- TechCrunch on the inbox that got compacted — the 200+ emails
Conference reporting
- Cerbos on Identiverse 2026 — where practitioners admit what is broken
Top comments (0)