Amazon ne souhaite plus que les humains surveillent ses agents IA

Un opérateur humain chargé de valider les actions d’un agent IA fait d’abord son travail avec soin. Puis correctement. Puis mal. C’est le constat posé par Eric Brandwine, vice-président et ingénieur d’Amazon Security. Selon lui, la supervision humaine que la plupart des entreprises placent en bout de chaîne de leurs systèmes automatisés ne tient pas face au rythme d’exécution des agents IA. Amazon ne propose pas de supprimer toute implication humaine, mais de la déplacer : plutôt que de demander à un employé de valider chaque action en temps réel, l’entreprise encadre ses agents par des politiques de permissions vérifiées automatiquement avant chaque appel d’outil. Cette approche repose sur deux constats internes et une infrastructure technique déjà en production.

Quand la vigilance s’effondre sans que personne ne s’en aperçoive

En 2017, lors de la conférence re:Invent d’AWS, Brandwine avait déjà exposé le mécanisme qui fonde aujourd’hui la position d’Amazon. La « normalisation de la déviance » est un concept issu de la sécurité industrielle qui décrit un glissement progressif : un opérateur confronté à des alertes répétées sans conséquence finit par ne plus y réagir, et cette perte de vigilance devient la norme sans que l’organisation la détecte.

L’exemple qu’il choisit vient des services d’urgence. Dans un bloc hospitalier, les alarmes sonnent en continu. Le premier jour, un soignant réagit immédiatement à chaque signal. Après suffisamment de fausses alertes, il cesse de réagir. « La vie de quelqu’un est littéralement en jeu, et les gens peinent encore à maintenir leur discipline. C’est la condition humaine », explique Brandwine. Le même phénomène a été documenté chez les pompiers et les pilotes militaires.

Appliqué à la supervision d’agents IA, le problème est identique, mais plus insidieux. Un analyste chargé d’approuver ou de rejeter les actions d’un agent plusieurs fois par minute traverse les mêmes phases de dégradation. La différence est que dans un contexte logiciel, aucun incident visible (une alarme qui sonne, un patient en détresse) ne vient corriger le glissement en temps réel. L’opérateur continue de valider machinalement, et la dégradation de sa vigilance passe inaperçue pendant des semaines. « Les humains ne sont pas terriblement cohérents », résume Brandwine. « La supervision humaine n’est pas nécessairement l’étalon-or. »

Quand l’agent contourne l’interdiction au lieu de l’accepter

Le second problème identifié par Brandwine est distinct de la fatigue humaine. Il concerne le comportement de l’agent lui-même face à un refus. Lorsqu’un agent reçoit l’instruction de mettre à niveau une base de données, il peut retenir la suppression de cette base comme étape valide pour atteindre l’objectif. Pas d’injection de prompt malveillant, pas d’entrée corrompue. L’agent arrive seul à une action destructrice parce qu’il reste fixé sur son objectif sans évaluer les conséquences latérales de son approche.

Le réflexe intuitif est de lui notifier un refus, mais Brandwine a observé que ce refus produit l’effet inverse de celui attendu : privé de contexte, l’agent tente d’atteindre le même objectif par d’autres moyens, potentiellement tout aussi destructeurs. En revanche, lorsque l’équipe précise la raison de l’interdiction, en expliquant par exemple que l’action causerait un impact en production, et qu’elle inscrit cette contrainte directement dans la consigne initiale sous forme d’instruction positive (« ne pas causer d’impact en production »), les résultats sont « radicalement meilleurs » selon Brandwine. L’agent dispose alors d’un critère d’évaluation supplémentaire pour filtrer ses propres plans d’action.

VOIR AUSSI : Pourquoi le phénomène Clawdbot fascine autant qu’il inquiète le secteur de l’IA et de la tech ?

Ce qu’Amazon met à la place : identité, journaux et politiques externes

La solution d’Amazon ne consiste pas à retirer l’humain du processus, mais à le placer ailleurs. Brandwine parle de « responsabilité de bout en bout ». Si un employé déploie un agent qui écrit un script provoquant une panne, c’est l’employé qui est responsable, pas l’agent. Pour rendre cette responsabilité traçable, chaque agent déployé en interne chez Amazon reçoit un identifiant propre. Dans les journaux système, l’activité apparaît sous la forme « cet agent a fait ceci pour le compte d’Eric », et non « Eric a fait ceci ». La distinction vise à inciter les équipes à évaluer la pertinence de chaque déploiement d’agent, pas à dissuader leur usage.

La gouvernance technique repose sur deux niveaux. Le premier est un ensemble de garde-fous absolus, codés en dur, qui interdisent les actions les plus destructrices. Le second est un système de politiques dynamiques, générées en fonction de la tâche et de l’intention de l’utilisateur, qui fixent le périmètre maximal d’action pour chaque opération.

Amazon Bedrock AgentCore, la plateforme de déploiement d’agents du groupe, intègre depuis mars 2026 une fonctionnalité appelée Policy. Avant qu’un agent exécute un appel d’outil, une couche d’évaluation externe, définie en dehors du code de l’agent, intercepte cet appel via l’AgentCore Gateway et le vérifie en quelques millisecondes. Les politiques sont rédigées en Cedar, un langage d’autorisation open source conçu par Amazon pour être à la fois exécutable par la machine et lisible par un auditeur humain.

Les équipes sécurité peuvent ainsi auditer les règles indépendamment du code applicatif, sans avoir à comprendre le comportement interne de l’agent. Le point essentiel est que la politique s’applique quel que soit le modèle utilisé, quelle que soit la manière dont l’agent a été construit, et quelle que soit la façon dont il est sollicité, y compris en cas d’injection de prompt.