Qu'est-ce que sécuriser un agent Claude en production ?
Le jour où un agent exécute des actions avec de vrais accès, sans qu'un humain relise chaque étape, deux questions deviennent prioritaires : jusqu'où a-t-il le droit d'aller, et que se passe-t-il quand quelqu'un tente de le détourner ? La justesse de ses réponses reste nécessaire, et elle ne dit rien de ces deux points.
Sécuriser un agent Claude en production consiste à limiter ses permissions à ce que chaque tâche exige, à tenir ses secrets hors de son contexte, à journaliser chaque action pour pouvoir l'auditer et à réserver les décisions à fort impact à un humain identifié. Ce guide détaille ces chantiers, avec LOOP™ comme grille de classement du risque.
L'écart entre les usages et leur encadrement est documenté. Selon Deloitte (State of AI in the Enterprise, édition 2026), seules 21 % des organisations disposent d'un modèle de gouvernance mature pour leurs agents autonomes. Pour les entreprises et les secteurs régulés, où chaque action d'un agent peut devoir être justifiée devant un auditeur, cet écart se paie au moment du passage en production.
Ce qu'un agent change pour la sécurité
Un assistant conversationnel mal réglé produit une mauvaise réponse, qu'un humain lit avant d'en faire quoi que ce soit. Un agent peut modifier un enregistrement ou appeler une API, et enchaîner plusieurs actions de ce type dans la même tâche. Le risque se mesure alors à la portée de ses accès.
Ce que l'OWASP appelle l'agentivité excessive
Le Top 10 de l'OWASP pour les applications LLM, dans son édition 2026 publiée en août 2026, fait remonter l'agentivité excessive (« Excessive Agency ») du sixième au troisième rang, derrière l'injection de prompt et la divulgation d'informations sensibles. L'entrée vise les actions dommageables déclenchées par une sortie inattendue, ambiguë ou manipulée du modèle, et en nomme les causes : fonctions, permissions ou autonomie excessives. Ces excès relèvent de décisions de conception, prises au moment où l'on branche l'agent, bien avant qu'un attaquant s'y intéresse.
Un référentiel dédié aux agents depuis décembre 2025
L'OWASP GenAI Security Project a publié en décembre 2025 un Top 10 propre aux applications agentiques. On y trouve le détournement de l'objectif d'un agent par des instructions injectées (ASI01), le mauvais usage d'outils pourtant légitimes (ASI02), l'abus d'identité et de privilèges (ASI03) et les vulnérabilités de la chaîne d'approvisionnement, connecteurs compris (ASI04). Ces référentiels publics donnent à la DSI et au RSSI un vocabulaire commun pour classer les risques d'un agent avant de lui ouvrir un système.
Le moindre privilège appliqué aux permissions d'un agent
Pendant un prototype, il est tentant de laisser l'agent utiliser les accès de la personne qui l'a configuré, ou un compte de service à large portée. En production, la règle s'inverse : un agent ne dispose que des accès que sa tâche exige, et elle se vérifie action par action.
Scoper les accès au niveau de l'action
Un agent qui rédige des réponses clients a besoin de lire le dossier client et d'écrire un brouillon dans l'outil de messagerie. Il n'a besoin ni d'écrire dans la base de facturation, ni d'administrer le CRM. Ce découpage oblige à documenter, pour chaque action possible, ce qu'elle lit et ce qu'elle écrit. Le travail paraît fastidieux au démarrage, et il devient la seule base fiable le jour où l'agent reçoit une nouvelle capacité.
Faire appliquer l'autorisation par le système cible
L'entrée de l'OWASP sur l'agentivité excessive recommande d'implémenter l'autorisation dans la logique applicative, sans laisser le modèle décider si une action est permise. Concrètement, une consigne dans le prompt système ne remplace jamais un droit refusé côté API. Quand l'agent agit pour le compte d'un utilisateur, ses actions doivent s'exécuter avec les droits de cet utilisateur, et non avec ceux d'un compte technique qui voit tout.
Isoler l'environnement d'exécution
Un agent qui exécute du code, lance des commandes ou manipule des fichiers doit tourner dans un environnement cloisonné, avec un accès réseau et un système de fichiers restreints. Le Top 10 agentique de l'OWASP range l'exécution de code inattendue parmi ses risques (ASI05) : si l'agent est trompé, le cloisonnement décide de ce qu'il peut atteindre. Un conteneur dédié par agent, sans accès aux identifiants des autres services, borne la portée d'un incident.
Rotation et durée de vie des accès
Un jeton d'accès permanent reste exploitable aussi longtemps que sa fuite passe inaperçue. La rotation régulière des identifiants limite la fenêtre d'exploitation si un secret fuit, par exemple dans un journal mal filtré ou un dépôt de code. Pour un agent qui tourne en continu, nous recommandons des accès à durée de vie courte, renouvelés automatiquement.
Secrets et identifiants : ce qui ne doit jamais transiter par un prompt
Un agent Claude reçoit ses instructions et son contexte sous forme de texte. Coller une clé d'API ou un mot de passe dans un prompt, ou dans un document que l'agent va lire, revient donc à confier ce secret à tout ce qui peut influencer l'agent.
Le risque d'exfiltration par injection de prompt
Un agent qui lit des contenus externes, un email ou une page web, peut rencontrer du texte conçu pour détourner son comportement. L'OWASP maintient cette injection de prompt en tête de son Top 10 (LLM01) en 2026 et distingue l'injection directe, portée par le message de l'utilisateur, de l'injection indirecte, cachée dans un contenu tiers. Anthropic ne prétend pas avoir réglé la question : dans ses travaux publiés le 24 novembre 2025 sur l'usage du navigateur par Claude, l'éditeur écrit qu'aucun agent de navigation n'est immunisé contre l'injection de prompt. Un secret présent dans le contexte d'un agent reste exposé à toute source que cet agent consulte.
Isoler les secrets dans un coffre dédié
Dans l'édition 2026, l'OWASP a remplacé son entrée sur la fuite du prompt système par « Hidden Context Exposure » (LLM08), qui couvre tout le contexte caché placé devant le modèle : consignes système, textes de politique récupérés, schémas d'outils, directives de configuration. La consigne y est nette : aucun identifiant, secret ou paramètre critique pour la sécurité dans le prompt système ou le contexte caché, et ce contexte ne doit pas servir de mécanisme principal de contrôle. L'entrée sur l'injection de prompt va dans le même sens en demandant de garder les identifiants et la capacité de modifier un système dans le code applicatif, hors du modèle. Les secrets vivent donc dans un coffre, l'agent obtient un accès temporaire au moment du besoin par une couche d'orchestration qui gère l'authentification, et il ne voit jamais la valeur brute du secret. Cette séparation protège aussi contre un agent qui recopierait un identifiant dans sa propre sortie, par erreur ou sous manipulation.
Journalisation : reconstituer ce que l'agent a réellement fait
Surveiller les réponses d'un agent ne suffit pas à l'auditer. Après un incident, il faut retrouver précisément ce qu'il a fait, avec quel accès et sur quelle donnée.
Ce qu'un journal d'agent doit contenir
Un audit trail exploitable conserve la tâche demandée, l'identité et le niveau d'accès utilisés, la séquence d'appels d'outils avec leurs paramètres, et le résultat constaté. Chaque entrée est horodatée et stockée hors de portée de l'agent, qui ne doit pas pouvoir réécrire sa propre trace. Ce journal sert aussi à faire évoluer le classement d'une action, sur la base d'un comportement observé dans la durée.
Ce que l'AI Act exige, et à partir de quand
Pour les systèmes à haut risque, l'article 12 de l'AI Act exige qu'ils permettent techniquement l'enregistrement automatique des événements pendant toute leur durée de vie, et l'article 14 qu'ils puissent faire l'objet d'une supervision humaine effective. L'Omnibus IA, le règlement (UE) 2026/1744 entré en vigueur le 27 juillet 2026, a reporté ces obligations au 2 décembre 2027 pour les systèmes de l'annexe III, qui couvre notamment le recrutement, l'éducation et l'évaluation du crédit. Un agent qui trie des candidatures ou prépare une décision de crédit entre dans ce périmètre. Un journal conçu dès maintenant évite une reconstruction dans l'urgence, et il sert déjà de preuve dans un audit ISO 42001. Notre page sur la conformité AI Act en entreprise reprend le calendrier complet.
Les 4 zones de confiance LOOP™ appliquées au risque sécurité
La gouvernance LOOP™ (Living Oversight & Operations Protocol) classe chaque action possible d'un agent dans une zone de confiance, définie avant la mise en production. La zone s'attache à chaque action : le même agent peut générer un rapport en zone verte et voir une autre de ses actions bloquée en zone noire.
Zone verte : exécution autonome
L'agent exécute sans validation préalable et le résultat est journalisé. On y range des tâches réversibles, à faible risque et à fort volume, comme le tri de tickets de premier niveau ou la génération de rapports standards. Sous l'angle de la sécurité, cette zone suppose des accès étroits : une erreur y coûte peu et se corrige vite.
Zone orange : validation humaine avant exécution
L'agent prépare une recommandation complète et argumentée, et un humain désigné la valide avant que l'action parte. LOOP™ range dans cette zone les paiements fournisseurs au-dessus d'un seuil, les réponses clients sensibles et les modifications de contrats. Pour la sécurité, c'est la zone naturelle des écritures qui engagent l'entreprise vis-à-vis d'un client ou d'un fournisseur.
Zone rouge : escalade obligatoire
L'agent s'arrête, documente ce qu'il a compris et ce qui lui manque, puis alerte le responsable désigné dans le registre, qui doit décider sous 4 heures. Aucune action automatique n'est possible. LOOP™ range dans cette zone les situations ambiguës imprévues et les données sensibles inattendues.
Zone noire : blocage immédiat et alerte RSSI
La zone noire couvre ce qui sort du périmètre de l'agent : accès à des données hors de la classification autorisée, demandes de contournement des garde-fous, tentatives d'injection de prompt. L'exécution s'arrête, le RSSI est alerté et l'audit trail complet est activé. C'est là que gouvernance et sécurité se recouvrent le plus nettement, puisque LOOP™ y range plusieurs formes d'attaque.
Escalade et registre vivant
LOOP™ prévoit trois niveaux d'escalade : l'information, qui notifie sans bloquer, la validation, qui exige une approbation humaine avant l'action, et le blocage, qui arrête tout, alerte le RSSI et active l'audit trail. Chaque agent est inscrit à un registre vivant qui documente notamment ses responsables (métier, technique, référent escalade, validateur RSSI), les données auxquelles il accède et le périmètre de ses actions autorisées. Nous recommandons de revoir le classement d'une action dès que l'agent gagne un connecteur ou une capacité d'écriture. Notre article sur les zones de confiance pour classifier ses agents IA détaille la méthode de classement, et la page gouvernance LOOP™ présente le protocole.
Par où commencer pour sécuriser vos agents
Nous conseillons de commencer par un inventaire des agents déjà en service, même informels, puis de classer leurs actions selon leurs accès réels, tels qu'ils apparaissent dans les systèmes cibles. S&P Global relevait en mars 2025 qu'une organisation abandonnait en moyenne 46 % de ses preuves de concept d'IA avant la production, et les entreprises interrogées citaient le coût, la confidentialité des données et les risques de sécurité parmi les premiers obstacles. Poser les questions de sécurité dès le cadrage évite de les découvrir au comité de mise en production.
Tester, puis auditer les connecteurs
Deux vérifications complètent les permissions, les secrets et la journalisation. La première consiste à tester activement la résistance de l'agent aux tentatives de détournement, ce que couvre notre article sur le red teaming des agents IA Claude. La seconde porte sur les serveurs MCP par lesquels l'agent atteint vos systèmes : chacun ajoute une surface à auditer, que détaille notre article sur l'audit des serveurs MCP en production. Pour les agents construits avec Claude Code, notre guide pour connecter Claude Code au SI avec MCP décrit les réglages de permissions et de catalogue côté poste de travail.
Mesurer où vous en êtes
Notre diagnostic de maturité IA situe votre entreprise sur 6 axes, dont la gouvernance et l'industrialisation, en trois minutes, selon le référentiel Koneetiv (édition 2026). Pour les organisations qui veulent un pilotage continu, Claude Cockpit inscrit chaque agent au registre vivant LOOP™, avec ses zones de confiance, ses seuils d'escalade et ses tableaux de bord de supervision.