Artificial intelligence has now become a structuring lever for companies: 70%¹ have already placed it at the heart of their strategy. So far, most deployments relied on conversational assistants capable of returning information—sometimes enriched with internal data—but whose interactions with the information system (IS) remained limited.

A major shift is now underway with the emergence of agentic AI. Unlike simple chatbots, AI agents do not merely answer questions; they reason, decide to call tools, and trigger actions. They may send an email, schedule a meeting, update a record, initiate a transaction, or soon, carry out even more sensitive operations. Their promise in terms of automation is substantial—and so is their potential impact on the attack surface of the IS.

Because once an AI system acts, central questions arise: on whose behalf is it acting, with which permissions, on what perimeter, and under whose control?

Those questions are even more critical given the rapid evolution of use cases: 51%² of organizations have already deployed an AI agent for employees, while 59%³ of workers acknowledge using non‑approved AI agents. Beyond individual usage, each business unit may be tempted to deploy its own agents to fulfill local needs. This fuels a form of agentic Shadow IT, where agents multiply in a fragmented way, with heterogeneous architectures, variable controls, and frequently incomplete governance.

In this context, Identity and Access Management (IAM) must return to the center of the security strategy. Every piece of data an agent can access, every resource it can modify, every action it can execute must fall under a centralized access control with, traceability, and a governance framework.

This article analyzes the security of AI agents through the IAM lens—not as one brick among others, but as a structural safeguard required to frame their usage and sustainably protect the information system.

From conversational assistants to AI agents: how they interact with the IS

How can an AI agent act on an application?

The ability of an AI agent to interact with enterprise applications relies on the emergence of new protocols, among which the Model Context Protocol (MCP) is gaining prominence. This type of protocol enables an AI agent to communicate with third‑party applications through an intermediate layer, often implemented as an MCP server.

The MCP server acts as an exposure and orchestration component. It receives requests generated by the model, translates them into executable calls, and forwards them to the application’s API. To achieve this, the MCP server provides the model with tools, describing the actions it is authorized to invoke. Once the server is declared in the conversational interface or agent environment, the model can decide—based on user intent and its own reasoning—to call one or several of these tools.

From a security perspective, this raises a key question: how is the end‑user authenticated, and how is this identity propagated—or not—to downstream services? In modern architectures, user authentication typically relies on OpenID Connect (OIDC), while API access authorization relies on OAuth 2.x through access tokens. The challenge for an agent is to ensure that tool invocations and API calls occur through a controlled delegation model.

Is the agent acting with its own rights, with the user’s rights, or through a hybrid mechanism?

Let’s illustrate this with a real-world use case: scheduling a meeting. The user asks: “Schedule a meeting with the team tomorrow at 10 a.m.” The AI agent interprets the request and uses the “Calendar” tool exposed by the MCP server. It sends the minimal structured request (participants, date, time, subject). The MCP server then calls the enterprise calendar API to create the event.

The mechanism seems simple. In practice, it represents a major shift: the model is no longer a passive assistant but an active intermediary between human intention and technical execution.

An inherently opaque operating model

This architecture introduces an immediate security difficulty: in many cases, the integration layer only has partial visibility over the originating context. It receives a structured request but not the full initial prompt, the model’s internal reasoning, or why it selected a specific tool. The IS therefore sees an action without necessarily being able to reconstruct the chain linking user demand, agent reasoning, tool invocation, and final effect.

This loss of context becomes even more problematic when the API call is made using an OAuth token: depending on the architecture, the target service may only see a technical identity (service account / application) rather than the real end‑user. This undermines attribution, abuse detection, and the ability to apply conditional policies differentiating human and agentic actions.

In other words, the agent interacts with the IS in a partially opaque manner, breaking with traditional application patterns and complicating real‑time control, auditing, and accountability.

A fast‑emerging technology introducing new security challenges

AI agents introduce new use cases—and new risks—that must be addressed at the IAM level. Four challenges stand out.

Challenge 1: Inventory of AI agents

Most organizations lack a comprehensive inventory of deployed agents and the tools they connect to.

