Who is acting, on whose behalf, under what authority?

Two writers have been pointing at the same wound from different sides.

Koshy John, from the engineering seat, says the trap is using AI to look effective without building the judgment that makes effectiveness durable. "There is no generated explanation that transfers mastery into your brain without you doing the work." That is a personal-discipline argument, and he is right.

Bright Simons, from the systems seat, makes it structural. AI is "a model of human social reasoning with the human wrangled out." Automating cognition erodes the substrate AI depends on. The IBM reversal he cites, 7,800 jobs replaced and then hiring tripled, is the receipt. He is also right.

Both stop at the diagnosis. Naming the disease is not building the cure.

Here is the part neither one gets to. The systems agents act through have no working concept of who is acting, what they are allowed to do, or who is responsible when something goes wrong. That is the bottleneck. The same question I have been working on for two decades, in a new setting. The settings keep changing. The question does not.

The production gap

Picture an agent doing real work in production. It is reading a customer's account, drafting a refund request on their behalf, calling out to a payments API, posting an update to an internal ticket. Maybe it talks to a second agent on the way. Maybe it spawns a third for a sub-task. Whose authority is it acting under at each of those steps?

For most agent systems shipping today, the answer is a single API key in an environment variable. The agent has the key, so the agent has all the authority that key confers. There is no delegation chain. No scope. No revocation that does not require rotating the key for everything. No audit trail that ties a specific action back through the agent to the user who started the chain.

That works for a demo. The actions are small, the blast radius is contained, the agent only does what the prompt says. It does not work for production at scale. At scale you need to know which user delegated what authority to which agent for what purpose, and you need to know it months later when somebody asks who did this.

This is the plumbing nobody has built. Not for lack of trying. Identity stacks built for human users do not handle the multi-actor, multi-step, machine-speed shape of agent activity. OAuth scopes were designed for a person clicking allow on a single app. They do not describe an agent that delegates to a sub-agent that calls a tool that triggers another agent. The original primitives bend, and then they break.

Most teams have not noticed yet because they are still in the demo phase. The systems work, the agents do impressive things, the slide deck looks good. The first time an agent does something nobody told it to do, somebody is going to ask who did that, and the answer will be a 50-megabyte JSON log nobody can read.

What agent identity has to do

What agent identity has to do, concretely, comes down to four things. None of these are new ideas. The interesting work is in stitching them together at the speed and scale agents now operate at.

Start with delegation across actors. A user delegates authority to an agent. That agent might delegate to a sub-agent, or call a tool that calls another agent. The chain can go three or four hops deep before any real work happens. Every hop has to be traceable back to the user who started it, and every hop has to honor the bounds the user set. The closest human analog is a power of attorney, except multi-hop and machine-speed. The technical primitives are not exotic. Signed tokens, capability chains, and verifiable credentials all do versions of this. The challenge is that none of them were built with multi-agent chains in mind. They bend. We have been bending them carefully at Krutho, and in some places building new ones.

The second is scoped, revocable authority. An agent should hold the smallest possible permission for the task at hand. Read this customer's account. For the length of this refund flow. Nothing else. When the flow ends, the permission ends. When the user revokes, every downstream agent and tool that was acting on the chain loses authority within seconds, not minutes. Capability-based access control has been around for fifty years. It was always the right shape for this. We did not need it for human users because humans do not chain themselves like this. We need it now.

The third is attestation that travels with the action. Every action an agent takes carries a signature that links back to the original user, through every delegation hop, intact. When an action lands at the payments API, the API can see who originally authorized it, what scope they granted, and what the agent's path through the chain was. This is what makes "who did that" answerable. Verifiable credentials and decentralized identifiers are the primitives here. The standards have been in development for years. Most production systems do not use them yet because they were not built for human-led applications, where session cookies were enough. Agents need them.

Last, audit you can replay. Six months after an action, when somebody asks what happened, the answer cannot be a stack of logs nobody can correlate. The answer has to be a full replay. Which user authorized what. Which agent acted under what scope. What input it received. What it decided. What it returned. What the next hop did with it. Every layer signed. Every layer linked. This is closer to the audit trails financial systems already have to produce, except the events come in at a thousand times the rate.

Stitched together, these four primitives are the substrate. With them, an agent in production is auditable and bounded. Without them, an agent is a process running with everyone's keys. That is the architectural shape we have been working on at Krutho. Not from scratch. Building on real prior art from the identity, capabilities, and verifiable-credentials communities, where good engineers have been waiting for someone to actually need this.

The wrong layer

There is a reason IBM reversed course on replacing 7,800 jobs and started tripling hiring. They tried to automate the wrong layer. The agents could draft, summarize, route, and respond. What the agents could not do was hold the institutional context of who was responsible for what, and why something was done in a particular way. When the wrong action shipped, nobody could explain it. The audit trail was not there. The judgment had been hollowed out at exactly the layer that needed it most.

That is not a model problem. That is a substrate problem. The model can keep getting better. The substrate has to get built.

Most companies hiring "AI engineers" right now are loading themselves with hidden risk. Every agent in production is taking actions that create legal exposure, regulatory exposure, reputational exposure. If you cannot answer "who did that," you have liability with no traceability. Compliance will catch up. Regulators will. Your auditor will. The companies that built the substrate first will keep moving. The companies that shipped agents on a single API key will spend the next two years retrofitting identity into a stack that was not designed for it.

The org shape this requires is not familiar yet. The CISO is built for human-attacker threat models. The CTO is too broad. The AI engineer is one layer too low. The right person sits between identity, security, AI, and legal, and writes the architectural rules the others live by. Most companies do not have that person on staff yet. Some do not yet know they need one.

Bright Simons calls the move "convex leadership," converting cognitive abundance into structural ambition. The substrate is the structural ambition. Building it is what separates the companies that get the next decade right from the companies that retrofit it under duress.

Koshy John's argument about distinguishing judgment from polished output applies at the org layer. Surface output impresses long before substance shows up. Leaders who can tell the difference are the ones building durable AI organizations. The substrate is what makes that read possible.

The throughline

Twenty years ago I was solving identity at SunTrust, building the infrastructure that let banking systems trust each other across networks they did not control. After that, the same work at Toyota Europe and AGCO, where the systems were vehicles, sensors, and operators on a factory floor. At Vouch, identity for connected devices and the IoT layer, where the parties trusting each other had no humans in the loop. Two US patents along the way, both on the same shape of problem. Now Krutho, identity for AI agents, which is the same problem at machine-speed and multi-hop scale.

The companies change. The customers change. The threat models change. The question does not.

The substrate

The substrate is where the next decade gets won. Identity for agents is the part of the AI stack with the highest stakes and the least attention. Models will keep improving, almost regardless of what we do. The substrate will not improve unless someone builds it. Most companies will figure this out the expensive way, after the first incident nobody can explain. A few will figure it out now, and build it on purpose.

Trust between systems used to be about people clicking allow on a single screen. Now it is about agents acting on behalf of people, under bounded authority, with audit trails that survive months later. The question is the same. The setting just got serious.