Rupture de confiance dans les pipelines d'agents : « filtré » n'est pas « autorisé »

De quoi s’agit-il ?

Une conférence prévue à Black Hat USA 2026, le 5 août 2026 — Trusted Enough to Run: Breaking AI Agents in Official Workflows, présentée par Elad Meged de Novee Security — signale une catégorie de défaillance que les auteurs appellent rupture de confiance à la transmission (trust-handoff failure), et affirme qu’elle se retrouve simultanément dans des workflows d’agents bâtis sur des systèmes d’Anthropic, de Google et d’OpenAI. Selon le descriptif publié par Novee (27 juin 2026) et une analyse indépendante (juillet 2026), la faiblesse ne tient pas à un bug d’un modèle particulier, mais à une propriété structurelle des pipelines d’agents multi-étapes.

Les détails techniques complets sont attendus lors de la conférence. Ce qui a été décrit publiquement, c’est la forme du problème : une étape du workflow marque une donnée comme sûre au regard de son propre modèle de menace, puis une étape suivante consomme cette même donnée avec davantage d’autorité que le contrôle précédent ne l’avait jamais anticipé. Pas de 0-day, pas d’identifiant volé, aucune action de l’utilisateur au-delà du fonctionnement normal de l’agent. Cet article traite du schéma rapporté et de ses défenses ; nous y reviendrons lorsque le matériel complet sera public.

Comment ça marche

Les « workflows » d’agents modernes sont des pipelines. Une étape de navigation ou de récupération importe du contenu externe, une étape de filtrage ou de modération le contrôle, une étape de planification décide de l’action, et une étape d’action appelle un outil. Chaque étape est écrite au regard d’un modèle de menace local — ce qu’elle a précisément pour mission d’attraper.

La défaillance rapportée vit dans les coutures entre ces étapes. Une étape de filtrage peut légitimement conclure « ce texte ne contient aucun motif d’injection que je surveille » et transmettre sa sortie, implicitement marquée comme propre. Le problème est que « propre » a été défini par rapport à la mission de cette étape. Lorsqu’une étape d’action ultérieure traite la même sortie comme suffisamment fiable pour autoriser un appel d’outil, elle a silencieusement promu « a passé un filtre » en « approuvé pour agir » — un sens que le filtre n’a jamais attribué.

Frontière d'étape où la confiance est silencieusement promue
------------------------------------------------------------
[browse]  -> contenu externe importé                (non fiable)
[sanitize]-> « aucun motif d'injection surveillé »  (propre *pour cette étape*)
[plan]    -> traite le texte filtré comme fiable    (promotion implicite)
[act]     -> appelle un outil dessus                 (désormais traité comme autorisé)

C’est un problème de frontière de confiance, pas de contenu : aucune chaîne malveillante qu’un filtre aurait pu attraper, car chaque étape a fait son travail. Le défaut, c’est que la frontière entre elles transporte la donnée, mais pas le niveau de confiance qu’elle mérite pour l’objectif de l’étape suivante. Ce cadrage rejoint la vision orientée systèmes de la synthèse de juin 2026 Toward Secure LLM Agents, qui modélise la sécurité des agents autour de l’interaction entre flux d’information, autorité déléguée et état persistant, plutôt qu’autour de bugs de composants isolés.

Pourquoi c’est important

Trois éléments méritent l’attention, même avant la conférence.

Premièrement, c’est multi-fournisseurs. Les auteurs signalent le même schéma chez Anthropic, Google et OpenAI, ce qui pointe une hypothèse d’architecture partagée par tous ceux qui construisent des agents multi-étapes, plutôt qu’une erreur d’un seul éditeur. Passer à un modèle « plus sûr » ne supprime pas une faille qui vit dans le câblage du pipeline.

Deuxièmement, il ne faut aucun déclencheur exotique. Si le constat tient, il suffit que l’agent exécute son workflow ordinaire. Cela le place dans la même famille que le trio létal : des capacités individuellement raisonnables qui ne deviennent dangereuses que lorsqu’elles partagent un contexte de confiance que personne n’a conçu explicitement.

Troisièmement, c’est difficile à détecter en test. Une passerelle qui n’inspecte que les prompts et les réponses — la configuration que Rein Security aurait défaite contre l’assistant d’achat d’un grand distributeur dans une autre conférence de Black Hat 2026 — n’a aucune visibilité sur ce que l’agent exécute réellement ; elle ne peut donc pas voir un niveau de confiance promu à une frontière interne. Des tests ponctuels qui vérifient chaque étape isolément passeront chaque étape et rateront quand même la couture.

