Endpoint Detection and Response a passé deux décennies à répondre correctement à une question : ce processus fait-il quelque chose qu'un code malveillant ferait ? Il vérifie les signatures, surveille les comportements anormaux et signale toute élévation de privilèges non autorisée. Un agent d’IA ayant accès aux outils brise le principe de cette question, non pas en étant un code malveillant, mais en étant un programme de confiance qui peut être amené à abuser de son propre accès, tout à fait légitime.
La version pré-IA de ce problème a déjà un nom
Utiliser un programme légitime et signé pour faire quelque chose de malveillant n’est pas nouveau. MITRE ATT&CK le catalogue comme Exécution du proxy binaire système (T1218) : « les binaires signés avec des certificats numériques de confiance peuvent généralement s'exécuter sur des systèmes Windows protégés par une validation de signature numérique », ce qui explique exactement pourquoi les listes autorisées et les vérifications de signature ont du mal une fois que le binaire de confiance lui-même est la chose qui agit. Un agent IA étend la même faiblesse à un programme qui n’a pas du tout besoin d’être préchargé avec du code malveillant : il peut être redirigé au moment de l’exécution, par le texte qu’il lit.
Un agent détourné est un adjoint confus
Le terme applicable ici est problème d'adjoint confus : « un programme informatique trompé par un autre programme (avec moins de privilèges ou moins de droits) pour qu'il abuse de son autorité. » Donnez à un agent de vrais outils, puis laissez-le lire le contenu que vous n'avez pas vérifié, et il pourra être instruit par ce contenu. C'est exactement le modèle décrit par Entrée d'injection rapide de l'OWASP, et il a déjà été démontré, pas seulement théorisé : Rapport du 26 mai 2025 d'Invariant Labs a montré un agent de codage, lisant un problème GitHub d'apparence ordinaire dans un référentiel public, suivant des instructions cachées pour exposer les données d'un référentiel privé, en utilisant des outils qui lui ont été légitimement accordés. La propre conclusion des chercheurs : « il ne s’agit pas d’une faille dans le code du serveur GitHub MCP lui-même, mais plutôt d’un problème architectural fondamental qui doit être résolu au niveau du système d’agent. »
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.C’est là le véritable point mort : il ne s’agit pas d’une lacune dans un produit donné, mais du fait que les entrées du journal « l’agent a fait son travail normal » et « l’agent a été détourné pour abuser de son travail normal » peuvent être identiques au niveau du processus. Rien dans le binaire n’a changé. Rien dans le modèle d’appel système n’est nouveau. Seule l'intention derrière la demande a changé, et l'intention n'est pas un champ dans un journal de processus.
Qu'est-ce qui réduit réellement cela et qu'est-ce qui ne le réduit pas
Il vaut la peine d’être précis sur ce que recommande réellement la personne qui a nommé ce modèle. Simon Willison, qui a décrit le « tiercé trio mortel » de l'accès aux données privées, de l'exposition au contenu non fiable et de la communication externe réunis dans un seul agent, est explicite sur le fait qu'éviter cette combinaison est la véritable solution, et non un garde-fou supplémentaire : « la seule façon de rester en sécurité là-bas est d'éviter complètement cette combinaison mortelle du tiercé gagnant ». Il est ouvertement sceptique quant aux produits qui prétendent capturer de manière fiable les instructions injectées après coup, notant que « nous ne savons toujours pas comment empêcher cela de manière fiable à 100 % » et qu’un taux de capture de 95 % est « vraiment un échec » pour un contrôle de sécurité.
- Concevoir d'abord : donnez à un agent les outils et l'accès aux données les plus restreints dont sa tâche a besoin, de sorte qu'il y ait moins de risques d'abus pour une injection réussie (le correctif architectural pointé par Willison et Invariant Labs).
- Traitez en principe à chaque fois tout contenu lu par l'agent et que vous n'avez pas écrit ou vérifié, les problèmes, les pages récupérées, les fichiers téléchargés, comme une entrée non fiable.
- Là où la conception et la révision ne suffisent pas, la seule étape qu’une tentative d’exfiltration de données ne peut pas ignorer est la coupure de la connexion réseau. Surveiller ou restreindre cela, par processus, n'empêche pas un agent d'être trompé, mais il s'agit d'une couche réelle et indépendante qui ne dépend pas de la reconnaissance de l'instruction injectée en premier lieu.
Le rôle de FireAI et de HisnLabs
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
FireAI est le produit de HisnLabs : un pare-feu IA embarqué pour Mac. Il montre en langage clair chaque connexion faite par vos applications et vous laisse décider ce qui sort de votre Mac — son IA fonctionne en local, votre trafic ne nous est jamais envoyé, ni à personne d’autre. L’équipe de recherche en sécurité de HisnLabs est celle qui garde ces décisions fiables : elle recense les domaines de simple télémétrie face à ceux d’un vrai service, suit le pays et le réseau derrière une connexion, et entraîne le modèle embarqué (la fonction Autopilot) sur du trafic réel, sans que rien ne quitte votre Mac.
Vous pouvez lire les choix techniques qui s’y trouvent, ou essayer FireAI pendant 17 jours, sur FireAI, par HisnLabs.