Architecture de sécurité d'un agent IA en entreprise

Un chatbot reçoit une question et renvoie du texte. Le risque principal porte sur ce qu'il dit et sur les données qu'il a vues. Un agent reçoit un objectif, choisit des outils, les appelle avec des paramètres qu'il construit, lit les résultats et enchaîne. Chaque appel utilise une identité et un token, cible une ressource et peut modifier un état.

Notre fil rouge, Hermes, est un agent d'entreprise fictif. Il reçoit des demandes, envoie du contexte à un LLM, interroge un RAG, consulte le Web, appelle des outils MCP et des API internes, agit dans des applications et pousse du code. Chacun de ces chemins est une frontière distincte.

Une instruction dans un prompt n'est pas une frontière de sécurité. Le modèle peut l'ignorer, un contenu injecté peut la contredire. Seul un composant placé sur le chemin de l'action peut la bloquer.

La sécurité doit donc couvrir toute la chaîne entre l'intention de l'utilisateur et l'effet réellement produit, en distinguant prévention, autorisation, enforcement, détection et réponse. Voir aussi la conviction un prompt n'est pas une frontière de sécurité.

Avant que la demande atteigne Hermes, un guardrail d'entrée inspecte le contenu. Le même principe s'applique à la réponse finale avant restitution à l'utilisateur.

PII

Détection de données personnelles : noms, identifiants, coordonnées.

Secrets

Clés d'API, tokens, mots de passe collés dans une demande ou produits dans une réponse.

Données sensibles

Contenus classifiés ou réglementés qui ne doivent pas circuler dans ce canal.

Action

Bloquer, masquer, transformer ou journaliser selon une logique DLP.

Exemple d'implémentation · AccuKnox propose des guardrails applicables aux entrées et sorties d'applications IA. D'autres technologies peuvent remplir ce rôle.

Un guardrail ne sait pas si l'utilisateur a le droit de demander l'action. Il qualifie un contenu, pas une permission.

Le contexte envoyé au LLM est une frontière à part : il agrège la demande, l'historique, les documents récupérés et les résultats d'outils. Tout ce qui y entre peut sortir du périmètre (fournisseur de modèle, journaux, réponse) et tout ce qui y entre peut influencer la suite.

Un contrôle placé avant le modèle peut empêcher l'envoi de secrets et de données non autorisées, réduire le contexte au nécessaire, appliquer des politiques de protection des données et repérer certaines injections. La réponse du modèle est inspectée à son tour avant que Hermes ne l'utilise pour décider d'un appel d'outil.

Approfondir · Protéger les données sensibles envoyées au LLM

Deux problèmes distincts se posent quand Hermes interroge un RAG.

Sécurité du contenu

Documents empoisonnés, instructions cachées, données sensibles indexées par erreur. Relève de l'inspection.

Autorisation de la donnée

Quels documents Hermes peut récupérer pour cet utilisateur, cette finalité, ce contexte. Relève de la décision d'autorisation.

PEP, PDP, PIP, PAP

Le PEP est placé sur le chemin obligatoire vers le retrieval. Il intercepte la requête de Hermes et demande au PDP : cette action précise est-elle autorisée dans ce contexte précis ? Le PDP évalue les politiques à partir d'attributs fournis par la demande ou récupérés auprès des PIP : utilisateur, identité de Hermes, rôle, équipe, manager, finalité, action, ressource, classification, environnement, relations entre identité et ressource.

Les règles combinent RBAC, ABAC, PBAC et ReBAC. Elles sont administrées dans le PAP : règles de la société, d'une direction, d'un métier, d'un manager, du propriétaire d'une ressource, exceptions et priorités. Elles doivent être gouvernées, versionnées et testables.

Le PDP répond Permit, Deny ou Permit accompagné d'obligations : masquer des champs, limiter les résultats, interdire l'export, imposer une destination, journaliser davantage, exiger une validation.

Exemple d'implémentation · Axiomatics fournit le PAP et le PDP. Il prend la décision ; il ne remplace pas le PEP, qui reste sur le chemin de l'action et l'applique.

Approfondir · Sécuriser le RAG d'un agent IA

Approfondir · Autorisation fine d'un agent IA

Cas d'usage lié : protéger le RAG et la mémoire.

Hermes découvre et utilise des serveurs MCP. La description d'un outil est lue par le modèle et oriente ses choix : c'est une surface d'attaque. Les risques : tool poisoning, description trompeuse, schéma inattendu, paramètres malveillants, outil trop puissant, serveur non approuvé, résultat contenant une instruction ou une donnée dangereuse.

