Le nouveau whitepaper « Lethal by Design » de Noma Security trace une ligne architecturale plus nette entre deux mécanismes d'extension d'agents IA que les développeurs traitaient comme à peu près équivalents : les serveurs MCP et les Skills (le pattern Claude Skills, qui s'est répandu à d'autres surfaces d'agents). Le chiffre manchette — environ un serveur MCP sur quatre analysés expose un risque d'exécution de code à travers huit catégories de capacités — c'est la partie qui se fait citer. La méthodologie n'est pas pleinement divulguée dans le résumé public (taille d'échantillon, couverture de registre, et définition exacte du « risque d'exécution de code » à travers les catégories, tout est flou), donc traite le pourcentage comme un signal directionnel, pas comme un résultat d'audit pairs-évalué. L'observation architecturale substantive en dessous compte plus.
Cette observation : les outils MCP et les Skills se ressemblent du point de vue de l'auteur d'agent mais vivent de part et d'autre d'une frontière d'observabilité. Quand un agent appelle un outil MCP, les défenseurs voient les paramètres qui sortent et les réponses qui reviennent — structurés, loggables, énumérables comme code source. Les Skills, c'est différent. L'agent charge un ensemble d'instructions textuelles dans son contexte de raisonnement, et ce qui se passe après se joue à l'intérieur du raisonnement du modèle, où les outils d'observabilité ne peuvent pas suivre. Tu peux auditer le fichier qui livre le Skill; tu ne peux pas auditer les décisions runtime qu'un modèle prend une fois ce Skill chargé en contexte. Ce n'est pas un gap d'outillage qu'une meilleure couverture SIEM ferme; c'est structurel à comment les Skills fonctionnent.
Le whitepaper nomme cinq patterns d'incidents réels pour ancrer l'abstraction. **ContextCrush** : documentation empoisonnée mène à exfiltration de fichiers locaux. **ForcedLeak** : données CRM malveillantes déclenchent des requêtes sur des records sensibles. **DockerDash** : métadonnées d'image Docker empoisonnées déclenchent exécution de commande. Les **incidents Replit et Amazon Q** qui ont déjà eu lieu — hallucinations d'agents résultant en suppression de production. **Manipulation de mémoire** pour transferts financiers frauduleux récurrents. Ce ne sont pas des spéculations; ça mappe à des expositions architecturales spécifiques qui existent *aujourd'hui* dans des déploiements d'agents en production. Chacun est une forme différente de « l'agent a été autorisé à faire quelque chose qu'il ne devrait pas, et le stack de sécurité autour n'a pas attrapé ça parce que la décision pertinente s'est passée dans une couche qui n'émet pas de signaux observables ».
Le cadre défensif de Noma, c'est « No Excessive CAP » — **Capacités** (allowlist d'outils étroits, pinning des versions MCP), **Autonomie** (gates d'approbation pour les actions irréversibles), **Permissions** (credentials user-scoped expirants, pas des comptes de service statiques). Pour les développeurs, la lecture pratique, c'est que le stack de sécurité agent se bifurque le long des mêmes lignes que le problème d'observabilité. Les outils qui marchent pour MCP — firewalls hors-processus comme Pipelock, enforcement style gateway — n'aident pas avec les Skills, parce que les Skills ne font pas d'appels externes qu'un proxy peut intercepter; ils façonnent le comportement du modèle de l'intérieur. Si ton déploiement d'agent utilise MCP *et* Skills, t'as besoin de deux postures de sécurité séparées : une couche d'enforcement pour MCP à la frontière réseau, et une discipline de *revue de contenu* pour les Skills avant qu'ils entrent dans le contexte du modèle. Le whitepaper est sur go.noma.security/lethal-by-design.