Le contexte de vos agents IA est une surface d'attaque

Il y a quelques mois, l'équipe sécurité d'un acteur bancaire de premier plan a découvert une anomalie dans les logs de son agent de support documentaire. L'agent avait traité une demande client contenant un document PDF apparemment anodin — un contrat type. Sauf que ce document comportait, en texte blanc sur fond blanc, une instruction destinée à l'agent : extraire les paramètres de configuration de la base documentaire et les inclure dans la prochaine réponse de synthèse. L'agent avait obéi. Personne n'avait rien vu.

Le vecteur d'attaque n'était pas le modèle de langage. Ce n'était pas le code de l'application. C'était le contexte — ce que l'agent lisait, consommait et répercutait comme vérité de travail.

Cette situation n'est pas une projection catastrophiste. Elle est la formalisation d'une tension que les équipes d'ingénierie commencent à nommer publiquement : à mesure que les agents IA gagnent en mémoire persistante, en capacité d'ingérer des données externes et en autonomie d'action, le contexte qu'on leur fournit devient à la fois leur carburant opérationnel et leur principale surface d'attaque. L'OWASP LLM Top 10, le CDLC de Patrick Debois, et l'architecture d'identité publiée par les équipes d'Uber Engineering en mai 2026 convergent vers le même diagnostic : le contexte nécessite audit, contrôle d'accès et gouvernance — exactement comme le code.

Cet article se concentre sur le contexte comme vecteur, non sur le code produit par les agents. Pour la revue du code généré, voir Agentic Coding et sécurité : quand l'agent pousse du code en production.

Le paradoxe de la mémoire persistante : ce qui rend les agents puissants les rend vulnérables

Comprendre pourquoi le contexte est une surface d'attaque commence par comprendre pourquoi la mémoire persistante est à la fois indispensable et risquée.

L'architecture en 3 tiers décrite par Vassil Vasilopoulos — et adoptée comme cadre structurant dans le Context Engineering — décompose la mémoire des agents en trois niveaux distincts¹ :

• Hot Memory (Tier 1) : toujours chargée, elle contient les conventions, les règles de comportement et la « culture d'entreprise » de l'agent. C'est le CLAUDE.md, le system prompt, les instructions permanentes.
• Warm Memory (Tier 2) : les experts invoqués à la demande. 50% de faits, peu de directives. Elle définit quels agents spécialisés peuvent être mobilisés et dans quel cadre.
• Cold Memory (Tier 3) : le savoir de référence massif — specs, documentation, bases de connaissance — tiré uniquement au besoin.

Patrick Debois, inventeur du DevOps et fondateur de Tessl, résume la condition de l'agent en une formule qui éclaire structurellement le problème : « Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir. »¹²

Le paradoxe est précisément là. Pour qu'un agent soit efficace — pour qu'il ne reparte pas de zéro à chaque session — il faut lui fournir un contexte riche, structuré et persistant. Une étude de 283 sessions d'agents montre que l'infrastructure contextuelle représente désormais 24,2% de la documentation totale d'un projet outillé.¹ Dans une session type, les lectures de fichiers de contexte représentent ~96% des tokens consommés.³

Mais ce même contexte riche — celui qui rend l'agent productif — est aussi ce qui l'expose. Plus la mémoire est persistante, plus une modification malveillante persiste. Plus la Cold Memory est étendue, plus la surface d'ingestion de données externes est large. Et plus l'agent est autonome, plus les conséquences d'un contexte compromis sont silencieuses et difficiles à tracer.

Un contexte pauvre = agent inutile. Un contexte riche mal gouverné = vecteur d'attaque silencieux. C'est le paradoxe structurel de l'architecture agentique.

Anatomie des trois vecteurs d'attaque du contexte

La formulation de la slide 10 du deck Context Engineering de Didier Girard (SFEIR, 2026-03) est directe : « Surface d'attaque — Le contexte nécessite audit et contrôle d'accès. C'est une faille potentielle. » Derrière cette formule, trois vecteurs distincts méritent d'être distingués — car les mécanismes de défense ne sont pas les mêmes.

