How to Handle AI Agents

Moving from the fundamentals of modern identity security to the secure use of artificial intelligence.

Copyright: Okta

Guest article by Stephen McDermid, Regional CSO EMEA at Okta

Corporate security leaders should not wait for the finalisation of an internal AI governance policy to take practical, concrete steps toward securing AI agents. These agents are already present in corporate networks and actively in use. Without comprehensive oversight, however, a massive issue known as “Shadow AI” is emerging. This means these AI tools and agents are operating below the radar of IT security departments, leaving no one with precise control over them.

It is crucialthat decision-makers today can answer three key questions regarding AI agents: Where are my AI agents located? What are they authorized to do? What can they connect to?

A rapid shift in mindset is essential, as AI agents are no longer merely isolated chat interfaces; they are increasingly integrating with ticketing systems, SaaS platforms, tools, development environments, files, and calendars. Various standards, such as the Model Context Protocol (MCP), are accelerating this trend by standardising how AI applications connect to external systems, data sources, tools, and workflows. This gives rise to additional questions: Which MCP servers are permitted? Which tools do they provide? What data are the AI ​​agents allowed to access? What actions can they trigger? What permissions does the AI ​​agent use when performing tasks? Which tools, resources, and workflows are made accessible to the AI ​​agents?

The AI-Paradox

Our latest report, AI Agents at Work 2026, revealed that 32 percent of German respondents use unauthorised AI applications – so-called “shadow AI” – in the workplace (14 percent regularly, 18 percent occasionally), the second-lowest figure globally. However, 68 percent of these users experienced AI-related security issues over the past year, with 44 percent suffering an actual AI security incident – the highest rate recorded. This underscores that a lack of adequate security measures for the AI ​​tools in use has significantly expanded the attack surface.

Consequently, autonomous AI agents can no longer be viewed merely as software utilities. They operate independently and must be treated as privileged, high-level digital identities – subject to the same rigorous access rights, IAM controls, and monitoring mechanisms that have long been standard for human employees.

This entails assigning them an owner, restricting access to the absolute minimum required (based on “least privilege” and “zero trust” models), utilising short-lived tokens, and implementing a “kill switch” that allows for the immediate termination of access at any time to respond to anomalies. Furthermore, full compliance with regulations, adherence to security standards and best practices, and comprehensive documentation for audits are essential.

As a first step companies must address the fundamentals of identity management to establish modern identity security as the foundation for the secure operation of AI agents.

The reality of everyday life

Excessively privileged AI agents are active across many networks and must be identified so they can be registered and brought under a unified governance framework.

The use of MCP (Model Context Protocol) intensifies this requirement, as it does more than just link an AI agent to information; it provides the agent with a wide range of actionable capabilities. An MCP server can query production systems, provide tools, send messages, modify files, create tickets, access calendars, and interact with developer platforms. If these tool interfaces are not registered, managed, and monitored, a new execution layer emerges that lies beyond the visibility of traditional IAM, endpoint, and network controls.

The threat escalates further when AI agents operate across multiple applications within a single workflow. A user request might require an AI agent to read a specific document, check a calendar, create a support ticket, update a CRM record, trigger a deployment, or generate an audit entry.

One way to address this risk is Cross-App Access (XAA). It enables an identity provider to issue short-lived, signed delegation credentials that propagate a user’s identity across various services. This eliminates the need for repetitive consent prompts, shared service accounts, and error-prone token handoffs. Consequently, this approach empowers CISOs to maintain identity context as the AI ​​agent moves from one application to another.

Solving the problem through identity security

The digital identity of autonomous AI agents serves as their primary layer of security. This framework enables the discovery, identification, and integration of AI agents across various platforms. MCP and XAA play a supporting role here: MCP provides a standard for connecting AI agents with data and tools, while XAA standardizes and maintains the agent’s context and identity across multiple applications.

Consequently, this identity-centric model treats AI agents not merely as software utilities, but as virtual employees possessing full-fledged identities. Four measures can serve as a guide in this regard:

  • Create first-class identities for AI agents: Whether developed in-house, embedded in a SaaS tool, or running on an employee’s laptop, AI agents must be registered as workload principals. They require credentials, a human owner, and a controlled lifecycle.
  • Implement cryptographic association: The identities of both the human owner and the AI ​​agent must be cryptographically signed and recorded with every action.
  • Enforce least privilege: Use short-lived, single-invocation tokens instead of session tokens that span the entire session. The guiding principle is least privilege rather than standing privilege.
  • Integrate governance: Requests for AI agent access – along with their review and approval – must be integrated into the identity platform from the outset, rather than being handled as an afterthought.

