Comment maintenir un agent d’IA sous le contrôle d’un humain ?

Enregistrer l’approbation d’une action spécifique et vérifiable, puis faire en sorte que le service d’exécution applique cette même action dans le respect des conditions d’autorisation en vigueur. L’enregistrement doit identifier l’opération, la cible, les paramètres significatifs, la version de la charge utile, l’autorité d’approbation et la durée de validité autorisée. Toute modification de la demande nécessite une nouvelle décision. Un résultat d’exécution incertain doit faire l’objet d’un rapprochement avant qu’une nouvelle tentative ne puisse produire un autre effet.

Un bouton intitulé « Approuver » ne définit pas ces propriétés. Le réviseur peut voir un résumé anodin alors que l’outil reçoit des arguments différents. L’agent peut modifier une pièce jointe après révision. Un employé peut réessayer une opération qui a déjà abouti. Dans chaque cas, l’interface peut enregistrer fidèlement un clic tandis que le système effectue une action que la personne n’a jamais évaluée.

Je considérerais l’approbation comme un contrat transactionnel entre l’évaluateur et le service qui produit l’effet. Le présent article développe ce contrat à partir de douze travaux originaux portant sur la recherche, les protocoles et les recommandations en matière de sécurité. Il propose une méthode d’ingénierie et un exemple fictif de mise en production ; il ne fait état d’aucun déploiement chez un client, d’aucune expérience ni d’aucune amélioration mesurable de la sécurité. L’objectif est de rendre vérifiable une affirmation d’approbation délimitée, et non de certifier qu’un agent est globalement digne de confiance.

Distinguer un plan utile de l’autorisation de le mettre en œuvre

L’utilisateur, le modèle de planification, le service d’approbation et l’exécuteur ont des responsabilités différentes. L’utilisateur formule la tâche. Le modèle propose des actions. Le service d’approbation détermine si une personne autorisée a accepté une action particulière en conséquence. L’exécuteur vérifie si cette acceptation autorise toujours la requête qu’il s’apprête à exécuter. Le fait de regrouper ces rôles dans un seul transcript de conversation rend leurs délimitations difficiles à cerner.

L’injection indirecte de prompts revêt une importance particulière, car des éléments externes peuvent influencer la proposition. Greshake et ses collègues ont démontré que le contenu récupéré pouvait orienter les applications intégrant des modèles de langage à grande échelle (LLM), à l’aide d’applications synthétiques et d’expériences contrôlées incluant des entrées HTML locales (Greshake et al., 2023, §4). Leurs démonstrations historiques mettent en évidence un mécanisme de défaillance pertinent, et non un taux de défaillance actuel pour votre déploiement. Elles ne prouvent pas que chaque action proposée soit malveillante ni que chaque système de validation soit nécessairement soumis à cette influence.

Mon hypothèse de départ est plus restrictive : le planificateur peut générer une demande erronée ou manipulée, mais il ne peut pas modifier l’enregistrement d’approbation fiable, usurper l’identité du réviseur ni contourner l’exécuteur. Si ces hypothèses s’avèrent fausses, une boîte de dialogue d’approbation bien conçue ne constitue pas la seule barrière restante. L’architecture doit protéger le service d’approbation et veiller à ce que les effets pertinents soient soumis à des mesures d’application, y compris les effets accessibles via des outils de script ou des tâches en arrière-plan.

L’OWASP distingue les fonctionnalités, les autorisations et l’autonomie excessives dans ses recommandations relatives à l’« excessive-agency » (OWASP Foundation, 2025). Il s’agit là de choix de conception distincts. Supprimer une fonction d’envoi superflue est plus efficace que de demander à un réviseur de contrôler chaque tentative d’envoi. Lorsqu’une fonction ayant des conséquences importantes est nécessaire, dotez-la d’une interface restreinte et d’un niveau d’autorisation adapté à la tâche. L’approbation humaine doit régir une capacité délimitée, et non compenser un exécutant sans restriction.

Définissez l’objet de l’approbation avant de concevoir la boîte de dialogue

