OWASP SAMM se dote d'Agentic SAMM, une extension pour développer en sécurité avec des agents IA

Un nouveau projet à l'état de brouillon, Agentic SAMM (ASAMM), a vu le jour autour d'OWASP SAMM. Il s'agit d'une extension destinée aux équipes qui développent des produits avec des agents IA et utilisent des modèles dans leur développement. Son objectif : couvrir les risques que le secure SDLC classique perçoit mal, à savoir le contexte malveillant, les appels d'outils dangereux et les fenêtres d'autonomie trop longues.

Pourquoi l'ancien SAMM ne suffit plus

Le OWASP SAMM classique fonctionne bien lorsque les principaux objets à protéger sont le code, le build, la release et l'infrastructure de livraison. Mais dans les systèmes agentiques, la surface d'attaque s'étend plus loin : aux documents, aux tickets du tracker, aux descriptions d'outils, aux résultats de recherche web, aux logs de CI et à tout autre contenu que le modèle lit comme partie de son contexte de travail. Si ce contexte influence le comportement de l'agent, il cesse d'être une simple donnée d'entrée et fait partie du control plane.

C'est pourquoi l'auteur d'ASAMM propose de voir le développement non comme un cycle fermé, mais comme une spirale. L'équipe repasse par la conception, l'implémentation et la vérification, mais à chaque tour, le système, les outils et les menaces elles-mêmes changent. Dans ce schéma, il ne suffit plus de vérifier que l'agent a reçu les bons droits. Même un agent pleinement autorisé peut exécuter une action qui ne correspond pas à la tâche initiale si le contexte ou la logique de délégation l'écartent de sa route.

Ce que propose ASAMM

ASAMM n'est pas conçu pour remplacer OWASP SAMM, mais comme une couche supplémentaire pour les équipes qui déploient des agents IA, des serveurs MCP et de l'automatisation avec des pouvoirs délégués. Le cadre ajoute une couche distincte de garanties là où s'arrêtent les vérifications habituelles du code : à la frontière des appels d'outils, dans le flux de contexte, dans les approval checkpoints et dans le comportement du système à l'exécution. Il n'abolit pas les pratiques de base de SAMM, il les étend au comportement en runtime et aux actions déléguées.

• Une taxonomie des menaces pour les systèmes agentiques, où le contexte est considéré comme une commande potentielle
• Un modèle de confiance à deux axes pour les agents, les outils, les serveurs MCP et les sources de contexte
• Un ensemble de contrôles pour les cinq fonctions de SAMM, avec des niveaux de maturité et des scénarios de mise en œuvre
• Deux parcours de lancement : migrer depuis un programme de sécurité existant ou déployer from scratch
• Une correspondance avec le NIST AI RMF et les recommandations du NCSC pour les équipes qui ont besoin d'une compatibilité avec des cadres déjà connus

Le document met un accent particulier sur l'environnement de développement. Les plugins d'IDE, les hooks de pre-commit, les agents de CI et les connecteurs MCP externes fonctionnent avec les privilèges du développeur, mais vivent souvent en dehors d'un threat model complet. Pour ASAMM, ce n'est pas un élément secondaire, mais une cible d'analyse à part entière : si un agent peut lire, appeler et modifier plus que ce que l'équipe suit réellement, les voyants verts des dashboards ne garantissent plus rien. De fait, l'environnement de développement devient la production de l'agent lui-même.

Où les équipes se trompent déjà

Le document énumère des erreurs typiques, particulièrement visibles dans le développement agentique. Une équipe peut juger son threat model terminé alors qu'il ne comporte aucune source de contexte ni aucun chemin d'appel d'outils. La code review peut couvrir tout le code d'une PR sans toucher aux prompts système, aux schémas de tool calls et aux configurations des agents. Le DAST peut afficher un résultat propre alors que personne n'a vérifié le comportement de l'agent face à un contexte hostile. Et le least privilege n'est souvent appliqué qu'au niveau des comptes de service, sans limiter les actions autorisées via les outils.

« Aucun plan ne survit au premier contact. »

L'auteur en fait un principe de conception : le prompt système doit fixer l'intention, et non chercher à décrire rigidement tout l'algorithme de comportement.

De là découle un autre paramètre de risque important : le produit de la fenêtre d'autonomie par le blast radius des outils disponibles. Plus un agent agit longtemps sans point de contrôle humain et plus l'éventail de ses capacités est large, plus les dégâts potentiels sont élevés, même avec des droits d'accès formellement corrects. C'est pourquoi les fenêtres d'autonomie deviennent ici un paramètre d'architecture, et pas seulement d'exploitation.

Ce que cela signifie

Agentic SAMM acte un basculement déjà survenu dans le développement avec l'IA : la sécurité doit désormais vérifier non seulement le code, mais aussi le comportement du système après la release. Pour les équipes qui bâtissent des produits sur des agents et du vibe coding, c'est un signal pour revoir leur threat model, leur code review et le contrôle des outils avant que la première erreur autonome ne tourne au véritable incident.