Anaconda relie développement d’agents, tests de sécurité et production

Anaconda a annoncé le 6 octobre une extension de plateforme qui relie développement d’agents, tests de sécurité et orchestration en production. L’enjeu est simple à formuler : quand plusieurs agents agissent en parallèle, comment garder la trace de leurs choix et bloquer une action risquée avant qu’elle n’atteigne un vrai système ? La réponse proposée par l’éditeur passe par un ensemble baptisé AI Dev Factory.

Des agents qui travaillent ensemble, mais pas en roue libre

La brique Kilo Code sert à coordonner des agents qui se répartissent les tâches, par exemple une revue d’authentification d’un côté et des tests de l’autre. Son mécanisme repose sur un tableau de messages partagé entre une session principale et ses agents descendants ; chacun peut y publier des observations pendant que le travail continue. Pratique pour éviter les doublons, moins pour servir de chef de sécurité : Kilo précise que ces messages ne réveillent pas, n’approuvent pas et ne stoppent pas automatiquement les agents.

Sur sa page de lancement, Anaconda situe ces flux dans VS Code et décrit aussi un travail parallèle dans des worktrees. La société ajoute Kilo Desktop en version bêta, avec gestion des environnements Python, usage combiné pour ingénierie et data science, et accès à plus de 500 modèles en inférence locale. Bref, les agents gagnent en autonomie, mais le contrôle humain ne disparaît pas par magie.

Tester les modèles comme des adversaires, pas comme des clients dociles

La partie sécurité repose sur Enkrypt AI, chargée du red teaming autonome. Anaconda dit que l’offre étendue teste modèles, agents et intégrations MCP sur plus de 300 catégories d’attaque, tout en ajoutant une protection en temps d’exécution. Le principe consiste à partir d’attaques connues, puis à adapter les tentatives selon les réponses du système testé.

Dans cette logique, un refus ne ferme pas la porte ; il change la stratégie. L’agent d’attaque mémorise les échecs, explore plusieurs pistes en parallèle et cherche des vulnérabilités qui ne se limitent pas à une mauvaise réponse textuelle, mais touchent aussi les chaînes d’actions. C’est là que les agents deviennent plus délicats à sécuriser : une instruction cachée dans du contenu récupéré peut influencer une décision ultérieure, puis un appel d’outil.

Quand la sécurité doit aussi vivre en production

Enkrypt AI apporte aussi Guardrails, un produit conçu pour approuver, modifier ou bloquer un comportement risqué dans les agents, les outils, la génération augmentée par récupération et les connexions MCP. Les risques ciblés incluent l’injection de prompt, les actions d’outil non sûres, les violations de frontières de privilèges et l’exfiltration de données sensibles. Le point clé est moins spectaculaire que le discours marketing habituel, mais nettement plus utile : un blocage traçable aide autant l’enquête après incident que la prévention.

Anaconda ajoute de son côté des scores de risque de modèle dans Kilo et un Agent Incident Registry alimenté par des incidents publics sourcés. Ces éléments servent à orienter la sélection des modèles et les priorités de test, sans valoir certificat de sécurité universel. La société cite aussi un chiffre de son enquête auprès de builders AI-native : 63 % des répondants disaient évoluer vers des swarms sous une forme ou une autre.

L’orchestration, le bout de chaîne qu’on oublie souvent

La troisième brique vient d’Outerbounds, désormais présenté comme AI Orchestration. Elle couvre l’exécution reproductible, le suivi des artefacts et la lignée des workflows, avec du calcul disponible sur plusieurs clouds et une gouvernance appliquée aux paquets comme aux modèles. Autrement dit, Anaconda cherche à relier ce qui a été construit, testé et exécuté, avec la possibilité de remonter les dépendances exactes.

La plateforme annonce aussi Fast Bakery, qui fabrique des images de conteneurs à partir de dépendances conda et PyPI, y compris des bibliothèques natives. À cela s’ajoutent plus de 19 000 paquets curés et 77 modèles open source validés. L’idée générale est claire : quand un workflow change, il faut savoir quel modèle, quel paquet ou quelle politique a changé avec lui, sinon l’audit ressemble vite à une chasse au trésor sans carte.