L’expression « approuver le plan » laisse planer une ambiguïté importante : quelles parties du plan l’agent est-il autorisé à modifier par la suite ? Un plan de déploiement peut comporter un environnement, un artefact, une configuration, une portée de déploiement et un plan de secours. Approuver son objectif général ne revient pas nécessairement à approuver chaque choix futur concernant ces valeurs. Je commencerais par définir les champs dont la modification influe sur la décision prise par le réviseur.

Pour une action de publication, ces champs peuvent inclure l’identifiant immuable de l’artefact, l’environnement cible, la révision de configuration, la limite de déploiement et l’identifiant de l’opération. Pour une action de divulgation, ils peuvent inclure la version exacte du document, les pièces jointes, l’identité des destinataires et le canal de diffusion. Il s’agit d’une proposition de contrat d’application. Les champs appropriés dépendent du contexte, et non d’une liste universelle copiée dans chaque intégration.

Il convient de séparer le contexte descriptif de l’autorité d’exécution. Une explication rédigée sous forme de modèle peut aider le réviseur à comprendre une modification proposée, mais elle ne doit pas constituer la seule représentation de cette modification. Le service doit résoudre les identifiants cibles réels et construire l’enregistrement d’action faisant autorité. Sinon, le modèle peut fournir à la fois la requête et l’explication rassurante de ce que signifie cette requête, sans qu’une vérification indépendante ne les relie.

Je préférerais stocker une révision approuvée et immuable plutôt que de marquer une tâche modifiable comme « approuvée ». Si une révision est modifiée, l’approbation précédente reste inscrite dans l’historique mais n’est pas automatiquement transférée vers la nouvelle révision. L’autorité de la personne chargée de l’approbation doit également avoir une portée bien définie : l’autorisation d’examiner une modification en environnement de test ne vaut pas autorisation de la mettre en production. Un simple clic de la part d’un décideur non habilité ne constitue toujours pas une autorisation suffisante.

Présentez au relecteur les mêmes faits significatifs que ceux utilisés par l’exécuteur

Les recommandations de OWASP en matière d’autorisation des transactions exigent une prise en compte significative des données de transaction importantes, une application côté serveur, des transitions d’état contrôlées et une vérification finale liée à l’exécution. Elles abordent également l’invalidation de l’autorisation lorsque les données de transaction changent (Fondation OWASP, s.d., §§ 1.1, 2.1, 2.5–2.8). Ces principes sont antérieurs aux Agents d’IA. Leur intérêt réside ici dans le fait qu’ils se concentrent sur la transaction plutôt que sur le caractère convaincant de l’explication fournie par l’assistant.

La surface d’examen doit donc être générée à partir du registre des actions faisant autorité. Affichez l’environnement et la ressource résolus, la modification effective, les limites matérielles et toute poursuite autorisée. Si les noms sont ambigus, indiquez une identité suffisamment stable pour distinguer la cible. Un nom d’affichage familier qui renvoie désormais à une autre destination peut modifier le sens de l’approbation sans changer les mots que le réviseur reconnaît.

Pour les artefacts volumineux, ne prétendez pas que l’affichage d’une somme de contrôle rend le contenu vérifiable. Le réviseur a besoin d’un comparatif approprié, d’un aperçu prévisualisé ou d’une description de l’artefact vérifiée de manière indépendante, ainsi que d’un lien vers la version qui sera exécutée. Une somme de contrôle permet de préserver l’intégrité du document après inspection. Elle ne permet pas de garantir que la personne a compris le document, que celui-ci est exact ou que l’action proposée est appropriée.

Testez explicitement la limite de représentation. Transmettez à l’interface de révision un enregistrement comportant une cible et à l’exécuteur une requête comportant une autre cible. Modifiez un champ masqué par défaut, un champ de pièce jointe ou un champ de déploiement tout en conservant le résumé généré identique. Le résultat attendu est un rejet ou une nouvelle révision conformément à la politique déclarée. Si le seul argument de défense est que le modèle produit normalement un résumé fiable, l’approbation dépend précisément du comportement qu’il était censé limiter.

Veillez à ce que la représentation approuvée soit sans ambiguïté