Injection de contexte : quand le document devient le prompt

L'injection de prompt directe — où l'attaquant modifie le message envoyé à l'agent — est un vecteur connu et relativement facile à filtrer. L'injection indirecte est plus insidieuse : l'instruction malveillante arrive via un document, une page web, un fichier PDF ou une entrée de base de données que l'agent ingère dans son contexte de travail.

La recherche Magentic Marketplace publiée par Microsoft en novembre 2025 a testé six stratégies de manipulation d'agents dans un environnement de marketplace simulé — 100 agents acheteurs, 300 agents vendeurs.⁴ Parmi les stratégies testées : dubious claims, injections de prompt overt, informations trompeuses. La grande majorité des modèles testés a cédé à au moins une de ces stratégies. Un seul modèle a montré une résistance totale à toutes les tentatives.

Ce résultat est contre-intuitif : ce n'est pas le modèle en lui-même qui résiste — c'est l'architecture d'entraînement et la façon dont le contexte est traité par le modèle qui déterminent la robustesse. Et cette robustesse est variable selon le modèle et selon la nature de l'injection.

Ce risque n'a rien de théorique : l'OWASP le place en tête de son Top 10 des vulnérabilités des applications LLM. L'entrée LLM01 (Prompt Injection) décrit explicitement l'injection indirecte — celle qui arrive par des sources externes, sites web ou fichiers, dont le contenu interprété par le modèle « altère son comportement de manière inattendue ».⁷ Autrement dit : la première vulnérabilité référencée du domaine est précisément une vulnérabilité du contexte.

Exfiltration via la Knowledge Base

Le deuxième vecteur est plus difficile à détecter : l'exfiltration via la Cold Memory. Un agent autorisé à écrire dans la base de connaissance — pour mettre à jour une documentation, ajouter un résumé de session, enrichir une fiche produit — peut, après injection de contexte malveillant, écrire des données sensibles dans des emplacements a priori anodins.

Le canal est particulièrement furtif pour deux raisons. D'abord, les écritures en base documentaire sont rarement loguées avec le même niveau de détail que les appels API. Ensuite, la nature même de la Cold Memory — un savoir massif, hétérogène, mis à jour en continu — rend les modifications anormales difficiles à détecter sans audit spécifique.

Ce mécanisme d'exfiltration est inféré de l'architecture 3 tiers (Vasilopoulos) et du problème de perte de provenance documenté par Uber — aucun cas précis documenté publiquement identifié à ce stade.

Patrick Debois souligne que sans versioning du contexte, les modifications de la Cold Memory sont non auditables par construction.² La phase « Distribuer » du CDLC traite le contexte comme un package versionné précisément pour permettre la traçabilité de chaque modification.

Empoisonnement de la Hot Memory

Le troisième vecteur est le plus durable : si un attaquant parvient à modifier la Hot Memory — le system prompt, les règles de comportement, le CLAUDE.md — l'effet est permanent sur toutes les sessions suivantes, sans nécessiter de nouvelle injection.

La slide 9 du deck DG formule une observation qui prend ici une dimension de sécurité directe : « Le contexte pourrit. Comme le code, le contexte entre en conflit et devient obsolète. Une spec périmée est pire que pas de spec : elle induit l'agent en erreur activement. »¹

Ce qui vaut pour la spec périmée vaut, a fortiori, pour la spec délibérément empoisonnée. Un agent dont la Hot Memory a été modifiée agira de façon incorrecte à chaque session, de façon cohérente, sans signal d'alerte évident — car il suit ses règles, qui ont été altérées.

Le problème de provenance : quand les agents perdent le fil

Ces trois vecteurs partagent une propriété commune : ils sont difficiles — souvent impossibles — à tracer après coup. Et cette difficulté de traçabilité n'est pas un bug à corriger : c'est une propriété structurelle des architectures agentiques actuelles.

Les équipes Uber Engineering ont documenté le problème avec précision dans un article publié le 21 mai 2026 : « Execution context (originating user, intermediate agents) is dropped across agent hops. »⁵

