Chaque entreprise a sa propre version de la même chose.
Parfois, c'est un wiki de sécurité. Parfois, c'est une page Confluence. Parfois, c'est un PDF que personne ne veut mettre à jour. Parfois, c'est « demandez à Sarah de l'équipe AppSec, car elle sait comment nous faisons ici. »
Son rôle est d'expliquer comment les API doivent être authentifiées, comment les données sensibles doivent être traitées, comment les secrets doivent être utilisés, quels modèles de journalisation sont acceptables et quelles normes sont importantes pour votre entreprise, vos régulateurs et vos clients.
Ensuite, un développeur ouvre un assistant de codage IA et lui demande de construire quelque chose.
L'assistant n'a rien lu de tout cela.
C'est là le fossé. Et un très gros problème.
Pendant des années, les équipes de sécurité ont essayé de résoudre ce problème en révisant le code après qu'il ait été écrit. Scannez-le dans le pipeline. Ouvrez un ticket. Renvoyez-le au développeur. Attendez la correction. Recommencez le cycle.
Ce modèle était déjà pénible lorsque les humains écrivaient la majeure partie du code.
Aujourd'hui, près de 50 % du code est écrit par l'IA, et ce modèle a montré ses limites.
L'IA n'écrit pas seulement du code. Elle écrit la couche d'action.
Dans le monde des agents, le code généré par l'IA n'est pas juste une autre application interne. C'est souvent l'infrastructure qui donne aux agents les moyens d'agir.
API. Serveurs MCP. Outils d'agent. Connecteurs. Intégrations. Flux de travail.
Ce code généré par l'IA devient le chemin qu'un agent utilise pour interagir avec l'entreprise.
Un développeur demande à un assistant de créer un outil de support qui peut rechercher des commandes et émettre des remboursements. L'assistant génère un serveur MCP. Le serveur MCP appelle des API internes. Ces API accèdent aux dossiers clients, aux systèmes de paiement, aux données logistiques et aux journaux d'audit.
De l'extérieur, cela ressemble à de la productivité.
Du point de vue de la sécurité, c'est la naissance d'un nouveau chemin d'action et d'un risque invisible.
Si ce chemin a une autorisation faible, des identifiants codés en dur, des limites de débit manquantes, une journalisation médiocre ou des données sensibles circulant au mauvais endroit, le problème n'est pas théorique. Il devient une partie des moyens d'action de l'agent.
Et une fois que le code est écrit, révisé, fusionné, déployé et connecté à de vraies API, corriger le modèle est beaucoup plus difficile.
C'est la partie que je pense que l'industrie doit dire plus clairement :
Si votre politique de sécurité n'agit qu'au moment de la création du code, elle sera toujours à la traîne par rapport à ce que l'IA a déjà écrit.
Le Wiki de sécurité ne peut pas suivre le rythme de l'assistant de codage.
Ce n'est pas parce que les développeurs sont négligents. C'est parce que le flux de travail a changé.
Un développeur écrivait du code, recherchait des ressources internes, demandait à un autre ingénieur, lisait la norme et copiait des modèles de services existants. Ce processus avait de nombreux problèmes, mais au moins l'humain savait qu'il existait une façon de faire propre à l'entreprise.
Les assistants de codage IA ne connaissent pas naturellement la façon de faire de votre entreprise.
Ils connaissent des modèles courants provenant d'internet. Certains sont bons. Certains sont obsolètes. Certains sont non sécurisés. Certains sont totalement inadaptés à votre environnement.
Ils ne savent pas que vos API nécessitent un modèle d'autorisation spécifique. Ils ne savent pas que votre entreprise interdit les jetons dans la configuration des outils. Ils ne savent pas que chaque point de terminaison public doit avoir un schéma OpenAPI, que certaines classes de données ne peuvent pas être renvoyées à un agent, ou que les outils MCP avec des autorisations d'écriture nécessitent des contrôles plus stricts.
À moins que vous n'intégriez la politique à l'assistant, celui-ci improvisera.
Et « improviser » n'est pas une stratégie de sécurité. Je suis fier de dire que notre équipe chez Salt a résolu ce problème.
Aujourd'hui, nous lançons Salt Code.
L'idée fondamentale derrière Salt Code est simple : la politique de sécurité devrait accompagner le code dès la première invite.
Pas après la pull request.
Pas après la détection SAST.
Pas après l'écart de posture d'exécution.
Mais dès le moment où le développeur demande à l'assistant IA de créer quelque chose.
Salt Code connecte notre moteur de gouvernance de la posture aux assistants de codage que les développeurs utilisent déjà : Claude, Cursor, GitHub Copilot, Windsurf, Codex, Gemini CLI et d'autres flux de travail compatibles MCP. Le moteur de gouvernance de la posture est notre couche de politique où les normes de sécurité et de conformité sont définies une fois, puis appliquées tout au long du cycle de vie.
Pour le développeur, cela fonctionne en arrière-plan dans le flux de travail qu'il utilise déjà. Pour l'équipe de sécurité, cela signifie que la norme n'est plus piégée dans un wiki. Elle fait partie de la façon dont le code est créé.
Un développeur peut demander à Cursor de construire un serveur MCP qui appelle une API de facturation interne. Salt Code peut guider le code généré pour qu'il respecte la norme d'entreprise : pas de secrets codés en dur, le bon modèle d'authentification, les vérifications d'autorisation requises, la documentation OpenAPI, le comportement de journalisation approuvé et les contrôles pour les données sensibles. Et construire le serveur MCP conformément à la politique.
Le développeur n'a pas besoin de se souvenir de demander du code sécurisé.
L'assistant le génère ainsi par défaut.
C'est l'écart qui est en train d'être comblé.
La sécurité doit passer de la révision à la création.
Les outils de sécurité de code existants ont toujours leur place. Le SAST, le DAST, la révision de code, les vérifications CI/CD et la surveillance en temps réel ne vont pas disparaître.
Mais si la politique de sécurité n'intervient qu'après que l'IA a déjà généré le code, nous commençons trop tard, et l'écart est déjà devenu trop grand pour être comblé.
C'est comme laisser une usine produire des milliers de pièces toute la journée, puis envoyer quelqu'un en fin de chaîne pour jeter les pièces défectueuses. L'inspection finale reste nécessaire. Mais il faut aussi que la machine soit calibrée avant le début de la production.
Salt Code vise à calibrer la machine.
Il applique la politique lorsque le code est généré. Il valide la même politique dans le pipeline. Il utilise l'intelligence d'exécution pour comprendre comment les API, les intégrations MCP et les agents se comportent réellement une fois déployés. Et avec le temps, les observations d'exécution peuvent alimenter les flux de travail des développeurs afin que la version suivante soit meilleure que la précédente.
Cette dernière partie est importante car la sécurité agentique n'est pas un simple point de contrôle. C'est une boucle.
Le code vous dit ce qui a été construit. La configuration vous dit comment il est géré. L'exécution vous dit ce qui s'est passé. La même norme de sécurité doit relier les trois.
C'est l'idée fondamentale derrière Salt Code : un modèle de politique unique qui suit le système agentique, du code qui le crée, au plan de contrôle qui le gouverne, jusqu'au comportement d'exécution qui prouve ce qui s'est réellement passé.
Le code n'est pas seulement du code. C'est aussi un comportement futur.
S'il ne s'agissait que de générer des extraits de code plus sûrs, ce serait utile. Mais les systèmes agentiques estompent la frontière entre le développement et l'exécution.
Le code qu'un développeur génère aujourd'hui pourrait devenir un outil MCP demain, utilisé par un autre agent dans deux jours. Cet outil MCP pourrait appeler une API la semaine prochaine. Cette API pourrait donner à un agent l'accès aux données clients, aux flux de paiement, aux modifications de compte ou aux systèmes opérationnels.
En d'autres termes, le code n'est pas seulement du code. C'est un comportement futur.
C'est pourquoi Salt Code fait partie intégrante de notre plateforme de sécurité agentique et non un scanner de code autonome. Les mêmes politiques qui façonnent le code à la création devraient régir les API et les systèmes agentiques que ce code devient en production.
C'est ainsi que nous passons de « trouver le problème plus tard » à « empêcher la création du modèle dès le départ ».
L'horizon temporel est important.
Chaque semaine où un assistant de codage IA s'exécute dans votre environnement sans application de politique est une semaine de code agentique qu'aucune révision de sécurité n'a jamais vu.
Une partie de ce code sera inoffensive. Une partie deviendra des prototypes. Une partie passera discrètement en production. Et une partie deviendra la couche d'action que vos agents utiliseront pour interagir avec des systèmes critiques.
C'est pourquoi je crois que la sécurisation de l'IA agentique commence avant la première invite.
Non pas que la sécurité des invites soit sans importance. Non pas que la protection à l'exécution soit facultative. Mais parce que la première invite qu'un développeur donne à un assistant de codage IA peut devenir la première version d'un outil, d'une API ou d'un serveur MCP sur lequel vos agents s'appuieront plus tard.
Si nous voulons que les agents agissent en toute sécurité, nous devons nous soucier de ce qu'ils font.
L'IA transforme la façon dont les logiciels sont développés.
La politique de sécurité doit aussi évoluer dans ce sens.
Salt Code est disponible via notre programme d'accès anticipé pour les 100 premières organisations, avec les quatre packs de codage sécurisé inclus. Vous pouvez vous inscrire à votre essai gratuit ici ou participer à notre webinaire le 16 juin pour voir une démonstration de Salt Code.