Une réserve sur les sources : il s’agit d’une conférence à venir, et ce qui est public aujourd’hui, c’est le résumé et des synthèses de seconde main, pas la preuve de concept sous-jacente. Considérez les détails comme provisoires jusqu’à la publication de l’exposé et de tout support associé. La leçon d’architecture, elle, ne dépend pas de la démonstration.

Défenses

Le correctif que pointent les auteurs et les analystes est architectural, et il est disponible dès maintenant, indépendamment de l’exposé.

1. Attachez un niveau de confiance explicite à chaque charge utile qui franchit une frontière d’étape. Ne laissez pas la confiance être déduite de « ça vient de l’étape précédente ». Étiquetez la donnée avec son origine et son degré réel de vérification, et transportez cette étiquette à travers la frontière avec la donnée.

2. Faites appliquer par les étapes en aval une exigence minimale de confiance. Toute étape qui agit — appelle un outil, écrit dans un système, dépense de l’argent, exécute du code — doit refuser une entrée sous un seuil déclaré et échouer en mode fermé. Le filtrage n’est pas une promotion : passer un filtre d’injection ne rend pas un contenu autorisé à déclencher une action financière.

from enum import IntEnum

class Trust(IntEnum):
    UNTRUSTED = 0      # contenu web/e-mail/utilisateur brut
    SCREENED  = 1      # a passé un filtre — limité au modèle de menace DE CE filtre
    INTERNAL  = 2      # sortie d'un autre agent de la chaîne
    VERIFIED  = 3      # signé / approuvé par un humain / sous contrôle de source

def act(payload_trust: Trust, min_required: Trust) -> bool:
    # Les étapes d'action échouent en mode fermé sous leur minimum, quelle que soit la source.
    if payload_trust < min_required:
        raise PermissionError("[BLOQUÉ] garde-fou de rupture de confiance : "
                              f"{payload_trust.name} < {min_required.name}")
    return True

3. Alignez le modèle de menace de l’étape de filtrage sur l’usage aval, pas seulement sur sa propre mission. Si un filtre a été conçu pour attraper des chaînes d’injection de prompt, son verdict « propre » ne dit rien de la sûreté du contenu remis à un shell, à un outil SMTP ou à une API de paiement. Chaque surface de risque exige son propre contrôle.

4. Autorisez l’action, pas l’identité ni l’origine. Liez l’approbation à l’opération précise et à ses arguments concrets au moment de l’exécution, conformément au principe qui consiste à autoriser les étapes du workflow plutôt que l’identité de l’agent. Cela bloque directement la promotion « fiable parce que venu d’une étape interne ».

5. Instrumentez les coutures. Journalisez ce que chaque étape affirme de sa sortie et ce que l’étape suivante suppose, afin qu’une promotion silencieuse soit visible dans la télémétrie. C’est le manque d’observabilité derrière des défaillances d’autorité implicite sur les chemins d’erreur et de fenêtres time-of-check/time-of-use chez les agents.

6. Red-teamez vos propres frontières. Fournissez un contenu bénin pour le filtre de l’étape N mais dangereux pour l’outil de l’étape N+1, et vérifiez que le pipeline le bloque. S’il s’exécute, le défaut est dans votre câblage, pas dans le modèle.

Statut

Élément	Référence	Date	Notes
Trusted Enough to Run: Breaking AI Agents in Official Workflows	Conférence Black Hat USA 2026 (Elad Meged, Novee Security)	2026-08-05	À venir ; signale une rupture de confiance chez Anthropic, Google, OpenAI
Descriptif de la conférence	Novee Security	2026-06-27	Présentation du track et résumé
Analyse indépendante	The Agentic Protocol	2026-07	Cadrage défensif du schéma
Cadre systèmes	Toward Secure LLM Agents (SoK)	2026-06	Flux d’information, autorité déléguée, état persistant

L’enseignement utile n’attend pas l’exposé : dans un agent multi-étapes, « ceci a passé mon contrôle » et « ceci est autorisé pour ce que vous vous apprêtez à faire » sont deux affirmations différentes. Tant que chaque frontière ne transporte pas la première sans la promouvoir silencieusement en seconde, un filtre qui a fait son travail peut encore remettre à une étape d’action quelque chose qu’elle n’aurait jamais dû pouvoir exécuter.