L’ordinateur portable du développeur vient de devenir production. Et maintenant ?

Pendant des décennies, le développement de logiciels d’entreprise reposait sur l’hypothèse selon laquelle les développeurs pouvaient expérimenter en toute sécurité grâce à des garanties entre leur travail et leur production. Le développement, la mise en scène et la production obéissaient à des règles différentes, les intermédiaires humains jugeant ce qui était prêt à avancer. Les tests supposaient également que le logiciel se comporterait de manière prévisible lors de sa nouvelle exécution.

Les agents de codage bouleversent les deux hypothèses. Les développeurs exécutent désormais des logiciels autonomes sur des ordinateurs portables contenant des jetons GitHub, des clés SSH, des informations d’identification cloud et des sessions de navigateur authentifiées. Ils connectent des agents aux serveurs MCP, accordent l’accès aux référentiels et aux services et copient les commandes suggérées dans les terminaux sans toujours comprendre ce que feront ces commandes. Lorsque les demandes d’autorisation deviennent un obstacle, il est tentant de cliquer dessus ou d’autoriser un accès illimité. Les développeurs inventent des politiques de sécurité à la volée.

Le résultat est que l’ordinateur portable du développeur est devenu une extension de la production. Un agent peut atteindre des systèmes qui nécessitaient auparavant une intervention humaine délibérée, en utilisant souvent des autorisations accordées dans un but totalement différent. Contrairement aux logiciels conventionnels, un agent peut entreprendre des actions différentes lorsqu’on lui présente la même tâche, car son contexte et ses décisions changent. Les RSSI sont désormais confrontés à un défi fondamentalement différent : gérer les logiciels autonomes qui détiennent déjà des voies actives vers la production.

Le contrôle de sécurité que nous n’avons jamais reconnu était un jugement humain

Là où les développeurs humains et les agents de codage divergent le plus, c’est au niveau du jugement et non des capacités techniques.

Les développeurs comprennent dans quel état se trouve leur code, qu’il s’agisse de quelque chose qu’ils testent ou de quelque chose qui est prêt pour la production. Ils comprennent ce que leurs informations d’identification leur permettent de faire, mais aussi quand et comment ces informations doivent être utilisées. Il existe un cloisonnement implicite entre l’accès et l’exercice.

Un agent IA est beaucoup plus déterminé. Si un identifiant disponible permet d’accomplir la tâche, l’agent l’utilise. Les agents ne font pas la distinction entre ce qui est techniquement possible et ce que la politique permet.

Prenons l’exemple d’un agent chargé de dépanner une application défaillante. Il découvre les informations d’identification de production sur l’ordinateur portable du développeur et détermine que l’interrogation de la base de données active est le moyen le plus rapide de diagnostiquer le problème. Il peut modifier les données de production lors d’une tentative de correctif, même si le développeur avait uniquement l’intention d’enquêter sur un problème local. Aucune vulnérabilité ne doit être exploitée. L’agent utilise simplement l’autorité dont il dispose pour poursuivre l’objectif qui lui est assigné.

Les pipelines de développement traditionnels n’ont pas été conçus autour d’un logiciel qui décide de manière indépendante à quels systèmes accéder et quelles actions entreprendre. Les contrôles de sécurité doivent désormais tenir compte des comportements qui ne peuvent pas être entièrement anticipés à partir de la demande d’origine.

Un bac à sable peut contenir un agent sans contenir son autorité

Le sandboxing est apparu comme une réponse évidente aux risques des agents autonomes. En isolant l’exécution dans un conteneur, une machine virtuelle ou une microVM, les organisations peuvent limiter la capacité d’un agent à interférer avec son hôte ou d’autres charges de travail.

Une isolation solide est essentielle, en particulier lorsque les agents exécutent du code non fiable ou interagissent avec des outils potentiellement malveillants. Une microVM avec son propre noyau invité peut fournir une limite plus forte qu’un conteneur conventionnel partageant le noyau hôte. Mais l’isolement ne répond qu’en partie à la question de sécurité.

Un bac à sable d’agent qui bloque tout accès externe est aussi utile qu’un ordinateur enfermé dans le ciment au fond de l’océan.

Un agent n’a pas besoin de s’échapper de son bac à sable pour provoquer un incident de sécurité. Il peut abuser d’autorisations parfaitement légitimes, envoyer des informations sensibles via une connexion réseau autorisée ou apporter des modifications destructrices en utilisant les informations d’identification qui lui sont délibérément fournies.

Isoler l’exécution est inutile à moins que vous ne contrôliez précisément ce que cette charge de travail peut atteindre. Un bac à sable sécurisé contenant des informations d’identification illimitées laisse toujours une énorme surface d’attaque.

Peut-on révoquer un agent sans désactiver son développeur ?

Les professionnels de la sécurité sont familiers avec le moindre privilège, mais le développement agentique expose les limites de la gestion conventionnelle des identités et des accès.

Prenons l’exemple d’un développeur qui autorise un agent à modifier un référentiel GitHub. Si l’agent utilise le jeton personnel du développeur, il peut hériter de l’accès à chaque référentiel accessible par le développeur. Cela pourrait inclure les autorisations de fusion, les environnements CI/CD et les informations d’identification en aval associées à ces systèmes.

Il s’agit de l’autorité ambiante : la capacité d’effectuer des actions au-delà de la tâche particulière pour laquelle l’accès était initialement prévu. Même un jeton relativement restreint peut autoriser des actions répétées lorsque l’agent n’a besoin d’une autorisation qu’une seule fois pour effectuer l’action.

