AI Agents in the Enterprise: The Identity Problem Nobody Should Ignore

AI agents are not just another application layer. The moment an agent can read mail, open tickets, query finance data, launch jobs or call internal APIs, it stops being a neat demo and becomes an identity problem. In enterprise terms, that means the uncomfortable question is no longer whether the model is capable. It is whether the surrounding control plane can say, with confidence, which agent acted, on whose authority, against which systems, and with what limits. That is where most current agent talk becomes hand-wavy, and where most failures will occur.

For UK and Channel Islands infrastructure teams, this matters because the practical controls already exist in the wider IAM world: roles, federated identity, short-lived credentials, policy enforcement, conditional access and audit trails. What is new is not the security vocabulary. It is the pressure to apply it to software that can decide its own next step, choose tools dynamically and chain actions together. In other words, AI agent identity is not a side issue. It is the control surface.

That framing is supported by the direction of current primary guidance. Microsoft Entra’s workload identity material explicitly treats applications and service principals as identities that need protection, noting that workload identities differ from user accounts and are harder to manage because they cannot do MFA, often lack a formal lifecycle and must store credentials somewhere. Microsoft also recommends workload identity federation and certificates over client secrets where possible, because secrets are less secure and federation avoids long-lived shared credentials. AWS says much the same in its IAM guidance: roles are designed to provide temporary credentials, and identity federation is the preferred way to give external identities access without embedding long-term keys. Meanwhile, RFC 9700, the OAuth 2.0 Best Current Practice, pushes sender-constrained tokens and exact redirect URI matching to reduce replay and token leakage risks. (learn.microsoft.com)

Why now

The timing is not arbitrary. The enterprise market has moved from “Can we get a model to answer questions?” to “Can we let the model take action?” That second phase creates a different security profile. OWASP’s 2025 Top 10 for LLM Applications reflects the shift by continuing to emphasise prompt injection, sensitive data exposure, supply-chain weaknesses and the security risks that come with embedding models more deeply into operational workflows. NIST’s AI Risk Management Framework profile for generative AI adds another layer of context: the concern is not merely output quality, but governance, transparency, accountability and operational risk across the system as a whole. (genai.owasp.org)

That is why “agent identity” is becoming the phrase that should sit ahead of “agent autonomy”. Once an AI system can decide which tools to call, the identity question is no longer about human login alone. It becomes a problem of delegated authority, scoped credentials, lifecycle management, and whether the agent’s actions can be revoked cleanly when something goes wrong. If that sounds familiar, it should. It is the same shape of problem enterprise IT has been solving for service accounts, CI/CD pipelines and SaaS integrations for years. The difference is that agents are less predictable, more conversational, and often closer to sensitive data and privileged workflows.

What actually changes when an agent gets identity wrong

The first-order risk is not that a model hallucinates a bad answer. It is that it takes a bad action with valid credentials. That is a much uglier class of failure. A human user can be trained, challenged, stepped up for MFA or stopped by policy. A workload can only be constrained by the identity architecture around it. Microsoft’s documentation on conditional access for workload identities makes the point plainly: these identities differ from users, are higher risk for compromise and need dedicated controls. AWS similarly distinguishes between roles, users and federated principals because the access model changes materially depending on whether credentials are long-lived or temporary. (learn.microsoft.com)

In practice, this means an enterprise agent that can create records in a CRM, query a warehouse and trigger a procurement workflow should not have one blob of access labelled “AI”. It needs a chain of explicit trust. Ideally that includes:

• a distinct workload identity for the agent or agent service;
• short-lived credentials rather than shared static secrets;
• separate authorisation for each downstream tool or system;
• policy enforced at the identity provider and again at the target service;
• logs that preserve who approved the action, what the agent invoked, and which data it touched.

If that sounds like overkill, consider what happens when an agent is asked to summarise a customer account, update a case and attach documents from a knowledge base. A single prompt injection or over-broad token can turn that into an exfiltration path. OWASP’s current guidance for LLM and GenAI security exists precisely because these systems create new combinations of old mistakes: excessive permissions, insecure tool invocation, data leakage, and weak isolation between instructions and data. (genai.owasp.org)

Evidence and context: the market is already telling us to think in workload identities

What is striking about the current documentation is how unromantic it is. Neither Microsoft nor AWS is suggesting that agents deserve a special new identity theory because they are magical. Quite the opposite. They are pushing enterprises back towards the oldest, dullest, most reliable principles in IAM: least privilege, temporary credentials, federation and explicit trust boundaries. Microsoft Entra Workload ID frames the category around apps and services, not people, and specifically encourages workload identity federation to connect external workloads without managing secrets. AWS says roles are intended to be assumable by anyone or anything that needs delegated access, with temporary credentials replacing static keys. RFC 9700 strengthens the underlying OAuth discipline by recommending sender-constrained access tokens such as DPoP or mutual TLS to reduce replay of stolen tokens. (learn.microsoft.com)