Une couche de sécurité MCP inspecte le serveur, l'outil, sa description, son schéma, les paramètres de l'appel et le résultat avant son retour dans le contexte.

Le premier contrôle vérifie que l'appel n'est pas malveillant. Le second vérifie que l'action est permise par les règles de l'entreprise. Un appel peut réussir le premier et échouer au second : paramètres propres, mais montant ou destinataire hors mandat.

Approfondir · Sécuriser MCP pour un agent IA

Cas d'usage lié : sécuriser les serveurs et outils MCP.

Hermes veut appeler POST /payments. L'API Gateway joue le rôle de PEP : elle intercepte l'appel et interroge le PDP.

sujet      : agent=hermes, déclenché par=u.martin (finance)
action     : payments.create
ressource  : compte=FR76…, montant=48 000 EUR
contexte   : env=production, destination=hors UE, 23:40

décision   : Deny
motif      : montant > plafond délégué, destination non approuvée

La question posée au PDP est précise : cet agent, déclenché par cet utilisateur, peut-il exécuter cette action sur cette ressource, pour ce montant, depuis cet environnement, vers cette destination ? La gateway applique ensuite la réponse sur l'endpoint, la méthode, les paramètres, les champs, le volume, le montant et la destination.

Si Hermes peut joindre l'API de paiement sans passer par la gateway, la politique n'est pas un contrôle effectif.

Approfondir · Sécuriser les API appelées par un agent IA

Cas d'usage lié : contrôler les actions d'un agent IA.

Quand Hermes agit dans une application métier, un PEP applicatif (code de l'application, proxy, sidecar ou SDK) intercepte l'action et consulte le PDP. L'application n'est atteinte que si l'action est autorisée.

On externalise la décision d'autorisation, pas nécessairement le runtime complet de l'application. Les politiques deviennent communes à l'API, au RAG et aux applications, au lieu d'être réécrites dans chaque code.

Hermes peut écrire du code, ouvrir une pull request ou alimenter un pipeline. Avant qu'un artefact progresse, des contrôles recherchent secrets, vulnérabilités, dépendances et packages à risque, écarts de SBOM, images non conformes, erreurs d'Infrastructure as Code et configurations contraires aux politiques.

Ces contrôles n'empêchent pas un modèle de se tromper. Ils empêchent ou réduisent la possibilité qu'un artefact non conforme atteigne les étapes suivantes de la chaîne. Le pipeline conserve ses propres gates.

Exemple d'implémentation · AccuKnox couvre notamment l'analyse de code, d'images et d'IaC.

Approfondir · Sécuriser le code généré par IA

Un agent autonome explore, essaie plusieurs approches, multiplie les appels, cherche de nouvelles ressources. Il peut dévier de son périmètre sans qu'aucun contrôle unitaire ne se déclenche.

La deception ajoute des leurres : faux comptes, faux secrets, faux services, fausses machines, fausses ressources. Aucun utilisateur ni processus légitime n'a de raison d'y toucher. Une interaction produit donc un signal de très forte valeur.

La réponse, orchestrée par le SOC, peut révoquer un token ou une identité, bloquer un flux réseau, retirer un accès, isoler le workload, désactiver un outil ou arrêter l'exécution.

Exemple d'implémentation · Trapster détecte l'interaction avec le leurre. La réponse relève du SOC et de ses automatisations, pas de Trapster lui-même.

Approfondir · Détecter un agent IA rogue

Cas d'usage lié : sécuriser le runtime d'un agent.

Aucune brique ne suffit seule. L'architecture répond à quatre questions : que laisse-t-on entrer et sortir ? quelle action est réellement autorisée ? que fait réellement l'agent au runtime ? comment détecte-t-on et arrête-t-on une dérive ?

Les rôles peuvent se superposer. L'articulation entre ces solutions passe par l'architecture (chemins obligatoires, PEP, remontée des signaux), pas par une intégration native entre produits.

1. Niveau 1

   Assistant interne sans actions sensibles

   Guardrails, authentification, journalisation.

2. Niveau 2

   Agent accédant à des données ou outils internes

   Guardrails, contrôle MCP et API, autorisation fine.

3. Niveau 3

   Agent autonome pouvant modifier le SI

   Tous les contrôles précédents, enforcement runtime, deception, isolation et réponse.