Lorsqu’une approbation est associée à une demande structurée, l’application a besoin d’une représentation reproductible. Des données JSON d’apparence équivalente peuvent présenter des différences de sérialisation, et des schémas mal définis peuvent amener différents composants à interpréter une valeur de manière divergente. Je déterminerais quels champs sont obligatoires, comment les valeurs par défaut sont gérées, quelles valeurs sont interdites et quelle version du schéma d’action s’applique avant de créer l’enregistrement d’approbation.

La norme RFC 8785 définit le schéma de canonisation JSON, une spécification informative relative à une sérialisation déterministe adaptée au hachage ou à la signature. Ses contraintes d’entrée interdisent les noms de propriétés en double et limitent la représentation des nombres au modèle JSON/I-JSON pris en charge (Rundgren et al., 2020, §§ 3.1–3.2). Elle fournit une discipline de sérialisation possible. Elle ne définit pas la signification métier de votre action ni ne rend sémantiquement équivalents deux schémas d’outils différents.

Résolvez les identifiants et les valeurs par défaut avant de valider la liaison, et rejetez les champs que l’exécuteur ne comprend pas. Si un composant interprète une limite de déploiement omise comme « une instance » et qu’un autre l’interprète comme « toutes les instances », les octets canoniques ne suffiront pas à eux seuls à résoudre ce désaccord. L’application doit établir une sémantique commune et vérifier l’interprétation de l’exécuteur. Une migration de schéma peut donc invalider une approbation même lorsqu’un sous-ensemble pratique des champs visibles n’a pas changé.

Utilisez soit un enregistrement protégé côté serveur, soit une représentation portable correctement authentifiée, selon l’architecture. Un simple hachage soumis par le modèle ne constitue pas une preuve que quiconque a approuvé le contenu haché. L’exécuteur a besoin d’une connexion fiable entre l’enregistrement, le réviseur, la révision approuvée et l’opération en attente. Protégez cette connexion avec le même soin que l’autorisation d’exécution ; sinon, un attaquant pourrait substituer un autre enregistrement au lieu de modifier la charge utile.

Adapter le champ d’application de la certification à l’action concrète

OAuth provides useful components, but a valid access token doesn't by itself establish approval of a particular transaction. RFC 9396 introduces structured authorization_details for fine-grained requirements, with a required type that determines the permitted contents. The specification includes detailed transaction examples and describes enforcement involving authorization and resource servers (Lodderstedt et al., 2023, §§1–2). This is more expressive than a broad scope name, provided the deployment implements the relevant type and checks.

Je vérifierais si la plateforme est en mesure d’appliquer les restrictions d’action via ce mécanisme ou si elle nécessite un enregistrement d’approbation protégé distinct. Quelle que soit la conception retenue, documentez ce que le service de ressources applique concrètement. S’il se contente de lire « deployment.write » et ignore les limites relatives à l’artefact, à l’environnement et au déploiement, un objet d’autorisation détaillé situé ailleurs dans le système ne restreint pas la portée effective de l’identifiant. L’expressivité du côté de la requête n’est utile que lorsqu’elle se traduit par une application effective.

La norme RFC 8707 permet en outre à un client d’identifier la ressource protégée pour laquelle un jeton est demandé, ce qui permet de restreindre l’accès à un public spécifique. Son analyse de sécurité prend également en compte la spécificité des ressources multi-locataires (Campbell et al., 2020, §§ 2–3). La restriction d’accès aide à empêcher l’utilisation d’un jeton auprès d’un service inapproprié. Elle ne remplace toutefois pas la vérification de l’action, de l’objet et des paramètres au sein du service visé.

Cette distinction soulève une question pratique d’architecture pour le réviseur : qu’est-ce qui empêcherait qu’un artefact de préproduction approuvé soit envoyé en production via la même API ? Une vérification de l’audience pourrait s’avérer positive, car le service reste inchangé. La restriction d’environnement et la révision des actions approuvées doivent toutefois rester en vigueur. Évitez de décrire plusieurs contrôles utiles pris individuellement comme si chacun d’entre eux répondait indépendamment à toutes les questions d’autorisation.

Conserver l’identité de l’acteur lorsque la requête traverse plusieurs services

