The question of whether AI agents should have their own identities is one of the more substantive emerging debates in enterprise identity management, and the practitioner community has not yet converged on a single answer.

The spectrum of opinions in this discussion runs from "same principles, just apply them" to "agents are a fundamentally different class of principal that requires new infrastructure." Both positions have merit, and the right answer for any given organization depends on what their agents are actually doing and how autonomous they are.

This guide covers the core conceptual question, how practitioners are modeling agent identities today, what the tooling landscape looks like, and where Zluri fits into the picture.

The Core Question: Service Account or Something New?

The most defensible conservative position is that an AI agent is, at its core, a program executing automated tasks on behalf of an organization. From that perspective, the existing service account model applies: scope access to the work, enforce least privilege, maintain an audit trail, retire the identity when the agent is decommissioned. The fundamental principles of access control do not change because the executor is an AI model rather than a script.

The counter-argument, which gains force as agents become more autonomous, is that AI agents have characteristics that break the assumptions service account models are built on:

Autonomy and unpredictability. A traditional service account executes a defined, deterministic set of operations. An AI agent reasons about what to do and may take actions that were not explicitly anticipated at provisioning time. The access it needs is harder to scope precisely because its behavior is harder to predict.

Identity emulation and delegation. An AI agent may act on behalf of a human user, executing workflows across multiple systems in the user's context. When an agent takes an action in Jira on behalf of a user, the accountability chain (agent identity, human owner, delegated authority) is more complex than a service account accessing a single endpoint.

Ephemeral and variable lifecycles. Some AI agents exist for the duration of a single task and are then retired. Some persist indefinitely. Some spawn sub-agents to complete components of a workflow. The lifecycle model for these identities varies significantly from the relatively stable lifecycle of a traditional service account.

Chain-of-custody complexity. When an agent calls another agent (A2A workflows), the identity and permission chain extends across multiple autonomous actors. Auditing what happened and who authorized it requires tracing through multiple delegated identities, not just one.

The practitioner consensus from this thread is approximately: treat agents as advanced service accounts by default, but recognize that sufficiently autonomous agents, particularly those that emulate human identities, delegate across systems, or spawn sub-agents, require additional identity metadata and tighter runtime governance.

How IAM Practitioners Are Modeling Agent Identities Today

There is no single dominant pattern yet, but several approaches are in use:

OAuth/OIDC-based agent identity. Treating AI agents as OAuth clients with their own identities, receiving scoped, time-limited credentials per tool call rather than long-lived API keys. This approach, which aligns with the A2A (Agent-to-Agent) protocol's OAuth-based authorization model, provides per-agent identity, per-call scoping, and an audit trail that ties every action to a specific agent identity. The IETF community is actively working on standards in this space.

Proxied access with user context. In user-facing AI systems, the agent's identity inherits the human user's context. The agent acts as a proxy for the user, with the user's permissions determining what the agent can do. This preserves the human accountability chain and keeps the permission model simpler, at the cost of tighter integration between the agent and the specific user session it is operating within.

Service account with enhanced metadata. The conservative approach: create a service account for the agent, but enrich it with additional metadata that service accounts typically do not carry: the AI model and version it uses, where it is hosted, its human owner or responsible team, and explicit expiration or lifecycle controls. This is more achievable with current tooling than purpose-built agent identity infrastructure.

The most sophisticated practitioners, working with autonomous multi-agent systems, have concluded that none of these approaches fully resolves the problem, and that agent identity requires addressing three questions per action rather than per account: which agent is acting (including model version and run context), on whose behalf, and what is it specifically permitted to do right now given that context.

The Biggest Risk: API Keys Taped to an LLM

The most common failure mode in production agent deployments today is what one practitioner aptly described as "root API keys taped to an LLM." An agent is given a credential with broad permissions because it is easier than scoping tightly, and because the agent's unpredictable behavior makes tight scoping difficult. There is no per-agent audit trail because the key is shared across multiple agents or agent instances.

When something goes wrong, or when a compliance audit asks what the agent accessed, there is no answer. The identity infrastructure was not designed for the accountability requirement.