Le diagnostic est structurel, pas accidentel. Les modèles d'identité classiques — humain ou workload — ne capturent pas l'agency telle que définie par Uber : « an entity that is authorized to act for or in the place of another. » Trois propriétés des workflows agentiques ne sont pas modélisées par le modèle d'identité classique :

• La délégation est le mode par défaut — les agents agissent pour le compte de quelqu'un.
• Les workflows sont compositionnels — des agents appellent d'autres agents qui appellent des outils.
• Le comportement est dynamique — les plans évoluent selon les résultats intermédiaires.

Conséquence opérationnelle : dans une chaîne user1 → Agent A → Agent B → outil externe, si la provenance est perdue après le premier hop, l'audit est lacunaire, les politiques d'accès fine-grained ne peuvent pas être appliquées de façon cohérente, et la responsabilité en cas d'incident est intraçable.

Debois formule le corollaire depuis la perspective du contexte : des fenêtres de contexte infinies ne résolvent pas le problème de gouvernance — elles transforment le défi de la curation en défi de gouvernance, potentiellement plus complexe.² Plus le contexte est grand, plus les contradictions et les modifications malveillantes sont difficiles à détecter.

Pour les équipes soumises à des contraintes réglementaires fortes — institutions financières, opérateurs de santé, infrastructures critiques —, ce problème de traçabilité n'est pas académique. Il conditionne la capacité à répondre à un incident, à prouver la conformité, ou à démontrer qu'une décision automatisée n'a pas été influencée par un contexte compromis.

Le contexte traité comme dépendance logicielle : la bonne analogie

Si le contexte est une surface d'attaque, comment le gouverner ? L'analogie proposée par la slide 10 du deck DG est la plus opérationnelle : « Le contexte se traite comme une dépendance logicielle (npm/maven). »¹

L'analogie n'est pas rhétorique — elle est architecturale. Personne ne déploie une dépendance npm sans la versionner, sans scanner ses vulnérabilités, sans vérifier son intégrité cryptographique. Ces pratiques — qui ont mis des années à se normaliser dans l'écosystème logiciel — sont précisément ce qui manque au contexte des agents aujourd'hui.

Patrick Debois formule explicitement le parallèle : le contexte comme surface d'attaque nécessite la même posture de sécurité de la chaîne d'approvisionnement que les dépendances.² Le CDLC (Context Development Lifecycle) — défini autour de quatre phases : Générer, Évaluer, Distribuer, Observer — est précisément le cycle d'ingénierie qui manque pour traiter le contexte avec la rigueur d'une dépendance.

La phase « Distribuer » du CDLC est particulièrement pertinente ici : traiter le contexte comme un package versionné, c'est rendre chaque modification traçable, chaque version comparable, chaque régression détectable. C'est l'équivalent du lock file pour les dépendances logicielles — sans lui, on ne sait pas ce qu'on déploie.

L'analogie s'étend à la gouvernance : sans ownership explicite, le contexte pourrit — comme la documentation, l'infrastructure et la sécurité avant lui. Le Context Flywheel de Debois (2026-02-26) identifie trois piliers de cet ownership : la maintenance (revue de fraîcheur, résolution de conflits), l'enablement (contribution facilitée via CLI et évaluations en CI), et la gouvernance (seuil de qualité, détection de conflits, politiques de dépréciation).⁶

Ce qui distingue un contexte gouverné d'un contexte non gouverné n'est pas la richesse du contenu — c'est l'existence d'une chaîne de confiance vérifiable. Pour aller plus loin sur l'architecture de la dépendance contextuelle, voir CDLC : le contexte comme dépendance logicielle et Architecture 3 tiers : Hot, Warm et Cold Memory.

Cinq leviers de gouvernance du contexte

Nommer la surface d'attaque n'est pas une fin en soi. Voici cinq leviers concrets, ordonnés par facilité de mise en œuvre et par impact sur la réduction de la surface d'attaque.

1. Auditer le contexte comme on audite le code

