Every AI agent has three identities. The worst failures happen in the one nobody named
Its own name, the person it acts for and the cloud role it runs as answer different questions. This week's Google, Databricks and Zenity news shows why each needs an owner and a test.
Listen to this article · 5 min
AI-generated narration of the full article.
This week, the industry gave AI agents email addresses, cryptographically attested identities and audit trails written under their own names. In the same week, researchers showed how a set of agents could be exposed without touching any of that. What mattered was the role the agent’s runtime held in the cloud underneath.
Those two stories are not in tension. They are about different identities, and the confusion between them is, in our view, the most common design gap in enterprise agent programs today. “Agent identity” is not one thing. Every production agent has at least three, each answering a different question, usually issued by a different team, and failing in a different way.
The three
The agent’s own principal: which agent acted? This is the agent’s name in the directory and the audit log. Google’s coworker agents, described at Gemini at Work, are the clearest example yet: each gets an identity “governed like an employee”, and every action is “attributed to the agent rather than to a person”. We looked at what that means for hiring and offboarding agents. This identity makes agents accountable as objects. It typically fails when several agents share one name, or when an agent has a name and no sponsor.
The delegated authority: was this person allowed? When an agent acts for someone, it carries their permissions. Databricks’ Genie Agents are the model case: “every tool call runs with the permissions of the user who asks the question”, as we covered in Databricks’ identity design. Delegation guarantees the agent cannot exceed the person. It fails by being too generous: the agent inherits the user’s entire scope for a task that needs a sliver of it.
The workload identity: what can the runtime reach if the agent is subverted? Underneath every managed agent is compute, and compute runs as a cloud role or service account. Zenity Labs’ research on AgentCore, which we analyzed in our article on the execution role, is about this identity alone: according to the researchers, a default role that spanned the region let one compromised agent reach other agents and their memory. This identity fails quietly, because it is created by deployment templates, lives in cloud IAM rather than in the AI inventory, and never appears in the agent’s audit trail as “the agent”.
| Identity | Answers | Usually issued by | Typical failure | Test |
|---|---|---|---|---|
| Agent principal | Which agent acted? | The agent platform or directory | Shared names, no sponsor | Can you list one agent's actions and name its sponsor? |
| Delegated user authority | Was this person allowed? | The user, through OAuth consent | The agent carries the user's whole scope | Can you narrow it to the task? |
| Workload identity | What can the runtime reach if subverted? | A deployment template | One broad role shared by many agents | If this agent were fully compromised, what else falls? |
Why the third one gets missed
Agent governance teams review prompts, tools and data access. Cloud security teams review roles. In a typical organization, neither reviews the workload role in light of what a prompt could make the agent do with it. The agent principal shows up in the AI inventory; the delegated authority shows up in consent screens; the workload identity shows up nowhere the AI program looks.
That is why we would add a rule to the identity authority in our six-authority model of agent governance: the workload identity should reach only the resources of its own agent. Its runtime, its memory, its logs, its model access. Anything else should be reached through the agent principal or the delegated authority, in a call that is authorized and logged. A workload role that can reach a neighbor is a lateral path waiting for an injection. This is our design view, not a vendor requirement.
Where the three meet: the audit record
Each action an agent takes should be recorded with all three: which agent, on whose behalf, under which workload role. Google’s choice to attribute actions to the agent rather than a person is right, as long as the on-behalf-of field survives. Without it, accountability loses the human who set the objective. Without the workload role, an investigation cannot tell whether the agent acted through its intended path or through a credential it should never have held.
Our expectation, and it is a view rather than a fact: within a year, security questionnaires for agent platforms will ask for these three separately, the way they now ask separately about SSO, service accounts and API keys. Teams that can already answer the three tests in the table will spend that year shipping instead of explaining.