Solutions / 03
IA agentique sécurisée
Un plan de contrôle autour des agents autonomes : identité, gouvernance de la mémoire, portes de politique sur les outils et télémétrie exploitable par un SOC.
Le problème
Un système agentique concentre trois propriétés que l'architecture de sécurité tient normalement séparées : il raisonne sur du contenu non fiable, il conserve un état durable entre les sessions, et il agit via des outils sous une identité légitime. Chacune prise isolément est gérable. Ensemble, elles produisent un principal dont le comportement est influencé par des données qu'il a lues et dont les actions sont indiscernables d'un travail autorisé.
La mémoire persistante aiguise le problème. L'écriture et son effet sont deux événements distincts, potentiellement éloignés dans le temps, sous des utilisateurs différents et dans un contexte d'outils différent. Un attaquant n'a pas besoin d'être présent au moment où la charge s'exécute — seulement d'avoir fait en sorte, une fois, qu'un contenu soit plus tard traité par l'agent comme son propre souvenir.
Architecture
À quoi ressemble le système.
Six surfaces de contrôle entourent le runtime de l'agent. Chacune est un endroit où une question de sécurité ordinaire peut être posée et recevoir une réponse : qui est-ce, que peut-il atteindre, que peut-il retenir, que peut-il faire, qu'a-t-il lu, et que verrions-nous ensuite.
- Identité
- L'agent possède son propre principal, distinct de l'utilisateur pour lequel il agit et des services qu'il appelle. La délégation est explicite et bornée, de sorte que les systèmes aval distinguent une action d'agent d'une action humaine.
- Mémoire
- Chaque enregistrement porte sa provenance — origine, contexte d'écriture, niveau de confiance. La politique est évaluée au rappel, et pas seulement à l'écriture, pour qu'un contenu peu fiable ne puisse pas atteindre silencieusement un raisonnement à privilège élevé.
- Outils
- L'enregistrement des outils et des serveurs MCP est inventorié et versionné. Chaque outil a un niveau de privilège déclaré, et les appels traversent une porte de politique qui peut autoriser, exiger une revue ou mettre en quarantaine.
- Politique
- Des règles d'exécution exprimées sur les propriétés ci-dessus — niveau de confiance, périmètre, tenant, durée de vie, impact de l'action — évaluées par appel plutôt que par déploiement.
- Données
- Ce que l'agent peut lire et où ses sorties peuvent atterrir, appliqué avec la même classification que le reste du patrimoine.
- Télémétrie
- Récupération, invocation d'outils, décisions de politique et approbations émises comme événements de sécurité vers le SIEM. Le rappel devient un événement interrogeable de premier ordre plutôt qu'une étape implicite.
Compétences
- Inventaire des agents, outils et serveurs MCP avec niveaux de privilège déclarés
- Identité d'agent distincte, avec délégation explicite et bornée
- Provenance de la mémoire à l'écriture et évaluation de politique au rappel
- Portes de politique sur les outils, avec issues autoriser / revoir / quarantaine
- Circuit d'approbation humaine pour les actions au-delà d'un seuil d'impact défini
- Télémétrie des agents émise vers le SIEM existant
- Contenu de détection comportementale pour l'activité des agents
- Surveillance de la dérive du comportement des agents dans le temps
Contrôles de sécurité
- Le contenu non fiable est étiqueté comme tel et son niveau de confiance voyage avec lui
- L'autorisation de rappel est évaluée face au privilège de la tâche en cours
- Les appels d'outils sont autorisés par invocation, pas par session
- Chaque décision de politique — y compris une autorisation — est enregistrée
- Les approbations sont attribuées à une personne nommée et liées à une action précise
- La modification et la suppression de mémoire sont elles-mêmes des opérations auditées
Approche d'intégration
Le plan de contrôle est conçu pour se placer devant les runtimes d'agents plutôt que de les remplacer, et pour émettre vers le SIEM qu'un SOC exploite déjà plutôt que d'introduire une console parallèle. L'adoption commence généralement par l'inventaire et la télémétrie, car la plupart des organisations ne savent pas encore quels agents elles exploitent — et cette réponse est un prérequis à tous les contrôles suivants.
- Inventorier les agents, outils, serveurs MCP, magasins de mémoire et identités en usage.
- Émettre la télémétrie de récupération, d'appels d'outils et de décisions de politique vers le SIEM.
- Séparer l'identité de l'agent de celle de l'utilisateur et borner explicitement la délégation.
- Attacher provenance et niveau de confiance aux écritures en mémoire.
- Introduire les portes de politique à la frontière des outils, d'abord en mode revue seule.
- Activer la politique au rappel et l'approbation humaine sur les chemins à plus fort impact.
Résultats attendus
- La liste des agents que vous exploitez réellement, et ce que chacun peut atteindre
- Une activité des agents visible par le SOC dans son outillage existant
- Une mémoire qui porte sa propre provenance jusqu'au moment de son usage
- Un privilège d'outil appliqué par appel, avec la décision enregistrée
- Une position défendable sur les actions qui exigent un humain
Limites
La politique au rappel ajoute de la latence, et l'arbitrage entre granularité de la politique et utilité de l'agent est réel et non résolu. La détection comportementale des agents est un travail précoce : nous pouvons décrire ce qui devrait être observable, mais il n'existe pas encore de chiffres publiés d'efficacité de détection du comportement des agents, y compris les nôtres.