AI Agent Guardrails: construire une porte d'action à quatre contrôles

Les barreaux de protection de l'agent AI ne doivent pas être constitués d'un seul commandement, d'un seul classifiant ou d'un seul bouton d'approbation. Pour un agent qui peut changer l'état externe, la défaillance pratique est une passerelle d'action à quatre contrôles: décider si l'action est autorisée, prouver que l'appelant a l'autorité pour cette action exacte, lier la tentative, puis vérifier l'effet externe. Chaque contrôle répond à une question différente. Les combiner en un seul drapeau safe: true cache si un agent est bloqué, en attente d'une personne, hors de budget, ou simplement manque de preuves après un appel à l'outil. Gardez ces états séparés et le système peut échouer sans traiter chaque pause comme un incident. Mettre la politique à la limite de l'action Commencez par réduire ce que l'agent peut demander à un outil. Une passerelle politique devrait recevoir des données d'action structurées et non seulement de la prose: Le résultat de la politique devrait être celui de allow , deny ou unknown . Unknown est important. Une classification manquante n'est pas une autorisation, et l'imposition d'ambiguïté sur allow ou deny rend le modèle inventeur de certitude au nom de l'opérateur. Cette passerelle doit également vérifier si l'outil appartient à l'ensemble des capacités de l'agent. Le Conseils de l'OWASP sur l'excès d'agence identifie la fonctionnalité, les autorisations et l'autonomie excessives comme des causes profondes distinctes. Ses atténuations sont par conséquent concrètes: exposer uniquement les extensions nécessaires, préférer les fonctions étroites aux commandes ouvertes, accorder des autorisations minimales en aval et faire respecter l'autorisation dans le système en aval. Cette dernière limite compte. Une instruction telle que ne jamais supprimer les données de production est un contexte utile, mais ce n'est pas un contrôle d'autorisation. Un point final de suppression doit rejeter une identité non autorisée même lorsqu'un agent présente une raison persuasive. De même, un flux de travail à lecture seule ne devrait pas recevoir un client dont les informations d'identification peuvent être écrites. Les barreaux modèles ont encore un travail, mais sachez leur timing. Le Documentation du SDK OpenAI Agents distingue les barreaux d'entrée/sortie de l'agent des barreaux d'outil fonctionnel. Il note également qu'une barrière d'entrée parallèle peut se terminer après que l'agent ait déjà consommé des jetons ou exécuté des outils. Pour une limite d'effet secondaire, utilisez un contrôle de blocage immédiatement avant l'exécution, soutenu par une véritable autorisation en aval. Le défaut raisonnable est: refuser des outils en dehors d'une liste d'allocations par agent; calculer les champs d'action requis à partir de l'action structurée; faire respecter ces champs d'application en dehors du modèle; retourner unknown lorsque les entrées des politiques sont incomplètes; enregistrer la version de la politique et le résumé de l'action avec la décision. Les filtres de contenu ne remplacent pas cette passerelle. La documentation de garde de la connexion AI d'AWS couvre les sujets démenti, les filtres de contenu, les vérifications de mise à terre, les filtres de mots et les contrôles d'informations sensibles, tout en documentant les limites de configuration et les compromis de latence. Ce sont des garanties utiles pour les entrées et sorties. Ils ne prouvent pas qu'une libération, un paiement, un message ou une mutation de fichier est autorisé. Obliger l'approbation à une seule action, pas à une conversation. Approuvé est trop vague pour être exécuté. Une approbation sécurisée est une enveloppe de courte durée de l'autorité liée à l'action exacte de la personne examinée. Au moins, persistez: Récupérez l'action immédiatement avant l'exécution. Si la ressource, les arguments, l'acteur, l'outil, l'impact ou l'expiration diffèrent, l'approbation ne correspond pas. Demandez à nouveau plutôt que de prolonger une ancienne décision sur un nouveau travail. Cela empêche une classe silencieuse mais sérieuse d'échecs. Une personne peut approuver un candidat de sortie pour un référentiel, puis le contexte de l'agent change, une nouvelle tentative reconstruit différents arguments, ou une autre course réutilise le même état de conversation. Un booléen flottant survit à toutes les trois erreurs. Un reçu obligatoire ne le fait pas. L'approbation a également besoin d'un propriétaire et d'un état réactible. awaiting approval n'est pas stuck : il a une décision nommée, un itinéraire vers la bonne personne et une expiration. Après une décision, reprenez à partir de l'enveloppe d'action gelée au lieu de reprendre la planification et espérer que le modèle propose la même opération. Toutes les actions n'ont pas besoin d'un humain. Utilisez l' impact pour décider: des actions réversibles et de faible portée, qui ne peuvent être prises que pour lecture, peuvent être menées en vertu d'une politique permanente; les modifications ayant un retour limité et bien testé peuvent utiliser des limites et des audits explicites; les actions publiques, financières, destructrices, changeantes de privilège ou autrement à fort impact nécessitent une approbation exacte; l'ambiguïté concernant les voies d'impact vers une personne. L'examen humain est donc un contrôle à l'intérieur de la pile, pas la pile elle même. Exécution restreinte même après autorisation Une action autorisée et approuvée peut encore mal tourner. L'exécuteur a besoin de limites strictes que l'agent ne peut pas renégocier en silence: un délai absolu, vérifié avant chaque tentative; un nombre maximal de tentatives; une clé d'idempotence pour les effets secondaires; un plafond de ressources et d'impact; une voie d'annulation; une règle pour ce qui se passe quand le résultat est ambigu. L'identité de l'opération doit rester stable au cours des tentatives répétées. Si un délai de transport intervient après que la destination a effectué un changement, la délivrance d'une nouvelle identité d'exploitation peut dupliquer l'effet. Si la destination prend en charge l'idempotence, réutilisez la même clé. S'il offre une recherche autoritaire, réconciliez vous avant de recommencer. Si aucun n'existe, arrêtez avec unverified plutôt que de deviner qu'une autre tentative est sûre. Gardez l'exécuteur mécanique. Un modèle peut recommander une nouvelle tentative, mais le code doit décider si attempt < maxAttempts , la date limite est fraîche, la ressource est toujours la même et l'action a une clé d'idempotence utilisable. C'est l'un des rares endroits où les conditionnels ennuyeux sont exactement le bon design. Les limites ne sont pas uniquement destinées à limiter les dommages. Ils préservent le diagnostic. Sans eux, un appel répété peut ressembler à une persistance, une opération expirée peut ressembler à un progrès lent, et un effet dupliqué peut ressembler à une récupération. Avec des limites explicites, l'opérateur peut distinguer les états de travail, d'attente, de blocage et d'incertitude. Vérifiez l'effet de manière indépendante Une réponse à l'outil prouve ce que l'outil a rapporté, pas nécessairement ce dont l'utilisateur avait besoin. La porte finale compare une postcondition observable avec le résultat promis. Je préfère les preuves déterministes: récupérer l'objet créé par ID stable; lire la branche de destination ou le dossier de libération; vérifier l'existence du fichier attendu et ses correspondances de hachage; effectuer les essais pertinents; confirmer qu'un message apparaît à la destination prévue; comparer les valeurs avant et après la ressource exacte. Ne pas utiliser le même signal faible deux fois. Si le point final d'écriture renvoie { "ok": true } , copier ce champ dans un enregistrement d'achèvement n'est pas une vérification indépendante. Lisez à partir de la destination autorisée ou inspectez la livraison promise. Certains résultats ne peuvent pas être vérifiés immédiatement. Une notification peut être acceptée mais non fournie, un fournisseur externe peut manquer d'API de lecture ou un canal d'observation peut être obsolète. représenter que comme unverified , inclure les preuves manquantes et la prochaine vérification sûre, et éviter de signaler le succès. C'est là que la santé et la sécurité opérationnelles se rencontrent. La politique et l'autorisation empêchent les actions interdites; la vérification des effets empêche la fausse réalisation. Un agent peut obéir à toutes les règles d'accès et échouer. À l'inverse, un résultat réussi n'excuse pas une voie non autorisée. Retournez neuf cases avant de faire confiance à la conception L'artefact qui l'accompagne transforme les quatre commandes en un petit test exécutable. Le guardrail cases.json contient neuf actions proposées. Le evaluate agent guardrails.mjs est doté d'une priorité fixe: 1. la politique; 2. les champs d'application et l'autorité compétente en matière d'homologation; 3. les limites d'exécution; 4. preuve de l'effet. Faites le avec: Le résumé reproduit est le suivant: Les cas intéressants ne sont pas le "clean pass" ou le déni évident. Une approbation est expirée. Une autre a été émise pour une empreinte digitale d'action différente. Une lettre a épuisé son budget de réessayer. Une commande s'est déroulée sans effet observable. Une politique ne peut pas classer l'action du tout. Ces cas montrent pourquoi la priorité de l'État doit être explicite. Vérifiez d'abord les preuves de l'effet et une action non autorisée pourrait être étiquetée simplement non vérifiée. Vérifiez l'approbation avant la politique et vous pourriez demander à une personne d'autoriser un outil qui n'aurait jamais dû être disponible. L'inconnu s'effondre en déni et l'opérateur perd un signal de qualité de données réparable; l'effondrement en autorisation et le système invente l'autorité. Adaptez l'appareil à vos propres outils. Ajoutez des cas de substitution de ressources, de perte de portée, de non approbation réutilisée, de versions périmées des politiques, d'expiration du délai, d'effets partiels, d'échec de rétroaction et d'un canal de vérification qui n'est pas d'accord avec la réponse de l'outil. La porte n'est prête que lorsque ces échecs produisent l'état et la prochaine action que vous avez prévu. Gardez les limites honnêtes Les barreaux d'agent AI fonctionnent lorsque chaque contrôle peut opposer un veto à l'action pour sa propre raison et exposer des preuves de cette décision. La règle est la suivante: La politique décide si l'action appartient. L'autorité oblige qui peut faire exactement quoi. Les limites restreignent la tentative. La vérification prouve l'effet. Cela coûte plus cher que l'ajout d'un classifiant. Les approbations exactes ajoutent du temps d'attente. Les vérifications de lecture après écriture ajoutent des appels. Les outils étroits nécessitent l'ingénierie. Les États inconnus ont besoin d'une gestion de l'opérateur. Le commerce vaut la peine d'avoir des effets secondaires car l'ambiguïté reste visible au lieu de devenir une autorité silencieuse ou un faux succès. 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. La pile de contrôle ici est un modèle d'implémentation que vous pouvez tester maintenant, pas une affirmation que Sidewisp l'applique actuellement. Si vous évaluez Sidewisp pour les futurs flux de travail sur la santé des agents, rejoignez l'aperçu privé. En attendant, gardez l'enveloppe d'action et ses preuves dans votre propre temps d'exécution: la barrière de protection la plus sûre est celle qui tient encore lorsque le modèle est en toute confiance erroné.