Les annonces de Google des 15 et 16 septembre 2026 et le projet ACS d'OWASP éclairent un problème de délégation : vérifier un accès, autoriser une opération et repérer une dérive ne protègent pas au même moment. Cette différence devient décisive lorsqu'un agent peut modifier des données ou déclencher un paiement.
Un agent de service client peut appeler le bon outil, transmettre un montant valide et annoncer un remboursement avec une réponse impeccable. L'opération peut pourtant contrevenir aux règles de l'entreprise. Si son habilitation se limite à lui donner accès au service de remboursement, elle ne précise pas nécessairement quels produits il peut rembourser, dans quelles circonstances ni avec quelle validation.
Le problème ne commence donc pas au moment où l'agent « se trompe ». Il commence lorsque l'entreprise lui confie une capacité d'exécution sans définir assez précisément le mandat qui l'accompagne.
Le contrôle doit porter sur l'opération proposée
Dans une démonstration publiée le 15 septembre, Google met en scène un agent chargé des retours clients. Une demande de remboursement de 120 dollars pour une licence logicielle ne contient ni instruction manifestement hostile ni paramètre mal formé. Mais la politique de l'entreprise exige l'accord d'un responsable pour ce type de remboursement au-delà de 30 dollars.
La solution présentée intercale un moteur de politiques entre l'agent et l'exécution. Celui-ci examine l'appel proposé, ses paramètres, la demande de l'utilisateur et l'historique de la conversation à la lumière des règles métier. Le refus intervient avant le versement. Le contrôle ne demande plus seulement si le compte de l'agent peut appeler cet outil, mais si cette opération précise entre dans son mandat.
Cette décision doit être appliquée hors du seul discours de l'agent. Lui rappeler une consigne dans ses instructions et lui donner un outil capable de passer outre ne produit pas le même contrôle qu'un refus effectivement imposé au point d'exécution. Google place ici l'application des politiques au niveau de sa plateforme, sous la responsabilité d'un administrateur distinct du développeur de l'agent.
Le recours à un modèle de langage pour interpréter ces politiques n'est toutefois pas une nécessité universelle. Si la catégorie du produit, le montant et l'accord du responsable sont des données structurées fiables, une règle déterministe peut trancher. L'interprétation sémantique peut aider lorsque le contexte doit être compris ; elle ne justifie pas de remplacer un plafond comptable vérifiable par l'appréciation d'un modèle.
Une alerte peut arriver après le paiement
Le scénario Google se poursuit avec plusieurs petits remboursements. Pris séparément, ils passent les contrôles ; additionnés, ils dépassent le montant de la commande. Il faut alors examiner une séquence, pas seulement la dernière demande.
C'est le terrain d'Agent Anomaly Detection, dont Google a annoncé la Private Preview le 16 septembre. Le service analyse les journaux et traces d'exécution de manière asynchrone, en dehors du traitement de la requête en cours. Une première couche repère des anomalies statistiques, puis une analyse par modèle examine les sessions signalées. Une intégration peut récupérer les résultats et bloquer des appels ultérieurs.
Ce fonctionnement explique à la fois son intérêt et sa limite : détecter une séquence anormale ne garantit pas d'empêcher sa première opération dommageable. Le contrôle préalable décide si l'action peut partir ; la surveillance peut révéler ce que ce contrôle n'a pas su reconnaître. Bloquer la suite réduit éventuellement le dommage, sans annuler les versements déjà effectués.
Il serait d'ailleurs trompeur d'en conclure que tout dépassement cumulé exige une IA de détection. Si le cumul des remboursements d'une commande est une contrainte connue, nous recommandons de la faire respecter dans le système qui tient les transactions. La détection comportementale apporte un autre regard sur les séquences ; elle ne dispense pas d'appliquer les invariants métier disponibles.
La disponibilité compte aussi. Au 23 septembre, la documentation Google réserve l'accès aux utilisateurs approuvés, avec activation explicite et prérequis techniques. Elle impose notamment la capture du contenu des entrées et sorties ainsi que des espaces de stockage des journaux et de l'observabilité en région US. Pour une équipe européenne, ce sont des conditions d'architecture et de traitement des données à examiner, pas le détail d'une fonctionnalité déjà accessible à tous.
Un standard n'est pas un dispositif prêt à l'emploi
Le projet Agent Control Standard, présenté par l'OWASP GenAI Security Project le 1er septembre, aborde une autre pièce du problème : comment permettre à des environnements d'agents différents de solliciter et d'appliquer des contrôles communs pendant leur exécution.
ACS définit un contrat d'échange entre l'agent observé et un composant de contrôle appelé « Guardian ». À des points prévus du déroulement, par exemple avant un appel d'outil, l'agent soumet l'action envisagée. Le contrôle peut l'autoriser, la refuser, la modifier, demander une approbation ou différer sa décision. Le projet prévoit une couche déterministe en premier ; la délégation à un modèle de langage reste facultative. Un « gardien » n'est donc pas nécessairement un deuxième modèle chargé de juger le premier.
Il faut cependant distinguer ce contrat de sa réalisation. Le README du projet, dans sa révision du 10 septembre, documente sans détour les limites de l'implémentation de référence : son canal n'est pas authentifié et son comportement par défaut laisse l'exécution continuer lorsque le contrôle échoue ou devient indisponible. C'est le mode fail-open. Seuls deux points de contrôle y sont évalués en direct. Le composant permettant d'exporter les traces au format OpenTelemetry vers les outils d'observabilité n'est pas encore fourni.
Ces limites décrivent cette implémentation de référence à cette date, pas une obligation ni une propriété de tout système conforme au standard. Elles rendent surtout visible l'écart entre une spécification, une démonstration qui bloque une commande et un dispositif sur lequel une entreprise peut réellement s'appuyer. Pour une opération sensible, la question n'est pas seulement « le contrôle sait-il refuser ? », mais « l'exécution reste-t-elle maîtrisée quand ce contrôle ne répond plus ? ».
Une trace ne révèle pas une intention
La surveillance soulève enfin une difficulté de lecture. Dans son annonce, Google parle d'analyse d'intentions suspectes et accompagne les alertes d'explications. Une explication plausible peut aider un analyste ; elle ne transforme pas l'intention en fait directement observable.
Chez Maple Labs, notre analyse des conversations avec les assistants IA distingue les traces accessibles, l'interprétation que nous en tirons et les mécanismes internes auxquels nous n'avons pas accès. Cette distinction permet ici de lire une alerte sans lui demander plus qu'elle ne peut établir.
Un journal peut montrer qu'un agent a demandé plusieurs remboursements, avec quels paramètres et quelles réponses du service. Pour établir ce qui a réellement été versé, il faut rapprocher ces traces de l'état des transactions. Le caractère inhabituel de la séquence peut ensuite être étayé par une comparaison. En revanche, conclure à une volonté de contourner les règles demande une interprétation du contexte : un abus, une relance après incident ou une mauvaise gestion des reprises ne se confondent pas.
La justification produite par un modèle de détection est elle-même un résultat à examiner, pas un accès au raisonnement caché de l'agent surveillé. Nous en déduisons une exigence simple : une alerte utile doit permettre de retrouver les opérations concernées et les éléments qui fondent le diagnostic. Sa formulation assurée ne suffit pas.
La vraie preuve se trouve au point d'exécution
Pour évaluer un agent qui agit, la démonstration décisive ne consiste donc pas seulement à lui faire réussir un remboursement. Elle consiste aussi à lui soumettre une opération hors mandat, à rejouer une série dont le cumul devient interdit et à rendre le contrôle indisponible. L'entreprise doit pouvoir constater ce qui est bloqué avant effet, ce qui exige une approbation et ce qui ne sera découvert qu'ensuite.
Le choix dépend de l'action : continuer une lecture en cas de panne n'engage pas les mêmes conséquences que poursuivre des versements. Cette décision doit appartenir au responsable du processus et être traduite dans le système, non improvisée par l'agent au moment du problème.
Un accès technique ouvre une possibilité. Un mandat en fixe les limites. La capacité réelle à déléguer se mesure à l'endroit où ces limites continuent de s'appliquer, y compris lorsque l'agent insiste ou que son contrôleur tombe en panne.