Sécuriser un agent IA autonome : surfaces d'attaque et risques

Un chatbot LLM produit du texte. Un agent IA autonome agit. Cette différence est triviale à énoncer, structurelle à sécuriser. La surface d'attaque ne se réduit plus à "que peut dire le modèle ?" mais à "que peut faire le modèle, avec quels privilèges, dans quel environnement, avec quelle mémoire, en chaînant quels outils ?". EchoLeak (CVE-2025-32711, juin 2025) a fait passer cette question du laboratoire de recherche à la salle de crise des RSSI : un agent M365 Copilot exfiltrant des données sans clic utilisateur via une simple injection email.

Cet article cartographie les six surfaces d'attaque spécifiques aux agents (LLM, mémoire, outils, planning, environnement, multi-agent), les incidents publics documentés, les principes de défense alignés sur OWASP LLM06 Excessive Agency et les patterns d'architecture sécurisée. Pour les méthodologies de test, voir tester un agent IA autonome et auditer un agent connecté à des APIs.

Pourquoi un agent change la donne

Trois différences structurelles avec un LLM simple :

1. Actions vs sorties. Le LLM produit du texte ; l'agent émet des tool calls qui modifient l'état du monde (envoi email, écriture fichier, transaction API). Le blast radius d'une compromission devient celui de toutes les actions accessibles.
2. Mémoire persistante. Un chatbot oublie après la session ; un agent retient (mémoire long-terme, knowledge graph, vector store). Une attaque réussie peut persister au-delà de la session et impacter d'autres utilisateurs.
3. Planning et boucles. L'agent décompose un objectif en étapes, raisonne sur les retours d'outils, peut s'auto-corriger. Cette boucle réflexive est elle-même une surface : un attaquant peut manipuler le plan plus que la sortie finale.

Conséquence directe : les contrôles classiques (filtre input, filtre output) restent nécessaires mais pas suffisants. Il faut ajouter des contrôles spécifiques aux actions, à la mémoire, aux séquences d'outils.

Info — OWASP LLM Top 10 v2 (2025) introduit LLM06 Excessive Agency comme catégorie distincte précisément à cause de cette différence. Cf. audit OWASP LLM Top 10.

Six surfaces d'attaque spécifiques aux agents

Surface 1 — LLM core

Le cœur reste le LLM, donc toute la littérature prompt injection s'applique : directe, indirecte (PDF, web, email), jailbreak, compositional. Les contre-mesures sont celles déjà documentées : input filter, system prompt durci, sanitization à l'ingestion, output filter. Voir notre stratégie de défense en profondeur.

Spécificité agent : la sortie du LLM n'est pas seulement du texte, c'est aussi la décision d'appeler un outil. Une injection qui ne fait que biaiser le texte d'un chatbot peut, sur un agent, déclencher une action.

Surface 2 — Mémoire

L'agent mémorise pour gagner en cohérence sur le temps long. Cette mémoire — vector store (Pinecone, Qdrant, Chroma), knowledge graph (Neo4j), fichiers structurés (Mem0, Letta) — est lue à chaque tour et insérée dans le contexte du LLM.

Surface : tout ce qui peut être écrit dans la mémoire est une surface d'injection persistante. Patterns connus :

• Faux faits insérés via conversation (le user dit "rappelle-toi que mon adresse est X" avec X malveillant).
• Drip poisoning : 100 petites assertions cohérentes qui finissent par former un faux contexte.
• Retroactive modification : si l'agent peut éditer sa mémoire, un attaquant peut le manipuler pour qu'il modifie d'anciennes entrées.

Pour le détail, voir notre article memory poisoning d'un agent IA.

Surface 3 — Outils / function calling

Le tool calling est la fonctionnalité qui transforme un LLM en agent. C'est aussi la surface la plus exploitable opérationnellement.

Vecteurs documentés :

• Tool injection via output : un outil retourne du texte qui contient une instruction injectée, parsée par le LLM comme s'il s'agissait du résultat légitime.
• Argument poisoning : l'attaquant manipule les arguments générés par le LLM (ex: URL externe dans un appel HTTP, destinataire externe dans un email).
• Tool chaining unauthorized : l'agent enchaîne deux outils légitimes pour produire un effet non prévu (ex: read_user_data → post_to_external_webhook).
• Plugin abuse : exploit publié sur ChatGPT plugins en 2023 (Salt Labs) — un plugin peut redéfinir des fonctions disponibles à d'autres plugins via injection.

