Le blog sécurité de FireAI

Par FireAI Security & Research Team · Publié

Surveiller les connexions réseau de Cursor sur Mac : la sécurité des agents IA

Surveiller les connexions réseau de Cursor sur Mac : la sécurité des agents IA

Cursor est un éditeur de code assisté par IA développé par Anysphere, Inc. Outre la complétion de code, son agent peut exécuter des commandes shell dans un terminal, et l’éditeur maintient des connexions ouvertes avec le backend de Cursor pour les requêtes, les mises à jour et sa place de marché d’extensions. Cet article résume ce que Cursor documente sur ses modes d’exécution, sa sandbox macOS et les hôtes qu’il utilise, puis montre comment observer les connexions de l’éditeur avec FireAI.

Ce qu’est Cursor

La page sécurité de Cursor décrit le produit comme un éditeur de code fondé sur l’IA et indique que l’application envoie des requêtes aux domaines du backend de Cursor pour fournir les fonctions d’API, de mise à jour et de place de marché. Elle documente aussi un Privacy Mode qui empêche l’entraînement de modèles sur vos données et qui est disponible sur les offres gratuites comme payantes. Le Privacy Mode est une politique relative au traitement des données que Cursor reçoit. Il ne change pas les hôtes auxquels l’éditeur se connecte.

Ce que l’agent peut faire et comment il est encadré

La documentation de Cursor indique que l’agent exécute des commandes shell dans le terminal, selon un comportement défini par les réglages Run Mode. Il existe trois modes :

  • Auto-review exécute les appels connus comme sûrs, isole les commandes shell dans une sandbox lorsque c’est possible et soumet tout le reste à l’examen d’un classificateur.
  • Allowlist n’exécute que des actions fiables et préapprouvées.
  • Run Everything exécute toutes les commandes sans demande, ce que la documentation considère comme l’option la plus risquée.

Sur macOS, la documentation indique que Cursor isole les commandes avec Seatbelt et sandbox-exec, en restreignant l’accès aux fichiers, la connectivité réseau et le comportement des processus dans toute l’arborescence des sous-processus. Cela nécessite Cursor v2.0 ou une version ultérieure et ne demande aucune configuration supplémentaire sur les installations de bureau. Dans la sandbox, le réseau est limité aux domaines d’une liste d’autorisation sandbox.json lorsque ce fichier est utilisé seul ; par défaut, cette liste est combinée avec les domaines intégrés de Cursor pour les gestionnaires de paquets et les outils de développement.

Une sandbox de ce type restreint les commandes lancées par l’agent. L’éditeur lui-même, qui communique avec les serveurs de Cursor, s’exécute hors de ce périmètre : ses propres connexions ne sont donc visibles qu’au niveau du réseau.

Les hôtes documentés par Cursor

La page de configuration réseau de Cursor liste les domaines utilisés par l’éditeur. Ceux que documente l’éditeur du logiciel sont les suivants :

Source : documentation de Cursor, configuration réseau. Cursor indique utiliser par défaut le streaming bidirectionnel HTTP/2, avec un repli sur les Server-Sent Events en HTTP/1.1, et TLS 1.2 ou supérieur pour toutes les connexions.
HôteUsage documenté
api2.cursor.shLa plupart des requêtes d’API
api5.cursor.sh et des sous-domaines d’agent comme agent.api5.cursor.shRequêtes de l’agent de Cursor
Passerelles api3.cursor.sh, api4.cursor.sh et *.gcpp.cursor.shRequêtes Cursor Tab (HTTP/2 uniquement)
repo42.cursor.shRecherche dans la base de code (HTTP/2 uniquement)
authenticate.cursor.sh, authenticator.cursor.shPoint de terminaison d’autorisation et webview de connexion
marketplace.cursorapi.com, cursor-cdn.com, downloads.cursor.comPlace de marché et mises à jour

Comme Cursor documente un ensemble stable de domaines qui lui sont propres, une connexion de l’éditeur vers un hôte situé hors de cet ensemble, et hors des gestionnaires de paquets et des sites avec lesquels vous travaillez, est le type d’événement qui mérite un second regard. Ce n’est pas en soi la preuve d’un problème : les extensions, les serveurs MCP et les commandes que vous approuvez ont tous leurs propres destinations.

Pourquoi une vue réseau reste utile

Les modes d’exécution déterminent ce que l’agent peut faire. Ils ne fournissent pas de trace des connexions établies ensuite par la machine. Avec Run Everything, par exemple, aucune demande n’apparaît, et c’est alors le réseau qu’il faut observer. Voir aussi les articles consacrés à Claude Code et à Windsurf, qui traitent d’outils similaires.

Surveiller Cursor avec FireAI

