Enterprise AI does not only generate content. It increasingly retrieves data, invokes tools and changes the state of business systems. As that shift accelerates, governance must move closer to the point of action – and identity will become the mechanism that connects authority, permission and accountability.
Consider a plausible enterprise workflow. An employee asks an AI agent to resolve a supplier discrepancy. The agent checks the contract, retrieves purchase records, queries the finance system, drafts a response and updates the case. Every individual action may be technically permitted. The harder question is whether the agent was entitled to combine them, whether its authority remained within the user's original request and whether the organisation can later reconstruct the sequence and justify the result.
That is where AI governance changes character.
Policies, principles and review boards still matter. But once an AI system can act across applications, governance becomes a runtime problem. The organisation must identify the active agent, the source of its authority, the permissions available in the current context and the evidence retained after execution.
Agent identity will therefore become foundational enterprise infrastructure. It will not replace identity and access management. It will extend it to software actors that can interpret intent, select tools and exercise delegated authority.
The Existing Weakness
Enterprise AI Amplifies the Weaknesses Already Present
Many AI governance programmes begin with models, acceptable-use policies and risk classifications. Those are sensible starting points, but they can obscure a more immediate problem. Agents operate through the organisation that already exists.
They encounter the same overshared documents, inconsistent permissions, undocumented exceptions and unclear process ownership as employees. They also connect systems that may previously have been governed separately. A weakness contained within one application can become part of an automated chain.
A poorly defined workflow is manageable when an experienced employee knows where the official process ends and informal judgement begins. An agent does not possess that institutional understanding unless it is deliberately represented in rules, data, tools and escalation paths. Give it broad access and it may act beyond the intended boundary. Restrict it too tightly and it cannot complete the task.
Enterprise AI therefore exposes governance debt rather than creating a wholly new problem. Fragmented identity, data and workflow controls were already limiting the organisation. Agents increase the speed, scale and interconnectedness of the consequences.
Identity cannot repair those weaknesses by itself. It can, however, make them enforceable and visible.
The Strategic Shift
Governance Moves to the Point of Action
Traditional AI governance has often focused on what a system is allowed to be used for. Agentic systems add a second question: what is this particular system allowed to do, now, within this workflow?
Every retrieval, tool call and system update is an access decision. That makes identity the practical link between governance intent and operational enforcement.
The market is already moving in this direction. Microsoft describes Entra Agent ID as an identity and security framework for authenticating, authorising, governing and protecting AI agents. AWS positions AgentCore Identity as the identity foundation through which agents access internal and external services, with each request explicitly verified. These are vendor implementations, not neutral standards, but they reveal the same architectural assumption: an agent must become a governed principal rather than an invisible extension of an application or user.
This does not mean every assistant needs an elaborate new identity stack. A read-only tool that summarises information already visible to a signed-in employee presents a different risk from an agent that can approve refunds, modify production code or create supplier payments. The governance requirement grows with the authority to act.
The shift becomes material when AI moves from producing an answer to exercising permission.
The Identity Model
Agent Identity Is More Than a Service Account
Enterprises already manage non-human identities: service accounts, application programming interface credentials, workloads, robotic process automation bots and privileged system accounts. It is reasonable to ask whether agent identity is simply another name for the same discipline.
Partly, it is. Existing identity and access management, privileged access management and workload identity provide much of the foundation. Agents still need unique identifiers, secure authentication, short-lived credentials, lifecycle management and least-privilege access. SPIFFE, for example, provides unique workload identities and short-lived identity documents without relying on static secrets.
The difference lies in delegated authority and behavioural variability.
A conventional workload usually performs a defined technical function. An agent may interpret a goal, decompose it into steps, choose among tools and delegate work to other agents. The enterprise must therefore distinguish the agent's execution identity from the authority it has been given for a particular task.
That distinction prevents impersonation from becoming the default architecture. The agent should not simply borrow a human account and inherit everything that person can access. It should authenticate as itself, while carrying a bounded and traceable record of whose authority it is using, for what purpose, over what period and with which constraints.
OpenID Foundation work reflects this direction. It argues that existing identity frameworks can support many current, in-domain agent use cases, but that increasing autonomy creates harder problems around delegated authority across connected agents. Recent Internet Engineering Task Force drafts are exploring attested agent-instance identifiers, provenance and delegation-chain semantics. These are emerging proposals rather than settled standards, but their existence is a strong signal that ordinary authentication is no longer enough.
The Control Problem
The Real Design Problem Is Bounded Flexibility
The strategic tension is not simply autonomy versus control. Enterprises want agents because they can adapt to circumstances and complete work across traditional system boundaries. If every action requires a new role definition or human approval, the productivity case weakens. If the agent receives broad standing access, operational flexibility becomes uncontrolled authority.
Static permissions create the worst version of this trade-off. They are usually granted before the system knows the exact task, so teams either over-permit the agent or constrain it to narrow demonstrations that cannot survive production complexity.
OWASP's agentic security work identifies tool misuse and identity and privilege abuse among the central risks created when legitimate capabilities operate with inadequate boundaries. The problem is often not a failed login. It is an authenticated actor using valid permissions in a context the organisation did not intend.
A better model is bounded flexibility. The agent receives enough authority to complete the current task, but access is contextual, temporary and progressively constrained as it moves through the workflow.
That model combines several established controls:
- A unique identity for each material agent or agent instance
- Explicit delegation from a user, process owner or approved workflow
- Short-lived, task-scoped credentials rather than shared secrets
- Policy checks before sensitive retrievals, tool calls and state changes
- Step-up approval for high-consequence actions
- End-to-end evidence linking intent, permissions, data access and outcomes
- A rapid suspension or revocation path
OAuth token exchange already provides a basis for obtaining narrower downstream tokens, and current agent-focused drafts are extending the model to make the acting agent and delegation chain more explicit.
The aim is not to eliminate friction. It is to place friction where consequences increase. Reading an approved knowledge article may require no additional approval. Exporting customer records, changing access policy or initiating a financial transaction should trigger stronger conditions.
That is how permission control protects the productivity case rather than undermining it.
The Evidence Chain
Identity Must Travel Through the Workflow
An agent identity that exists only in a directory is not a governance system. It must be propagated through the systems the agent uses and preserved in the evidence those systems generate.
For a material workflow, the organisation should be able to reconstruct a chain such as:
- A named user or approved event initiated the task.
- A registered agent accepted it under a defined purpose and risk tier.
- The agent received a time-limited permission envelope.
- Each retrieval and tool call was evaluated against that envelope.
- Any delegated sub-task received narrower authority.
- High-consequence actions were approved or blocked.
- The final action, affected records and policy decisions were logged.
This is particularly important in multi-agent systems. Without separate identities and explicit hand-offs, one agent can become a confused deputy for another, carrying permissions into a context where they were never intended to apply.
The observability requirement is also becoming more concrete. Microsoft's audit documentation now includes events for agent invocation, model inference and tool execution. An early preview of ISACA's 2026 AI Pulse Poll found that 56% of respondents were unsure how rapidly they could stop an AI system during a security incident. The percentage should be treated as directional survey evidence, but the operational point is difficult to dismiss: an organisation that cannot identify, trace and suspend an agent does not yet control it.
The Operating Reality
Identity Cannot Compensate for Weak Data and Workflow Governance
There is a risk of turning agent identity into the next technology-led answer to an organisational problem. That would repeat the pattern enterprise AI is already exposing.
Least privilege depends on knowing what the minimum necessary access actually is. That requires a defined workflow, a clear process owner, classified information, reliable access controls and explicit exception handling. Where those foundations are absent, the identity team is forced to encode ambiguity.
The result is usually one of two failures. The agent receives broad permissions because nobody can define the required boundary, or the agent remains trapped in a low-value pilot because production access cannot be approved.
Identity should therefore be treated as the operational spine of AI governance, not the whole body. Data governance determines what information may be used. Workflow design determines what actions are legitimate. Risk governance determines which consequences require review. Observability determines whether the organisation can demonstrate what occurred. Identity binds those decisions to an actor at runtime.
The most mature response will connect agent identity to the wider operating model rather than leaving it as a security workstream.
The Leadership Agenda
What Leaders Should Establish Now
Organisations do not need to predict the final agent-platform market before acting. The immediate agenda is architectural and managerial.
First, build an inventory that records every material agent's purpose, business owner, technical owner, runtime, data sources, tools, risk tier and lifecycle state. Discovery matters because agent provisioning can occur faster than conventional governance processes. A Cloud Security Alliance survey of 383 IT and security professionals found that 78% of participating organisations lacked documented policies for creating or removing AI identities. The sample is not a universal measure, but it is a useful warning about governance maturity.
Second, prohibit material agents from borrowing human identities or relying on shared, long-lived credentials. Give the agent its own execution identity and represent delegated authority separately.
Third, map permissions at workflow level. Start with the outcome, identify the minimum actions required, define consequence thresholds and specify where authority must narrow, expire or escalate.
Fourth, make auditability a design requirement. Logs should connect the initiating user or event, agent identity, delegation, policy decisions, retrieved sources, tool calls, approvals and affected records. A generic application log is not enough.
Fifth, define containment before deployment. Every consequential agent needs a known owner, a revocation mechanism and a tested procedure for suspending activity without waiting to diagnose the complete incident.
Finally, integrate rather than isolate. Agent identity should extend existing identity and access management, privileged access, workload identity, data security, policy and observability capabilities. Major platforms are already embedding agent-specific identity constructs, while standards bodies are developing the missing delegation and provenance semantics. The direction is clear even though the architecture is not yet settled.
The Takeaway
Identity Is the Infrastructure of Accountable Autonomy
AI governance will remain broader than identity. Organisations will still need policies, risk assessment, model evaluation, data controls, human oversight and legal accountability.
But those controls become operational only when they can be applied to a specific actor, in a specific context, at the moment it seeks to retrieve information or change a system.
That is why agent identity will become foundational infrastructure. It gives the enterprise a way to distinguish one agent from another, separate execution from delegation, limit authority, trace decisions and revoke access. It turns governance from a statement of intent into a property of the workflow.
The leadership question is no longer only where AI can improve productivity. It is which software actors the organisation is prepared to authorise, under whose authority and within which boundaries.
Enterprises should answer that before autonomy becomes the default.
