Système immunitaire agentique
Architecture de référence pour exploiter des agents d'IA en entreprise sans concentrer la confiance sur aucun d'eux. Cinq couches — identité, moindre privilège, confinement, supervision et récupération — partent du principe qu'un agent finira par se tromper ou être détourné, et rendent ce jour survivable plutôt que catastrophique. L'unité de défense est l'exécution, pas la flotte.
Concepts clés
- Présumer la compromission : la question n'est pas de savoir si un agent agira mal, mais jusqu'où il ira quand ce sera le cas.
- Identité par exécution : chaque exécution porte son propre justificatif éphémère, jamais un compte d'exploitation partagé.
- Confinement plutôt que prévention : le rayon d'impact se conçoit, il ne s'espère pas — une exécution détournée touche une tâche, pas le parc.
- La récupération est une surface de conception : tracer, annuler et arrêter se construisent avant, pas pendant l'incident.
Définition
Le système immunitaire agentique est une architecture d'exécution en couches qui permet aux agents d'IA d'agir réellement sur les systèmes de l'entreprise tout en bornant ce qu'une seule exécution peut atteindre, observer ou endommager, grâce à une identité par exécution, un privilège limité à la tâche, un confinement de l'exécution et des sorties, une supervision humaine par le risque et une récupération traçable.
Architecture
L'architecture renverse la question habituelle. Au lieu de demander comment empêcher un agent de se tromper — ce qu'aucune barrière n'obtient de façon fiable face à un système qui raisonne — elle demande jusqu'où l'agent va au moment où il se trompe. Chaque couche est une borne de portée, et les couches sont indépendantes pour que la défaillance de l'une n'ouvre pas les autres.
L'identité est le socle. Chaque exécution reçoit un justificatif éphémère lié à la tâche, au demandeur et aux outils qu'elle a déclarés. Les agents ne partagent pas de compte de service : quand quelque chose tourne mal, la trace nomme une exécution et non une flotte, et révoquer coûte un jeton au lieu d'une rotation sur tout le parc.
Le privilège se limite à la tâche et expire avec elle. Le courtier d'outils accorde l'ensemble étroit de capacités que l'exécution a déclaré d'emblée — lire ce ticket, écrire cet enregistrement — et refuse tout le reste, si bien qu'une injection de prompt qui convainc le modèle d'en tenter davantage ne trouve rien à appeler.
Le confinement suppose que les deux couches précédentes peuvent tomber. L'exécution a lieu dans un bac à sable sans justificatifs ambiants ; la sortie réseau passe par une liste d'autorisation, de sorte que l'exfiltration n'a nulle part où envoyer ; et ce que l'agent produit est encodé à la frontière pour que sa sortie ne devienne pas l'instruction du système suivant.
La supervision est l'endroit où une personne porte la responsabilité, placée selon le risque et non par défaut : les actions irréversibles ou réglementées s'arrêtent pour approbation, et les résultats peu confiants remontent avec tout le contexte de l'exécution. Mettre une porte partout défait l'automatisation et apprend aux relecteurs à approuver sans lire.
La récupération referme la boucle. Chaque exécution est tracée sous un identifiant de corrélation unique à travers modèles, outils et reprises ; les actions sont conçues avec leur contrepartie compensatoire lorsque le système sous-jacent le permet ; et un coupe-circuit arrête une classe d'exécutions sans faire tomber la plateforme.
Flux de requêtes
- 1. Demande : une tâche arrive avec son demandeur et un ensemble déclaré d'outils et de portées de données.
- 2. Émission : le courtier frappe une identité éphémère, limitée à l'exécution et liée à cette déclaration.
- 3. Admission : l'exécution démarre dans un bac à sable, sans justificatifs ambiants et avec une liste de sortie autorisée.
- 4. Action : chaque appel d'outil est autorisé contre la portée de l'exécution ; ce qui en sort est refusé et journalisé.
- 5. Porte : les actions irréversibles ou réglementées s'arrêtent pour approbation humaine, contexte joint.
- 6. Sortie : ce qui est produit est encodé à la frontière pour ne pas être exécuté comme instruction en aval.
- 7. Clôture : l'identité expire, la trace est scellée sous son identifiant de corrélation et les actions compensatoires restent disponibles.
Composants
Scénario de référence
- Contexte
- Une entreprise illustrative exploitant des dizaines d'agents sur la billetterie, la finance et la connaissance interne, où chaque agent peut lire et écrire dans des systèmes de référence.
- Scénario
- Une étape de récupération ingère un document contenant une instruction injectée demandant à l'agent d'exporter des dossiers clients. Le modèle obtempère, mais l'outil d'export est hors de la portée déclarée de l'exécution et il est refusé ; la tentative est journalisée, la règle d'anomalie arrête l'exécution et l'identifiant de corrélation donne au répondant la chaîne complète en une seule requête.
- Technologie
- Courtier de justificatifs par exécution, courtier d'outils à portées, exécution en bac à sable, liste de sortie autorisée, encodage de frontière, porte d'approbation par le risque et traçage corrélé.
- Charge
- Automatisation continue en arrière-plan avec des pics autour des processus métier ; l'action rare et à fort impact est une faible fraction des appels et c'est elle qui porte le risque.
- Résultats
- Cible de référence, non une mesure : une exécution détournée reste bornée à sa portée déclarée, chaque refus est imputable à une exécution, et toute action exécutée peut être tracée et — quand le système sous-jacent le permet — compensée.
Avantages
- Un agent qui se trompe ou qui est détourné coûte une tâche, pas le parc entier.
- Les incidents sont imputables à une exécution et non à un compte partagé : la réponse est ciblée et la révocation peu coûteuse.
- L'injection de prompt perd l'essentiel de sa valeur : convaincre le modèle ne lui accorde pas une capacité qu'il n'a jamais eue.
- L'effort de supervision se concentre sur les actions réellement irréversibles, ce qui préserve le sens de l'approbation.
Risques
- Les portées déclarées s'éloignent de ce dont les agents ont réellement besoin, et les équipes les élargissent jusqu'à rendre le moindre privilège nominal.
- Trop de portes apprend aux relecteurs à approuver sans lire, ce qui est pire que pas de porte du tout.
- Le bac à sable et les courtiers ajoutent de la latence et une surface d'exploitation qu'un petit déploiement ne justifie peut-être pas.
- Certains effets externes n'admettent aucune compensation : un courriel envoyé ou une facture payée ne s'annulent pas.
KPI
- Part d'exécutions dotées d'une identité propre et éphémère
- Le contrôle porteur. Tout chiffre en deçà de 100 % signifie qu'un chemin utilise encore un justificatif partagé.
- Tentatives d'outil hors portée, refusées
- Comptées par exécution. Une hausse renseigne sur l'environnement, pas nécessairement sur un défaut de conception.
- Rayon d'impact par exécution
- Nombre de systèmes et d'enregistrements qu'une seule exécution entièrement détournée pourrait atteindre. C'est le nombre que l'architecture existe pour réduire.
- Taux d'actions sous porte et latence d'approbation
- Les deux comptent : un taux trop élevé défait l'automatisation, une latence trop élevée pousse les équipes à désactiver la porte.
- Complétude de la trace
- Part d'exécutions reconstituables de bout en bout sous un identifiant de corrélation, reprises et changements de modèle inclus.
- Délai de révocation
- De la détection à la disparition de la capacité d'une exécution. Avec des justificatifs éphémères, il devrait ressembler à leur expiration, pas à une rotation.
Coût et mise à l'échelle
- Les courtiers d'identité et d'outils sont sur le chemin chaud de chaque appel : ils fixent le plafond ; ils sont sans état et passent à l'échelle horizontalement, mais leur latence se paie à chaque usage d'outil.
- Le démarrage du bac à sable domine le coût des exécutions courtes ; garder un pool de bacs chauds échange de la profondeur d'isolement contre de la latence et doit être une décision explicite.
- L'approbation humaine ne passe pas à l'échelle linéairement et constitue la vraie contrainte : l'ensemble sous porte doit rester petit à mesure que la flotte grandit, sinon la file devient la panne.
- Le stockage des traces croît comme exécutions fois appels d'outils ; l'échantillonnage convient à l'observabilité mais pas à l'audit, donc les deux politiques de rétention doivent être distinctes.
Modes de défaillance observés
- Un justificatif de service partagé survit quelque part dans la pile et défait silencieusement l'identité par exécution.
- La liste de sortie est contournée via une destination autorisée qui retransmet elle-même les données.
- Les traces se rompent lors d'une reprise ou d'un changement de modèle, et la chaîne de l'incident ne peut plus être reconstituée.
- La file d'approbation s'engorge et la porte est désactivée « temporairement » pour la vider.
- La sortie d'un outil est traitée comme une entrée de confiance à l'étape suivante, et le confinement se réduit à une frontière unique qui fuit.
Leçons apprises
- Concevez le rayon d'impact avant la capacité : jusqu'où un agent peut aller est une question plus difficile que ce qu'il peut faire, et y répondre d'abord rend le reste traitable.
- L'identité par exécution est la couche porteuse ; sans elle, tout autre contrôle s'applique à un sujet que vous ne savez pas nommer.
- Une porte qui se déclenche sur tout est une porte qui ne se déclenche sur rien : réservez l'approbation humaine à l'irréversible.
- Supposez que le modèle sera convaincu et concevez pour que convaincre ne soit pas autoriser.
- La récupération se construit quand le système est calme ; personne ne conçoit une action compensatoire pendant un incident.
Technologies
Exemples
- Une instruction injectée dans un document récupéré demande un export de données ; l'outil est hors de la portée de l'exécution, l'appel est refusé et journalisé.
- Un agent financier prépare un paiement et une personne l'approuve avant exécution, la trace de l'exécution jointe à l'approbation.
- Une classe d'agents défaillante est arrêtée par le coupe-circuit pendant que le reste de la flotte continue.
- Un incident est reconstitué à partir d'un seul identifiant de corrélation couvrant trois modèles, neuf appels d'outils et deux reprises.
FAQ
- Pourquoi un système immunitaire plutôt qu'un pare-feu ?
- Un pare-feu suppose une frontière entre l'intérieur et l'extérieur. Une entreprise qui exploite des agents n'a pas cette frontière : l'agent est déjà à l'intérieur, agissant avec de vrais justificatifs. Un système immunitaire tient l'intrusion pour normale et investit dans la reconnaissance, le confinement et la réparation plutôt que dans un périmètre.
- N'est-ce pas du moindre privilège avec des étapes en plus ?
- Le moindre privilège est l'une des cinq couches et la plus familière. Ce que soutient l'architecture, c'est qu'elle ne suffit pas seule : sans identité par exécution vous ne pouvez pas limiter le privilège à un sujet, et sans confinement ni récupération une exécution correctement bornée qui dérape malgré tout n'a ni borne ni marche arrière.
- Cela arrête-t-il l'injection de prompt ?
- Non, et considérer un contrôle comme l'arrêtant est justement l'erreur. Cela rend l'injection bon marché à survivre : convaincre le modèle de tenter une action n'équivaut pas à ce que cette action soit autorisée, et la tentative refusée est elle-même un signal.
- Quelle est la version minimale viable ?
- Identité par exécution et accès aux outils limité à la tâche. Ces deux-là donnent l'imputabilité et une borne. Le confinement, la porte et les actions compensatoires pèsent d'autant plus que les actions deviennent irréversibles.
- Quel rapport avec les cadres de gouvernance ?
- C'est leur expression à l'exécution. Le NIST AI RMF et l'ISO 42001 exigent responsabilité et traçabilité ; l'OWASP LLM Top 10 et MITRE ATLAS décrivent les attaques. Cette architecture est l'endroit où ces obligations deviennent des identités, des portées, des bacs à sable et des traces.