MCP Protect prend le contrat déjà audité et scanné et le transforme en politique d'exécution — le même modèle que 42Crunch utilise pour protéger les API depuis dix ans, désormais appliqué au trafic entre les agents IA et les outils qu'ils appellent.
Même si cela ressemble à la sécurité des API, il s'agit d'un problème de nature fondamentalement différente : une attaque contre un serveur MCP — ou contre la logique métier et les données qui se trouvent derrière — peut être transmise par le serveur et atteindre l'agent IA lui-même. 42Crunch protège les deux côtés.
La même rigueur que 42Crunch applique aux API depuis dix ans : le contrat approuvé devient une liste blanche. Tout ce qu'un appel d'outil tente de faire sans que le contrat ne l'ait déclaré — accès non autorisé aux données, opération hors périmètre, contournement d'une limite de débit déclarée — est quelque chose que le point d'application est en mesure de bloquer, de la même manière qu'un pare-feu API applique aujourd'hui un contrat OpenAPI.
La partie la plus récente du problème : un contenu qui atteint l'agent IA via un résultat d'outil ou une description d'outil peut orienter son comportement — injection de prompt, empoisonnement d'outil, substitution « rug-pull » entre la revue et la production. L'application des règles de ce côté vise à empêcher tout contenu malveillant d'atteindre le modèle, et pas seulement à contrôler qui peut appeler quel outil.
Il n'applique que ce qui a déjà été déclaré et validé. Rien n'atteint cette étape sans être d'abord passé par la génération MCP Contract, la notation MCP Audit et la validation en conditions réelles MCP Scan.
Déclare ce qui est autorisé.
Note la déclaration.
Valide le comportement en conditions réelles.
L'applique, en continu — cette page.