What a first-class agent identity actually is, and whether it is just workload identity
The previous post left you with a borrowed credential and a non-deterministic actor that a static grant cannot govern. The fix is to stop borrowing. Give the agent a stable, verifiable runtime principal you can authorize against, attribute actions to, and revoke on its own.
That sentence hides four requirements. Pull them apart.
The four things an agent identity needs
A distinct principal. The agent is its own actor, not a human it impersonates and not a shared service account it hides inside. Its actions resolve to it.
Scoped permissions. The grant is narrower than any human’s, sized to the task, not to the person who launched it. Scope is the answer to the non-determinism problem from Part 1: you cannot predict every action, so you bound the space the agent can act in.
A clear owner. Every agent traces back to a person or team accountable for it. An identity with no owner is a liability with no name on it.
A kill switch. You can revoke the agent without touching anyone else’s credentials. Independent revocation is what makes the identity safe to hand out in the first place.
Miss any one of these and you are back in Part 1. The alternatives engineers reach for first each miss at least one.
| Approach | Actor model | Attribution | Scoping | Revocation | Where it breaks |
|---|---|---|---|---|---|
| Shared service account | One identity, many agents | None: all agents look identical | Coarse, shared by all | Revoke one, you revoke all | No way to tell agents apart or shut one off |
| Per-user impersonation | Agent borrows a human | Logs show the human, not the agent | Inherits the human’s full access | Rotating the key breaks the human | The Part 1 problem, by another name |
| Static secret | A long-lived key | Tied to a secret, not an actor | Whatever the secret was minted for | No rotation, no clean revocation | Secret leaks, lives forever, scopes nothing |
| First-class agent identity | A distinct principal | Actions resolve to the agent | Task-scoped, narrower than a human | Independent kill switch | Cost of running it as real infrastructure |
Table 1. The same four questions, asked of every option people try before they give the agent its own identity.
The question a good engineer is already asking
If the agent gets a stable runtime principal with scoped permissions and a kill switch, you have described workload identity. So is agent identity just workload identity with a new label?
This is a live debate, not a settled point, and the honest answer is: it depends. It depends on three invariants.
A one-to-one mapping. One agent corresponds to exactly one workload. When that holds, the workload’s identity is the agent’s identity.
A registry as the source of truth. Something authoritative records which agents exist and what they are. Without it, you cannot reason about the population of agents, only about individual processes.
Identity continuity. The identity survives restarts, pauses, and reschedules. The agent that comes back up is provably the same agent that went down.
When all three hold, agent identity collapses into workload identity. You attest the workload with something like SPIFFE or WIMSE and you authorize against it directly. No extra layer earns its place.
When they break, agent identity becomes a layer on top of workload identity. And they break often. Agents are bursty. They are ephemeral. They churn across workloads instead of pinning to one. They spawn sub-agents that have no workload of their own to attest. The one-to-one mapping dissolves, continuity gets hard, and the workload is no longer a faithful stand-in for the agent.
What the shipping platforms tell you
The publicly announced platforms show the layered pattern in production. Microsoft Entra Agent ID introduces a specialized principal that extends an existing directory, rather than reusing a plain workload identity. AWS Bedrock AgentCore exposes a stable agent identity that sits above a sandboxed workload, which can churn underneath without the agent’s identity churning with it.
Notice what both share. Each lives inside a single control plane and a single trust domain. One system issues the identity, governs it, and can see every hop the agent makes, because every hop happens on home turf. That is what makes the layered model tractable for these platforms.
Hold that observation. It is doing more work than it looks like, and it is the assumption that breaks in Part 4.
The take-away
An agent identity is a stable runtime principal with its own scoped permissions, a clear owner, and an off switch. Whether that is plain workload identity or a layer above it is not a matter of taste. It depends on whether you can hold the one-to-one mapping, a registry as source of truth, and continuity across the agent’s life. Audit your own agents against those three invariants. Where they break is where you need the extra layer, and where most real fleets live.
You now have a single agent with an identity. Real systems are not single agents. A user calls an agent, the agent calls a tool, the tool calls another agent, and the identity has to survive every hop. The next post is about what happens to identity in that chain, and the protocols that either preserve it or destroy it.
The post What a first-class agent identity actually is, and whether it is just workload identity appeared first on DataRobot.