This lack of visibility arises from two factors:

• usage often develops outside traditional governance processes;
• integration modalities are heterogeneous (MCP, proprietary connectors, local code execution, platform‑native features, etc.).

The issue is not only inventorying the agents themselves but understanding their entire execution chain: interface, exposed tools, target applications, accounts used, data processed, and flows generated. Without visibility, no meaningful governance is possible.

Challenge 2: Attribute and govern AI agent permissions

Traditional IAM systems often lack a native, standardized object to represent an AI agent as a fully governable non‑human identity.

As a result, integration layers are registered as technical apps or service accounts. This leads to well‑known risks: excessive privileges, poor separation of duties, coarse controls, and inability to distinguish a human action from an agentic action.

The risk becomes substantial as the agent may become a privileged indirect access vector into the IS.

Challenge 3: Authenticate AI agents

Authentication presents the third challenge, on two distinct levels. First, the end user must be properly authenticated to ensure that the agent is not operating without an identity. But the agent itself—or at the very least the component acting on its behalf—must also be authenticated so that specific policies, appropriate restrictions, and proportionate oversight requirements can be applied to it.

This dual requirement is unprecedented in its complexity: with AI agents, the system must simultaneously manage the identity of the requester, the identity of the executing system, and the precise relationship between the two.

Challenge 4: Trace agent‑driven actions

The final challenge is that of traceability. In many current architectures, logs primarily allow us to observe the technical call sent to the target service. However, it remains difficult to reliably reconstruct:

• which user originated the request;
• which agent decided to execute it;
• the business context;
• the intermediate reasoning steps.

This lack of auditability undermines detection, investigation, and accountability. When a sensitive action is triggered, it must be possible to determine whether it resulted from a legitimate instruction, a misinterpretation, an autonomous deviation, an abuse of privilege, or a compromise of the input context—for example, through a prompt injection attack.

IAM as the reference framework for securing AI agents

Core IAM principles remain unchanged

In light of this transformation, one point must be made clear: the fundamentals of IAM do not disappear with agent-based AI. On the contrary, they become essential once again.

A well-managed information system is based on a few simple and robust principles:

• centralize authentication via a reference IdP;
• avoid generic accounts when nominative identities are possible;
• enforce least privilege;
• govern entitlements over time;
• ensure robust logs;
• clearly separate roles and execution perimeters.

AI agents do not invalidate these principles—they expose existing weaknesses and require adapting the IAM execution model to a new class of digital actors.

A four‑step security trajectory

1. Inventory use cases and agents

Identify:

• deployed agents,
• environments,
• tools,
• target apps,
• accounts and tokens,
• accessible data.

This inventory exercise is not merely a secondary documentation task; it is a prerequisite for any coherent access control policy. To carry it out, commercial tools are emerging, such as Microsoft’s Agent 365 solution.

2. Introduce a dedicated identity type for AI agents

The second step involves recognizing AI agents as a specific category of non-human entities. This classification is essential because it enables the implementation of differentiated policies: prohibitions on certain actions, restrictions to specific areas, requirements for prior approval, enhanced monitoring, or conditional restrictions.

This distinction is fundamental. A traditional application does not have the same level of autonomy, nor the same risk profile, as an AI agent capable of selecting a tool on its own, chaining together multiple actions, or reacting to an ambiguous context. IAM must therefore be able to determine not only who is acting, but also how the system is acting.

For example, a user may have the right to send an email or create a change request. This does not mean that an agent can execute this action without safeguards. Depending on the sensitivity of the process, a dedicated policy may require human validation, a restricted scope, or a complete prohibition.

3. Link authentication and rights to a central IdP + the end‑user

The third step involves bringing authentication under the purview of a central identity provider, so that access rights are managed consistently. The goal is twofold: to prevent the uncontrolled use of over-privileged technical accounts, and to ensure that the agent operates, as much as possible, within the limits of the permissions held by the user who initiated the request.

This does not mean that the agent must be transparent from a security standpoint. On the contrary, the challenge is to apply a logic such as: “even if the user has the right, the agent does not necessarily have the right to do so alone, in any context, and without additional oversight.

