Sécurité des agents d'IA : Liste de contrôle pratique

La sécurité des agents d'IA repose sur le système de contrôle d'un modèle capable de lire le contexte, de choisir des outils et d'agir étape par étape. Une conception sécurisée part du principe que les résultats du modèle, le contenu récupéré et les résultats des outils peuvent être erronés ou malveillants. Elle limite l'accès, valide chaque action, rend l'incertitude visible et désigne une personne responsable des modifications qui en découlent.

Ottermind applique cette même approche de délimitation prioritaire aux travaux connectés : le contexte source et les livrables restent vérifiables, tandis que les actions consécutives demeurent soumises aux autorisations et à l’approbation humaine. Il s’agit d’une option d’espace de travail, et non d’un substitut à l’audit de sécurité de l’organisation.

Recherche et divulgation: La liste de contrôle s’appuie sur le cadre de gestion des risques liés à l'IA du NIST, le Top 10 OWASP pour les applications LLM et les consignes Anthropic sur la sécurité des agents, révisés le 3 septembre 2026.

Les cinq limites de sécurité

La sécurité est distribuée tout au long du flux de travail. Un message final invitant un agent à « faire attention » ne constitue pas une mesure de sécurité.

Modélisation des menaces avant la conception des fonctionnalités

Décrivez ce que l'agent peut observer, ce qu'il peut modifier et qui pourrait tirer profit d'une erreur. Prenons l'exemple d'un utilisateur curieux, d'un connecteur compromis, d'un texte malveillant dans un document récupéré, d'un outil renvoyant des données inattendues et d'une interruption de service lors d'une écriture. Pour chaque menace, définissez une mesure de prévention, un signal de détection et une action de récupération. Ce modèle de menaces simplifié révèle souvent que la fonctionnalité la plus risquée est un connecteur trop général plutôt que le modèle lui-même.

Isolation des identités et des locataires

Authentifiez l'utilisateur avant de lancer l'exécution et autorisez chaque récupération et appel d'outil avec cette identité. Ne présumez pas qu'un ID de projet visible par le modèle soit fiable. Vérifiez les autorisations au niveau du locataire, du projet, du rôle et de l'enregistrement dans le service propriétaire des données. Pour les espaces de travail multi-utilisateurs, testez explicitement une requête inter-locataires et vérifiez que les journaux ne révèlent aucun nom de fichier, extrait ou argument d'outil interdit.

Intégrité de la récupération

Les systèmes de récupération peuvent divulguer des données, renvoyer des enregistrements obsolètes ou exposer des instructions intégrées aux documents. Stockez la provenance avec chaque segment : identifiant source, propriétaire, date d'effet et décision d'autorisation. Privilégiez les enregistrements les plus récents et exposez les conflits. Traitez les fichiers HTML, PDF, les e-mails et les commentaires de tickets comme des données, et non comme des instructions. Un modèle ne doit jamais pouvoir s'octroyer l'accès à lui-même simplement parce qu'un paragraphe récupéré l'y autorise.

Isolation des outils et de l'environnement d'exécution

Utilisez des outils spécifiques à un usage métier plutôt qu'un shell général ou un client HTTP non restreint. Validez les arguments, appliquez des quotas, définissez des délais d'expiration et assurez l'idempotence des écritures. Exécutez le code ou les actions du navigateur dans un environnement isolé (sandbox) avec un système de fichiers éphémère et des sorties restreintes. Séparez les identifiants de développement de ceux de production et renouvelez les jetons à durée de vie limitée après l'exécution.

Conception nécessitant une validation humaine

L'approbation doit indiquer l'action proposée, la cible, les preuves sources, les effets secondaires et les alternatives. L'approbation ne doit pas masquer des écritures sans rapport avec le sujet. Un examen plus approfondi est requis pour les communications externes, les suppressions, les paiements, les modifications d'accès et les mises à jour de politiques. Il est impératif de conserver l'approbateur, l'horodatage, la décision et toutes les modifications afin qu'une nouvelle tentative ne puisse pas contourner silencieusement le point de contrôle.

Cas de test d'équipe rouge

Créez un petit ensemble de tests de régression comprenant l'injection d'une invite dans un document, un utilisateur sans accès, un outil renvoyant du JSON malformé, des informations d'identification expirées, un schéma modifié, une nouvelle tentative en double et une demande d'envoi ou de suppression. Le résultat attendu n'est pas toujours la réussite de la tâche ; un refus sans risque, une escalade et une erreur utile sont des résultats valides. Exécutez l'ensemble de tests à chaque modification des invites, des outils, des connecteurs ou des versions des modèles.

Liste de contrôle des opérations de sécurité