To ensure these measures achieve their full potential, they – and the underlying IT security strategy – must be firmly integrated into the IT ecosystem. This approach preserves platform independence and ensures consistent governance across the board.

This is where MCP and XAA prove crucial: MCP establishes a shared integration layer for AI agents and tools, while XAA provides a model that maintains identity and delegated permissions across various applications.

To avoid the “identity sprawl” that concerns many IT architects – specifically, the creation of isolated identity silos for AI applications – identity security must meet certain prerequisites that are easily achievable with the right tools. The system deployed must be based on standard protocols (such as OIDC and SAML) and designed for federation, enabling it to communicate with the existing Identity Provider (IdP). It then adopts the IdP’s established trust framework without duplicating credentials or requiring a separate login. When an employee invokes an AI agent, the system validates the identity information provided by the IdP and issues a cryptographically signed token containing the identities of both the user and the AI ​​agent. In this way, human identities remain within the familiar environment, while AI agents are subject to governance tailored specifically to them.

With the help of XAA, the IdP can even issue short-lived delegation proofs that specify which user is behind a given AI agent and define which actions are permitted under what conditions.

MCP should be managed in a similar fashion, as MCP servers can no longer be viewed merely as neutral infrastructure components. Instead, they too must be registered and require a designated person responsible, as well as classification, monitoring, and continuous review; for if an MCP tool is classified as high-risk – for instance, because it can access production code – it cannot be managed in the same way as a read-only tool that merely accesses public documentation.

Four Essential Capabilities for Full Visibility and Control over Agents

When identity serves as the control plane for AI agents, four capabilities become possible in a unified manner:

  1. First-Class Agent Identity: AI agents – whether developed internally, embedded within a SaaS tool, connected through MCP, or running on an employee’s laptop – are registered as workload principals, equipped with credentials, an assigned human owner, and a managed lifecycle.
  2. Cryptographic Attribution: Every action carries the identity of both the human and the AI agent – each cryptographically signed. In cross-app workflows, this attribution must survive every hop, so that downstream systems can distinguish between “Alice performed this action,” “an agent acted for Alice,” and “a service account performed an unaudited operation.”
  3. Enforcement of the Principle of Least Privilege: Tokens are scoped to a specific action, tool, resource, and context – not to an entire session, application, or broad MCP server. Standing privileges are eliminated.
  4. Integrated Governance: Requests for AI agent access, as well as the review and approval of access rights, are deeply integrated into the identity platform – not merely bolted on as an afterthought. This includes governance over MCP servers, exposed tools, delegated XAA credentials, OAuth grants, and agent-to-application access paths.

However, these capabilities are only meaningful if they apply wherever AI agents are deployed. This means that the associated security strategy must be firmly anchored across the entire IT ecosystem, as AI agents may run concurrently on various platforms – such as Salesforce Agentforce, Amazon Bedrock, and ServiceNow AI – as well as on any other platform that different teams may introduce in the future. Every time an AI agent crosses the boundaries of an IT ecosystem, the governance of the platform on which it was originally developed is left behind.

This is precisely why MCP and XAA are so important. MCP provides a common integration layer for agents and tools; XAA provides a model for carrying identity and delegated authority across application boundaries. Without governance at these two layers, organizations may know who logged in, but not what the agent connected to, which tool it invoked, which downstream system accepted the delegation, or how far the action propagated.

Conclusion: Focusing on identity

Given that a wide range of AI agents and tools are already being deployed across many companies – often in an uncontrolled manner that fuels the alarming growth of “shadow AI” – IT security leaders can no longer afford to wait. They must immediately begin – or intensify existing efforts – to bring these AI agents and tools under a governance framework. An effective approach is to assign them digital identities and manage them just as one would human users; this entails establishing access rights, ownership, and policies. Consequently, identity security should take center stage, and decision-makers should prioritize addressing the fundamentals of modern IAM.

Furthermore, by successfully navigating the challenges associated with the new connectivity and delegation layers – which are precisely what enable AI agents to deliver such significant performance – companies can fully unlock the productivity benefits these agents offer. MCP establishes the standard for what AI agents can see, what they may connect to, and what they are authorised to invoke. XAA, meanwhile, defines how their identities and delegated access rights are reliably and securely maintained across various applications. Together, these elements create an operational framework for the secure use of AI agents. IT security leaders can also benefit greatly from leveraging existing frameworks and blueprints; these serve as vital guides for transforming into an AI-agent-enabled enterprise and provide decision-makers with clear direction.