An AI agent that reads your CRM, drafts emails, or books meetings still needs an identity to access enterprise systems. When those identities rely on over-privileged service accounts, workload identities, or long-lived API credentials, they create a security gap. AI agent identity security addresses that gap, while accounting for an added challenge: agents can decide at runtime which tools to call and what actions to take.

The risk is growing with agent adoption. Gartner predicts that by 2028, 25% of enterprise breaches will be traced to AI agent abuse. This guide examines why AI agents are becoming an identity blind spot, what zero trust means for agent access, and the controls needed to govern non-human identities without blocking legitimate agent actions.

What Is AI Agent Identity Security?

AI agent identity security is the set of practices that give each AI agent a registered, scoped, revocable identity. Those practices bind every action it takes to that identity and to the initiating principal (a human, workload, workflow or service) it is acting for, and they enforce what the agent may access as a discrete decision on every request.

It sits inside the broader field of non-human identity security. OWASP describes that field as the identification of the large number of applications in production environments, commonly paired with secrets that function as credentials, some static and long-lived and some short-lived and generated at runtime through attestation.

Agents are non-human identities with a property that sets them apart from most earlier kinds: they decide what to do with the credential after they have it.

That property is what makes agents different.

A service account runs code somebody wrote and reviewed. An agent runs a plan a model produced from its inputs, and those inputs include documents, web pages and tool results that an attacker may control.

If the credential the agent holds is broad, a manipulated agent can misuse every permission it has, so the blast radius of a prompt injection grows with the privileges behind it. If the credential is scoped to the task, the delegating principal and the specific resource, the same manipulation is limited to what that scope allows, and out-of-scope attempts become denied requests and log entries.

Scoped identity does not make prompt injection harmless. It constrains what a manipulated agent can do. Current guidance, including OpenAI’s, treats prompt injection as a problem that needs layered controls: limited permissions, structured data flows, sandboxing, approvals and monitoring.

That is why AI agent identity security is a foundational layer rather than the only one, and why it is an identity problem as much as a model problem.

Why Are AI Agents an Identity Blind Spot?

Three reasons, and they compound, which is why AI agent identity security cannot be handled as a service-account clean-up:

1. 1. Provenance. Agents are often deployed by product and engineering teams without the identity team involved, so the credentials they hold can be created outside the identity lifecycle. There may be no owner in the directory, no expiry and no review.
2. 2. Delegation. An agent acting for a user may do so with its own credential, so the downstream system sees the agent and never the person. The audit trail records that the agent read 400 customer records, with no way to say which request caused it or whether the requester was entitled to any of them.
3. 3. Scope creep by design. An agent that might need to call ten tools may be given credentials for all ten, permanently, because provisioning per task is inconvenient. OWASP’s non-human identity list names the failures this can produce: over-privileged identities, long-lived secrets, insecure authentication, improper offboarding when the pilot ends and the key does not, and reuse of identities across environments and across applications.

An inventory of agent credentials can surface keys with administrator scope, keys older than the team that created them, and keys shared between development and production. None of that is new to identity teams. What is new is that a component now decides at run time how to use them.

The table below maps the OWASP Non-Human Identities Top 10 categories most relevant to AI agent identity security to how each appears in practice and which control addresses it.

What Does Zero Trust for AI Agents Mean in Practice?

NIST’s zero trust architecture (SP 800-207) rests on one assumption. No implicit trust is granted to assets or user accounts based solely on their physical or network location or on asset ownership, and authentication and authorisation are discrete functions performed before a session to an enterprise resource is established.

NIST does not define agent-specific rules. The following is an implementation pattern derived from its principles. Applied to agents, zero trust for AI agents means the agent gets no access because it runs inside the network, was deployed by an approved team, or previously succeeded. Each tool call is treated as a request with an agent identity, a delegation context and a target resource, and it is authorised on its own.

The Model Context Protocol (MCP) is one published example of how this looks for agent tooling. Its authorization specification, updated on 28 July 2026, has several features worth knowing:

• Authorization is optional. The defined OAuth flow applies to HTTP-based transports. Implementations using STDIO are not expected to follow it and instead retrieve credentials from the environment.
• Discovery and audience binding. An MCP server acts as an OAuth 2.1 resource server and must publish protected resource metadata, which clients use to find the authorization server. Resource indicators bind tokens to the resource they are meant for.
• Hardening. Clients must validate the issuer parameter on authorization responses, credentials are bound to the authorization server that issued them, and step-up authorization has clearer rules for how scopes accumulate.
• Client registration is shifting. Client ID Metadata Documents are now the recommended approach, and Dynamic Client Registration is deprecated, though it remains available for backwards compatibility.