Le premier levier est le plus simple à formuler — et le moins souvent appliqué. Un contexte qui n'est pas audité régulièrement est une dette technique opaque : on ne sait pas ce qu'il contient, ce qui a changé, ni pourquoi.

L'audit du contexte suit la même logique que l'audit du code : chaque modification de la Hot Memory (system prompt, règles de comportement) doit être revue par un humain. Chaque ajout à la Cold Memory doit être validé avant ingestion. La phase « Observer » du CDLC de Debois ferme la boucle : les agents en production signalent les lacunes par leurs questions inattendues et leurs comportements hors-spec.² Ces signaux sont de l'audit automatisé — si on les lit.

2. Contrôle d'accès différencié par tier

Les trois tiers de l'architecture n'ont pas la même sensibilité. La Hot Memory — règles de comportement, contraintes permanentes — doit être en lecture seule pour les agents en production. Seuls des acteurs humains authentifiés peuvent la modifier. La Warm Memory — agents spécialisés, règles d'orchestration — doit être sous contrôle de version strict. La Cold Memory — données de référence, documentation — doit distinguer clairement les segments en lecture seule des segments éditables, et loguer toutes les écritures.

La vision long terme d'Uber est un Three-Layer Framework : (1) Identity & Trust Foundation, (2) Dynamic Access Control avec human-in-the-loop, (3) Unified Enforcement Plane.⁵ L'idée centrale est que les permissions ne peuvent pas être binaires dans un environnement agentique : elles doivent être contextuelles — accordées en fonction de qui demande, pour qui, dans quel workflow, avec quelle provenance.

3. Versioning et signature du contexte

