AI agents are becoming actors inside the enterprise. They read data, invoke tools, call APIs, create content, trigger workflows and, in some cases, make decisions. They therefore need identity. Not as an afterthought. Not as a shared service account. And not merely as a label inside an AI platform. This paper argues that enterprises should treat agents as first-class, non-human identities with explicit ownership, lifecycle, delegated authority, least privilege, auditability and revocation. The operating model should be driven by Enterprise Architecture, in close collaboration with Cyber Security, because agent identity is not only a security control. Like any other actor within the business we need to track what they do, checking that they are authorised to access particular types of data. Each agent needs a unique identity. It is part of the enterprise control plane for AI.
AI agents change the identity problem because they do not only consume information. They act. A reporting chatbot that answers questions from approved data is one thing. An agent that can query systems, change records, send messages, raise purchase orders or deploy code is another. The risk sits in the gap between “assistant” and “actor”. NIST has recognised this shift through its AI Agent Standards Initiative and its draft work on applying identity and authorisation standards to software and AI agents.
Traditional identity controls were built around three broad classes: humans, service accounts and workload identities. Agents do not fit neatly into any one of these. They may act for a human, act for a process, act on behalf of several users, or call other agents. They may also be short-lived, self-extending, tool-using and difficult to predict. The OpenID Foundation’s 2025 white paper makes the point directly: current standards can support simple agent scenarios, but more autonomous, cross-domain and delegated use cases expose unresolved questions in authentication, authorisation and identity management.
The central question is therefore simple: should agents be treated like system accounts, or like humans? The answer is neither. Agents should be treated as first-class non-human identities. They require the governance discipline normally applied to users, the technical controls normally applied to workloads, and additional controls for delegation, intent, containment and observability.
The first enterprise principle should be that every agent has a distinct identity. A credential is only a means of access. An identity is the durable control object that links purpose, owner, authority, risk, policy and evidence. If an agent only uses a shared API key, a generic service account or a human’s long-lived token, the enterprise cannot reliably answer who acted, under whose authority, for what purpose, and within what limits.
This matters because agent activity can scale faster than human governance. The Cloud Security Alliance’s research on non-human identity and AI security found that AI adoption is amplifying existing problems around visibility, ownership, credential lifecycle and token sprawl. It also found that fewer than a quarter of organisations had documented and formally adopted policies for creating or removing AI identities.
The right design pattern is therefore to create a registered agent identity for each material agent. That identity should include a human sponsor, business owner, technical owner, purpose, approved tools, data boundaries, allowed actions, risk rating, expiry date, logging requirements and revocation path. This aligns with emerging guidance from the Coalition for Secure AI, which describes agents as first-class identities and highlights lifecycle, delegation, governance and enforcement as core identity topics.
There is a temptation to call agents “digital employees”. This is useful commercially, but loose operationally. Agents are not accountable legal persons. They cannot be trained, disciplined or held responsible. Accountability must remain with a named human and a business function. However, agents should go through processes that look familiar from workforce identity: onboarding, access request, approval, certification, monitoring, change control and offboarding.
This distinction is important. Giving an agent a first-class identity does not make it equivalent to a human. It makes it governable. The identity record should make clear whether the agent acts under user delegation, under application authority, or under a bounded enterprise mandate. It should also make clear whether the agent can act autonomously or only recommend actions for human approval.
The policy should be blunt: no owner, no identity; no identity, no access; no audit trail, no production use. This is a practical way to avoid the unmanaged spread of local agents, embedded SaaS agents, coding agents, MCP servers and API-connected assistants. Current vendor direction supports this: Microsoft describes Agent 365 as a control plane for agents, with Microsoft Entra Agent ID providing identity, lifecycle and access controls; Okta positions its AI agent capability around discovery, onboarding, ownership, lifecycle governance and a kill switch.
Most enterprise access models answer the question: “Is this identity allowed to access this resource?” Agents add another question: “On whose behalf, and for what task?” This is the delegation problem. It is especially hard where an agent handles multiple users, multiple tools, multiple sessions or asynchronous tasks.
A safe pattern is to separate three things: the agent identity, the user or business authority being delegated, and the specific task context. The agent should not simply inherit all of a user’s permissions. It should receive scoped, time-bound, purpose-bound authority. Where the action is sensitive, the agent should require step-up approval or human confirmation.
In practical terms, this means enterprises should avoid broad standing privileges for agents. They should use short-lived tokens, just-in-time access, policy decision points and tool-level authorisation. Microsoft’s Entra Agent ID documentation refers to applying Zero Trust principles and familiar access controls to agents; Okta similarly describes temporary credentials, least-privilege policies and lifecycle governance for agent connections.
Agent identity management should cover six stages:
Discovery — find agents, including unmanaged agents, SaaS-native agents, coding agents, local agents and MCP servers
Registration — create a formal identity record with owner, sponsor, purpose, environment, risk tier and approved capabilities
Authorisation — define what the agent can access, what tools it can call, what actions it can take, and under whose authority
Runtime enforcement — apply policy at the point of action, not only at login
Monitoring and audit — log prompts, tool calls, token usage (and cost thereof), data access, decisions, outputs, delegated authority and exceptions proportionate to risk
Revocation and offboarding — remove access when ownership changes, purpose expires, behaviour is anomalous, or the agent is retired
This lifecycle view is consistent with the market’s direction. Newer vendors such as NewCore are explicitly arguing that AI agents should be managed as first-class identities with their own permissions, lifecycle controls and revocation mechanisms. Established identity vendors are also moving in this direction, with Microsoft, Okta, Ping Identity and others building identity and governance capabilities for agents.
Privileged access is the sharp edge of agent identity. An agent that can read a document library is a risk. An agent that can change payment details, approve access, modify production code, alter security policy or administer cloud infrastructure is a different class of risk.
The enterprise should therefore treat privileged agent access as a distinct control domain. The default position should be that agents do not receive standing privileged access. Where privilege is required, it should be temporary, task-bound, approved, logged and revocable. Microsoft, Okta and Ping are all moving in this direction, with agent controls focused on least privilege, short-lived credentials, lifecycle governance, auditability, delegated authority and just-in-time access.
The privileged access model for agents should rest on five principles.
First, no shared privileged accounts. An agent should never use a generic administrator account, shared service account or embedded privileged secret. This destroys attribution and makes revocation difficult. Agent access should be tied to a unique agent identity, a human sponsor and a defined business purpose.
Second, privilege should be just-in-time. Agents should request privilege only when needed, for a defined task, for a short duration. Approval may be pre-authorised for low-risk repeatable tasks, but high-risk actions should require human approval or step-up control. This is consistent with the direction of Microsoft Entra Agent ID and Okta for AI Agents, both of which emphasise lifecycle governance, short-lived access and policy-based control.
Third, privilege should be constrained by action, not only by system. Traditional access often grants broad rights to a system. Agent access should be narrower. For example, an agent may be allowed to create a pull request but not merge code; draft a customer communication but not send it; recommend a firewall rule but not apply it; prepare a payment batch but not release it. This distinction matters because agents reason through goals and may choose unexpected routes unless runtime controls limit what tools and actions are available.
Fourth, privileged agent activity must be fully attributable. Logs should show the agent identity, the human or process authority under which it acted, the approval path, the tools used, the data accessed, the action taken and the outcome. This is not simply a monitoring requirement. It is the evidential basis for audit, regulatory assurance and incident response.
Fifth, the enterprise must be able to stop the agent quickly. Privileged agents need a kill switch. This should revoke current tokens, prevent new token issuance, disable tool access and alert the accountable owner and security function. Okta explicitly describes this kill-switch pattern for AI agents; Microsoft similarly describes blocking risky agents and governing agent lifecycle through Entra Agent ID and Agent 365.
In practical terms, privileged agent access should be integrated with the enterprise Privileged Access Management model. However, PAM tooling will need to evolve. The historical PAM pattern was designed around human administrators and service accounts. Agentic AI requires a more dynamic model: high-volume requests, short-lived privileges, machine-speed execution, policy evaluation at runtime, and continuous logging of tool calls. The right target state is not a separate “AI PAM” silo, but an extension of the enterprise privileged access model to cover agents as first-class non-human identities.
The policy should be clear: an agent may be powerful, but it should never be permanently privileged.
The joiner, mover, leaver process is usually associated with employees. The same discipline is now needed for agents. The difference is that agents may be created faster, changed more often and retired less visibly than people. Without a formal lifecycle, enterprises will accumulate orphaned agents, stale permissions, ownerless credentials and unreviewed delegated authority. The Cloud Security Alliance has identified visibility, ownership, credential lifecycle and token sprawl as material weaknesses in current non-human identity management.
The enterprise should therefore define an Agent Joiner, Mover, Leaver process. This should be mandatory for production agents and proportionate for lower-risk development or experimental agents.
An agent should not enter production simply because a team has built it or enabled it in a SaaS platform. It should go through a controlled onboarding process.
At minimum, the joiner process should capture:
This should create the agent’s identity record in the enterprise identity platform or agent registry. Microsoft’s Entra Agent ID describes similar concepts, including agent identities, sponsors, access packages, blueprints, lifecycle governance and audit logs. Okta also describes discovery, registration, human ownership, lifecycle governance and deactivation for AI agents.
The joiner process should also classify the agent. A useful classification could look something like this:
The higher the class, the stronger the approval, monitoring and access requirements.
Agent identity risk often increases through change. An agent built to summarise documents is later connected to a workflow tool. A coding assistant is later allowed to raise pull requests. A finance agent is later connected to payment systems. These are not minor configuration changes. They are identity and authority changes.
The mover process should be triggered when any of the following changes:
The mover process should require reassessment of risk and reapproval of access. It should also trigger access recertification. Where the agent’s purpose changes materially, the default should be to remove existing access and require a new access request. This avoids silent privilege accumulation.
A strong policy statement would be: agent access does not move automatically with the agent; it must be rejustified.
This matters especially where an agent follows a human sponsor or business owner. If a sponsor changes role, leaves the firm or moves business unit, the agent should not simply continue with inherited access. The agent identity should be reviewed, reassigned, reduced or retired.
The leaver process is as important as onboarding. Many identity failures arise from accounts that should no longer exist. For agents, the risk is larger because credentials may be embedded in workflows, APIs, scripts, MCP servers, SaaS connectors or developer environments.
The leaver process should be triggered when:
Offboarding should include:
For privileged agents, leaver activity should be immediate and verified. Deactivation in only the AI platform is not enough. The enterprise must confirm that downstream credentials, API tokens, service accounts, secrets and delegated permissions have also been removed. CSA research highlights token sprawl and weak revocation as recurring non-human identity risks.
Agent JML should be linked to human JML. If a human sponsor leaves or changes role, the agents they sponsor should be reviewed automatically. If a business owner changes department, any agents under their ownership should be recertified. If a developer who created an agent leaves, technical ownership should be reassigned or the agent should be suspended until the ownership gap is closed.
This is a critical design point. Agent accountability is anchored in human accountability. When the human anchor changes, the agent’s authority must be questioned.
The enterprise policy should therefore be:
Every agent must have a valid human sponsor. If the sponsor leaves or moves, the agent enters review. If no new sponsor is approved, the agent is disabled.
Policy is enforced when the agent acts — not only when it signs in.
A robust enterprise pattern has five layers.
First, an agent registry. This is the authoritative inventory of agent identities. It should link to enterprise CMDB, application portfolio, data catalogue, API catalogue and identity governance tooling. Without a registry, the enterprise cannot manage agent sprawl.
Second, an identity provider integration. Agents should authenticate through approved identity infrastructure. Where the agent is a workload, it should use workload identity patterns. Where it acts for a user, it should use delegated flows. Where it acts autonomously, it should use a bounded non-human identity with explicit policy.
Third, a policy layer. Policy should express what the agent may do, not just what system it may access. For example: “read invoices under £50,000”, “draft but do not send customer communications”, “create pull request but do not merge”, or “summarise regulated data but do not export it”. The AAGATE research paper describes a governance control plane using policy, behavioural analytics and zero-trust concepts for agentic AI.
Fourth, tool and API mediation. Agents should not connect directly to sensitive systems using embedded secrets. Access should pass through gateways, brokers, MCP servers or API controls that enforce policy, issue short-lived credentials, redact sensitive data where needed, and record actions. CSA guidance highlights just-in-time credentials, fine-grained control and real-time monitoring as important for agentic IAM.
Fifth, observability and response. The enterprise must be able to trace what the agent did, which tools it used, what data it touched, what authority it relied on, and what result it produced. This is not optional; it is the basis for assurance, incident response, regulatory evidence and trust. OWASP’s Agentic Security Initiative and NIST’s AI RMF work both point towards structured risk management, threat modelling and control verification for agentic systems.
Enterprises should adopt the following policy positions.
1. Agents must be first-class identities. Shared service accounts, unmanaged API keys and embedded long-lived secrets should be prohibited for production agents.
2. Every agent must have a named human sponsor and business owner. Accountability must sit with a person and a function, not with the model, platform or vendor.
3. Agent authority must be explicit, bounded and reviewable. Agents should receive the minimum access needed for a defined purpose, with time limits and periodic recertification.
4. Delegated access must be task-scoped. Agents should not automatically inherit all rights of the user they assist. Sensitive actions should require human approval or step-up control.
5. Runtime controls matter more than static approval. Because agents can adapt their path to a goal, controls must operate when tools are called, data is accessed and actions are executed.
6. Agent activity must be observable. Logs should capture identity, owner, delegated user, tool calls, data access, decisions, outputs and exceptions. The level of logging should reflect the risk of the agent.
7. Revocation must be immediate. The enterprise needs a kill switch for agents that are compromised, misconfigured, obsolete or outside policy.
8. Vendor-native controls are useful, but not sufficient. Enterprises will use agents from Microsoft, Salesforce, ServiceNow, Google, OpenAI, Anthropic, coding platforms, SaaS providers and internal teams. The control model must therefore be enterprise-wide and vendor-neutral, even where vendor tooling provides enforcement in specific domains.
The vendor market is moving quickly. Microsoft has positioned Agent 365 as a control plane for enterprise agents, with Entra Agent ID providing identity, lifecycle, Conditional Access, governance and audit capabilities for agents. Microsoft’s public documentation describes agent identity blueprints, sponsors, access packages, logs and protection of agent access to resources.
Okta has launched Okta for AI Agents, focused on discovering agents, onboarding them as first-class identities, assigning human owners, providing temporary credentials, enforcing least privilege, governing lifecycle and supporting a kill switch. Okta also links this to its wider identity security fabric and Auth0 capabilities for standards-based agent development.
Ping Identity, Orchid Security and Palo Alto Networks are also moving towards agent identity control-plane capabilities. Reported capabilities include agent discovery, governance, auditability, delegation mapping, privileged just-in-time access and monitoring of agent activity and authorisation paths.
New entrants are appearing as well. NewCore, for example, has emerged around the proposition that identity platforms need to manage both human and AI-agent identities, with agents treated as first-class identities rather than conventional service accounts or machine credentials. This is a useful signal: the market is converging on agent identity as a distinct discipline.
Alongside newer agent-focused capabilities, established identity and security platforms are extending their offerings to support non-human and agent identities. These vendors play a critical role in providing the foundational governance, lifecycle management and privileged access controls required for agent identity.
SailPoint is extending its identity governance platform to cover non-human identities, including service accounts, APIs and emerging agent identities. Its strengths in lifecycle management, access certification and policy-driven governance make it well suited to managing the onboarding, review and ongoing governance of agents within enterprise identity programmes.
Saviynt provides a cloud-native identity governance platform with strong capabilities in application access control, risk visibility and compliance. Its architecture is particularly relevant where agents interact with SaaS applications such as ERP, HR and finance systems, enabling fine-grained control over what agents can access and perform within business-critical environments.
CyberArk brings deep capability in privileged access management and secrets security. In an agent context, this is especially important for controlling high-risk agents that require elevated access, ensuring credentials are protected, access is granted on a just-in-time basis, and sensitive operations are tightly controlled and auditable.
These platforms provide essential building blocks for agent identity, particularly in governance and privileged access. However, they do not yet constitute a full agent identity control plane on their own and must be integrated with runtime policy enforcement, tool mediation and observability layers.
The enterprise should not wait for the market to settle. The correct approach is to define principles and architecture now, then map vendor capabilities against them. Buying tooling without a policy model will automate confusion.
Agent identity should be led by the Enterprise Architecture function, in collaboration with Cyber Security. Cyber Security owns many of the controls, but Enterprise Architecture owns the coherence of the enterprise control plane: identity, data, applications, integration, platforms, operating model and technology standards.
This matters because agent identity decisions cut across domains. They affect application architecture, API strategy, data governance, SaaS governance, developer platforms, service management, risk, procurement and compliance. If the topic is treated only as a security tooling issue, the result will be fragmented controls, inconsistent ownership and weak adoption.
Enterprise Architecture should therefore define the reference architecture, approved patterns, identity taxonomy, lifecycle model, integration standards and exception process. Cyber Security should define risk thresholds, control requirements, monitoring, incident response, privileged access rules and assurance testing. Together, they should create the enterprise standard for agent identity.
The correct enterprise position is clear.
Agents should not be treated as ordinary service accounts. They are more dynamic, more delegated and more capable. They should not be treated as humans either. They have no personal accountability and cannot be trusted through training, culture or intent.
Agents should be treated as first-class non-human identities. Each should have a unique identity, named human sponsor, business owner, defined purpose, bounded authority, lifecycle controls, runtime enforcement, audit trail and rapid revocation.
Privileged access should be exceptional, not standing. It should be just-in-time, task-scoped, approved, logged and easy to revoke. Agents should not hold permanent administrative access or use shared privileged credentials.
The joiner, mover, leaver process must also be extended to agents. Agents should be formally onboarded, reviewed when their role or owner changes, and fully decommissioned when no longer needed. Human JML and agent JML should be linked, because agent accountability depends on accountable human ownership.
These principles, policies and patterns should be driven by the Enterprise Architecture function, working in close collaboration with the Cyber Security. Enterprise Architecture should own the reference architecture, lifecycle model, identity taxonomy and integration patterns. Cyber Security should own the control requirements, risk thresholds, privileged access rules, monitoring and response model.
Agent identity is not a side issue. It is one of the foundations of the AI control plane.
This glossary defines the terms used throughout the paper in plain enterprise language.
A software actor that can reason about a goal, use tools, call systems or APIs, and perform work with some degree of autonomy.
The durable identity record for an agent, including owner, purpose, permissions, lifecycle state, risk tier and audit requirements.
The authoritative inventory of approved enterprise agents and their associated owners, sponsors, scope and access.
The degree to which an agent can act without human approval, from advisory only through to bounded autonomous execution.
Permission granted to an agent to act for a user, process or business function for a defined purpose and time.
An identity that is managed directly through enterprise identity governance rather than hidden behind a shared account, token or platform label.
The named person accountable for an agent’s existence, purpose, review and retirement.
Access granted only when required, for a limited duration and a defined task.
A mechanism to rapidly disable an agent, revoke tokens, block new access and alert accountable owners.
Model Context Protocol; a pattern for connecting AI assistants and agents to external tools and data sources.
An identity for a machine, workload, service, bot or agent rather than for a person.
An agent that can administer systems, change controls, deploy code, approve access or perform high-impact business actions.
Policy enforcement at the moment an agent calls a tool, accesses data or takes an action.
A non-person account commonly used by applications or services. It should not be used as a shared or unmanaged substitute for agent identity.
Access limited to a specific job, transaction or action rather than broad access to a whole system.
The use of gateways, brokers, MCP servers or API controls to govern how agents connect to enterprise systems.
An identity assigned to software or infrastructure workloads so they can authenticate without embedded secrets.