MCP’s security guidance has also long treated passing a client’s token through to upstream APIs as an anti-pattern. Audience binding and avoiding token passthrough are the two ideas that stop a token issued for one tool from becoming a key to another, which is the confused-deputy failure agents can be prone to. Whether or not a deployment uses MCP, they are sound design principles for AI agent identity security.

What Are the Six Core Controls for Agentic AI Access Control?

These six controls are a practical architecture for AI agent identity security and agentic AI access control. They cover the identity layer of the wider governance and audit practices discussed in our AI agent audit guide. Where possible, each should be enforced by infrastructure outside the model, so that it holds whether or not the model cooperates. How many are needed, and how strictly, depends on risk, as the later section on proportionate controls explains.

1. A registered identity per agent, with an owner and an expiry

This first control is the foundation of AI agent identity security. Every agent is an entry in the identity provider. It is a workload identity with a named human owner, a purpose, an environment, an expiry date and a review cadence. There are no shared agent identities and no agent running on a developer’s personal credential. When the agent is retired, the identity is disabled through the same offboarding path as a leaver, which addresses OWASP’s first risk before it opens and is a core non-human identity governance task.

2. Delegation context on every action

When an agent acts for a person, the person’s identity should travel with the request. Depending on the identity platform, this may use an on-behalf-of flow or standards-based token exchange and delegation, such as OAuth 2.0 Token Exchange (RFC 8693), which can represent both the subject and the acting party. The downstream system can then authorise against the user’s entitlements as well as the agent’s own, so the customer records the agent can read are limited to those the requesting user could read.

Not every agent acts for a live human. Some run on schedules, events or service-to-service workflows. In those cases, the action is traced to the initiating principal, whether that is a workload, a workflow or a service, and delegation is preserved wherever a human is involved. Zero trust for AI agents depends on this binding, because without it every other control may authorise the wrong principal. It is also what makes agentic AI access control auditable, and it is a control that is often missing.

3. Short-lived, resource-bound tokens

Agents should avoid holding long-lived API keys. They hold tokens issued for a specific resource, with an audience claim the resource validates, valid for a short period and rotated by the platform. Short lifetimes shorten the exposure window.

They do not prevent a stolen bearer token from being replayed while it is still valid. Audience restriction limits where a leaked token can be used, and current IETF OAuth security guidance also points to sender-constrained tokens, such as DPoP (RFC 9449) or mutual TLS, where appropriate, so that a token is useless without the key held by the legitimate client.

Where a tool’s API only supports static keys, the key can live in a secrets gateway and the agent receives a short-lived proxy credential instead.

4. Capability- or policy-bound tool permissions

Each tool the agent may call has an argument schema and a permission scope. One architecture pattern is to enforce capability- or policy-based restrictions on how data may flow between tools.

For example, customer data returned by a read tool can be labelled so that the orchestration layer refuses to pass it to an external email tool.

Current agent-security guidance supports constraining data flow and tool permissions, but there is no single universal mechanism for doing so. The aim is that a manipulated agent meets a denied request instead of an open door.

5. For higher-risk deployments: an egress and secrets gateway

For higher-risk deployments, a centralised egress and secrets gateway can route agent traffic to tools, models and external services through one controlled point.

The gateway can hold the real credentials, issue the short-lived ones, enforce an allow-list of destinations and log every request. No raw secret needs to appear in the agent’s context, configuration or logs, which reduces secret leakage at the source.

The gateway is also a natural place to register a new tool before an agent can reach it, giving non-human identity governance one place to review what agents can talk to. This is an architecture recommendation rather than an industry requirement, and it may not suit every deployment.

6. An execution audit trail linking action, agent and initiating principal

Every tool call can be logged so that an investigator can reconstruct what happened. A useful decision and execution trace records:

• the agent or workload identity
• the initiating user or process
• the authorisation decision
• the tool called
• relevant arguments, with sensitive fields protected or redacted
• any approvals
• the outcome, with timestamps and correlation IDs

An audit system should not depend on recording the model’s internal reasoning. Depending on the platform, full reasoning may be unavailable, inappropriate to retain, or unsafe to log because traces can contain sensitive context. This trace answers a regulator, a customer and an incident responder, and it feeds the periodic review that keeps agent permissions matched to what agents actually do.

What Do Teams Get Wrong About AI Agent Identity Security?

Teams rarely get AI agent identity security wrong because they lack security controls. The bigger problem is applying old identity practices to agents that can act dynamically, call multiple tools, and operate on behalf of people. A few mistakes repeatedly create unnecessary access and accountability gaps:

• Keeping the pilot key: A demo agent gets a key created for testing, the demo becomes production, and the credential never gets rotated or properly governed.
• Making the agent a superuser: One identity gets every permission an agent might need, creating unnecessary blast radius when its actions can be influenced by inputs.
• Losing the initiating principal: When agents act with their own credentials on behalf of users, audit logs can show what the agent did without showing who initiated the action.
• Treating the model as the control: A system prompt cannot enforce access restrictions on its own. Security controls must hold even when an agent is manipulated through prompt injection.
• Treating identity as the whole solution: Identity controls limit what an agent can access, but secure agentic workflows also need sandboxing, structured data flows, approvals, and monitoring. See our guide to agentic AI workflows for how these layers fit together.
• Skipping the inventory: Non-human identity governance starts with discovery. Teams cannot govern agent identities they do not know exist.

How Much Control Is Enough? A Risk-Based View

The right depth of AI agent identity security depends on architecture, data sensitivity, regulation and threat model. There is no universal threshold. As access becomes more sensitive or actions become consequential, stronger identity, delegation, authorisation, egress and audit controls become increasingly appropriate.

Building every control for an internal documentation assistant may be more than its risk warrants. The same controls are usually easier to design in early than to retrofit once an agent is embedded in a business process. The build-versus-integrate decision for the agent itself is covered in our comparison of custom AI agents and integration. The identity layer is a question in either case.

Give Every Agent a Name, a Scope and an Accountable Owner

AI agent identity security is the ordinary discipline of identity applied to a component that is anything but ordinary. The component decides at run time what to do with what it holds. The forecasts point to rising incident rates.

The OWASP list says which identity failures to look for. NIST says no implicit trust, and the MCP specification shows what audience-bound, delegated authorisation looks like in a published protocol. The six controls are one practical way to get there: register the identity, preserve delegation, shorten and bind the token, constrain the tools, gate the egress where risk warrants it, and link every action to an initiating principal and an execution record.

The central principle holds across all of them. AI agents should not receive trust simply because they are approved applications. Their identities, delegated authority, tool permissions and actions need enforceable boundaries outside the model itself.
Start with the inventory, because the keys nobody owns are among the cheapest risks to remove.

Frequently Asked Questions

1. What is AI agent identity security?

AI agent identity security is the set of practices that give each AI agent a registered, scoped and revocable identity. They bind every action to that identity and to the initiating principal, whether a human, workload, workflow or service, and authorise each request as a discrete decision. It is part of non-human identity security, with one added challenge: an agent decides at run time how to use the credentials it holds, so its inputs can steer its actions.

2. Why are AI agents an enterprise identity blind spot?

Because agents are often deployed outside the identity lifecycle with credentials that can lack an owner or expiry. They may act for users with their own credentials, so audit trails can lose the human, and they can be given broad permanent scope for convenience. Gartner predicts 25% of enterprise breaches will be traced to AI agent abuse by 2028. The OWASP Non-Human Identities Top 10 names the specific failures agents inherit.

3. What does zero trust for AI agents mean?

It applies NIST’s zero trust principle, no implicit trust from network location or asset ownership and authentication and authorisation as discrete functions before access, to agents. NIST does not define agent-specific rules, so the practical pattern is derived from those principles. An agent gets no access because it runs inside the network or was deployed by an approved team. Each tool call is treated as a request with an agent identity, a delegation context and a target resource, authorised on its own.

4. How does the Model Context Protocol handle agent authorisation?

MCP’s authorization specification, updated on 28 July 2026, is optional, and its OAuth flow applies to HTTP-based transports, while STDIO implementations retrieve credentials from the environment. It requires protected resource metadata for discovery, uses resource indicators to bind tokens to their intended resource, and requires clients to validate the issuer on authorization responses. It also clarifies step-up authorization and favours Client ID Metadata Documents, with Dynamic Client Registration now deprecated.

5. What is non-human identity governance for AI agents?

Non-human identity governance gives every agent identity an owner, a purpose, an environment, an expiry and a review cadence. It retires the identity through the same offboarding path as a human leaver, keeps separate identities per environment, and reviews permissions whenever the agent’s tools change. For higher-risk deployments, a gateway that registers every tool an agent may reach gives governance one place to see what agents can talk to.

6. How do you implement agentic AI access control?

AI agent identity security in practice means adopting the controls that match the risk of the agent. These are a registered identity per agent, delegation context on every action, short-lived resource-bound tokens, and capability- or policy-bound tool permissions enforced by the orchestration layer. Higher-risk deployments can add an egress and secrets gateway, and every deployment benefits from an execution audit trail that records the agent, the initiating principal, the authorisation decision and the outcome. Starting with an inventory shows where the largest gaps are.