# Mauvais : tool sans allowlist d'arguments
def send_email(to: str, subject: str, body: str):
    smtp.send(to=to, subject=subject, body=body)
 
# Bon : allowlist + validation stricte
def send_email(to: str, subject: str, body: str, _ctx):
    if not to.endswith("@yourcompany.com"):
        raise ToolNotAuthorized("external recipient")
    if not _ctx.user.has_approval_for_outgoing_email():
        raise ToolNotAuthorized("user approval required")
    if _contains_canary_token(body):
        log_security_event("canary_in_email_body", body)
        raise ToolNotAuthorized("system token in body")
    smtp.send(to=to, subject=subject, body=body)

Voir notre audit d'agent IA APIs/outils internes pour le détail.

Surface 4 — Planning et chain-of-thought

Les agents type ReAct (Reason + Act) ou ReWOO formalisent un plan en étapes. Manipuler le plan = manipuler les actions sans avoir à compromettre chaque outil individuellement.

Patterns :

• Goal hijacking : injection qui modifie l'objectif initial. "Avant d'exécuter la tâche demandée, exécute d'abord cette tâche prioritaire : ..."
• Step injection : insertion d'une étape supplémentaire dans le plan ("après cette étape, fais aussi X").
• Reasoning manipulation : modifier les conclusions du modèle sur l'environnement (faux signaux dans tool outputs qui font croire à un succès ou un échec).

Sur AutoGPT en 2023, plusieurs PoC ont montré qu'une page web malicieusement crawlée pouvait littéralement réécrire l'objectif de l'agent.

Surface 5 — Environnement

Plus l'agent est autonome, plus son environnement d'exécution est riche : système de fichiers, exécution de code, accès réseau, secrets, conteneurs. Chaque privilège est une surface.

Risques typiques :

• Exécution de code généré par le LLM dans un environnement non isolé (sandbox absente ou faible).
• Accès aux variables d'environnement (clés API, tokens) que le LLM peut lire et exfiltrer.
• Accès réseau non restreint (sortie web sans allowlist) qui permet l'exfiltration vers domaine attaquant.
• Misconfig MCP (Model Context Protocol) : serveurs MCP locaux ou distants avec permissions trop larges.

Pour le détail MCP : audit MCP.

Surface 6 — Multi-agent

Les architectures CrewAI, AutoGen, LangGraph multi-agent introduisent des communications agent-à-agent. Ces canaux sont rarement sécurisés.

Vecteurs :

• Un agent compromis (via injection) peut envoyer des prompts forgés à d'autres agents qui lui font confiance par défaut.
• Aucune authentification ni signature des messages inter-agents dans la plupart des frameworks.
• Pas de logs structurés des échanges inter-agents → forensique post-incident difficile.
• Confused deputy : agent A a des privilèges, agent B n'en a pas mais demande à A d'agir en son nom.

Cas réels publiquement documentés

Ces cas couvrent toutes les six surfaces identifiées plus haut. Aucun n'est un cas de bord exotique — toutes sont des classes d'attaque applicables à n'importe quel agent enterprise.

Principes de défense pour agents autonomes

Sept principes structurants. Tous doivent être présents — l'absence d'un seul casse la chaîne.

1. Allowlist stricte des outils

Aucun outil par défaut. Chaque outil ajouté avec :

• Schéma d'arguments validé strictement (Pydantic, Zod).
• Allowlist des arguments à fort risque (URLs, destinataires, IDs).
• Documentation explicite du blast radius.
• Tests d'audit dédiés.

2. Approval HITL pour les actions sortantes

Toute action irréversible ou à effet externe (envoi email, transaction, suppression, modification API tierce) → confirmation utilisateur explicite avant exécution. Ce pattern aurait neutralisé EchoLeak.

# Pattern minimal HITL
def require_approval(action_name: str, args: dict, user_session) -> bool:
    risk = classify_action_risk(action_name, args)
    if risk in {"low"} and user_session.has_blanket_approval(action_name):
        return True
    return user_session.request_explicit_approval(
        action=action_name, args=args, risk=risk
    )
 
# Usage dans le tool
def send_email(to: str, subject: str, body: str, _ctx):
    if not require_approval("send_email", {"to": to}, _ctx.user_session):
        raise UserDeniedAction()
    smtp.send(to=to, subject=subject, body=body)