• Tenir à jour un inventaire des modèles, outils, connecteurs et bases de données.
• Revoir régulièrement les étendues des connecteurs et les rôles privilégiés.
• Configurer une alerte en cas d'activité inhabituelle des outils, de récupération inter-projets ou d'actions bloquées.
• Conserver les traces suffisamment longtemps pour enquêter sur les incidents sans stocker de données confidentielles inutiles.
• Documenter la procédure de révocation d'accès, d'arrêt d'exécution et de restauration de l'enregistrement source.
• Fournir aux utilisateurs un moyen clair de signaler une suggestion non sécurisée ou une fuite de contexte.

Mappage des contrôles aux étapes de l'agent

Les revues de sécurité sont facilitées lorsqu'elles suivent le cycle de vie de l'agent. À la réception, vérifiez l'identité, la finalité et les données autorisées. Lors de la récupération, appliquez les permissions et rattachez la provenance. Lors du raisonnement, contraignez le schéma de sortie et signalez les incertitudes. Avant l'appel d'un outil, validez les arguments et les effets de bord. Après l'appel, vérifiez le résultat et enregistrez la transition. Avant la finalisation, exigez l'intervention du réviseur compétent et enregistrez le statut final. Ce mappage étape par étape empêche les équipes de considérer la sécurité comme un simple point d'accès à un agent sans restriction.

Risques liés à la chaîne d'approvisionnement et aux connecteurs

Les capacités effectives d'un agent comprennent son SDK, ses plugins, ses serveurs MCP, ses extensions de navigateur, ses modèles d'invite et les étendues de ses connecteurs. Inventoriez ces dépendances et examinez les mises à jour avant leur mise en production. Épinglez les versions lorsque cela est possible, signez ou vérifiez les packages et séparez les identifiants de test des données client. Un connecteur capable de lire l'intégralité d'un disque peut engendrer davantage de risques que le fournisseur du modèle, même si ce dernier est correctement configuré.

Que contient une analyse de sécurité utile ?

Consignez le flux de travail prévu, la classification des données, les identités, les outils, les versions du modèle et du SDK, les scénarios de menaces, les contrôles, les cas de test, les risques non résolus et le responsable. Incluez un exemple d'action bloquée et un exemple d'escalade sécurisée. Réexaminez cette revue lors de l'introduction d'un nouveau connecteur, outil, modèle ou niveau d'autonomie ; l'approbation précédente ne doit pas masquer une surface d'action sensiblement différente.

Principe du moindre privilège en pratique

N'accordez à un agent que les sources et les outils nécessaires à la tâche en cours. Séparez les informations d'identification de lecture et d'écriture. Limitez l'accès aux fichiers par projet et identité, restreignez les destinations réseau et faites expirer les accès temporaires. Testez les limites d'autorisation avec un utilisateur qui ne devrait pas pouvoir consulter le code source.

Contrat d'appel d'outil

{
  "tool": "create_draft_task",
  "arguments": {"title": "...", "owner": "...", "due_date": "..."},
  "requires_approval": true,
  "idempotency_key": "project-123:brief-v2"
}

Validez les types, les valeurs autorisées, l'identité et les effets de bord dans le code de l'application. Exiger une confirmation pour l'envoi, la suppression, l'achat, la modification d'accès ou la publication. Sécuriser les nouvelles tentatives grâce à des clés d'idempotence.

Injection de données lors de la récupération et de l'exécution

Considérer les documents, les pages web, les courriels et les résultats d'outils comme des données non fiables. Les isoler des instructions système, préserver les identifiants de source et empêcher le texte récupéré de modifier les autorisations ou la politique de l'outil. En cas de conflit de sources ou de récupération infructueuse, renvoyer un état d'escalade plutôt que de tenter une estimation.

Évaluation et réponse aux incidents

Testez les cas normaux, incomplets, adverses, inter-locataires, sensibles et de défaillance d'outils. Suivez les actions bloquées, les suggestions non sécurisées, les tentatives de divulgation de données, les erreurs d'outils et les corrections des réviseurs. Prévoyez une procédure de restauration et désignez un responsable de la gestion des incidents.

FAQ

Un agent d'IA peut-il être totalement autonome ?

L'autonomie est un paramètre du produit, et non une propriété de sécurité. Plus l'action est importante, plus les contrôles d'approbation, de surveillance et de restauration doivent être rigoureux.

Un modèle privé garantit-il la sécurité des agents ?

Non. Un modèle privé peut modifier les risques liés aux flux de données, mais l'identité, la récupération, les autorisations des outils, l'isolation d'exécution, la journalisation et la vérification humaine restent essentielles.

Que doivent sécuriser les équipes en priorité ?

Commencez par l'identité, les autorisations de récupération et les limites d'écriture des outils. Un flux de travail en lecture seule avec des traces claires constitue un premier déploiement plus sûr qu'un accès autonome étendu.

Pour la structure du système, voir Architecture des agents IA ; pour les détails d'implémentation, comparez avec Guide Claude Agent SDK.