Les deux listes OWASP consacrées à la sécurité des systèmes fondés sur des modèles de langage traitent la sortie de données hors du système comme une conséquence centrale : le Top 10 for LLM Applications 2025 classe la divulgation d’informations sensibles (Sensitive Information Disclosure) en LLM02 [2], et le Top 10 for Agentic Applications for 2026, publié le 9 décembre 2025, mentionne l’exfiltration dans huit de ses dix entrées [4]. Sur un Mac, cette exfiltration prend la forme d’une connexion réseau. FireAI 1.0.4 étend son Agent profile de trois agents reconnus à 19, y compris des agents qui s’exécutent dans node ou python ; cet article précise quels risques OWASP ce travail couvre et lesquels il ne couvre pas.
Contexte
Un agent d’IA sur un Mac s’exécute avec les autorisations du compte qui le lance. Il lit des fichiers, exécute des commandes shell et ouvre des connexions réseau, et il décide de la suite de ses actions à partir du texte qu’il lit, y compris un texte rédigé par un tiers. L’OWASP définit l’injection de prompt comme une vulnérabilité qui « survient lorsque des prompts utilisateur modifient le comportement ou la sortie du LLM de manière non voulue », et range « la divulgation d’informations sensibles » parmi ses conséquences [1].
FireAI est un pare-feu réseau. Il ne s’exécute pas à l’intérieur d’un agent et ne lit ni les prompts, ni les fichiers, ni le contenu des connexions chiffrées. Il voit en revanche quel programme ouvre chaque connexion, l’hôte de destination et le nombre d’octets envoyés [5]. Agent profile, introduit dans FireAI 1.0.2, s’appuie sur ces métadonnées pour apprendre où chaque agent se connecte habituellement, et signale une destination jamais contactée ou un envoi d’un volume inhabituel. Le mode de sécurité Agent profile, ajouté en 1.0.3, bloque toute nouvelle destination jusqu’à ce que l’utilisateur l’autorise [6].
Ce que décrit l’OWASP
Top 10 for LLM Applications 2025
- LLM01:2025 Prompt Injection. Le scénario d’exemple 2 décrit des instructions cachées dans une page web qui amènent un modèle à « insérer une image renvoyant vers une URL, ce qui conduit à l’exfiltration de la conversation privée » [1].
- LLM02:2025 Sensitive Information Disclosure. L’entrée cite « les informations personnelles identifiables (PII), les données financières, les dossiers médicaux, les données commerciales confidentielles, les identifiants de sécurité et les documents juridiques » comme informations en jeu [2].
- LLM06:2025 Excessive Agency. L’entrée fait remonter le risque à un excès de fonctionnalités, d’autorisations et d’autonomie ; dans son exemple, un e-mail entrant amène un agent à parcourir la boîte de réception de l’utilisateur et à transmettre des informations sensibles à l’attaquant [3].
Top 10 for Agentic Applications for 2026
- ASI01 Agent Goal Hijack : des instructions cachées dans des pages web ou des documents « redirigent silencieusement un agent pour exfiltrer des données sensibles ou détourner les outils connectés » [4].
- ASI02 Tool Misuse and Exploitation : des agents détournent des outils légitimes, « ce qui conduit à l’exfiltration de données, à la manipulation des sorties d’outils ou au détournement de flux de travail ». Les exemples comprennent un agent qui enchaîne des outils d’administration légitimes, dont cURL, pour envoyer des journaux sensibles vers l’extérieur, et un outil ping approuvé utilisé pour faire fuiter des données au moyen de requêtes DNS [4].
- ASI04 Agentic Supply Chain Vulnerabilities : parmi les exemples, un paquet npm compromis, installé automatiquement par des agents de programmation, qui « a exfiltré des clés SSH et des jetons d’API » [4].
- ASI05 Unexpected Code Execution : des commandes shell cachées dans un prompt et exécutées par l’agent, « entraînant un accès non autorisé au système ou une exfiltration de données » [4].
- ASI10 Rogue Agents : un agent qui continue d’envoyer des données vers l’extérieur après une injection de prompt indirecte ; la mesure d’atténuation proposée est une couche comportementale qui surveille les écarts, notamment « les tentatives inattendues d’exfiltration de données » [4].
Pour ASI02, la troisième mesure d’atténuation du document s’intitule Execution Sandboxes and Egress Controls et énonce : « Appliquer des listes d’autorisation sortantes et refuser toutes les destinations réseau non approuvées » [4]. La même entrée demande des profils de moindre privilège par outil, incluant des listes d’autorisation sortantes. Ce sont ces deux recommandations qu’un pare-feu réseau sur le Mac est en mesure d’appliquer.
Ce que FireAI 1.0.4 reconnaît
Les versions précédentes reconnaissaient Claude Code, l’application de bureau Claude et Cursor par leur signature de code, et ChatGPT et Codex par leur chemin. Les agents exécutés dans un environnement d’exécution de scripts n’étaient pas reconnus : pour le pare-feu, OpenClaw était node et Aider était python [5]. FireAI 1.0.4 lit les arguments des processus node, bun, deno et python pour identifier le script qu’ils exécutent, et ajoute 14 agents.
| Agent | Mode de reconnaissance par FireAI |
|---|---|
| Claude Code, Claude, Cursor | Signature de code avec l’identifiant d’équipe du développeur ; Claude Code également par son dossier d’installation |
| ChatGPT, Windsurf, Kiro, Trae, Goose, OpenClaw | Le paquet d’application à partir duquel le programme s’exécute |
| Muse de Meta | L’identifiant de signature de son application du Mac App Store |
| Codex, opencode, Crush, Goose, l’agent en ligne de commande de Cursor | Le nom du programme natif en ligne de commande |
| OpenClaw, Hermes Agent, Gemini CLI, GitHub Copilot CLI, Amp, Qwen Code, opencode, Aider, Codex, Claude Code | Le script exécuté par node, bun, deno ou python, ou le dossier dans lequel il est installé |
OpenAI décrit dots comme des agents qui s’exécutent sur leur propre ordinateur dans le cloud [8]. Leur trafic sur le Mac transite par l’application ChatGPT ; FireAI l’attribue donc à ChatGPT. Muse de Meta [9] est reconnu par son identifiant App Store.
La reconnaissance s’étend à ce qu’un agent lance. Lorsqu’un shell, git, curl ou un installateur de paquets ouvre une connexion, FireAI remonte la chaîne des processus parents, jusqu’à huit niveaux, jusqu’à atteindre un agent reconnu, et enregistre la connexion au nom de cet agent [5]. C’est le cas décrit par l’OWASP sous ASI02, où des outils légitimes comme cURL font sortir les données : l’outil est de confiance, mais son parent est un agent.
Les navigateurs web agentiques et les applications de terminal sont délibérément exclus. Tout leur trafic serait attribué à l’agent, et le mode Agent profile bloquerait alors la navigation ordinaire.
Correspondance entre les contrôles et les entrées OWASP
| Entrée OWASP | Contrôle FireAI | Ce qui reste hors de son champ |
|---|---|---|
| LLM01, ASI01 : des instructions injectées détournent l’agent | Une requête vers un hôte jamais contacté par l’agent est signalée, ou bloquée en mode Agent profile | L’injection elle-même ; les données envoyées vers une destination que l’agent utilise déjà |
| LLM02 : divulgation d’informations sensibles | Un pic d’envoi est signalé : une heure atteignant au moins 4 fois l’heure la plus chargée de l’agent, et jamais moins de 25 Mo | Les petites fuites, comme une seule clé ou un seul jeton ; FireAI ne peut pas déterminer si des données sont sensibles |
| LLM06 : agentivité excessive | Des règles par application limitent les destinations accessibles à chaque programme | Les messages envoyés via un service que l’agent est autorisé à utiliser, comme son fournisseur de messagerie |
| ASI02 : outils légitimes utilisés pour exfiltrer | Les processus enfants sont attribués à l’agent ; le mode Agent profile fonctionne comme une liste d’autorisation sortante apprise | Les données encodées dans des requêtes DNS : le DNS n’est jamais bloqué par le mode Agent profile |
| ASI04, ASI05 : un paquet ou une commande exécuté par l’agent | Les connexions issues du code que l’agent exécute sont signalées ou bloquées comme celles de l’agent lui-même | Le code qui s’exécute plus tard, hors de l’agent, relève à la place des règles ordinaires par application |
| ASI10 : un agent qui continue d’envoyer des données | Chaque agent dispose d’une référence ; les écarts sont signalés par une phrase en langage courant | Le comportement appris pendant les 3 premiers jours est intégré à la référence |
Le signalement décrit les faits mesurés par FireAI, par exemple qu’un agent n’a jamais contacté un serveur auparavant et lui a envoyé 40 Mo. Lorsque le modèle d’IA local est activé, il reformule ces faits en une phrase. Il ne juge pas si une destination est sûre ; la décision revient à l’utilisateur [5].
Les autres entrées de la liste 2026, Identity and Privilege Abuse (ASI03), Memory and Context Poisoning (ASI06), Insecure Inter-Agent Communication (ASI07), Cascading Failures (ASI08) et Human-Agent Trust Exploitation (ASI09), portent sur ce qui se passe à l’intérieur des agents et entre eux. Un pare-feu réseau sur le Mac n’en voit les conséquences que lorsqu’elles aboutissent à une connexion.
Recommandations
- Laisser chaque agent fonctionner normalement pendant ses 3 premiers jours, afin que sa référence reflète le travail ordinaire plutôt qu’un essai d’un nouvel outil.
- Consulter régulièrement la carte Agents d’IA dans Suggestions. Une destination contactée pour la première fois juste après que l’agent a lu une page web, un e-mail ou un dépôt inconnu correspond au schéma décrit par l’OWASP sous ASI01.
- Pour un agent qui travaille sur du code ou des documents sensibles, passer au mode de sécurité Agent profile, afin que les nouvelles destinations soient bloquées jusqu’à autorisation [6].
- Tenir les secrets hors de portée de l’agent. FireAI voit où vont les données, pas leur nature, et ne peut pas récupérer des données déjà envoyées vers une destination autorisée.
- Pour un agent que FireAI ne nomme pas, écrire une règle pour le programme sous lequel il s’exécute [7].
Pertinence pour FireAI
FireAI applique le volet sortant des recommandations de l’OWASP sur le Mac lui-même : une liste d’autorisation par agent, apprise plutôt que rédigée à la main, avec un signalement ou un blocage en cas de dépassement. Il fonctionne uniquement à partir des métadonnées de connexion, et rien de l’activité de l’utilisateur ne quitte le Mac. Il n’empêche pas l’injection de prompt, n’inspecte pas ce qu’un agent envoie et ne remplace ni le sandboxing, ni les identifiants à moindre privilège, ni l’approbation humaine des actions à fort impact, que les documents de l’OWASP recommandent également.
Limites
- FireAI reconnaît les 19 agents énumérés ci-dessus, et non tous les agents. Tout autre programme, agent ou non, relève des invites de connexion ordinaires et des règles par application de FireAI, mais ne dispose d’aucune référence et ne déclenche aucun signalement propre aux agents.
- La reconnaissance par chemin ou par nom de script sert d’étiquette pour la référence, non de preuve d’identité. Un programme peut reprendre le nom de dossier d’un autre agent. Seuls Claude Code, Claude et Cursor sont vérifiés par rapport à l’identifiant d’équipe de leur développeur ; l’identifiant d’équipe de Muse n’a pas encore été vérifié sur une copie installée.
- Un processus enfant qui se termine en un dixième de seconde environ peut avoir disparu avant que FireAI ne remonte ses parents ; sa connexion n’est alors pas attribuée à l’agent.
- Pendant les 3 premiers jours, rien n’est signalé, et tout ce que fait l’agent durant cette période devient normal pour lui.
- Les destinations sont regroupées par domaine. Les données envoyées vers un nouveau serveur d’un domaine que l’agent utilise déjà, ou vers un service partagé comme un hébergeur de code, ne sont pas signalées.
- FireAI ne peut lire ni les prompts, ni le contenu des outils MCP, ni les skills, ni le trafic chiffré, et ne voit pas quels fichiers un agent ouvre.
- La correspondance ci-dessus constitue la lecture des documents de l’OWASP par HisnLabs. L’OWASP n’a ni examiné ni approuvé FireAI.
Le rôle de FireAI et de HisnLabs
Un agent sur votre Mac peut être détourné par une instruction cachée. FireAI montre, et peut bloquer, la destination suivante de ses données.
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 FireAI Pilot) 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.