The accelerated adoption of artificial intelligence is profoundly transforming technological systems. From copilots integrated into business tools to automated workflows driven by autonomous agents, AI is no longer limited to a simple application service. It now acts as an operational player in the IT system, capable of executing actions, querying third-party systems, and even handling sensitive data. An emerging challenge for Zero Trust architectures.

This evolution gives rise to a new category of digital identities: non-human identities associated with AI agents. API keys, service accounts, OAuth tokens, or machine-to-machine identities become the vectors of interaction between models, applications, and infrastructures. But how can these new actors be integrated into existing trust models?

For several years, the Zero Trust paradigm has established itself as a reference for securing information systems. Its principle is simple: trust no identity by default and systematically verify each access based on context and risk level.

However, Zero Trust was initially designed to manage human identities and user equipment. Yet, in an IT system enriched by AI, an increasing share of interactions comes from automated agents. If these technical identities are neither inventoried, governed, nor monitored with the same level of rigor as human accounts, the Zero Trust architecture loses part of its effectiveness. Securing AI agents thus becomes an essential element of any modern security strategy.

AI Agents, New Identities of the IT System

AI architectures rely on multiple automated access mechanisms. To call a model, query a database, trigger an action in a business tool, or retrieve information via an API, an AI agent must have a technical identity. Identities can take the form of API keys for accessing services or databases, service accounts to execute automated workflows, OAuth tokens authorizing access to SaaS applications, or machine-to-machine identities in cloud-native architectures.

These mechanisms are essential for the functioning of agents. However, they also introduce a paradigm shift: interactions with the IT system, primarily triggered by human users, are increasingly orchestrated by autonomous processes. An agent capable of analyzing a support ticket, consulting a documentation base, and triggering an action acts as a system user, often on a much larger scale and speed.

The Blind Spot of Zero Trust

The Zero Trust model is based on several pillars: strong authentication, access segmentation, continuous verification, and the principle of least privilege. These mechanisms are well mastered today for human users. Non-human identities, however, often remain less regulated. In many organizations, API keys and service accounts are created to meet a project need and then remain active without real supervision. They sometimes have extended privileges to simplify technical integrations.

This phenomenon is amplified by the rapid experimentation around AI. Data, innovation, or business teams deploy agents to automate tasks, connect models, or enrich applications, sometimes outside traditional governance processes. As a result, part of the IT system operates with automated access that escapes usual controls.

For an attacker, these identities represent an attractive target. Unlike user accounts, they are generally not protected by multi-factor authentication and may have extensive permissions. An exposed API key in a code repository or a compromised token can thus open access to critical resources. In a Zero Trust architecture, these identities outside the control perimeter create an implicit trust zone. Exactly what this model seeks to avoid.

Excessive Privileges and "Shadow Agents": Beware of Danger!

One of the major risks related to AI agents concerns privilege management. To simplify development, it is common to grant an agent excessive rights: full access to a database or extended permissions on multiple APIs.

Contrary to the principle of least privilege. An agent should only have the rights necessary for its function. However, this granularity is still rarely applied.

Added to this is the emergence of "Shadow Agents." Like Shadow IT, agents can be informally created by business or technical teams to automate certain tasks. They often use quickly generated technical identities without centralized registration.

Over time, these identities become difficult to trace. Some persist even though the initial project has disappeared, while others retain unjustified high privileges. In an environment where AI agents interact with multiple systems (databases, SaaS, or internal tools), these phantom identities constitute a significant risk vector.

Mapping and Governing AI Agents

To effectively secure an automated IT system, it is essential to make AI agents' identities visible and controllable. This involves inventorying all present agents, whether officially deployed by IT or from unregulated local initiatives. Each technical identity (API key, service account, OAuth token, or machine-to-machine identity) must be inventoried and associated with a human responsible to ensure traceability and accountability.

Beyond their simple location, it is crucial to control the resources these agents can connect to. Centralized management of tools, applications, APIs, and databases allows the application of the principle of least privilege to each interaction, continuous monitoring of access, and immediate detection of any abnormal activity. Technical identities must be able to be quickly revoked or updated to limit risks related to abusive exploitation or malfunction.

Finally, the governance of agents must cover their entire lifecycle: creation, privilege assignment, activity monitoring, secure renewal of identifiers, and deletion when no longer needed. Treating AI agents as full-fledged identities ensures complete visibility, systematic control, and coherent integration into the overall security strategy.