L'analogie npm/maven impose ses contraintes opérationnelles : chaque version du contexte doit être identifiable, chaque modification tracée, chaque déploiement signé. Ce n'est pas un défi technologique — les outils existent (Git, des pipelines CI/CD, des registres d'artefacts). C'est un défi organisationnel : décider que le contexte est un artefact de première classe, soumis aux mêmes pratiques que le code.

La doctrine SPIFFE/SPIRE — adoptée par Uber pour les identités workload — illustre le principe : des identités cryptographiquement signées, vérifiables à chaque hop. Le même principe s'applique au contexte : une version signée du contexte est une version dont l'intégrité peut être vérifiée à tout moment.⁵

4. Évaluations continues : les evals comme tests de sécurité

La phase « Évaluer » du CDLC transpose le TDD au contexte : on définit le comportement attendu, on l'exécute, on observe l'écart. Debois formule la conséquence : « Un échec d'évaluation n'est pas un défaut de l'agent, c'est une spécification non écrite. »¹²

La dimension sécuritaire est directe : une évaluation qui teste le comportement de l'agent face à des inputs malveillants — injections, documents corrompus, instructions contradictoires — est un test de sécurité du contexte. « You wouldn't ship code without tests. Why would you ship context without evaluations? » (Debois, 2026-02-19)

Pour les équipes qui déploient des agents en production, les évaluations de sécurité du contexte devraient faire partie du pipeline CI/CD — au même titre que les tests d'intégration. Pour la méthodologie complète, voir Maintenir le contexte par les évaluations.

5. Actor chain : préserver la provenance à travers les hops

Le cinquième levier est le plus technique — et peut-être le plus important à l'échelle de la flotte d'agents. La doctrine Uber est directe : « Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. »⁵

Le principe : chaque saut dans une chaîne d'agents nécessite un nouveau token, valide pour une destination unique, avec une durée de vie de quelques minutes. En cas de vol, le blast radius est minimal. En cas d'audit, la chaîne complète des acteurs — l'actor chain — est vérifiable à chaque point du workflow. Le walkthrough documenté par Uber illustre le résultat : la chaîne user1 → Oncall Agent → Investigation Agent → MCP Gateway transporte l'actor chain [user1, oncall-agent, investigation-agent], permettant des décisions d'accès tool-level basées sur l'historique complet de la requête.

La performance est documentée en production : P99 de latence pour l'API d'échange de tokens inférieure à 40 millisecondes.⁵ La sécurité par défaut et la fluidité développeur ne sont pas incompatibles.

L'approche multi-agents et la gestion de la mémoire inter-sessions sont approfondies dans Context Engineering pour systèmes multi-agents.

Ce que SFEIR observe : intégrer la sécurité dans le Context Engineering, pas en couche additionnelle

La tentation est forte d'aborder la sécurité du contexte comme un chantier à part — une couche additionnelle à ajouter après coup sur une architecture déjà déployée. C'est généralement la mauvaise approche.

Chez SFEIR, l'expérience accumulée sur le Context Engineering — à travers des déploiements d'agents dans des secteurs aux contraintes réglementaires fortes — indique que la gouvernance du contexte est plus simple à intégrer en amont qu'à corriger après coup. Deux raisons principales.

D'abord, les décisions d'architecture du contexte — qui peut écrire dans la Hot Memory, quels agents ont accès à quelle partie de la Cold Memory, comment les versions sont gérées — sont des décisions d'architecture tout court. Les prendre tôt coûte peu ; les revisiter coûte cher.

Ensuite, la formule de Debois mérite d'être prise au sérieux dans sa dimension de sécurité : « Pour la première fois, partager la connaissance sert directement l'intérêt de l'auteur. » Le même alignement d'incitations s'applique à la sécurité du contexte : un contexte bien gouverné — versionné, audité, avec des accès différenciés — est un contexte qui améliore la performance de l'agent, pas seulement sa sécurité. La sécurité et la productivité du contexte ne sont pas en tension. Elles partagent les mêmes pratiques.

La slide 17 du deck DG le résume : « Le contexte est un actif, pas une dépense. » Un actif mal gouverné perd de la valeur et accumule du risque. Un actif bien gouverné s'apprécie dans le temps — c'est l'effet volant d'inertie du Context Flywheel de Debois.

Points clés

Le contexte est une surface d'attaque à trois vecteurs distincts. L'injection de contexte (via documents ingérés), l'exfiltration via la Cold Memory (base de connaissance), et l'empoisonnement de la Hot Memory (system prompt, CLAUDE.md) ne se défendent pas avec les mêmes mécanismes. Les distinguer est le prérequis d'une gouvernance efficace.

La richesse du contexte et sa vulnérabilité sont corrélées. Un agent sans contexte persistant est inutile. Un agent avec un contexte riche et non gouverné est un vecteur d'attaque silencieux. Le paradoxe est structurel — la réponse est la gouvernance, pas la réduction du contexte.

La provenance disparaît à travers les hops d'agents. L'audit est impossible sans traçabilité de la chaîne d'acteurs. L'architecture Uber (actor chain, single-hop short-lived tokens) est aujourd'hui la première implémentation de référence à l'échelle industrielle pour préserver cette traçabilité en production.

Le contexte se gouverne comme une dépendance logicielle. Versioning, signature, évaluations continues, contrôle d'accès différencié par tier : les pratiques existent dans l'écosystème du développement logiciel. Les appliquer au contexte n'est pas un chantier technologique — c'est un changement de posture organisationnelle.

La sécurité du contexte s'intègre, elle ne se rajoute pas. Les décisions d'architecture qui déterminent la surface d'attaque sont prises tôt dans le cycle de vie du système agentique. Les reprendre après coup coûte structurellement plus cher que de les prendre correctement dès la conception.

Sources

1. SFEIR — Context Engineering, matière first-party, mars 2026.
2. Patrick Debois, Context Development Lifecycle (CDLC) — tessl.io, 19 février 2026.
3. SFEIR — Tokens & SDLC v3, matière first-party, 2026.
4. Webb Wright, Microsoft researchers tried to manipulate AI agents — and only one resisted all attempts — zdnet.com, 6 novembre 2025.
5. Uber Engineering, Solving the Agent Identity Crisis — uber.com, 21 mai 2026.
6. Patrick Debois, The Context Flywheel — tessl.io, 26 février 2026.
7. OWASP, LLM01 — Prompt Injection, Top 10 for LLM Applications — genai.owasp.org, 2025.