roobriefL’actualité IT pour les développeurs

Dev et versions

Les commandes des agents Cursor peuvent tourner sur des machines d'entreprise, mais le contrôle de vulnérabilités tourne dans le cloud Cursor

Les appels d’outils des agents cloud peuvent rester sur des machines d’entreprise, mais le contenu des fichiers que le modèle lit pour répondre ne reste pas forcément dans l’entreprise.

Cursor a ouvert deux fonctions entreprise en septembre. Le 2 septembre, il a annoncé Self-Hosted Machines, qui déplacent les modifications de fichiers et l’exécution de commandes des agents d’IA en cloud (des programmes qui accomplissent seuls des tâches en plusieurs étapes pour l’utilisateur) vers des ordinateurs que l’entreprise possède. Le 23 septembre, il a ouvert Security Review sur les offres Teams et Enterprise. Security Review cherche des bugs exploitables dans les pull requests (un changement de code proposé, à relire avant de l’intégrer).

Design Mode, qui permet de cliquer des éléments à l’écran pour les faire corriger, et Agent Tabs, qui montrent plusieurs chats côte à côte dans l’éditeur, ne font pas partie de ces sorties de septembre. Design Mode est apparu avec Cursor 3 le 2 avril ; la sélection multiple et la voix ont été ajoutées le 5 juin. Agent Tabs figure aussi dans le journal du 2 avril.

Pointer des éléments à l’écran et les confier à l’agent

Design Mode s’utilise dans le navigateur de la Agents Window, pas dans un navigateur web ordinaire. Sur Mac, on l’allume et l’éteint avec Cmd+Shift+D. La documentation ne donne pas de raccourci Windows.

Un clic sur un élément envoie cet élément et le code derrière à l’agent. Depuis le 5 juin, on peut en sélectionner plusieurs et demander par exemple de « faire correspondre celui-ci à celui-là », ou dicter la modification suivante. Le micro reste ouvert pendant que les agents travaillent. Encadrer une zone place la marque sur une image figée, pour que l’agent parte de la scène vue.

Deux signaux partent pour un élément choisi : où il se trouve et quel composant c’est (chemin, nom, attributs, styles calculés, props), et une capture du layout autour. Quand la modification est faite, l’application redessine sans tout recharger. Cursor recommande son modèle Composer 2.5 pour ce flux.

La fenêtre multi-agents et les onglets de l’éditeur sont différents

La Agents Window est un écran à part, disponible pour tous depuis le 2 avril. Dans l’éditeur, Cmd+Shift+P puis Open Agents Window l’ouvre. On y voit les agents locaux, cloud et SSH distant (travailler en se connectant à un autre ordinateur) au même endroit, et on peut en lancer plusieurs en parallèle dans le cloud. Pour revenir à l’ancien éditeur, choisir Open IDE dans la même liste. Pendant deux semaines après le lancement, les admins Enterprise pouvaient limiter l’accès ; ce délai est passé.

Les Agent Tabs dans l’éditeur figurent dans le même journal mais servent autrement : ils montrent plusieurs chats côte à côte ou en grille. L’écran pour faire tourner beaucoup de tâches cloud à la fois est la Agents Window.

Commandes sur les machines d’entreprise, décisions dans le cloud Cursor

Le journal du 2 septembre résume Self-Hosted Machines ainsi : l’exécution des outils reste dans le réseau de l’entreprise ; la base de code (tout le code du dépôt), les artefacts de build et les secrets restent sur des machines internes.

La documentation Cursor de Self-Hosted Machines laisse la planification dans le cloud Cursor. Les modifications de fichiers, les commandes de terminal, les clics à l’écran et les serveurs MCP locaux (une norme qui permet à l’IA d’utiliser des outils externes) tournent sur un worker — la machine qui reçoit et exécute le travail. Décider quoi faire et l’inférence (utiliser un modèle terminé pour produire des réponses) restent chez Cursor.