Towards a Truly Extended Zero Trust

The principle of Zero Trust (Never Trust, Always Verify) must also apply to automated entities. This implies several evolutions in security strategies to systematically authenticate machine-to-machine identities, apply the principle of least privilege to AI agents, monitor their behaviors to detect potential abnormal uses, or integrate these identities into segmentation and access control policies. As AI architectures become more complex, controlling these identities becomes a structuring element of the security posture.

Artificial intelligence no longer just analyzes or recommends: it acts directly in information systems. In an increasingly automated IT system, trust must no longer be verified only for users but for every agent capable of acting on their behalf.

*Aziz si Mohammed is Senior Manager, Solutions Engineering at [OKTA](https://www.okta.com/fr-fr/).*

The post [{ Expert Opinion } – AI Agents: The Missing Link of Zero Trust?](https://www.silicon.fr/cybersecurite-1371/tribune-expert-agents-ia-le-chainon-manquant-du-zero-trust-226404) appeared first on [Silicon.fr](https://www.silicon.fr).

L’adoption accélérée de l’intelligence artificielle transforme en profondeur les systèmes technologiques. Des copilotes intégrés aux outils métiers aux workflows automatisés pilotés par des agents autonomes, l’IA ne se limite plus à un simple service applicatif. Elle agit désormais comme un acteur opérationnel du SI, capable d’exécuter des actions, d’interroger des systèmes tiers et même de manipuler des données sensibles. Un défi émergent pour les architectures Zero Trust.

Cette évolution fait émerger une nouvelle catégorie d’identités numériques : les identités non humaines associées aux agents IA. Clés API, comptes de service, tokens OAuth ou identités machine-to-machine deviennent les vecteurs d’interaction entre modèles, applications et infrastructures. Mais comment intégrer ces nouveaux acteurs dans les modèles de confiance existants ?

Depuis plusieurs années, le paradigme Zero Trust s’impose comme une référence pour sécuriser les systèmes d’information. Son principe est simple : ne faire confiance à aucune identité par défaut et vérifier systématiquement chaque accès en fonction du contexte et du niveau de risque.

Cependant, le Zero Trust a été initialement conçu pour gérer des identités humaines et des équipements utilisateurs. Or, dans un SI enrichi par l’IA, une part croissante des interactions émane d’agents automatisés. Si ces identités techniques ne sont ni inventoriées, ni gouvernées, ni surveillées avec le même niveau d’exigence que les comptes humains, l’architecture Zero Trust perd une partie de son efficacité. La sécurisation des agents IA devient ainsi un élément essentiel de toute stratégie de sécurité moderne.

Les agents IA, nouvelles identités du SI

Les architectures d’intelligence artificielle reposent sur de multiples mécanismes d’accès automatisés. Pour appeler un modèle, interroger une base de données, déclencher une action dans un outil métier ou récupérer des informations via une API, un agent IA doit disposer d’une identité technique. Les identités peuvent prendre la forme de clés API permettant d’accéder à des services ou bases de données, de comptes de service pour exécuter des workflows automatisés, de tokens OAuth autorisant l’accès à des applications SaaS ou d’identités machine-to-machine dans les architectures cloud natives.

Ces mécanismes s’avèrent indispensables au fonctionnement des agents. Toutefois, ils introduisent aussi un changement de paradigme : les interactions avec le SI majoritairement déclenchées par des utilisateurs humains sont de plus en plus orchestrées par des processus autonomes. Un agent capable d’analyser un ticket de support, de consulter une base documentaire et de déclencher une action agit comme un utilisateur du système, souvent à une échelle et à une vitesse bien supérieures.

L’angle mort du Zero Trust

Le modèle Zero Trust repose sur plusieurs piliers : authentification forte, segmentation des accès, vérification continue et principe du moindre privilège. Ces mécanismes sont aujourd’hui bien maîtrisés pour les utilisateurs humains. Les identités non humaines, en revanche, restent souvent moins encadrées. Dans de nombreuses organisations, clés API et comptes de service sont créés pour répondre à un besoin projet, puis restent actifs sans supervision réelle. Ils disposent parfois de privilèges étendus afin de simplifier les intégrations techniques.

Ce phénomène est amplifié par la rapidité d’expérimentation autour de l’IA. Les équipes data, innovation ou métiers déploient des agents pour automatiser des tâches, connecter des modèles ou enrichir des applications, parfois en dehors des processus de gouvernance traditionnels. Résultat : une partie du SI fonctionne avec des accès automatisés qui échappent aux contrôles habituels.

Pour un attaquant, ces identités représentent une cible attractive. Contrairement aux comptes utilisateurs, elles ne sont généralement pas protégées par authentification multifactorielle et peuvent disposer d’autorisations étendues. Une clé API exposée dans un dépôt de code ou un token compromis peut ainsi ouvrir l’accès à des ressources critiques. Dans une architecture Zero Trust, ces identités hors du périmètre de contrôle créent une zone de confiance implicite. Exactement ce que ce modèle cherche à éviter.

Privilèges excessifs et “Shadow Agents” : attention danger !

L’un des risques majeurs liés aux agents IA concerne la gestion des privilèges. Pour simplifier le développement, il est fréquent d’attribuer à un agent des droits excessifs : accès complet à une base de données ou permissions étendues sur plusieurs API.

A l’encontre même du principe du moindre privilège. Un agent devrait disposer uniquement des droits nécessaires à sa fonction. Néanmoins, cette granularité est encore rarement appliquée.

À cela s’ajoute l’émergence des “Shadow Agents”. A l’instar du Shadow IT, les agents peuvent être créés de manière informelle par des équipes métiers ou techniques pour automatiser certaines tâches. Ils utilisent souvent des identités techniques générées rapidement, sans enregistrement centralisé.

Avec le temps, ces identités deviennent difficiles à tracer. Certaines subsistent alors que le projet initial a disparu, tandis que d’autres conservent des privilèges élevés injustifiés. Dans un environnement où les agents IA interagissent avec plusieurs systèmes (bases de données, SaaS ou outils internes), ces identités fantômes constituent un vecteur de risque significatif.

Cartographier et gouverner les agents IA

Pour sécuriser efficacement un SI automatisé, il est essentiel de rendre les identités des agents IA visibles et contrôlables. Cela implique de recenser tous les agents présents, qu’ils soient officiellement déployés par l’IT ou issus d’initiatives locales non encadrées. Chaque identité technique (clé API, compte de service, token OAuth ou identité machine-to-machine) doit être inventoriée et associée à un responsable humain afin d’assurer la traçabilité et la responsabilité.

Au-delà de leur simple localisation, il est crucial de maîtriser les ressources auxquelles ces agents peuvent se connecter. Une gestion centralisée des outils, applications, API et bases de données permet d’appliquer le principe du moindre privilège à chaque interaction, de surveiller en continu les accès et de détecter immédiatement toute activité anormale. Les identités techniques doivent pouvoir être révoquées ou mises à jour rapidement pour limiter les risques liés à une exploitation abusive ou à un dysfonctionnement.

Enfin, la gouvernance des agents doit couvrir l’intégralité de leur cycle de vie : création, attribution de privilèges, suivi des activités, renouvellement sécurisé des identifiants et suppression lorsqu’ils ne sont plus nécessaires. Traiter les agents IA comme des identités à part entière garantit une visibilité complète, un contrôle systématique et une intégration cohérente dans la stratégie de sécurité globale.

Vers un Zero Trust réellement étendu

Le principe du Zero Trust (Never Trust, Always Verify) doit s’appliquer aussi aux entités automatisées. Cela implique plusieurs évolutions dans les stratégies de sécurité pour authentifier systématiquement les identités machine-to-machine, appliquer le principe du moindre privilège aux agents IA, surveiller leurs comportements afin de détecter d’éventuels usages anormaux ou intégrer ces identités dans les politiques de segmentation et de contrôle d’accès. À mesure que les architectures d’IA se complexifient, le contrôle de ces identités devient un élément structurant de la posture de sécurité.

L’intelligence artificielle ne se contente plus d’analyser ou de recommander : elle agit directement dans les systèmes d’information. Dans un SI de plus en plus automatisé, la confiance ne doit plus être vérifiée uniquement pour les utilisateurs, mais pour chaque agent capable d’agir en leur nom.

*Aziz si Mohammed est Senior Manager, Solutions Engineering chez OKTA

The post { Tribune Expert } – Agents IA : le chaînon manquant du Zero Trust ? appeared first on Silicon.fr.