Un service destiné aux agents peut appeler un autre service sous sa propre identité de charge de travail. Cela peut masquer la distinction entre la personne qui a donné son accord, l’application agissant pour le compte de cette personne et le compte techniquement autorisé à modifier la cible. Je veillerais à ce que ces identités soient explicites dans le modèle d’autorisation et d’audit, en précisant notamment laquelle dispose de l’autorité nécessaire pour approuver l’effet spécifique.

La norme RFC 8693 distingue la délégation de l’usurpation d’identité et définit une revendication d’acteur permettant d’identifier un acteur délégué (Jones et al., 2020, §§ 1.1, 4.1). Elle ne détermine pas votre politique d’approbation métier. L’identité d’un acteur indique qui agit ; elle ne précise pas automatiquement quelle version le réviseur a acceptée. Un service en aval doit recevoir un contexte d’approbation fiable ou imposer une opération restreinte par le biais d’un autre mécanisme défini.

Les recommandations de sécurité versionnées du MCP interdisent le « token passthrough », décrivant les risques liés à l’acceptation de jetons non correctement émis pour le serveur MCP et à leur transmission en aval (Model Context Protocol, 2025, « Token Passthrough »). Ces recommandations concernent les limites des identifiants. Je les considérerais comme complémentaires à l’approbation des actions, sans supposer qu’une connexion MCP fournit un consentement spécifique à la transaction simplement parce que l’autorisation du protocole aboutit.

Il convient de remonter de l’identifiant final jusqu’à l’effet réel. Si une opération approuvée est confiée à un opérateur d’automatisation généraliste, qu’est-ce qui empêche ce dernier d’exécuter une version différente en vertu d’autorisations permanentes plus larges ? Un identifiant de tâche fiable n’est utile que lorsque l’opérateur le résout en une action protégée et applique cette action. Un message généré indiquant « l’utilisateur a approuvé ceci » doit rester une allégation à vérifier, et non une attestation que d’autres agents acceptent telle quelle.

Ne confondez pas la possession d’une clé avec l’approbation d’une charge utile

Les jetons liés à l’expéditeur répondent à un autre problème utile, mais différent. La norme RFC 9449 définit des preuves DPoP qui lient les requêtes à la possession d’une clé. Son analyse de sécurité précise explicitement que la preuve porte sur l’URI HTTP et la méthode plutôt que sur le corps du message ou les en-têtes généraux de la requête ; l’intégrité du message repose sur d’autres protections telles que le protocole TLS (Fett et al., 2023, §§ 3–4, 11.7). Le DPoP ne constitue pas un enregistrement de ce qu’un être humain a examiné.

Un client détenant légitimement la clé peut néanmoins proposer une version, un destinataire ou une pièce jointe erronés. La contrainte d’expéditeur peut contribuer à empêcher l’utilisation abusive d’un jeton copié par une personne ne disposant pas de la clé, tandis que l’application vérifie séparément si l’action demandée par le détenteur de la clé correspond à l’autorisation. Ces propriétés se renforcent mutuellement, mais elles doivent faire l’objet de tests distincts et être étayées par des preuves différentes lors de l’examen.

Je demanderais à l’équipe de simuler une requête comportant un transport valide, des identifiants valides et une preuve de possession valide, mais avec un paramètre significatif modifié. L’action doit échouer au contrôle d’approbation même si les autres couches réussissent. Il s’agit d’un test négatif contrôlé du contrat d’application, et non d’une affirmation selon laquelle le protocole serait défectueux. Cela permet d’éviter une erreur de catégorie courante : considérer la preuve fournie par le demandeur comme la preuve de la décision métier sollicitée.

Valider à nouveau l’état qui a donné tout son sens à l’approbation

Une charge utile inchangée peut devenir inadaptée lorsque le contexte évolue. Une cible de publication peut être transférée à un autre propriétaire, le rôle d’un validateur peut être supprimé, ou une restriction de partage peut être introduite. Je ferais la distinction entre les données d’entrée approuvées et immuables et les prédicats dynamiques que l’exécuteur doit vérifier au moment de l’effet. Le contrat doit préciser quels changements invalident l’exécution et quelles continuations approuvées sont délibérément autorisées.