Pendant une exécution, le worker envoie à Cursor le contenu de fichiers nécessaire, la sortie du terminal, les diffs, les captures, les résultats MCP locaux et les métadonnées de routage. Si le partage de bureau est actif, ce flux sort aussi. Les captures, vidéos et références de journaux destinées aux pull requests et au tableau de bord montent aussi vers un stockage géré par Cursor. Ce qui reste dans l’entreprise, c’est le dépôt entier, le cache de build (fichiers intermédiaires pour éviter de reconstruire) et les identifiants sur la machine. Les docs disent de ne pas mettre de secrets dans les sorties d’outils ni les artefacts.

Avec le Privacy Mode, Cursor et les fournisseurs de modèles n’entraînent pas sur le code envoyé par le worker. Cela ne veut pas dire que le code ne sort pas. Les workers n’ouvrent pas de ports entrants : une connexion web chiffrée sortante vers Cursor suffit. Pour bloquer seulement les artefacts, bloquer le trafic sortant vers cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Le travail continue ; les artefacts n’apparaissent plus dans les pull requests ni le tableau de bord.

Deux modes d’emploi :

  • My Machines est personnel. On relie son ordinateur au compte avec une connexion navigateur ou une clé API personnelle (une chaîne secrète qu’un programme présente à la place d’une connexion). Plusieurs agents peuvent tourner sur une machine. Les secrets du tableau de bord ne descendent pas sur ce worker.
  • Team Pools regroupe des workers pour une organisation. La documentation Cursor exige l’offre Enterprise. L’authentification passe uniquement par une clé API de compte de service. Un compte de service appartient à l’équipe, pas à une personne. Avec l’opt-in, on choisit par requête ; sinon, ça tourne sur l’infrastructure Cursor. En mode obligatoire, chaque exécution d’agent cloud va sur vos workers. Dans un pool, un agent prend une machine à la fois.

Les environnements cités le 2 septembre incluent AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel et E2B. La documentation mentionne aussi Kubernetes (un système open source qui gère de nombreux conteneurs). Plafonds : 200 workers par utilisateur, 1 000 par équipe. Le prix des modèles reste ; l’entreprise paie les machines. Les agents gérés par Cursor incluent la machine d’exécution.

Les docs recommandent d’abord les agents cloud gérés pour la plupart des équipes. Le self-hosting convient quand le code ne doit pas sortir du réseau, ou quand il faut des GPU ou des Mac pour les apps iPhone et iPad. Si le seul problème est un serveur Git privé ou un dépôt de paquets interne, les docs disent d’essayer d’abord une liaison privée vers le réseau d’entreprise sur des agents gérés. Exemples : AWS PrivateLink et Cloudflare Tunnel.

Trouver des bugs exploitables dans les propositions de changement

Security Review a ouvert le 23 septembre sur Teams et Enterprise. On choisit des dépôts dans le tableau de bord ; il lit les pull requests hors brouillon dans le contexte de la base de code et laisse un commentaire de revue sur les bugs exploitables. Le style et la qualité restent à Bugbot. Il ne fusionne pas et ne réécrit pas le code tout seul.

Ce contrôle ne tourne pas sur des machines d’entreprise. La documentation Security Agents indique que Security Review et les scans de vulnérabilités du dépôt tournent sur des agents cloud et utilisent le cloud Cursor sans installation supplémentaire. Un agent cloud clone le dépôt autorisé dans une machine virtuelle du cloud Cursor. Ce clone n’est pas effacé dès la fin de l’exécution ; les instantanés partent après 30 jours d’inactivité. Exception : le Security Review d’une équipe déclenché par un événement de pull request tourne sur un hébergement géré par Cursor, pas sur un agent cloud. Ce n’est toujours pas une machine d’entreprise. Ces docs ne disent pas si cet hôte clone tout le dépôt.

Le périmètre couvre l’injection dans les requêtes de base de données, les commandes shell et les modèles de page ; les contrôles de connexion ou de droits manquants, y compris ceux qui cessent de tourner après un refactor ; les secrets commités dans le code ; le SSRF (un défaut où un serveur envoie une requête vers une adresse choisie par un attaquant) et les redirections non validées ; la désérialisation dangereuse quand des données enregistrées redeviennent des valeurs de programme ; les changements de dépendances qui apportent des vulnérabilités connues ; et le suivi de l’entrée utilisateur et de son parcours.

