Risques liés à la sécurité des agents AI: créer un registre des menaces opérationnelles

La manière pratique de gérer les risques liés à la sécurité des agents AI consiste à modéliser la menace de chaque opération d'effet secondaire avant l'appel à l'outil. Enregistrez quel actif peut changer, quelle identité fournit l'autorité, quels champs sont requis, d'où provient l'instruction, comment l'effet sera limité et quelles preuves rendent une nouvelle tentative sûre. Si un champ est inconnu, arrêtez vous à cette limite au lieu de demander au modèle de déduire la permission. Il s'agit là d'une décision utile, et non d'une autre liste de risques. L'opérateur peut procéder, restreindre une carte d'identité, supprimer les autorisations excédentaires, revoir une instruction non fiable, définir une limite d'effet ou concilier un résultat ambigu avant de réessayer. Une réponse valide n'est pas suffisante: la sécurité dépend de l'autorité utilisée et de l'effet externe produit. La menace modèle de l'opération, pas seulement le modèle Un agent est plus qu'un LLM. Il regroupe un modèle, un temps d'exécution, des informations d'identification, des outils, du contenu externe et des systèmes de destination dans un seul chemin d'action. Le Sécurité du papier AI Agents rend cette distinction explicite: les agents utilisent des actions générées par le modèle pour invoquer des outils qui peuvent affecter des systèmes réels, créant des problèmes de confidentialité, d'intégrité et de disponibilité au delà de l'alignement du modèle. Commencez par une opération proposée et tracez quatre limites: 1. Limité d'instruction: L'intention utilisateur, le contenu récupéré, la sortie de l'outil et la mémoire entrent dans le contexte du modèle. 2. A limite d'autorité: le temps d'exécution attache une identité ou une carte d'identité à l'appel d'outil proposé. 3. E Limite d'effet: L'outil peut lire ou modifier une ressource externe. 4. Retry boundary: Les résultats de transport ou d'outil incertains peuvent provoquer une répétition de l'effet du temps d'exécution. Le L'initiative de sécurité agentique de l'OWASP décrit ses orientations comme une référence basée sur un modèle de menace pour les risques agissant émergents. C'est la bonne position de départ: identifier les actifs, les acteurs, les changements de confiance et les effets possibles avant de choisir les contrôles. Utilisez un registre de menaces à niveau de fonctionnement plutôt que des notes en forme libre: Ne mettez pas de valeurs secrètes dans le livre. Les références de stockage, les identifiants de l'émetteur et du public, l'expiration, les champs d'application, l'identité de l'exploitation et les emplacements des preuves. L'artefact devrait répondre à ce qui pourrait changer, sous l'autorité de qui, et comment le saurons nous ? sans devenir une nouvelle fuite de crédibilité. Le défaut raisonnable est de créer une ligne de registre par opération externe. Un modèle de menace général au niveau de l'agent aide toujours avec l'architecture, mais il ne peut pas vous dire si ce paiement particulier, message, libération ou mutation de fichier est sûr maintenant. Vérifiez l'identité de la pièce d'identité avant de vérifier la demande Une carte d'identité n'est pas sûre simplement parce qu'elle authentifie. Pour chaque opération, enregistrer: qui ou ce que représente la carte d'identité; où il a été délivré et où il peut être présenté; s'il est partagé entre agents ou environnements; sa voie d'expiration et de révocation; l'audience de ressources exacte; une référence non secrète permettant à un opérateur de la faire tourner. Le Spécification de l'autorisation de MCP de juin 2025 est concret sur la limite HTTP. Les clients incluent un indicateur de ressources, les serveurs valident qu'un jeton a été émis pour le public prévu, et une autorisation invalide ou insuffisante reçoit une erreur. Le Conseils sur la sécurité des PCM connexe interdit le passage des jetons et explique pourquoi la confusion de l'audience affaiblit les limites de contrôle, d'attribution et de confiance. Ces règles s'appliquent directement aux autorisations HTTP MCP. Le principe d'exploitation est également bon: ne laissez jamais un seul jeton opaque se tenir silencieusement pour chaque destination. Un jeton d'administrateur partagé sans propriétaire de tâche et sans audience étroite peut fonctionner parfaitement tout en détruisant l'attribution et en augmentant le rayon d'explosion. La santé et la sécurité de l'instruction sont séparées. Un prompt propre ne peut pas réparer un jeton expiré, et un jeton valide ne rend pas une instruction non fiable légitime. Vérifiez d'abord les preuves d'identification car chaque contrôle ultérieur dépend de savoir quelle identité franchira les limites de l'outil. Lorsque des preuves manquent, utilisez stop credential , pas probablement autorisé. La réparation est mécanique: émettre une carte de crédit de courte durée, révocable pour l'agent exact, la tâche, le public et l'environnement. Gardez le modèle hors de cette décision. Comparer l'autorisation requise avec l'autorisation accordée Le moins de privilège ne devient testable que lorsque vous comparez deux ensembles pour une opération: Si surplus n'est pas vide, arrêtez et remplacez la subvention. Un outil autorisé ne suffit pas. Le même client d'outil peut contenir des champs de travail non liés à l'emploi actuel, et ces autorisations dormant deviennent disponibles lorsque le contexte est empoisonné, un argument d'outil est remplacé ou que le modèle choisit simplement la mauvaise opération. Rejeter également les champs de champs requis manquants. Ce cas est généralement moins dangereux que l'excédent d'autorité, mais il crée des tentatives de reprise bruyantes et encourage des solutions dangereuses telles que l'échange d'une carte d'identité plus large. Un déséquilibre de permis devrait produire un état explicite et une réparation, pas une invitation pour l'agent à chasser des secrets plus forts. Les contrôles d'autorisation doivent avoir une description des effets. Utiliser l'outil de référentiel est trop large; créer un candidat de sortie dans le référentiel X fournit un plafond de ressources et d'impact. L'approbation doit être liée, si nécessaire, à cette description gelée. L'examen humain est précieux pour les opérations à fort impact ou non fiables, mais il ne faut pas demander à une personne d'approuver une action qui a encore des ressources anonymes ou des effets illimités. C'est là qu'un modèle de menace diffère d'une mise en œuvre de barrière. Le registre des menaces identifie l'autorité et l'effet qui nécessitent une protection. La politique, l'approbation, le sandboxing et la vérification sont des contrôles sélectionnés par la suite. En commençant par les contrôles seuls, les équipes protègent souvent l'instruction alors qu'une carte d'identité débordante reste inchangée. Traiter les instructions, les effets et les retentissements comme des risques distincts Le contenu externe peut influencer un agent sans devenir une autorité. La marque de provenance de l'instruction est trusted , untrusted external content ou mixed . Si un contenu non fiable contribue à une action ayant des effets secondaires, geler la ressource et les arguments proposés, puis exiger une décision politique ou une révision humaine en dehors de cette voie de contenu. Ne résolvez pas ce problème en supprimant toutes les instructions externes. Un agent peut avoir besoin de documents récupérés ou d'un outil de sortie pour travailler. La limite de sécurité est de savoir si ce contenu peut discrètement choisir un effet privilégié. Une analyse à lecture seule et un envoi de message public ne devraient pas partager la même règle d'examen. Ensuite, définissez l'effet indépendamment de la réponse de l'outil: la ressource de destination exacte; le nombre ou la taille maximale de changements; la réversibilité et le propriétaire du roulement; une identité opérationnelle stable; une lecture révisée ou une autre preuve de résultats. Les retries méritent leur propre rangée car un temps d'arrêt ne signifie pas que rien ne s'est passé. Le AWS Builders Guide bibliothécaire sur les API idempotentes montre comment un identifiant de requête client stable peut rendre les requêtes répétées semanticement équivalentes. Ce contrat prend en charge les tentatives de récupération sécurisées par défaut. Il n'autorise pas l'action initiale et n'aide pas si le temps d'exécution génère un nouvel identifiant pour la deuxième tentative. Après une pause ambiguë, utilisez l'ordre suivant: 1. conserver l'identité d'exploitation originale; 2. effectuer des recherches sur la destination autorisée; 3. classer l'effet comme présent, absent, partiel ou inconnu; 4. ne réessayez que lorsque le contrat rend une autre tentative sûre; 5. vérifier le résultat promis après la tentative finale. Si la destination n'offre ni idempotence ni effet de recherche, l'état correct est reconcile before retry . Cela peut nécessiter une personne. C'est encore mieux que de transformer les preuves manquantes de transport en un paiement, un message, une libération ou une suppression dupliqués. Récupérez le registre de menaces de neuf cas . Le dispositif d'accompagnement rend la règle de décision inspectable. Le security risk cases.json contient neuf opérations proposées. Le evaluate ai agent threat ledger.mjs vérifie les limites dans un ordre fixe: 1. la présence, l'expiration, le partage, la révocabilité et l'audience de l'accréditation; 2. les champs d'application requis par rapport aux champs d'application accordés; 3. provenance non fiable de l'instruction pour les écritures; 4. la définition des ressources et de l'effet maximal; 5. l'identité de l'exploitation, l'idempotence et la réconciliation avant les renouvellements; 6. preuve indépendante d'effet. Faites le avec: Le résumé reproduit est le suivant: Seulement deux affaires se poursuivent. L'une est une lecture limitée. L'autre est un écrit idempotent avec un public exact, un ensemble de champs exact, une ressource nommée, un impact maximal et des preuves indépendantes. Les autres cas démontrent une carte d'identité partagée de l'administrateur, un jeton de tâche expiré, un champ de suppression de surplus, une instruction externe non révisée, une exportation illimitée, une nouvelle tentative avec une nouvelle identité d'exploitation et une réponse réussie sans preuve d'effet. L'ordre est important. Si l'autorisation est vérifiée devant le public de l'identité, un jeton cross service peut sembler sûr parce que ses champs de champs correspondent. Si les preuves de l'effet sont vérifiées avant de réessayer l'identité, l'opérateur peut étiqueter la course simplement incomplète alors qu'une autre tentative dangereuse est déjà possible. La première limite de confiance dangereuse devrait déterminer la disposition. Adaptez l'appareil à vos vrais champs d'action et effets. Ajoutez un chemin de révocation manquant, un environnement incorrect, une approbation obsolète, une substitution de ressources, une écriture partielle, un échec de rétroaction et un désaccord entre l'état de sortie de l'outil et l'état de destination. L'objectif n'est pas de prédire chaque attaque. Il s'agit de rendre impossible l'autorité et l'incertitude de se cacher à l'intérieur d'un même statut d'agent vert. Garder le modèle de menace opérationnel Réviser le registre lorsqu'un outil, une portée, un émetteur de certificats, une API de destination, une politique de retrait ou une source d'instructions changent. Ne nécessitez pas un atelier complet pour chaque course; générez la plupart des champs à partir de schémas d'outils, de métadonnées d'identité, de politiques et de reçus d'exploitation, puis demandez à une personne uniquement l'impact ou l'incertitude que le code ne peut pas résoudre. La règle de la décision compacte est la suivante: Ne procéder que lorsque l'identité est liée au public, que les autorisations sont égales à l'ensemble requis, que les instructions non fiables ne peuvent pas autoriser silencieusement les effets, que l'impact est limité, que les retries préservent l'identité de l'opération et que la destination peut prouver le résultat. Cette règle a des limites. Les métadonnées peuvent mentir ou devenir obsolètes. Une portée exacte peut encore permettre un argument dangereux. L'idempotence peut expirer. Un canal de lecture peut être compromis avec l'écrivain. Le registre réduit donc l'ambiguïté; il ne prouve pas que l'ensemble du système est sécurisé. Combinez le avec l'autorisation en aval, l'isolement, les journaux d'audit, les tests et la réponse aux incidents appropriés à l'impact. Sidewisp est actuellement en préversion privée. Il est conçu comme une couche de santé autour des temps d'exécution existants des agents, mais la collecte et la récupération des agents de production et de santé ne sont pas expédiées dans le référentiel du site Web actuel. Ce modèle de répertoire de menaces est quelque chose que les opérateurs peuvent mettre en œuvre dans leur propre temps d'exécution maintenant, pas une affirmation selon laquelle Sidewisp sécurise ou surveille actuellement les agents en direct. Si vous évaluez Sidewisp pour les futurs flux de travail sur la santé des agents, rejoignez l'aperçu privé. En attendant, gardez le registre des menaces près de la limite de l'outil et laissez des preuves inconnues arrêter l'action avant qu'elle ne devienne un incident.