4. Introduce human approval for certain agent‑initiated actions

Securing AI agents cannot rely solely on authentication and authorization. It also requires defining the acceptable level of autonomy based on the criticality of the actions in question.

Three models are typically distinguished

Human‑in‑the‑loop

This is the most secure mode. The agent prepares the action, but its execution is contingent upon explicit validation. This approach should be prioritized for sensitive operations: financial transactions, changes to permissions, external communications on behalf of the company, access to sensitive data, actions with irreversible consequences, etc.

Its key advantage is that final validation is handled by a control interface independent of the agent’s reasoning. Even if the model has been influenced, manipulated, or simply deceived, the user or operator retains control over the decision.

Human‑over‑the‑loop

In this model, humans do not approve each action individually but oversee the execution and retain the ability to interrupt the process immediately. This approach may be suitable for frequent, well-defined, low-risk processes, provided that monitoring is effective, and the shutdown mechanism is fully operational.

Human‑out‑of‑the‑loop

Here, the agent operates autonomously without immediate human intervention. This level of autonomy should only be considered for very low-criticality use cases, in strictly bounded environments with limited scopes of action, robust compensatory control mechanisms, and explicit tolerance for residual risk.

For a CISO, the logic is simple: the greater the business, regulatory, or security impact, the closer the human oversight must be to the execution.

A clear target state—still constrained by several limitations

Functional obstacles

The target security model can be clearly defined. Its implementation, however, encounters several major functional obstacles.

The first obstacle concerns the lack of granular authorization mechanisms. Today, a user may want to ask an agent to perform a precise action on a precise resource. Yet available mechanisms often require permissions that are far broader than necessary. Processing an email may require opening access to an entire mailbox; scheduling a meeting may imply extended access to the user’s full calendar; interacting with a repository may require read or write permissions far beyond the expressed need. This mismatch is particularly problematic in an agentic context. Because an AI is inherently non‑deterministic in the way it selects and chains actions, overly broad access rights mechanically become a disproportionate risk. Secure adoption therefore requires moving toward finer‑grained, contextualized, temporary authorization mechanisms, proportionate to the specific request being made.

The second obstacle concerns authentication and identity propagation. In many cases, current architectures still rely on technical accounts, shared secrets, or authentication mechanisms that fall short of mature IAM governance standards. The target state, in contrast, requires that each action be explicitly linked to (i) the user originating the request, and (ii) the fact that this action was executed by an agent — which implies distinguishing between the identity of the initiator and the identity of the executing system, while documenting the delegation relationship between the two. In practice, this refers to controlled delegation mechanisms such as OAuth “On-Behalf-Of (OBO)” flows: the agent (or its orchestration layer) calls an API while carrying an authorization derived from the user, but with additional constraints (limited scope, reduced duration, contextual checks, conditional access policies). The objective is to reduce reliance on over‑privileged technical accounts while preserving a usable chain of accountability. At this stage, however, the market does not yet offer a fully homogeneous and interoperable model that covers authentication, fine‑grained authorization, traceability, and agent governance at scale.

A final foundational obstacle is traceability: every action must be linked explicitly to a clear and intelligible chain of responsibility. Without this capability, there can be no robust auditability, no effective control, and no defendable governance in front of business stakeholders, auditors, or regulators. And this obviously comes at a cost for SIEM platforms…

A fragmented market complicating security

From the perspective of enterprises, the difficulty is not only technical: it also relates to the overall maturity of the market. Agentic capabilities are proliferating faster than the security and governance standards needed to frame them in a consistent way. As a result, organizations must deal with heterogeneous solutions, in which identity models, audit capabilities, and control mechanisms vary significantly from one vendor to another.

Will MCP become the standard?

Some vendors expose their applications through MCP servers or comparable mechanisms, while others favor more closed, native integrations within their own ecosystems. In practice, there is still no fully homogeneous framework that satisfactorily covers authentication, authorization, traceability, governance, and the nomenclature of exposed capabilities.