The minimum governance requirements for AI agent identities in production environments should include:

• Per-agent credentials, not shared API keys across agents
• Scoped permissions that reflect what the agent actually needs, reviewed at provisioning
• An audit log that ties every agent action to a specific agent identity and a human owner
• Defined lifecycle: when the agent is retired or replaced, its identity is explicitly retired
• Human ownership assignment: every agent has a named person or team responsible for its actions

What the IAM Tooling Landscape Offers Today

The major identity providers are beginning to create first-class support for agent identities:

Microsoft Entra has introduced "Entra Agents" as a distinct identity category, separate from service principals, to surface and manage AI agents deployed in the Microsoft ecosystem.

Okta has published guidance on AI agent lifecycle management and OAuth-based authorization for agent-to-agent workflows, treating agents as OAuth clients with their own registration and permission scope.

Emerging purpose-built tools like Kontext are building identity and authorization infrastructure specifically for AI agents: per-agent OAuth/OIDC identities, just-in-time scoped credentials per tool call, and audit trails tied to responsible humans. The protocol space is also active, with IETF drafts for agent identity specifications in development.

The honest state of the market is that tooling is early and fragmented. The standards are not finalized. The platforms that handle this most coherently today are either native cloud platforms with AI-specific extensions or purpose-built agent identity tools. General-purpose IGA platforms are in the process of building first-class agent identity support.

Where Zluri Fits: The Governance Layer for Agent Identities

Zluri's approach to AI agent identity is through its Identity Visibility and Intelligence (IVIP) module, which extends the platform's governance capabilities from human identities to non-human identities and AI agents.

Discovery and classification. Zluri automatically discovers AI agents operating in the environment and classifies them as a distinct category of non-human identity, separate from standard service accounts. The classification captures the metadata that makes agent identities governable: which AI model the agent uses, where it is hosted, what systems it connects to, which human or team owns it, and what its current lifecycle state is.

Relationship mapping. Rather than treating the agent as a single endpoint, Zluri maps the relationship graph: which identities the agent connects to or emulates, which roles it holds across connected systems, and what downstream resources it can access. This is the context needed to understand the actual access surface of an agent deployment.

Governance integration. AI agents discovered by Zluri can be brought into the same governance framework as human identities and traditional service accounts: access reviews, ownership assignment, lifecycle controls, and risk assessment through ISPM. The governance process is not identical to human JML workflows, but it uses the same infrastructure.

MCP server integration (roadmap). Zluri's product roadmap includes exposing a Model Context Protocol server, which will allow AI agents and service accounts to programmatically request their own access to downstream applications. This reflects the direction the industry is moving: agents that can manage aspects of their own identity and access lifecycle within defined policy boundaries, rather than requiring human administrators to manage agent access manually.

Shadow AI governance. For organizations concerned about AI agents and tools that were deployed without IT oversight, Zluri's GenAI visibility capabilities surface agent-based tool usage alongside human AI tool usage, giving governance teams visibility into the full AI identity landscape rather than just the agents that went through formal procurement.

The Open Questions

Several questions in this space do not yet have settled answers:

At what level of autonomy does a service account model break down? Practitioners disagree on whether sufficiently sophisticated agent behavior requires fundamentally different identity infrastructure or whether the existing model, applied rigorously, is sufficient.

Who is liable when an agent takes an action that causes harm? The accountability chain between an agent's actions, its identity, its human owner, and the organization deploying it is not clearly defined in most legal or regulatory frameworks. This is an open question that will likely be resolved through governance frameworks and regulatory guidance rather than technology.

How do you scope permissions for an unpredictable actor? The least privilege principle is clear in theory and difficult in practice when the actor's behavior cannot be fully specified at provisioning time. The emerging answer involves runtime-evaluated policy rather than static role assignment, but the tooling for this is immature.

The direction of travel is clear even if the destination is not: AI agents will be treated as first-class identity principals with their own lifecycle, their own credentials, their own audit trails, and their own governance processes. The organizations that build this infrastructure now, even imperfectly, will be ahead of the compliance requirements that are coming.