HTTP conditional requests illustrate one available mechanism. RFC 9110 defines If-Match using strong entity-tag comparison so an operation can be conditioned on a matching representation. It also defines idempotent methods and cautions about automatically retrying non-idempotent requests without grounds for knowing the effect is safe to repeat (Fielding et al., 2022, §§9.2.2, 13.1.1). These are protocol semantics, not a complete cross-service approval transaction.

Une balise d’entité peut protéger la version de la ressource représentée sans protéger une autorisation stockée ailleurs. Si l’état pertinent pour la politique change sans que la balise vérifiée ne soit modifiée, la requête conditionnelle peut tout de même être acceptée. Identifiez l’état couvert par chaque condition et le moment où le service considère l’autorisation et l’effet comme validés. Une transaction locale n’inclut pas automatiquement une base de données d’approbation distante ou un fournisseur d’identité.

Lorsqu’un effet à distance ne peut pas être rendu atomique avec l’état d’approbation, documentez la course résiduelle et choisissez une conception de confinement ou de réconciliation appropriée. L’affirmation honnête peut être plus restrictive que « l’approbation ne peut jamais devenir caduque ». Pour un workflow ayant des conséquences importantes, cette incertitude devrait déterminer si l’opération est autorisée ou non, si elle nécessite un mécanisme de réservation, ou si une action de moindre ampleur peut être prise en charge en toute sécurité.

Accordez votre approbation à un cycle de vie d’exécution, et non à un « feu vert » réutilisable

Je modéliserais une action ayant des conséquences selon les états suivants : proposée, examinée, éligible, en cours d’exécution et résolue, avec des alternatives explicites pour les états rejetée, expirée, annulée et incertaine. Il s’agit d’états d’application proposés, et non d’une nouvelle norme. Leur intérêt réside dans le fait qu’ils obligent l’équipe à définir les transitions autorisées, plutôt que de laisser une valeur booléenne modifiable représenter plusieurs réalités différentes.

Le terme « éligible » ne doit pas signifier qu’un nombre illimité de collaborateurs puisse utiliser la même autorisation. Les demandes simultanées nécessitent une décision coordonnée quant à l’opération qui peut être exécutée. Cependant, le fait de marquer l’autorisation comme consommée avant l’envoi d’une demande peut également bloquer une action légitime si le travailleur échoue avant la transmission. La solution dépend de l’exécuteur et de la cible : des enregistrements d’opérations durables, ainsi que des règles de déduplication et de récupération prises en charge, doivent fonctionner de concert. Renommer l’indicateur ne résout pas le problème des défaillances distribuées.

Un délai d’expiration est particulièrement important. La cible a peut-être validé la modification avant que sa réponse ne soit perdue. Je placerais l’opération dans un état incertain et interrogerais l’état faisant autorité lorsque la cible le prend en charge. Si la cible ne fournit aucun état fiable ni aucun contrat de déduplication, une répétition automatique peut s’avérer inappropriée. Une personne choisissant de réessayer doit néanmoins comprendre que l’effet antérieur pourrait déjà exister.

Distinguer l’autorisation d’exécution de l’autorisation de récupérer un résultat antérieur. Une requête en double peut être identifiée sans divulguer les données de réponse protégées à un appelant qui n’y a plus droit. De même, l’annulation peut interrompre les tâches mises en file d’attente localement sans annuler un effet déjà accepté en aval. L’interface doit signaler clairement ces distinctions plutôt que de transformer la mention « requête annulée » en une promesse non fondée selon laquelle rien ne s’est produit.

Exercez-vous à un scénario fictif d’approbation de mise en production

Imaginons un assistant fictif préparant la mise en production de l’artefact A7 dans un environnement de préproduction. L’action proposée spécifie la révision de configuration C3 et le déploiement de deux instances de test. Un réviseur habilité pour l’environnement de préproduction examine les preuves relatives à l’artefact et approuve cet enregistrement précis. L’application autorise une seule opération de mise en production dans le cadre de cette approbation ; elle n’autorise pas le déploiement en production ni un artefact révisé ultérieurement.

Les identifiants, limites et résultats ci-dessous sont fictifs. Ils illustrent le contrat proposé, et non le comportement d’un produit réel ni le résultat d’un test mesuré.