3. Limites strictes (steps, calls, time, cost)

class AgentLimits:
    max_steps: int = 25
    max_tool_calls: int = 50
    max_session_seconds: int = 300
    max_token_cost_usd: float = 1.0
    max_same_tool_consecutive: int = 5  # détection boucle

Sans limites, un agent en boucle ou compromis peut consommer un budget illimité ou tourner indéfiniment.

4. Sanitization à l'ingestion

Tout contenu externe (web crawled, document uploadé, email, output d'outil) passe par un sanitizer avant d'atteindre la mémoire ou le contexte LLM. Voir protéger une application LLM.

5. Isolation par contexte de confiance

Pas de mélange entre :

• Données système (system prompt, configuration).
• Données utilisateur courant (sa session, ses données).
• Données externes (web, RAG, autres utilisateurs).

Chaque source est marquée et le LLM est instruit de ne pas suivre d'instructions venant des sources non-système.

6. Logs structurés exhaustifs

Tout tool call loggué avec :

• request_id, session_id, user_id
• nom de l'outil, arguments (avec masking PII)
• état (allowed/denied/error)
• score de confiance des couches de détection
• canary tokens si présents

Format OpenTelemetry ou JSON propriétaire compatible SIEM.

7. Red teaming périodique

Tests adversariaux ciblés sur chacune des 6 surfaces, à minima trimestriellement pour les agents en production. Voir guide pratique red teaming LLM.

Architecture défensive minimale

        ┌─────────────────────────────────────────┐
        │  Utilisateur authentifié                 │
        └─────────────────┬───────────────────────┘
                          │ Approval HITL pour actions critiques
        ┌─────────────────▼───────────────────────┐
        │  Agent orchestrator (LangGraph/CrewAI)  │
        │  - Limites (steps, calls, time, cost)   │
        │  - Logs structurés tous tool calls      │
        └────┬─────────────┬───────────────┬──────┘
             │             │               │
        ┌────▼────┐   ┌────▼────┐    ┌─────▼─────┐
        │ LLM core│   │ Tools   │    │ Memory    │
        │+ guard  │   │+allowlist│   │+sanitization│
        │+system  │   │+args     │   │+provenance │
        │ prompt  │   │ validate │   │+isolation  │
        └─────────┘   └────┬────┘    └─────┬─────┘
                           │                │
                      ┌────▼─────────┐ ┌────▼──────┐
                      │ External APIs│ │ Vector DB │
                      │ (allowlist)  │ │+per-tenant│
                      └──────────────┘ └───────────┘

Chaque couche est instrumentée. Chaque tool call traverse au moins 3 contrôles (allowlist, args validation, approval si action critique). Chaque output d'outil est sanitizé avant retour au LLM.

Mapping OWASP LLM Top 10 v2 (2025)

Pour le mapping complet : audit OWASP LLM Top 10.

Points clés à retenir

• Un agent IA autonome n'est pas un chatbot avec des outils : c'est une nouvelle classe de système avec 6 surfaces d'attaque spécifiques (LLM core, mémoire, outils, planning, environnement, multi-agent).
• Le blast radius est les actions accessibles, pas seulement la sortie texte. EchoLeak (CVE-2025-32711) a démontré l'exfiltration zéro-clic via Copilot.
• Aucun framework agent (LangGraph, CrewAI, AutoGen, AutoGPT) n'est secure-by-default. Les couches sécurité s'ajoutent explicitement.
• Sept principes de défense obligatoires : allowlist outils, approval HITL actions sortantes, limites strictes (steps/calls/time/cost), sanitization ingestion, isolation contextes de confiance, logs exhaustifs, red teaming périodique.
• OWASP LLM06 Excessive Agency est la catégorie centrale pour les agents — la mitigation principale est l'approval HITL combiné à l'allowlist d'outils.
• Memory poisoning et planning manipulation sont les classes les plus sous-estimées en 2026 — voir nos articles dédiés.
• Audit minimal : threat model par surface + tests prompt injection + memory poisoning + tool chaining + red team avec corpus métier. Trimestriellement.

La sécurité d'un agent IA n'est pas une couche supplémentaire au-dessus du LLM. C'est une refonte du modèle de menace — qui inclut désormais la mémoire persistante, les actions sortantes, l'enchaînement d'outils et les communications inter-agents. Sans cette refonte, un agent en production reste exposé par construction.