Lorsqu’un agent opère avec les informations d’identification d’un développeur, la révocation de son accès peut également signifier la désactivation du développeur. Les équipes de sécurité doivent séparer les charges de travail autonomes de l’identité humaine.

Les agents doivent avoir des identités définies indépendamment, avec des autorisations déléguées à des fins spécifiques. Cela permet de suivre ce que chaque agent a fait, d’enquêter sur les problèmes et de révoquer l’autorité d’un agent individuel sans perturber son développeur.

Le chaînon manquant est un courtier de confiance

L’un des développements les plus intéressants en matière de sécurité agent est l’idée émergente d’un courtier de confiance situé entre un agent et les systèmes auxquels il souhaite accéder.

Certaines approches sont décrites comme des proxys MCP. D’autres utilisent des services d’autorisation, des passerelles ou des architectures différentes. Ils tournent autour du même problème fondamental : comment décider quels agents peuvent accéder à quelles ressources, dans quelles circonstances et pour combien de temps ?

Fondamentalement, l’agent ne peut pas être responsable de décider des limites de sa propre autorité. Ces décisions doivent être appliquées par un système distinct capable d’autoriser des opérations individuelles sans renoncer aux informations d’identification qui les rendent possibles.

Imaginez demander à un agent de résoudre un problème GitHub. Au lieu d’accorder un accès illimité au référentiel, le développeur autorise la tâche une seule fois. Un intermédiaire de confiance pourrait alors permettre à l’agent de lire le référentiel, de transmettre les modifications à une branche désignée et d’ouvrir une pull request. Ces autorisations pourraient expirer après une heure, sans exposer un identifiant de développeur largement réutilisable.

C’est la principale tension que la sécurité agente doit résoudre. Accordez trop peu d’accès et les développeurs abandonnent les contrôles. Accordez-en trop et l’isolement n’a plus d’importance par rapport aux dommages qu’un agent autorisé peut causer. L’objectif est de rendre la délégation sécurisée aussi fluide qu’un accès illimité.

La sécurité agent se rapproche peut-être d’un moment architectural comparable. Les développeurs, les projets open source et les fournisseurs commerciaux expérimentent des approches en matière d’identité, de délégation, d’autorisation et d’application des politiques. Certaines organisations construisent leurs propres contrôles autour des systèmes IAM existants. D’autres explorent des intermédiaires dédiés qui évaluent les demandes avant de permettre aux agents d’accéder à des ressources externes.

Le courtier de confiance n’est pas encore un composant universellement défini et rien ne garantit qu’une de ses implémentations deviendra l’équivalent de Kubernetes. Les questions concernant les décisions politiques, la conservation des diplômes, la latence, la disponibilité et l’auditabilité restent ouvertes.

Mais la fonction manquante devient plus claire. Nous avons besoin d’un intermédiaire fiable qui traduise l’intention humaine en autorité étroitement définie et exécutoire pour les logiciels autonomes.

Les serveurs MCP sont devenus une nouvelle chaîne d’approvisionnement en logiciels

MCP est l’un des principaux moyens par lesquels les agents se connectent aux outils et informations externes. Cela en fait à la fois un mécanisme d’intégration important et une frontière de sécurité.

Un serveur MCP malveillant peut devenir une voie indirecte vers le flux de travail d’un agent. Si des serveurs ou des outils s’exécutent avec un accès à des systèmes de fichiers, des processus ou des magasins d’informations d’identification partagés, un composant compromis peut être capable de lire les secrets appartenant à un autre outil.

Mais le vol d’identifiants n’est pas le seul problème. Un serveur compromis peut renvoyer des informations manipulées qui influencent les actions ultérieures d’un agent avant même que celui-ci n’utilise l’outil. Un attaquant n’a pas besoin de compromettre l’agent, mais uniquement le contexte qu’il consomme.

Les disciplines familières de provenance, de signature et d’intégrité de construction doivent s’étendre aux serveurs MCP, aux outils d’agent et aux poids de modèle. Les organisations doivent savoir d’où proviennent ces composants, s’ils ont été modifiés et quelle autorité ils reçoivent lorsqu’ils sont introduits dans un environnement.

La réponse est une sécurité à plusieurs niveaux : une isolation forte, des identités gérées de manière indépendante, des autorisations limitées, un accès réseau contrôlé et une observabilité suffisante pour comprendre ce que font réellement les agents.

Pourquoi la sécurité des agents a sa place dans le chemin d’exécution

La conteneurisation a démontré que la sécurité fonctionne mieux lorsque les garde-fous sont intégrés directement dans les plates-formes des développeurs sans réduire la vitesse. Kubernetes a finalement permis d’appliquer des politiques de sécurité et opérationnelles communes sur les charges de travail distribuées sans exiger que chaque développeur devienne un expert en infrastructure. Le développement agent nécessite un changement comparable.

L’opportunité à plus long terme consiste à passer de l’octroi d’un accès persistant à la délégation d’autorités spécifiques à des tâches. Les développeurs ont besoin d’un moyen d’autoriser un agent à résoudre un problème ou à ouvrir une demande d’extraction sans abandonner les clés permanentes.

Les ordinateurs portables sont désormais des points de terminaison de production et ils ne reviendront pas à des bacs à sable sécurisés. Les équipes de sécurité doivent protéger la vitesse des développeurs en intégrant les limites que le jugement humain utilisait pour gérer manuellement directement dans l’infrastructure.