FireAI est un pare-feu pour macOS conçu par HisnLabs. Depuis la version 1.0.2, il dispose d’une fonctionnalité appelée Profil d’agent. Elle reconnaît 19 agents IA, apprend où chacun se connecte habituellement et signale les comportements inhabituels pour que vous les examiniez. Cursor est reconnu par sa signature de code.

Cursor fait partie des trois agents que FireAI vérifie par rapport à la signature de code de leur éditeur : une correspondance repose donc sur davantage qu’un nom.

FireAI reconnaît aussi les processus enfants de l’agent, comme un shell, git ou curl lancés par celui-ci, en remontant la chaîne des processus parents jusqu’à l’agent. Ces connexions sont donc comptabilisées comme celles de l’agent lui-même.

Ce que FireAI signale

  1. Pendant les 3 premiers jours, FireAI apprend les destinations que l’agent contacte habituellement, regroupées par domaine. Rien n’est signalé pendant cette période d’apprentissage.
  2. Ensuite, toute destination jamais contactée et située hors de la base de référence apprise est signalée pour examen.
  3. Un pic d’envoi est également signalé : une heure au cours de laquelle l’agent a envoyé au moins 4 fois le volume de son heure la plus chargée jusque-là, et jamais moins de 25 Mo.

Le Profil d’agent n’utilise que des métadonnées, à savoir les noms d’hôte et les volumes en octets. FireAI ne lit jamais le contenu d’une connexion et ne peut pas lire l’intérieur d’une connexion chiffrée.

Configurer FireAI pour Cursor

  1. Installez FireAI et terminez la configuration, puis continuez à utiliser Cursor comme d’habitude. La période d’apprentissage de 3 jours repose sur ce que FireAI observe.
  2. Ouvrez Suggestions et consultez la carte Agents IA. Elle liste les agents que FireAI a reconnus et ce qu’il a appris sur chacun d’eux.
  3. Lorsque Cursor atteint une destination qu’il n’a jamais contactée, le signalement apparaît dans la carte Agents IA et dans la Revue rapide. Glissez vers la gauche pour bloquer, ou vers la droite pour « C’est bon ».
  4. Bloquer crée une règle visant le processus qui s’est connecté. « C’est bon » ajoute la destination à la base de référence de l’agent, qui ne sera plus signalée.
  5. Si vous souhaitez cantonner l’agent aux destinations qu’il utilise déjà, choisissez Profil d’agent dans le menu des modes de sécurité, à côté de Maison, Café, Parano et Sous attaque. Une fois l’apprentissage de l’agent terminé, une connexion vers une destination hors de sa base de référence est bloquée au lieu d’être signalée.
  6. Une destination bloquée apparaît dans la carte Agents IA avec Autoriser et Garder bloqué. Autoriser l’ajoute à la base de référence et l’agent peut l’atteindre immédiatement. Garder bloqué crée une règle de blocage, de sorte que la destination reste bloquée dans tous les modes.

Limites

  • FireAI n’empêche pas l’injection de prompt. Un prompt dissimulé dans une page web ou un fichier peut toujours orienter un agent. Ce que FireAI peut faire, c’est signaler, et vous permettre de bloquer, le chemin par lequel les données quitteraient votre Mac.
  • FireAI ne voit ni les prompts, ni le contenu des outils MCP, ni les fichiers que lit Cursor, comme ~/.ssh. TLS masque le contenu, et FireAI ne se trouve pas à l’intérieur de l’agent.
  • Les processus enfants qui se terminent très rapidement peuvent échapper à la détection, et ils sont identifiés par leur chemin, non par leur signature.
  • Pendant la période d’apprentissage de 3 jours, rien n’est signalé.
  • En mode Profil d’agent, une connexion vers une adresse IP nue, sans nom d’hôte, est identifiée par son adresse. Si un service que l’agent utilise habituellement répond depuis une nouvelle adresse, celle-ci est bloquée jusqu’à ce que vous l’autorisiez.
  • L’explication en langage clair que FireAI donne d’un signalement est rédigée à partir des faits qu’il a mesurés. Elle ne qualifie jamais une destination de sûre ou de dangereuse. La décision vous appartient.

Guides associés

La même approche s’applique aux autres agents que FireAI reconnaît : Claude Code, l’application de bureau Claude, l’application ChatGPT pour Mac, Codex CLI, OpenClaw, Hermes Agent, Gemini CLI, GitHub Copilot CLI, Amp, Qwen Code, opencode, Aider, Goose, Crush, Windsurf, Kiro, Trae, Muse de Meta, tout autre agent IA exécuté par Python ou Node. La description complète de la fonctionnalité figure dans la documentation du Profil d’agent.

Le rôle de FireAI et de HisnLabs

L’agent de Cursor peut exécuter des commandes. FireAI montre où votre Mac se connecte pendant qu’il travaille.

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.

Sources