Le scanner de sécurité MCP: prouve ce qu'un scanner propre couvre

Un scanner de sécurité MCP peut répondre à une question précoce précieuse: quels composants d'agent ai je découverts et quels risques a t il trouvés dans la version qu'il a inspectée? Il ne peut répondre à toute la question opérationnelle: est il sain maintenant l'agent connecté, et son appel à l'outil a il produit le résultat souhaité? Utilisez un scan propre comme un reçu limité. Avant de lui faire confiance, vérifiez quatre choses séparément: 1. le scanner couvrait toutes les configurations et tous les composants pertinents; 2. l'exécution du scanner n'a pas exécuté un serveur local non fiable à l'extérieur d'une boîte à sable; 3. le manifeste scanné est toujours le manifeste que le client utilisera; 4. une séance en direct et un passage de vérification des résultats spécifiques à la destination après la numérisation. Cette limite est importante car la numérisation n'est pas nécessairement passive. La documentation pour Snyk Agent Scan v0.5.15 indique que la numérisation d'une configuration MCP démarre les commandes stdio définies dans celle ci afin que le scanner puisse récupérer les descriptions de l'outil. Son flux interactif par défaut demande d'abord son consentement. La même documentation marque les champs de sortie CLI et les codes de sortie comme expérimentaux. Le défaut raisonnable est donc: l'inventaire en général, la numérisation dans un environnement jetable lorsqu'une configuration n'est pas déjà fiable, la conservation d'un reçu réduit au minimum de contenu et l'exigence de preuves vivantes avant de modifier l'état de santé d'un agent. Commencez par un reçu de couverture, pas une seule ligne verte. Un rapport de scanner a besoin d'un dénominateur. Aucun résultat signifie peu si une configuration au niveau du projet, un serveur bundled avec extension ou une commande locale refusée n'ont jamais été consultées. La documentation Agent Scan v0.5.15 publie deux matrices utiles: les agents pris en charge par système d'exploitation et la couverture de détection par portée de configuration. La matrice de portée distingue explicitement les emplacements du système, de l'utilisateur, du projet/de l'espace de travail et de l'extension/plugin. Il contient aussi des lacunes. C'est plus sain qu'une promesse non documentée de découverte universelle, mais cela signifie que l'opérateur doit comparer la couverture du scanner avec l'installation réelle. Construisez un reçu avec des identifiants et des haches, pas des invites, des informations d'identification, des arguments d'outil ou des résultats: expectedConfigs doit provenir de votre inventaire de déploiement, pas du compte de découverte du scanner lui même. Dans le cas contraire, un fichier non découvert réduit à la fois le numérateur et le dénominateur et semble toujours complet. Mettez aussi la sortie du scanner. Le Agent Scan version 0.5.15, publié le 16 juillet 2026, comprend des binaires de plateforme, des sumes de chèques, un fichier de sumes de chèques signé et un SBOM. Ces artefacts vous permettent d'enregistrer exactement ce qui a été exécuté. Ils ne certifient pas les versions futures, une binaire reconstruite localement ou la sécurité d'un serveur MCP. Traitez un serveur décliné comme une lacune d'inventaire, pas comme un serveur en cours. Le déclin peut être la bonne décision de sécurité. Le verdict global résultant est encore incomplet parce que les outils et les descriptions du serveur n'ont pas été inspectés. Traiter l'exécution du scanner comme un test privilégié Le Les meilleures pratiques en matière de sécurité des PCM actuel décrit les serveurs locaux comme des binaires téléchargés ou créés qui peuvent être exécutés avec les privilèges du client. Pour la configuration locale en un clic, l'orientation nécessite l'affichage de la commande exacte et l'obtention d'une approbation explicite avant la connexion. Il recommande également la sandboxing et la restriction de l'accès au système de fichiers, au réseau et aux processus. Appliquez la même prudence à un scanner qui démarre les serveurs configurés. Une commande malveillante ou tout simplement surprivilegiée ne devient pas inoffensive parce que son processus parent est appelé un scanner. Pour une configuration inconnue: copier uniquement les données de configuration et de fixation requises dans une machine à sous ou un conteneur jetable; supprimer les identifiants de production et remplacer les destinations par des doubles tests locaux; refuser l'accès au réseau, sauf si un test spécifique l'exige; montent le système de fichiers en lecture seule lorsque cela est pratique; examiner la commande exacte et les arguments avant de consentir; enregistrement des serveurs qui ont été refusés, mis à jour ou initialement échoué. Ne résolvez pas l'automatisation non interactive en permettant à l'aveugle d'exécuter chaque serveur configuré flag sur un ordinateur portable ou un hébergeur de production du développeur. Le scanner peut avoir besoin d'un tel mode pour une IC contrôlée, mais la décision de confiance appartient à l'environnement et au manifeste, et non à la commodité du drapeau. Il y a aussi une question de limite de données. L'Agent Scan indique que les noms et les descriptions des composants peuvent être envoyés à son service d'analyse, tandis que le contenu et les résultats des appels de l'outil MCP ne sont pas stockés ni enregistrés. Revoir la politique et la configuration réelle du scanner que vous choisissez. Un reçu opérationnel sans contenu devrait conserver les codes de publication, les comptes, les versions, les hachages, les lacunes de couverture et les timestamps; il ne devrait pas copier les descriptions sensibles ou la sortie du serveur dans un tableau de bord de santé par défaut. Des données de scan séparées provenant de la santé vivante Un scanner fonctionne principalement avant ou autour de la connexion. L'agent de santé continue après ce point. Gardez trois reçus: Vit: couverture de l'inventaire , version du scanner, résultats, exécution sécurisée et hash du manifeste. Recevoir de session en direct: Initialisation réussie, protocole et capacités négociés, autorisation actuelle, découverte d'outils frais et corrélation requête/réponse limitée. ORéception de résultat: preuve déterministe provenant de la destination de l'existence du changement ou de la livrabilité envisagés. La distinction empêche deux états faux verts. Premièrement, la configuration peut changer après la numérisation. Une description de l'outil, un argument de commande, une version du package, une URL du serveur ou une portée peuvent dériver pendant que l'ancien rapport reste vert. Comparez un hash de manifeste normalisé au moment de la numérisation et immédiatement avant la connexion. Un déséquilibre signifie STALE SCAN ; cela ne signifie pas probablement sûr. Deuxièmement, un scanner peut passer pendant que le temps d'exécution est inaccessible, non autorisé ou incapable de terminer un appel à l'outil. Même une réponse réussie au MCP tools/call ne prouve pas l'effet externe. Un fichier peut être écrit dans le mauvais répertoire, une API peut accepter mais plus tard rejeter un travail, ou un message peut ne jamais atteindre sa destination. Vérifiez l'artefact ou la déclaration que l'utilisateur a effectivement demandée. La priorité suivante donne à chaque défaillance une action suivante limitée: L'âge de 24 heures dans cet exemple est une entrée de politique, pas une constante de protocole. Une configuration de développement qui change fréquemment peut nécessiter une fenêtre beaucoup plus courte. Un déploiement immutable, signé pourrait utiliser le hash match comme la vérification de fraîcheur décisive. Répétez les cas d'inconvénient avant l'adoption J' ai joué huit reçus sans contenu contre ce classifiateur: une commande non fiable scannée directement sur l'hôte; un serveur refusé lors de la découverte; une constatation critique; un manifeste modifié après la numérisation; une analyse nette et courante sans vérification en direct; une analyse nette suivie d'une session en direct ratée; une déclaration réussie de l'outil sans preuve de destination; une analyse actuelle, une séance en direct et un résultat vérifié. Tous les huit ont produit l'état attendu. Plus important encore, le boîtier à scanner seulement a produit SCANNER PASS ONLY , et non HEALTHY BOUNDARY . Le premier verdict sain nécessitait les trois couches de preuves. Il ne s'agit pas d'un indicateur de précision de détection du scanner. Je n'ai pas exécuté délibérément les configurations MCP de tiers sur l'hôte: la documentation source établit que cela peut démarrer des commandes locales. Pour comparer les moteurs de détection, créez des dispositifs représentatifs sûrs pour les risques qui vous intéressent, exécutez chaque scanner dans un environnement isolé et mesurez les faux négatifs, les faux positifs, les champs non pris en charge et la stabilité de la sortie. Cette limitation est opérationnellement utile. Cela empêche une équipe de transformer une comparaison de scanner non vérifiée en une réclamation de sécurité. Utilisez un scanner pour la décision qu'il peut prendre Adoptez un scanner de sécurité MCP lorsqu'il vous donne un meilleur inventaire de composants, détecte la configuration pertinente ou les risques manifestes, expose ses limites de couverture et peut fonctionner à l'intérieur de vos limites de sécurité. Le rejeter ou le contenir lorsque le scan lui même a besoin de privilèges ou de transfert de données que vous ne pouvez pas justifier. Après l'adoption: 1. identifier et vérifier l'artefact du scanner; 2. définir l'inventaire de configuration attendu en dehors du scanner; 3. scanner des commandes locales non fiables uniquement dans un environnement jetable; 4. blocage des résultats critiques et des lacunes explicites dans la couverture; 5. comparer à nouveau le hash manifeste au moment de la connexion; 6. effectuer une vérification minimale d'initialisation et d'autorisation en direct; 7. vérifier un résultat représentatif de la destination avant de déclarer la santé. Le scanner n'est pas diminué par cette règle. Il devient plus digne de confiance parce que son verdict est attaché aux preuves qu'il observe réellement. Sidewisp est une plateforme de santé de l'agent AI destinée à rendre visible la preuve, la fraîcheur, l'incertitude et la prochaine action sûre au cours des délais d'exécution existants. Sidewisp est actuellement en préversion privée. Le scanner MCP de production, la collecte des agents en direct et les adaptateurs de récupération ne sont pas expédiés aujourd'hui.