Événement après validation	Décision prise dans le cadre de ce contrat fictif	Pruves que le relecteur a besoin
L’agent remplace l’artefact A8	Refuser ; demander une nouvelle évaluation	L’identifiant de l’artefact exécuté diffère de celui de la révision approuvée
Mise en place des modifications de la cible, de l’environnement de préproduction à l’environnement de production	Rejeter	L’environnement est un domaine approuvé important ; l’évaluateur ne dispose pas des autorisations nécessaires pour valider la publication
Un autre processus modifie la configuration de C3 en C4	Réévaluez ; n’appliquez pas l’ancienne décision en silence	La condition préalable pertinente n’est plus remplie
La même opération est confiée à deux collaborateurs	Coordonner une opération ; harmoniser les livraisons en double	Identité d’opération durable et déduplication des cibles / contrat de statut
La cible accepte A7 mais la réponse est perdue	Enregistrer les incertitudes et les rapprocher	Statut de publication officiel de la cible, et non celui du compte de l’agent

Supposons que l’explication de l’agent reste « déployer la mise à jour révisée » dans chaque ligne. Ce texte est insuffisant pour distinguer les cas. C’est l’historique des actions faisant autorité et l’état cible observé qui permettent de faire la distinction. Un examen de sécurité devrait permettre de déterminer pourquoi les deux premiers cas ne relèvent pas de l’approbation, pourquoi le troisième nécessite une nouvelle évaluation, et pourquoi les deux derniers constituent des problèmes liés à l’état d’exécution plutôt que de nouvelles autorisations.

Supposons à présent que la tâche s’étende légitimement à l’environnement de production. La démarche appropriée consiste en une nouvelle proposition concrète, évaluée au regard de la politique de production par une autorité compétente. Copier l’identifiant d’approbation précédent dans une tâche de plus grande envergure masquerait la modification. Un agent compétent peut préparer la preuve nécessaire à la prochaine décision sans considérer la décision précédente comme un mandat l’obligeant à mener à bien tout ce qu’il estime être la volonté ultime de l’utilisateur.

Empêcher un lot de se multiplier à partir d’une autorisation restreinte

Un ensemble d’actions acceptables prises individuellement peut dépasser la limite globale approuvée. Supposons qu’une politique en vigueur autorise un déploiement de petite envergure et que deux collaborateurs constatent chacun qu’il leur reste la même part inutilisée avant de soumettre leurs demandes. Il ne suffit pas de vérifier chaque demande par rapport à la limite initiale si leur effet combiné la dépasse. Il s’agit là d’un problème de concurrence mis en évidence, et non d’un défaut constaté dans une plateforme d’orchestration particulière.

Il convient de préciser si la limite approuvée s’applique par requête, par tâche, par ressource ou à l’échelle d’une campagne entière. Lorsqu’il s’agit d’une limite agrégée, la mise en œuvre nécessite une comptabilité coordonnée ou un mécanisme de réservation. Un utilisateur ne doit pas pouvoir obtenir un nouveau quota simplement en créant un nouvel identifiant de tâche. L’enregistrement de l’approbation doit relier le budget à l’identité fiable de la tâche et à l’unité pertinente sur le plan opérationnel.

Une exécution partielle complique la gestion. Libérer une réservation après un délai d’expiration peut permettre la poursuite du traitement, même si la première action a déjà eu lieu. Conserver indéfiniment chaque réservation incertaine peut empêcher une reprise légitime. Résolvez ce compromis grâce à un rapprochement faisant autorité des résultats et à un processus d’exception explicite. Enregistrez quelle capacité est engagée, encore réservée ou en attente de résolution. Ces états permettent à une personne autorisée de décider de la suite à donner sans considérer un échec ambigu comme une autorisation de recommencer.

Testez le contrat séparément du planificateur

Je commencerais par envoyer des requêtes délibérément modifiées directement à un harnais d’exécution contrôlé. Je modifierais un champ significatif à la fois, j’utiliserais une révision obsolète, je substituerais un réviseur non autorisé et j’exécuterais la même opération simultanément. Cela permet de vérifier si la frontière rejette les actions non valides sans compter sur le modèle pour les générer par hasard. Enregistrez les effets réels et le travail utile autorisé, et pas seulement les messages d’erreur.

