Approfondissons le sujet: Agentic AI Security
La réalité dérangeante est que de nombreuses architectures d’IA actuelles ne sont pas suffisamment pensées du point de vue de la sécurité. La raison n’en réside pas dans des détails d’implémentation isolés, mais dans un malentendu fondamental: Les agents IA sont traités comme des applications classiques, alors qu’ils se comportent de manière fondamentalement différente.
C’est précisément là qu’intervient le concept de sécurité IA agentive.
L’autonomie bouleverse la logique de sécurité
Les logiciels classiques suivent des processus définis. Un utilisateur lance un processus, l’application l’exécute, et les autorisations sous-jacentes peuvent être modélisées selon cette logique. Les schémas d’accès sont prévisibles, les interactions clairement structurées. Les agents IA bouleversent ce modèle.
Un agent reçoit un objectif et décide lui-même comment l’atteindre. Il analyse le contexte, évalue les options et interagit avec différents systèmes. La séquence concrète d’actions ne se définit qu’au moment de l’exécution. Le contrôle passe ainsi d’une logique statique à des processus décisionnels dynamiques.
D’un point de vue technique, cela signifie que le comportement d’un système n’est plus entièrement connu au moment de la conception. Et c’est précisément à cela que la grande majorité des modèles de sécurité ne sont pas adaptés.
Les agents IA en tant que nouvelle classe d’identité
Un aspect central de ce changement est le rôle de l’identité.
Les systèmes IAM traditionnels font la distinction entre les utilisateurs humains, les services techniques et les appareils. Les agents IA n’entrent dans aucune de ces catégories. Ils n’agissent pas comme des humains, mais ne suivent pas non plus des processus déterministes comme les services classiques. Au lieu de cela, ils prennent des décisions de manière autonome et choisissent de manière dynamique les actions qu’ils vont exécuter.
Dans la pratique, on peut les décrire de manière très pertinente comme « des identités guidées par le raisonnement ». Cette nouvelle catégorie d’identités présente deux caractéristiques essentielles:
- Premièrement, leur comportement dépend du contexte.
- Deuxièmement, leur champ d’action n’est pas entièrement prévisible
Il ne suffit donc plus d’attribuer des autorisations statiques. La sécurité doit s’orienter vers un comportement dynamique.
Pourquoi les modèles OAuth classiques atteignent leurs limites
OAuth2 et OpenID Connect restent des éléments centraux des architectures de sécurité modernes. Ils ont toutefois été conçus pour un autre modèle d’interaction : des clients connus, des ressources clairement définies et des schémas d’accès relativement stables. Dans les systèmes pilotés par des agents, ce modèle évolue.
Un agent n’est pas un client classique. Il décide lui-même des ressources qu’il utilise et des actions nécessaires. L’ensemble des interactions possibles n’est plus entièrement connu à l’avance. Les scopes classiques perdent ainsi en précision. La question centrale de l’autorisation change fondamentalement.
Il ne s’agit plus de savoir si un système est autorisé à accéder à une API.
Il s’agit de savoir si un agent est autorisé à effectuer une action concrète dans un contexte donné.
In MCP-basierten Architekturen wird diese Verschiebung besonders deutlich, da Fähigkeiten als Tools modelliert werden. Autorisierung erfolgt damit auf der Ebene einzelner Aktionen statt auf Systemebene.
La délégation et la traçabilité: un problème central
La délégation constitue un autre point critique. Dans la plupart des scénarios , les agents IA agissent pour le compte d’un utilisateur. Parallèlement, ils prennent de manière autonome des décisions concernant la mise en œuvre concrète. Il en résulte une dualité d’identités: Celle de l’utilisateur en tant qu’initiateur et celle de l’agent en tant qu’instance exécutive.
Sans un modèle de délégation clair, plusieurs risques apparaissent. Les actions ne peuvent plus être attribuées de manière univoque, les autorisations peuvent être étendues implicitement et l’auditabilité est perdue.
Techniquement, ce problème peut être résolu grâce à des modèles de jetons étendus, par exemple via le Token Exchange et les Actor Claims. Le jeton reflète ainsi à la fois l’identité de l’agent et celle de l’utilisateur. C’est la seule façon de retracer pour le compte de qui une action est effectuée.
Cette séparation est essentielle pour toute architecture de sécurité d’IA agentique digne de ce nom.
De l’autorisation statique aux politiques basées sur le contexte
Un autre changement fondamental concerne le type d’autorisation.
Les modèles basés sur les rôles atteignent rapidement leurs limites, car ils ne sont pas suffisamment flexibles pour refléter des décisions dynamiques. À la place, les approches basées sur les attributs et les politiques gagnent en importance.
L’autorisation devient une décision prise au moment de l’exécution, qui tient compte de plusieurs facteurs: l’identité, le contexte, le système cible et l’action concrète.
Concrètement, cela signifie:
Toutes les actions d’un agent ne sont pas autorisées en soi, mais sont évaluées à l’aune de règles qui s’appliquent en fonction de la situation. Ces règles peuvent par exemple stipuler qu’un agent n’est autorisé à agir que dans le cadre de certains projets ou qu’il ne dispose que d’un accès en lecture aux données sensibles.
Sur le plan technologique, cela conduit à une découplage plus poussé entre la politique et l’application. Les moteurs de politique deviennent des composants centraux qui prennent les décisions d’autorisation, tandis que les systèmes se contentent d’appliquer ces décisions.
Le véritable défi: les interactions entre systèmes
La complexité augmente encore dès que les agents combinent plusieurs systèmes entre eux.
Un seul workflow peut s’étendre sur différents domaines de sécurité. Dans ce cas, les identités, les autorisations et les informations contextuelles doivent être transférées de manière cohérente.
C’est là qu’interviennent des mécanismes tels que l’échange de jetons, les jetons spécifiques à l’audience et les revendications standardisées. Ils permettent de propager les contextes d’identité au-delà des limites du système sans perdre le contrôle.
Dans le même temps, il faut s’assurer que chaque action reste traçable. L’auditabilité n’est pas une fonctionnalité facultative dans les systèmes pilotés par des agents, mais une condition sine qua non.
Une approche possible: l’identité comme plan de contrôle
Les défis décrits ne peuvent être résolus par des ajustements ponctuels. Ils nécessitent une approche structurelle.
L’idée centrale est de ne plus considérer l’identité comme une fonction de soutien, mais comme un plan de contrôle pour la sécurité de l’IA agentique. Une telle approche comprend plusieurs composants clés:
- Tout d’abord, il faut une identité claire pour chaque agent. Celle-ci est mise en œuvre via des mécanismes établis tels que les identifiants client OAuth2 ou la fédération d’identités de charge de travail.
- Sur cette base, la délégation doit être clairement représentée afin qu’il soit possible de vérifier à tout moment si un agent agit dans son propre contexte ou pour le compte d’un utilisateur.
- Un autre élément central est une autorisation basée sur des politiques, qui prend des décisions au moment de l’exécution. C’est là qu’interviennent des modèles tels que le PBAC (Policy-Based Access Control), capables de réagir de manière flexible au contexte.
- À cela s’ajoutent des mécanismes permettant de transmettre en toute sécurité les contextes d’identité au-delà des limites du système, par exemple via l’échange de jetons.
- Enfin, un audit de bout en bout est nécessaire pour pouvoir retracer toutes les actions en toute transparence.
Principes architecturaux pour la sécurité de l’IA agentique
Des principes architecturaux clairs peuvent être déduits de ces exigences.
- Premièrement, les agents doivent être traités comme des identités autonomes, et non comme une extension des services existants.
- Deuxièmement, chaque action d’un agent doit être explicitement autorisée, idéalement au niveau de l’outil ou de l’action.
- Troisièmement, la délégation doit toujours être modélisée de manière explicite afin de définir des responsabilités claires.
- Quatrièmement, les contextes d’identité doivent être propagés de manière cohérente d’un système à l’autre.
Enfin, chaque interaction doit pouvoir être auditée.
Les entreprises qui misent sur l’Agentic AI Security posent les bases d’infrastructures d’IA sécurisées et évolutives.
Conclusion: Agentic AI Security – le contrôle devient un facteur décisif
Les agents IA ne transforment pas seulement les applications, mais aussi les fondements de la sécurité informatique. Les systèmes deviennent plus dynamiques, les décisions sont prises au moment de l’exécution, et les modèles classiques atteignent leurs limites.
Agentic AI Security décrit la transformation nécessaire pour rendre ces systèmes contrôlables Il ne s’agit pas de freiner l’innovation, mais de la rendre évolutive en toute sécurité.
Les entreprises qui souhaitent utiliser l’IA de manière productive doivent donc non seulement se demander ce que leurs systèmes sont capables de faire, mais aussi dans quelles conditions ils sont autorisés à agir.
Car en fin de compte, ce n’est pas la capacité d’un agent qui détermine sa valeur, mais le contrôle que l’on exerce sur lui.
Plus d’informations sur Agentic AI Security
Pour en savoir plus sur un plan de contrôle d’identité exemplaire, rendez-vous sur Agentic AI Security.
Discutez avec nous de la manière dont vous pouvez renforcer la sécurité au sein de votre entreprise: prenez un rendez-vous gratuit avec nos experts.