Council Post: An AI Agent’s Name Tag Is Not A Permission Slip
David Goldschlag is co-founder and CEO of Aembit, an identity and access management platform for agentic AI and workloads.gettyAt a security conference, I was asked to define identity for AI agents. It is a goo...
David Goldschlag is co-founder and CEO of Aembit, an identity and access management platform for agentic AI and workloads.
getty
At a security conference, I was asked to define identity for AI agents. It is a good question, although I think it can lead the industry to frame the problem too narrowly.
Identity matters, of course. An AI agent acting inside an enterprise should not be an anonymous script, an untraceable service account or a vague extension of whichever user happened to start the workflow. Organizations need to know which agent acted, which user or system it acted for, what authority it used and what happened afterward.
Still, identity is merely the starting point for what is ultimately an access decision. For human users, identity and access management teams and technology have spent decades answering familiar questions. Who is this person? Are they still employed? What group are they in? What application are they trying to use? What device are they coming from? Has anything changed about their risk posture?
AI agents complicate that model because they do not behave like ordinary users. They can call tools, reach APIs, invoke other agents, retrieve data, make decisions at machine speed and operate in workflows that may outlive the original user interaction. They may be hosted in internal infrastructure, embedded in a software-as-a-service platform or chained through several systems before they reach the resource that matters.
That is why identity for agents must be discussed in service of authorization and access and also audit and attribution. The essential question is not simply “Does this agent have an identity?” The better question is “What should this agent be allowed to do right now, through this path and under this context, and how will we prove it later?”
Why The Credential Path Matters
Consider a common agentic flow: user to agent, agent to gateway, gateway to MCP server and then MCP server to resource. That sequence may sound technical, but it exposes a basic access-control problem. Every hop between a user and a resource is a place where credentials can become over-scoped.
The agent should not hold the credential for the final resource. If it does, the architecture has already given away too much. A compromised prompt, a poorly constrained tool call or a simple design error can turn that credential into a broad entitlement.
A better design gives each hop the credential it needs for that step. The agent proves itself to the gateway. The gateway proves itself to the MCP server. The MCP server reaches the resource using an appropriate credential, often through token exchange, without handing the agent more authority than it needs.
Access should narrow, shift or be recalculated as a request moves through the chain. Rights should not balloon simply because a workflow contains several systems.
This is the part I see teams underestimate. They often think they are making a protocol choice or an integration choice. In practice, they are making an authorization decision. MCP- and OAuth-based flows supply useful structure, though a valid token or a completed protocol handshake reveals little about whether the access decision behind it, made deliberately by a person accountable for it, was sound.
A Few Questions For Enterprise Teams
When I speak with security and identity leaders about agents, I usually come back to a few practical questions. They are simple questions, but the answers are often revealing.
Can you distinguish the user from the agent?
An agent may act on behalf of a person, but it should not disappear into that person’s identity. If the downstream log only says the user acted, attribution is already weakened.
Can you explain why the agent received a credential?
The answer should not be “because the workflow needed one.” There should be a policy decision behind it, including the agent, the user or workload context, the requested action and the target resource.
Is the credential scoped to the hop or to the whole chain?
A credential that is appropriate between an agent and a gateway may be inappropriate between an MCP server and a database. Each step should be treated on its own terms.
How long does the credential live?
Long-lived credentials are a poor fit for agentic systems because the agent’s task, context and authority may change quickly. Short-lived credentials force more frequent, more current access decisions.
What does the audit trail actually prove?
After an agent acts, the organization should be able to determine which agent acted, for whom, through which systems, with which credential and under which policy.
Making Sure Identity Earns Its Keep
These questions help expose why traditional service accounts are so often a bad default. A service account may be convenient, but convenience is not the same as control. The account may have more access than the task requires. It may be shared by several workloads. It may also make the final action look like old-fashioned automation when it was really an agentic workflow.
That distinction will matter more as agents move from low-risk productivity tasks into systems that touch customer data, source code, infrastructure, financial processes and regulated records. The goal is to keep what already works in IAM and be honest about where agentic systems strain its assumptions.
Agents need identity, but identity should earn its keep. It should help the enterprise decide what the agent can do, issue the right credential at the right moment, preserve the user and agent context and leave behind an audit trail that can be understood later.
Identity without those outcomes is just a label on a workflow. What actually protects the enterprise is the access decision behind that label, examined at every hop and every credential.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?