Enterprise identity was built around people: a user authenticates, a role grants access, and a policy decides which systems that person can reach. Autonomous agents change the architecture, because an agent does not simply access information. It acts.
At a glance:
- What happened: AI agents now retrieve data, call tools, invoke APIs, write to databases, communicate with other agents, initiate workflows, and increasingly affect physical and operational systems.
- What it exposes: Traditional IAM answers who is requesting access. It does not determine whether the requested action is admissible at that moment.
- What to examine: Whether every agent in your environment carries a verifiable identity, and whether each consequential action traces back to a named human authority.
Key quote: “Identity is the perimeter. Delegation is the policy. Execution is the proof.”
For decades, enterprise identity architecture was designed around people. A user authenticates. A role grants access. A policy determines which applications, files, and systems that person can reach. That model worked because humans were the primary actors, and a human making a request was, roughly, the same human who would bear the consequences.
AI agents change the architecture. An autonomous agent does not simply access information. It retrieves data. It calls tools. It invokes APIs. It writes to databases. It communicates with other agents. It initiates workflows. And increasingly, it can affect physical and operational systems.
The security question is no longer only “Who is the user?” It is now: “Who authorized this machine to perform this specific action, for this purpose, under these conditions?” That question has more parts than the old one, and every part matters. The machine. This specific action. This purpose. These conditions. An identity system that cannot answer all four is describing a different era’s problem.
Every agent action traces back to a named human authority through a verifiable identity chain. Illustrative artwork.
The Identity Chain: From a Named Human to Every Machine Action
Key quote: “Every high-consequence action must trace back to a named human authority.”
Answering the new question requires a new identity chain, with five links and no gaps:
- Human identity: the named person whose authority starts the chain.
- Agent identity: the agent’s own verifiable identity, cryptographic rather than asserted by a prompt.
- Delegated authority: the grant from human to agent, defining purpose, scope, duration, and limits.
- Context and constraints: the conditions under which the delegation is valid right now.
- Machine execution: the action itself, permitted only after independent evaluation.
Every agent needs its own verifiable identity, not a borrowed user account. Every delegation must define purpose, scope, duration, and limits in terms a machine can enforce, not just a human can read. And every execution request must be independently evaluated before it reaches the tool, database, network, operating system, or physical actuator. The evaluation happens outside the agent’s own reasoning, because the agent is the party being authorized, not the authority doing the authorizing.
Five links connect a named human to every machine action, with an independent check before execution. Conceptual diagram.
Notice what this chain makes possible that role-based access cannot: precision about the action. The old question was whether a person could reach a system. The new question is whether this agent may perform this operation, on this data, at this time, for this purpose. Identity is becoming the control plane because the control plane is where those questions get answered, for every action, at machine speed.
Now consider the situation question for your own environment: which agents in your systems can change production state today, and can you name the human whose authority each one acts under? If that inventory does not exist, the chain is already broken at the first link.
Authentication Proves Who. Admissibility Decides Whether.
Key quote: “A valid credential can still authorize the wrong action.”
This is where traditional IAM begins to fall short, and the gap is worth stating precisely. Authentication proves who, or what, is requesting access. It does not prove that the requested action is admissible at that moment.
A valid credential can still authorize the wrong action. An authenticated agent can still be over-permissioned. A legitimate session can still be manipulated through prompt injection, memory poisoning, tool abuse, or compromised context. None of these attacks need to defeat authentication. They ride on top of it. The credential is genuine; the instruction, the memory, or the context around it is not. Identity verification succeeds, and the wrong action proceeds anyway.
Authentication verifies who is requesting. Four attack channels show why that is not enough to decide what is allowed. Conceptual diagram.
That is the difference between authentication and admissibility. Authentication asks: who is requesting? Admissibility asks: is this specific action allowed right now, under the current delegation, scope, and conditions? The first is a fact about identity. The second is a decision about authority, and it has to be made deterministically at runtime, outside the agent’s influence, before the protected effect occurs.
The consequence question follows naturally. If an attacker poisoned one of your agent’s memories or injected instructions into its context, which mechanism in your environment would catch the resulting action before it executed? If the answer is “the agent would know better,” you are relying on the judgment of the compromised party. Intelligence can be probabilistic. Execution authority must be deterministic.
The Next Identity Architecture
Key quote: “Intelligence can be probabilistic. Execution authority must be deterministic.”
The next identity architecture must therefore combine seven capabilities, each doing a job the others cannot:
- Cryptographic agent identity: every agent carries an identity that can be verified, not merely asserted.
- Verifiable human-to-agent delegation: the grant of authority is explicit and checkable, not implied by a shared credential.
- Time-bound and purpose-bound authority: delegation expires and is limited to its stated purpose.
- Tool-level least privilege: the agent can reach only the tools and operations its task requires.
- Agent-to-agent lineage: when agents delegate to agents, the chain of who authorized whom is preserved.
- Deterministic runtime enforcement: the admissibility decision follows stated rules, evaluated the same way every time.
- Complete execution receipts: every consequential action leaves a record of who requested it, under what authority, with what result.
And for high-consequence actions, the chain must terminate in a Human Ethical Agent of Record, a HEAR, whose authority is explicitly named and cryptographically provable. Without that terminus, an organization may know which agent acted, but still be unable to prove why that agent was authorized to act. That distinction, between knowing who and proving why, will define the next generation of IAM.
Seven capabilities define the next IAM. Most organizations are still at stage A. Proposed direction.
So where does your organization sit today? The honest self-assessment has three stages. Stage A: agents use shared credentials and inherited user permissions, and nobody can reconstruct the authority behind a given action. Stage B: each agent has a distinct identity and scoped authority, but the scope is enforced by convention or by the agent’s own cooperation. Stage C: agent actions are cryptographically delegated and enforced at runtime, with receipts.
Most organizations are at stage A and believe they are at stage B. The way to find out is not to ask the platform team for an architecture diagram. It is to pick one consequential action from last week and try to reconstruct, from evidence, exactly who authorized it.
What to Do Next
1. Inspect. Inventory every agent that can change state in one production system: its identity, the credentials it holds, the tools it can reach, and the human authority behind its delegation. Record where the chain breaks.
2. Test. In a controlled environment, attempt one action outside an agent’s delegated scope using a valid credential, plus one legitimate action inside it. Confirm the unauthorized action is denied by an independent check and the legitimate one completes with a full execution receipt.
3. Decide. If agents share credentials or inherit user permissions, treat the environment as stage A and scope a runtime enforcement pilot on your highest-consequence workflow. If distinct identities and scoped authority already hold, document the tested paths and move toward cryptographic delegation with a named HEAR.
Find Your Exposure First
Free AI governance assessment, instant score, no sales call required.
Score Your AI Risk in 8 Minutes · Book a Strategy Briefing
Identity is the perimeter. Delegation is the policy. Execution is the proof.