Chaque constat a une gravité, un chemin d’attaque et une correction proposée. Le rejeter avec un motif empêche de le remonter sur cette pull request. Des règles d’équipe s’appliquent à chaque pull request — par exemple, les appels externes doivent passer par un client fixé, ou certaines tables ne doivent pas être interrogées depuis les gestionnaires de requêtes. Aucun tarif séparé n’apparaît dans cette annonce.

Le même jour, Rollouts a aussi ouvert sur Teams et Enterprise. Au déploiement, il indique par environnement si tout paraît sain, pire qu’avant ou indécis. Il ne fusionne pas et ne revient pas en arrière tout seul ; selon la configuration, il peut ouvrir une pull request de revert à relire ou confier une correction à un agent cloud. Le contrôle de source se branche sur Origin ou GitHub, les signaux sur Datadog et outils proches. L’intégration des feature flags (interrupteurs qui activent ou désactivent des fonctions par utilisateur) n’est annoncée que comme « bientôt » ; au 16 octobre, nous n’avons pas pu confirmer qu’elle était ouverte. Les crédits d’essai pour Rollouts valaient 10 jours à partir du lancement — environ 50 changements pour Teams, environ 500 pour Enterprise. Au 16 octobre, cette fenêtre était close ; nous n’avons pas pu confirmer s’il restait des crédits ensuite.

Ce que nous n’avons pas pu confirmer, ou à manier avec prudence

  • Voir ces fonctions comme une seule grande mise à jour est faux. Le pointage à l’écran date du 2 avril et du 5 juin, le self-hosting du 2 septembre, Security Review du 23 septembre.
  • « Le code et les artefacts de build ne sortent jamais » dépasse la documentation Cursor. Le dépôt entier, le cache de build et les identifiants sur la machine restent ; le contenu de fichiers nécessaire à l’exécution et les artefacts vont vers Cursor.
  • Dire que le self-hosting a ouvert en même temps sur Teams et Enterprise ne correspond pas à la documentation Cursor. Les Team Pools exigent Enterprise. Le journal du 2 septembre parle seulement d’une file pour équipes ou entreprises ; l’inclusion de l’offre Teams ne peut pas se déduire de cette seule phrase.
  • Que l’adoption accélère chez les clients entreprise sensibles à la sécurité n’a ni chiffre ni annonce officielle vérifiable.
  • Les affirmations selon lesquelles Security Review bloque toute vulnérabilité ou corrige les bugs tout seul sont aussi absentes de l’annonce de Cursor.

Ce qui pourrait changer pour les développeurs

Ce qui suit est notre estimation et nos conseils à partir des informations disponibles.

  • Ne pas écrire « le code ne sort pas » dans un dossier de sécurité. Séparer ce qui reste et ce qui sort selon la documentation Cursor. Bloquer l’envoi d’artefacts est une question à part : le trafic sortant vers cet hôte de stockage.
  • Les Team Pools demandent l’offre Enterprise et le coût d’exploitation des machines. Le prix des modèles ne change pas. Essayer sur son ordinateur passe par My Machines. Les docs recommandent encore les agents cloud gérés par Cursor pour la plupart des équipes.
  • Security Review ne tourne pas sur des machines d’entreprise. L’activer dépôt par dépôt ; les pull requests en brouillon sont ignorées. Un constat rejeté ne revient pas sur cette pull request : laisser un motif avant de le fermer. Style et qualité restent chez Bugbot.
  • Design Mode reste invisible si seul l’éditeur est ouvert. L’activer avec Cmd+Shift+D dans le navigateur de la Agents Window. Les tableaux de raccourcis dans les docs ne couvrent que le Mac.

À suivre

Si les feature flags se branchent sur Rollouts, si le prix et le taux de faux positifs de Security Review sont publiés, et si une option apparaît pour garder aussi le contenu des fichiers d’inférence dans l’entreprise.

Sources

Source: cursor.com

← Retour