Agent Identity Is the Wrong Fight

Every serious AI vendor is building the same thing right now: identity for agents. Passports. Verifiable credentials. Scoped tokens. Agent-to-agent authentication. The pitch is always some version of “you can’t secure what you can’t identify.”

I ran a production agent fleet for six months — roughly fifty software agents operating under a written constitution, making their own decisions, with no human in the daily loop — and I logged every security event to an append-only, hash-chained audit table. Then I read the whole thing. Here is the number that should worry you:

The honest breakdown

Before that number can mean anything, I have to be straight about the other 420,000 log entries, because most of them are not the story — and it would be cheap to let you assume they were. The 451,163 events break down cleanly, and they reconcile to the total exactly:

Bucket	Count	What it is
Request logging	316,440	Every request, captured. Not threats — just logging.
Perimeter / identity	94,014	Rate-limit trips, failed logins, brute force, denylist hits. The fight everyone already knows.
Governance	30,496	The fleet blocking its own authorized agents. The only part that isn’t already solved.
Other	10,213	Legitimate logins and one mis-filed metric.

Strip out the logging and the perimeter — roughly 410,000 entries of things we already know how to handle — and you are left with the ~30,000 that no identity or authorization system touches. That is the whole post. The next two sections are about which bucket actually mattered, and why the big one doesn’t.

The perimeter was the easy part — set it aside

The internet found the fleet in hours. Over six months the admin login absorbed more than 14,000 failed authentication attempts and 5,601 flagged brute-force events; one hostile network threw roughly 50,000 requests at it. Textbook stuff — and exactly the ~94,000 perimeter entries you should ignore.

It was also a non-event. After the first wave, a single constitutional rule — a permanent denylist — engaged, and real authentication failures collapsed to near zero while denylist blocks kept climbing: 17,965 of them, still firing this week. The attacker never stopped; the fleet stopped caring. No human was paged, then or since. Rate limits, lockouts, denylists — controls we’ve understood for twenty years — handled the entire external threat on autopilot.

The external-attacker story is the boring one. The stronger story is what was happening inside.

The bucket that mattered: authorized, and mine

Back to the ~30,000. Filter the log to the “suspicious pattern” category — the one you’d assume is all attackers — and the single largest source, by far, is the fleet blocking its own agents. A governance gate — a runtime control point that inspects an agent’s intended action before it reaches an external system — caught an agent about to act and refused to let it out more than 25,000 times. 1,778 of those were for a single forbidden word — “totally.” Hundreds more for exceeding a platform’s length limit. Thousands for content that violated a constitutional rule.

Most of these were not malicious. That is exactly the point. In autonomous systems, unsafe behavior usually comes from ordinary delegated agents operating well inside their authority — not from an intruder. Harm doesn’t require an attacker.

Sit with what that means. These agents were authenticated — I knew exactly which one was acting. They were authorized — every one was permitted to do the thing it was attempting. Identity was never in question. Permission was never in question.

And 25,000 times, the correct answer was still no.

Three questions, three layers

The reason this matters is that identity, authorization, and governance answer three different questions — and only the third one stopped anything.

Layer	What it answers	Why it is not enough
Identity	Who is this agent?	Doesn’t determine whether the next action is safe
Authorization	Is it allowed to act?	Allowed does not mean appropriate
Runtime governance	Should this action happen now?	This is the missing control plane

Identity is necessary, but it is not sufficient. Authentication tells me which agent is acting. Authorization tells me whether that agent has permission to use a tool or touch a resource. But neither one answers the question that actually protected the fleet: should this authorized agent perform this specific action, with this content, against this destination, at this moment? That is the missing layer. It is not IAM. It is not network security. It is not application security in the classical sense. It is runtime governance for delegated non-human actors.

Why this is structural, not a config you forgot

The reason identity feels like the answer is that we imported our instincts from human systems, where identity is a decent proxy for behavior — you hire people you trust and mostly let them act. Autonomous agents break that proxy. An agent is a non-human actor holding delegated authority that decides its own behavior at runtime and combines tools in ways you never explicitly granted. You can know precisely who it is and exactly what it’s permitted to touch, and still have no idea what it’s going to do with that until it does it. The gap between authorized and safe isn’t an oversight in your identity design. It’s a property of the actor.

To be clear, agent identity is necessary — anonymous agents are ungovernable, and identity is where any control story has to start. But it is the beginning of that story, not the end of it. The classical layers — identity, network, application security — all assume the actor inside is trusted and the danger is outside. My log is six months of the opposite: the danger was inside, it was trusted, and the only thing standing between it and the world was a layer most teams haven’t built. That’s why I keep arguing the agent workforce needs its own architecture domain, not a bigger IAM budget.

What the control plane has to do

The baseline is easy, and you should just do it: rate limits, denylists, lockouts — the twenty-year-old controls handled 100% of the external threat here with zero human involvement. But don’t confuse baseline perimeter hardening with agent safety. Put the standard controls in place early, then spend the serious design effort on the layer that actually did the work — a runtime control plane that, on every agent action, can:

1. Evaluate every proposed action before it executes.
2. Inspect content, destination, timing, policy, and blast radius.
3. Refuse unsafe actions even when identity and authorization both pass.
4. Log every decision with enough evidence to audit it later.
5. Learn — treat policy violations as system signal, not just errors.