Testez ensuite l’ensemble du flux de travail de l’agent avec des entrées adversaires et ordinaires. InjecAgent évalue les agents intégrés à des outils à partir d’un état hypothétique faisant suite à un appel utilisateur-outil et utilise des réponses simulées de l’outil pour certaines parties de son évaluation du vol de données (Zhan et al., 2024, §2.3). Cela rend l’outil utile pour étudier les actions induites, mais ne permet pas de déterminer le comportement de votre service d’approbation en temps réel ni de la transaction en aval. Utilisez ses catégories de menaces sans vous approprier les taux de réussite qu’il rapporte.

AgentDojo fournit des environnements d’outils avec état et vérifie la conformité des objectifs de l’utilisateur et de l’attaquant par rapport à l’état de l’environnement (Debenedetti et al., 2024, §3). Cette approche permet ici d’établir une distinction utile : le planificateur peut proposer une action non autorisée tandis que l’exécuteur parvient à en bloquer l’effet. À l’inverse, un agent qui n’effectue jamais aucune tâche peut éviter des effets néfastes tout en échouant dans l’exécution de la tâche légitime. Veuillez rendre compte séparément du comportement proposé, du confinement et de l’achèvement utile.

Intégrez l’interface humaine dans le test. L’évaluateur est-il capable d’identifier une cible modifiée, de comprendre une défaillance significative et de rejeter la requête sans déclencher accidentellement une exécution de secours ? Le rapport d’audit permet-il d’établir un lien entre la révision affichée et la requête effective ? Il s’agit là de critères d’acceptation locaux, et non de résultats définis par les références citées. Les tests doivent porter sur les outils, les politiques et les chemins de reprise réels, et leur conclusion doit indiquer quelles variantes n’ont pas été examinées.

Veillez à ce que la limite reste exploitable et précisez ce qu’elle ne peut pas prouver

La principale objection réside dans le fait que des autorisations strictes peuvent alourdir le travail des agents utiles. Exiger un nouveau clic pour chaque étape interne anodine mobiliserait inutilement l’attention sans pour autant améliorer nécessairement la prise de décision. Je réserverais l’approbation individuelle aux effets significatifs clairement définis et j’utiliserais une politique permanente délimitée pour les tâches courantes. Une politique permanente doit néanmoins préciser l’ensemble des ressources concernées, ses limites et ses conditions d’invalidation ; elle ne doit pas être déguisée en approbation ponctuelle d’une transaction.

Une autre objection réside dans le fait qu’un réviseur malveillant ou inattentif puisse approuver une action inappropriée. Précision : la liaison préserve la relation entre la révision et l’exécution ; elle ne garantit pas la pertinence de la décision. Les actions sensibles peuvent nécessiter des preuves indépendantes ou une séparation des tâches. Aucun résumé, aucune extension OAuth ni aucun benchmark ne peut fournir le jugement que le processus n’a jamais obtenu.

Pour la question précédente concernant la manière d’empêcher que des instructions récupérées ne deviennent une source d’autorité, utilisez l’ Analyse de la frontière entre le document et l’action. Pour déterminer si l’autorisation temporaire prend effectivement fin, utilisez l’ Analyse de l’expiration de l’accès privilégié. Cet examen d’approbation porte sur une décision différente : déterminer si l’effet reste dans les limites d’une autorisation humaine spécifique, y compris après des modifications et des défaillances.

La méthode combinée reste une proposition d’ingénierie. Son efficacité dépend d’une mise en œuvre intégrale, de dossiers protégés, de schémas corrects, d’une identité fiable et d’un comportement cible pris en charge. Les sources établissent des mécanismes individuels et des contextes de recherche historiques, et non la garantie de ce déploiement. Si vous avez besoin de cette preuve, demandez un examen des limites d’approbation par un Agent d'IA. Fournissez un flux de travail validé et les actions des outils qui en découlent ; je peux vous aider à identifier ce qui est réellement approuvé, où une substitution est possible et quels tests d’acceptation permettraient de justifier cette affirmation.