AI agents are proliferating across the enterprise. They inherit credentials, act on behalf of users, and make autonomous decisions. But most security teams still think about agent identity through the lens of service accounts and API keys. That framing covers maybe 20% of the actual risk.
Non-human identity (NHI) management focuses on static, predictable workloads. A service account does the same thing every time. An AI agent makes dynamic decisions based on context and instructions that change at runtime. It can chain tool calls, delegate to sub-agents, and take actions no human explicitly authorized. The identity questions that matter for agents are fundamentally harder: Who is accountable when this agent acts? Can I trace the full chain of who asked whom to do what? And is the agent actually doing what it was authorized to do?
Where Agents Show Up (and Why Identity Gets Complicated)
Agents run in three distinct environments across the enterprise, each with different architecture and different identity risks.
Homegrown AI
Engineering teams build agents on AWS Bedrock, Azure AI Foundry, Databricks, and in code using frameworks like LangChain and CrewAI. These tend to be high blast radius: customer-facing applications with access to sensitive data, chaining tool calls across production systems.
SaaS agent platforms
Business users build agents on Microsoft Copilot Studio, Salesforce AgentForce, and ServiceNow. They often do this without security teams ever knowing about it. Companies we work with typically discover 10 to 100 times more of these agents than they expected. This is where identity problems like inherited permissions and unscoped access become acute.
Prebuilt agents
Coding assistants like Claude Code, Cursor, and GitHub Copilot running on developer endpoints, connecting to a growing ecosystem of MCP servers. These agents operate with the developer’s full identity and permissions. Computer use capabilities mean the agent can access anything the developer can access through their browser or local machine.
Each environment requires different security approaches. But the identity challenges they share are what make this problem so hard to solve with existing tools.
Four Dimensions of Agentic Identity
To make sense of agentic identity, it helps to break it into four distinct dimensions. Each one represents a different type of risk, and each requires different controls.
1. Ownership and accountability
The most basic question: who owns this agent, and who do I contact when something goes wrong?
It sounds simple, but agents make this harder than it already was. Many agents run without a specific owner. Orphan agents running under system or root accounts are common across every environment. If there is no clear owner, there is no one to reach out to when an agent behaves unexpectedly, and no one accountable for its configuration and permissions.
Security governance starts here. Before you can manage what an agent does, you need to know who built it, who can edit it, who can change its tools, and who is responsible when something breaks.
2. Delegation and the Maker’s Identity problem
Agents act on behalf of users. The question is how permissions flow from the human to the agent, and whether that delegation matches what the agent actually needs.
The most common failure mode here is the Maker’s Identity problem, and it is one of the top three identity risks organizations raise. When a business user creates an agent on Copilot Studio or AgentForce, the agent often runs with the maker’s credentials, not the current user’s. Every subsequent user inherits the maker’s permissions. An HR manager builds an agent and shares it with the sales team. Now every sales rep can access HR data through the maker’s identity, without anyone realizing it.
The same problem appears with MCP servers. A developer builds an MCP server and encodes their API keys or a shared service account directly into the configuration. Everyone who connects to that MCP server now operates with the builder’s credentials. That is the default behavior in many deployments.
Even where delegation is done properly through mechanisms like OAuth, the scoping is often too broad. A coding assistant inherits the developer’s full permissions, which means the agent can do everything the developer can do. The deeper issues are around lifecycle: is the delegation short-lived or long-lived? Does the token expire? If the developer’s permissions change, does the agent’s access update accordingly? These compound when agents delegate to other agents.
3. Static agent identity
Many agents rely on static credentials to connect to the systems they need: API keys, shared service accounts, long-lived tokens. This is the NHI (non-human identity) dimension of the problem, and it is genuinely dangerous.
Static credentials do not expire on their own. They do not reflect the current user’s permissions. They are often shared across multiple agents or environments, meaning a single compromised key grants access to every system that key touches. Attackers with model-assisted code analysis can find embedded credentials in configuration files and code repositories quickly. Anthropic’s recent Zero Trust playbook for AI agents calls out static API keys and shared service-account passwords as no longer acceptable at any security tier.
The risk compounds when agents use these credentials to access sensitive enterprise systems. A static API key to a database means every agent using that key has the same level of access, regardless of who is operating the agent or what the task requires. There is no way to scope, audit, or revoke access at the user level. If the key is compromised, every agent that depends on it is exposed.
4. Connected agents
Agents increasingly talk to other agents. An orchestrator agent delegates tasks to specialized sub-agents. Each sub-agent may invoke its own tools, access its own data sources, and even spin up additional agents.
The identity challenge is that permissions can inflate or get lost through these chains. If a user delegates permissions to Agent A through OAuth, and Agent A triggers Agent B, does Agent B inherit those same permissions? Does it assume additional ones? When Agent B calls an external API, whose identity is it acting under?
In almost every agentic workflow today, agents trigger sub-agents without the user being aware of it. If you cannot trace the full delegation chain and verify that permissions narrow (rather than expand) at each handoff, you have a governance gap that grows with every new agent-to-agent connection.
Access is Half the Battle
There is a useful analogy for thinking about the relationship between access control and runtime security.
Think of it as a party. The first layer is the bouncer at the door. You have a list of who is approved, who is blocked, and who needs additional review. The bouncer checks credentials, verifies identity, and decides who gets in. This is the equivalent of an access control registry: which MCPs are approved, which agents are allowed, which tools are permitted, and for which users.
That layer is necessary. Without it, you have no governance at all. Many organizations today manage this through an Excel spreadsheet or a Jira ticket, which means enforcement is a hope, not a control.
But approval does not mean safety. Even someone who is on the list and approved for a specific task can still cause harm once they are inside. The fact that an agent is approved to use email and Salesforce does not mean you should stop watching it. This is where the second layer comes in: runtime behavioral detection that monitors what agents actually do after they are approved.
Both layers need to share context. The bouncer should tell the people inside who just walked in, so they know what to watch for. Without that connection, access control is just a registry with no enforcement, and runtime detection lacks the policy context to make precise decisions.
What “Good” Looks Like
Addressing agentic identity requires three capabilities working together, not as separate tools from different vendors, but as layers that share intelligence.
Discovery and posture – You need a complete inventory of every agent, its full identity profile, and its blast radius. Who built it? What credentials does it use? Does it run with static (maker’s) or dynamic (user’s) identity? What permissions do those identities grant? What tools, data sources, and downstream agents is it connected to? Without this visibility, you cannot make informed access decisions.
Access control – Per-agent, per-tool policies scoped by the current user’s identity and group membership. Not just “is this MCP approved or blocked,” but “is this specific user allowed to invoke this specific tool on this specific MCP.” The registry should be auto-populated from discovery and runtime data, not manually assembled one entry at a time. And critically, it needs an enforcement mechanism. A registry without enforcement is documentation, not security.
Runtime behavioral detection – Access control defines what agents are allowed to do. Behavioral detection verifies what they actually do. By monitoring the full sequence of agent actions across a session, you can detect when behavior diverges from intent. Any single action might look fine: reading customer records, sending an email, updating a CRM. But the combination of these actions in sequence can reveal data exfiltration that no individual action would trigger on its own.
The key is that these layers feed each other. Discovery tells access control what exists. Access control tells runtime what is permitted. Runtime tells discovery what is actually being used. When a detection fires, it is enriched by everything the platform knows about the agent: its identity, its permissions, its connections, and its risk profile. That shared context is what makes detections precise and keeps false positive rates low enough to actually use.
Where to Start
This domain is large. Tackling everything at once is not realistic.
The practical approach is to lay out the risks across your three AI environments and identify where the highest risk concentration is today. For most organizations, that starting point is prebuilt agents. Coding assistants are the most widely adopted, the most capable, and the most exposed from an identity perspective. They operate with developer credentials, connect to external MCP servers with minimal review, and can access anything on the developer’s machine.
Some of the risks may be hidden. Identity was already a hard problem before agents. Agents made it harder by introducing angles that existing identity infrastructure was never designed to handle. A developer’s Claude Code agent can take their credentials and act through their browser via computer use. That is not something your identity program accounted for.
Start with the highest-risk surface, get visibility, establish access policies, and layer in behavioral detection. Then expand across your other AI environments. The organizations making the most progress are the ones that started with a concrete surface rather than trying to boil the ocean.
Watch our on-demand webinar Agentic AI Identity & Access Control: Everything You Need to Know to learn more.