Two trajectories can be envisioned:

• The first would be convergence toward a standardized foundation enabling interoperability across agents, tools, and platforms. Such evolution would facilitate large‑scale deployment, improve user experience, and enable more coherent enterprise‑wide governance.
• The second would be persistent fragmentation. In this scenario, each vendor would continue to favor its own mechanisms, security objects, and integration models. The consequences for organizations would be significant: multiplication of blind spots, heterogeneous controls, difficulty centralizing supervision, and practical impossibility of applying a homogeneous IAM policy across the entire agentic perimeter.

In the short term, market signals point toward co‑existence: interoperability initiatives are emerging, but major vendors continue to build logically integrated ecosystems. For CISOs, this means thinking not only “tool by tool” but also in terms of the ability to govern a portfolio of agents spanning multiple vendors.

Toward enterprise AI agent registries

The rise of AI agents justifies the emergence of a new governance object: the AI agent registry. Because an agent is an autonomous system capable of triggering actions, it can no longer be treated as an invisible application component. It must be identified, qualified, assigned an owner, embedded in a lifecycle, evaluated according to its scope of action, and subjected to specific rules.

Such a registry must ultimately be able to answer several fundamental questions:

• Which agents exist within the organization?
• Who is responsible for them?
• In which environment do they operate?
• Which tools and which data do they have access to?
• Which authentication mechanisms do they use?
• Which human validations are required?
• Which logs do they produce?
• When must they be reviewed, requalified, suspended, or retired?

Some identity providers are beginning to introduce capabilities dedicated to this new category of non‑human identities. This is an important signal. But market maturity remains early, and governance cannot be outsourced entirely to vendors. The real issue is fundamentally organizational: defining a model of responsibility, control, and security that is adapted to the growing autonomy of AI systems.

When should organizations address IAM for AI agents? Right now.

The rise of AI agents marks a major evolution in the transformation of information systems. By shifting from a logic of assistance to a logic of action, these systems fundamentally reshape security concerns: the challenge is no longer limited to controlling the data an AI can access, but also the actions it can execute, the privileges it leverages, and the responsibilities it triggers.

In this context, IAM becomes a structuring pillar. It provides the foundation needed to make agents visible, control their entitlements, trace their actions, and define the conditions under which their autonomy can be accepted. In other words, securing AI agents cannot rely on peripheral measures: it requires an integrated governance approach that combines identity, access control, supervision, and human validation.

For organizations, the objective is not to slow down the adoption of agentic AI, but to frame it within a sustainable trust model. This means making structural decisions today: mapping use cases, integrating agents into IAM frameworks, distinguishing human and non‑human identities, adapting authorization policies, and defining safeguards proportionate to the criticality of the actions delegated.

As architectures become standardized and market offerings mature, the organizations best prepared will be those that treat AI agents not as simple innovative assistants, but as new actors of the information system, subject to the same requirements of security, traceability, and governance as any other critical component.

The question is therefore no longer whether AI agents will find their place in the enterprise, but under what conditions of control. For CISOs, the matter is clear: the ability to industrialize agentic AI will depend less on the performance of the models than on the robustness of the IAM and governance framework put in place to supervise them.

If you, too, are questioning how to manage access for AI agents or wish to deepen the security of these emerging use cases, we would be delighted to connect. Feel free to reach out to share your challenges or to explore together potential approaches tailored to your context.

1. Wavestone – Global AI Survey 2025  – AI Adoption and Its Paradoxes: Global AI survey 2025 | Wavestone)
2. PagerDuty (2025) More than Half of Companies (51%) Already Deployed AI Agents. Pager Duty, March 2025. Available at: 2025 Agentic AI ROI Survey Results (Accessed: 2 January 2026)
3. Cybernews (2025) Unapproved AI Tools in the Workplace. September 2025. Available at: https://cybernews.com/ai-news/ai-shadow-use-workplace-survey/ (Accessed: 2 January 2026).

Cet article Securing AI Agents: Why IAM Becomes Central est apparu en premier sur RiskInsight.