That is highly relevant because a lot of current AI agent rhetoric still assumes the model itself is the main security boundary. It is not. The model is better understood as a decision engine inside a workflow. The actual boundary is the identity and policy layer around it. If the agent is deployed in Microsoft-heavy estates, Entra workload identities, conditional access for service principals and federated credentials are the obvious starting points. If the estate is AWS-centric, IAM roles, federation and temporary credentials are the equivalent controls. In hybrid environments, the messy reality is that the agent may need to bridge both. That makes the management of trust relationships, not just token issuance, the thing that deserves board-level attention. (learn.microsoft.com)

This is also why the storage and backup side of the house should care. Once an agent can touch operational systems, the blast radius extends into data protection and recovery planning. A compromised agent identity is not just an access incident. It can become a mass-edit incident, a deletion incident or a ransomware-enabling pivot. Teams already wrestling with resilience strategy, whether around affordable enterprise storage or backup tooling, should assume that agent-driven automation will create new failure modes for both change control and restore scope. That is not a theory problem. It is a practical operations problem.

Second-order effects: the unglamorous parts become the important parts

Once enterprises start deploying agents with real permissions, three less fashionable disciplines move to the front of the queue.

First, lifecycle management. Human accounts already suffer from orphaned access and stale entitlements; workload identities are no better if teams create them ad hoc for every proof of concept and never retire them. Microsoft’s guidance on workload identities includes health checks, removal of unused applications and renewal of expiring credentials, which is exactly the sort of housekeeping many organisations neglect until an audit or incident forces the issue. (learn.microsoft.com)

Second, policy granularity. Agents are often sold as generalists, but enterprise controls work best when a workload does one thing well. A support agent that can draft responses does not need the same permissions as a procurement agent that can raise POs. If the policy model does not distinguish between them, the organisation will eventually discover that convenience has outrun governance. This is where the old enterprise habit of giving “the integration” a fat service account is particularly dangerous in an agentic world.

Third, evidence. Security teams will need logs they can actually investigate. Not just prompt history, but identity events, token issuance, tool invocation, downstream API calls, and the human or system reason that authorised the step. Without that, post-incident review becomes guesswork. NIST’s AI RMF is relevant here because it treats governance and traceability as part of risk management rather than optional extras. That should be read as a warning against building AI governance as a policy PDF detached from the platform layer. (nist.gov)

There is also a procurement consequence. Vendors will increasingly talk about “agent readiness”, “agentic workflows” and “secure autonomy”. Buyers should translate that into plain operational questions: Can the agent use federated credentials? Can it be bound to a specific trust policy? Can its permissions be narrowed per tool and per tenant? Can access be revoked centrally and immediately? Can the platform evidence who approved a sensitive action? If those questions get vague answers, the product is not ready for serious enterprise use, regardless of the demo.

What could invalidate this thesis

There are two ways this argument could be weakened. The first is if agent deployments remain mostly read-only assistants with no meaningful ability to act. In that case, the identity problem is still real, but less urgent. The second is if the industry converges on a strong, interoperable standard for agent identity, delegated authority and tool-scoped authorisation that is widely adopted across clouds and software stacks. That would not remove the issue, but it would make it easier to manage.

At the moment, neither outcome is assured. What the primary sources show is that the established identity vendors are extending existing workload identity models rather than inventing a special agent exception. That suggests the safer assumption is that agent identity will look like a stricter version of workload identity, not a separate category with looser rules. Until there is evidence otherwise, enterprises should design for the stricter interpretation.

It is also worth being honest about the limits of current guidance. OWASP’s GenAI work is valuable, but it is still a security project responding to a moving target. NIST’s AI RMF is a useful governance framework, but it is not an implementation blueprint. Microsoft and AWS are authoritative on their own platforms, but they do not solve the cross-vendor problem of an agent that spans SaaS, cloud and on-prem systems. That gap is where most enterprise complexity lives. The correct response is not to wait for a perfect standard. It is to build with portable control patterns now.

What this means in practice

If you are planning agent projects this year, the starting point should be an identity review, not a model bake-off. Before anyone asks whether the agent should use GPT, Claude or something else, ask what identity it will use, how it will obtain credentials, where policy will live, and how the organisation will revoke access when the agent is behaving badly or the use case is retired. That is especially true in mixed estates where Microsoft Entra, AWS IAM and SaaS platforms all have a claim on the trust chain. (learn.microsoft.com)

A sensible enterprise baseline would be:

1. treat each agent as a distinct workload identity, not as a shared integration account;
2. prefer federation and short-lived credentials over static secrets;
3. scope permissions by task and tool, not by team convenience;
4. log identity events and action lineage together;
5. review agent access as part of standard joiner/mover/leaver and change-management processes;
6. test what happens when the agent is tricked, over-scoped or denied access.

That is not glamorous, but it is how enterprise IT actually keeps systems running. And it is why AI agent identity should be treated as a first-class architecture decision, not an implementation footnote. The organisations that get this right will not simply have “smarter” automation. They will have automation that can be trusted, audited and withdrawn. In the enterprise, that is the difference between a pilot and a platform.