Listes autorisées des serveurs MCP : pourquoi les systèmes agentiques ont besoin de pare-feu de capacité

Une sécurité rapide est utile, mais elle ne résout pas le véritable problème lorsqu’un agent dispose d’un large éventail d’outils. Le correctif réside dans les pare-feu de capacité : des listes autorisées explicites indiquant quelles actions sont autorisées, où elles peuvent être exécutées et quelles données elles sont autorisées à toucher.

La portée de l'outil est le véritable rayon de souffle

Les équipes continuent de consacrer de l'énergie au filtrage des invites tout en permettant aux agents d'accéder discrètement aux shells, aux systèmes de fichiers, aux API de billetterie, aux tableaux de bord cloud et aux magasins de connaissances internes. C'est à l'envers. Une invite étrange est récupérable. Un outil hautement fiable avec des limites bâclées est la manière dont vous obtenez de réels dégâts.

Les serveurs MCP et les connecteurs d'agent similaires doivent être traités comme des middlewares privilégiés et non comme des plugins pratiques. S’ils peuvent relier les requêtes non fiables à des systèmes fiables, ils ont besoin de limites de capacités strictes.

Ce que signifie réellement un pare-feu de capacité

Si votre politique de connecteur est essentiellement « activé ou désactivé », elle est trop grossière. La véritable sécurité réside dans les autorisations limitées, et non dans un commutateur binaire.

Le schéma d'échec que tout le monde ne cesse de répéter

Un agent interne a accès à un outil flexible. L’outil peut lire et écrire largement. Le système suppose que l'invite et le message système maintiendront l'agent dans les limites. Ensuite, un document empoisonné, un résultat d’outil trompeur ou un chemin de secours mal conçu pousse le flux de travail là où il n’aurait jamais dû aller.

La cause première n’est pas un échec magique de l’IA. Il s’agit d’un échec d’autorisation ordinaire enveloppé dans la marque de l’IA.

Contrôles minimaux qui devraient exister maintenant

• Étendues par outil, et non étendues d'agent globales.
• Les autorisations de lecture et d'écriture sont divisées par défaut.
• Listes autorisées d’hôtes sortants pour chaque connecteur compatible réseau.
• Journalisation structurée de l'action demandée, de la portée approuvée et de l'objectif d'exécution réel.
• Supprimez les commutateurs pour les connecteurs qui commencent à se comporter étrangement.

Il ne s’agit pas d’une ingénierie excessive. C’est un confinement basique. Si un connecteur peut toucher aux données de production, de finance, d’identité ou de client, le confinement est la tâche à accomplir.

Comment les équipes concernées par KENSAI devraient évaluer le risque lié aux connecteurs

Commencez par répertorier tous les connecteurs pouvant effectuer des actions de changement d’état. Demandez-vous ensuite ce qui se passe si le flux de travail reçoit des instructions hostiles, un contexte trompeur ou un contenu récupéré trop large. Si la réponse inclut l’exécution de code, les modifications d’enregistrement, l’accès aux informations d’identification ou la transmission externe, le connecteur nécessite immédiatement une portée plus stricte.

La bonne mentalité est simple : traiter l’expansion des capacités comme l’ouverture de ports de pare-feu. Chaque nouvelle action devrait trouver sa place.

La recommandation brutale

Le refus par défaut gagne. Donnez aux agents le plus petit ensemble d'actions utiles, limitez où ces actions peuvent aboutir et exigez une approbation explicite pour tout ce qui est coûteux, destructeur ou sensible à la vie privée. Les pare-feux de capacités sont moins sexy que les démos d'agents, mais ils font la différence entre un système puissant et une responsabilité puissante.