Invariant Labs fournit des fonctionnalités d'inspection des politiques et de protection de la sécurité pour les chaînes d'appels des agents, aidant ainsi les équipes à identifier les accès non autorisés et les risques d'injection avant de se connecter.

LabsInvariants

Paramètres de base et statistiques d'Invariant Labs

Paramètres	Descriptif
Positionnement officiel	Produits sécurisés, fiables et robustes pour les agents IA
Gamme de produits de base	Explorateur / Garde-corps / Scan MCP / Passerelle
Nom complet de l'entreprise	Invariant Labs SA
Siège social	Zurich, Suisse (Josefstrasse 219, 8005 Zürich)
Fondateur/PDG	Marc Fischer
Directeur technique	Luca Beurer-Kellner
Équipe consultative	Martin Vechev (professeur à l'ETH Zürich), Florian Tramèr (professeur à l'ETH Zürich)
Formation académique	Entrepreneuriat dérivé de l'ETH Zürich, avec des équipes de l'ETH, Cambridge, Stanford et Google Brain
Licence Open Source	Apache-2.0 (bibliothèque principale et passerelle Guardrails)
Étoiles GitHub (garde-corps)	435
Étoiles GitHub (passerelle)	77
Étoiles GitHub (MCP-Scan)	Sous réserve des données en temps réel de l'entrepôt officiel
Événements écologiques	Acquis par Snyk en 2025 pour accélérer l'innovation en matière de sécurité de l'IA agentique
Version principale (MCP-Scan)	2025-04-11
Version de base (garde-corps)	Début 2025
Version principale (passerelle)	2025
Contacter	[email protected]

Un bref commentaire : La valeur fondamentale d'Invariant est de faire passer la gestion des risques des agents de la « réponse aux incidents » au « développement et contrôle d'accès en ligne », et de parvenir à une gouvernance de la sécurité opérationnelle grâce au moteur de règles trois-en-un + observation des liens d'appel + analyse de la chaîne d'approvisionnement MCP.

Vérification de la publicité : la valeur d'une plate-forme de sécurité ne réside pas dans la « démonstration des capacités de détection », mais dans la contrôlabilité des faux positifs, des faux négatifs contrôlables et des stratégies de blocage exécutables. Invariant offre une vérifiabilité dans les trois dimensions grâce au langage de règles de type Python de Guardrails et à la lecture de traces d'Explorer, plutôt qu'une simple présentation de la surface d'attaque. La stratégie open source de MCP-Scan abaisse le seuil de vérification de la communauté, mais les données sur le taux de fausses alarmes au niveau de l'entreprise restent des informations non publiées.

Reconnaissance des utilisateurs et du marché d'Invariant Labs

Positionnement sur le marché : Une couche de protection dédiée dans le volet de sécurité de l'agent, située entre la couche d'orchestration de l'agent et le fournisseur LLM/serveur MCP. Contrairement aux passerelles de sécurité API générales (telles que Kong, AWS WAF), le moteur de règles d'Invariant comprend nativement la chaîne d'appel des outils et peut détecter les abus d'autorisations et les attaques par injection à plusieurs étapes.

Snyk Acquisition Signal : en 2025, Snyk a annoncé l'acquisition d'Invariant Labs, intégrant ses capacités de sécurité Agentic AI dans la plate-forme de sécurité des développeurs de Snyk. Cette acquisition indique deux tendances : premièrement, le marché de la sécurité des applications considère la sécurité des agents AI comme la prochaine vague d'augmentation ; Deuxièmement, la sécurité des agents évolue d'une démarche entrepreneuriale indépendante vers un complément aux capacités des plates-formes de sécurité existantes. La disposition de Snyk dans l'écosystème de sécurité des développeurs (analyse des dépendances open source, sécurité des conteneurs sécurité IaC) complète les capacités de sécurité des agents d'Invariant, mais la feuille de route d'intégration du produit après l'acquisition n'a pas encore été rendue publique.

Crédit académique et communautaire : les principaux membres de l'équipe sont issus du laboratoire SRI (Secure, Reliable, and Intelligent Systems Lab) de l'ETH Zürich et ont publié de nombreux articles de conférence de premier plan dans le domaine de la sécurité de l'IA (ICML 2024, etc.). La bibliothèque principale Guardrails a reçu 435 étoiles sur GitHub, ce qui constitue une première reconnaissance de la communauté dans le domaine de la sécurité des agents. En tant qu'outil d'analyse de sécurité open source, MCP-Scan présente l'avantage d'être un pionnier dans l'écosystème MCP.

Conditions préalables à la vérification pour les achats d'entreprise : l'approbation de la marque (acquisition de Snyk + formation universitaire de l'ETH) a une valeur de référence, mais elle doit encore être vérifiée par le modèle de menace de l'organisation et les tests de l'équipe rouge. Les quatre aspects suivants doivent être mesurés avant l'achat : l'impact du taux de faux positifs sur la continuité des activités, le retard du moteur de politique en cas de concurrence élevée, l'augmentation de la surface d'attaque couverte par l'analyse MCP et l'adéquation de sa propre pile technologique, ainsi que l'indépendance du produit et l'engagement de la feuille de route après son acquisition par Snyk.

Avantage de coût d'Invariant Labs : une évaluation indépendante de la structure de coûts à trois niveaux

• C-side/Individuel : Généralement, une version gratuite est fournie pour découvrir les fonctions de base, et l'utilisation à haute fréquence nécessite un abonnement payant.
• API/Développeur : Facturé au volume d'appels, adapté aux équipes de développement qui peuvent être intégrées de manière flexible dans leurs propres systèmes.
• Entreprise/Privatisation : contactez le propriétaire de l'entreprise pour obtenir un devis personnalisé et un plan de déploiement. Le prix spécifique est soumis à la page officielle de tarification en temps réel.

Principales fonctionnalités des laboratoires invariants

Explorer — Observation du comportement des agents et analyse de trajectoire

• Visualisation de la trace : Enregistrez la trace complète de chaque appel d'agent, y compris la chaîne aller-retour complète de User → LLM → ToolCall → ToolOutput → LLM, présentée sous la forme d'une chronologie.
• Gestion des ensembles de données : organisez les données de trajectoire par projet (ensemble de données) et prenez en charge la classification des trajectoires et la récupération de plusieurs instances d'agent.
• Lecture de débogage : effectuez une lecture par étapes des trajectoires historiques pour reproduire le contexte de prise de décision de l'agent à chaque tour pour une analyse des faux positifs et un réglage des politiques.
• Intégration de la passerelle : En modifiant le base_url du client LLM pour pointer vers la passerelle invariante, les trajectoires peuvent être automatiquement collectées sans envahir le code de l'agent.

Guardrails – Moteur de protection des politiques contextuelles

• Langage de règles de style Python : les règles sont du code, utilisant la syntaxe raise "alert information" if: (variable: type) conditional expression, prenant en charge les fonctions de bibliothèque standard et les détecteurs personnalisés (Détecteurs). Exemple :

augmenter "Essayer d'envoyer un e-mail après avoir détecté une injection rapide" si :
    (sortie : ToolOutput) -> (appel2 : ToolCall)
    la sortie est l'outil : get_website
    prompt_injection (output.content, seuil = 0,7)
    call2 est l'outil : send_email

• Outil d'analyse de la chaîne d'appels : prend en charge de manière native la correspondance de modèles en plusieurs étapes et peut détecter un comportement non autorisé en plusieurs étapes, tel que "lire d'abord la boîte de réception de l'utilisateur, puis envoyer un e-mail à une boîte aux lettres externe".
• Bibliothèque de détecteurs standard : détecteurs intégrés tels que prompt_injection, secret_leak, tool_poisoning et prend en charge la personnalisation des seuils.
• Déploiement bimode : appliquez de manière transparente les règles en mode proxy LLM/MCP via Gateway (zéro intrusion de code), ou appelez LocalPolicy.analyze() directement dans le code via le package Python invariant-ai.

MCP Scan — Analyse de sécurité du serveur MCP (open source)

• Détection d'empoisonnement d'outil : analysez la description de l'outil du serveur MCP à la recherche d'instructions malveillantes cachées et identifiez l'injection rapide.
• Détection MCP Rug Pull : Détectez les modifications non autorisées des descriptions d'outils après l'approbation de l'utilisateur via Tool Pinning (comparaison de hachage de description d'outil).
• Détection de mise à niveau multi-source : Détectez les attaques d'observation d'outils (Tool Shadowing) entre différents serveurs MCP pour garantir l'isolation au niveau des commandes d'outils.
• Analyse en un clic : uvx mcp-scan@latest s'exécute sans configuration, lit automatiquement le fichier de configuration MCP local et se connecte au serveur pour récupérer la description de l'outil.
• Local + Cloud Dual Engine : les règles locales effectuent des contrôles de sécurité de base et le cloud appelle l'API Invariant Guardrails pour une analyse approfondie.

Gateway – Proxy LLM et couche intermédiaire de sécurité (open source)

• Compatible avec le protocole : prend en charge l'API OpenAI Chat Completions, l'API Anthropic Messages, l'API Gemini, LiteLLM, OpenAI Swarm, Microsoft Autogen.
• MCP Proxy : prend en charge trois protocoles de transmission MCP : stdio, SSE et Streamable HTTP, proxy tous les appels MCP et exécute des politiques de garde.
• Streaming Forwarding : prend entièrement en charge la transmission et la détection transparentes des réponses de streaming LLM sans endommager l'expérience de streaming du client.
• Déploiement Docker en un clic : fournit une image Docker officielle (ghcr.io/invariantlabs-ai/invariant-gateway/gateway:latest), prenant en charge le déploiement local et lié au cloud.

Lien caché (point de vue d'expert)

• Explorer ↔ Guardrails : Explorer fournit des preuves de trace et Guardrails effectue un blocage des politiques. Lorsque Guardrails déclenche une règle, le contexte de trajectoire correspondant tombe automatiquement dans l'Explorateur, formant un contexte « Détection → Blocage → Forensics → Tuning ».
• MCP Scan ↔ Guardrails : La description des outils de risque découverts par MCP Scan pendant la phase d'accès peut être directement convertie en règles de blocage dans la politique Guardrails pour obtenir une « analyse unique, protection continue ».
• Gateway ↔ Gamme complète de produits : Gateway est le pipeline de données central pour tous les produits. Après avoir modifié la « base_url » de LLM et connecté à la passerelle, Explorer collecte automatiquement les trajectoires et Guardrails exécute automatiquement la politique, éliminant ainsi le besoin d'intégrer deux fois pour l'observation et la sécurité.
• Perspectives d'intégration écologique de Snyk : après avoir été acquises par Snyk, les capacités d'analyse MCP d'Invariant pourraient être fusionnées avec l'analyse des dépendances open source (OSS) et l'analyse des conteneurs IaC existantes de Snyk dans une vue de sécurité unifiée « chaîne d'approvisionnement + runtime », mais cela reste de la spéculation.

Invariant Labs évolution du modèle et de la version

Invariant se concentre sur l'itération des capacités de la gamme de produits et le système de numérotation de version n'a pas encore été entièrement standardisé. Les jalons publics suivants sont traçables :

Version principale

Temps	Gamme de produits	Événement	Descriptif
~2024 mi	Garde-corps (bibliothèque principale)	Version initiale	Production de la recherche de l'ETH Zürich, version de base du moteur de règles
Fin 2024	Explorateur	Version bêta interne	Plateforme d'observation de trajectoire d'agent, invitation obligatoire
2025-04-11	MCP-Scan	Sortie publique	Outil d'analyse de sécurité MCP open source, prenant en charge la détection d'empoisonnement d'outils et de tirage de tapis
Début 2025	Passerelle	Sortie publique	Proxy LLM/MCP open source, intégration sans configuration avec Explorer + Guardrails
Début 2025	Garde-corps (langage des règles)	Mise à jour majeure	Présentation du DSL de type Python, prise en charge de la bibliothèque standard des détecteurs
2025	Gamme complète de produits	Acquisition de Snyk	Accélérer l'innovation en matière de sécurité de l'IA agentique, la feuille de route de suivi sera divulguée
2025	Explorateur	Intégration profonde de la passerelle	Prise en charge de la création automatique d'un ensemble de données via Gateway

Description des informations sur la version

• Le numéro de version de la bibliothèque principale Guardrails (package PyPI invariant-ai) est basé sur pyproject.toml, et la dernière version est basée sur les données en temps réel PyPI.
• Le numéro de version de Gateway (actuellement « 0.0.9 ») est marqué dans « pyproject.toml », selon la version de GitHub ou PyPI.
• Le moment de sortie des fonctionnalités de la version entreprise (gestion des politiques multi-tenant, journal d'audit RBAC) est soumis à la feuille de route du produit après l'acquisition de Snyk.

Suggestions de gestion de versions pour l'équipe en ligne

1. Établissez un référentiel Git indépendant pour la bibliothèque de règles Guardrails et utilisez CI/CD pour effectuer des tests de régression des règles.
2. Verrouillez les numéros de version majeurs de « invariant-ai » et « invariant-gateway » pour éviter toute interruption de production causée par une incompatibilité d'API en amont.
3. Après chaque mise à jour de stratégie, utilisez l'Explorateur pour lire les traces historiques afin de vérifier les changements de faux positifs/faux négatifs.
4. Faites attention aux informations sur les vulnérabilités de sécurité de l'agent dans l'avis de sécurité Snyk et mettez à jour la base de règles MCP-Scan en temps opportun.

Avantages techniques d'Invariant Labs

Moteur de règles : analyse native de la chaîne d'appels DSL + outil de style Python

Mécanisme : le langage de règles Guardrails est un sur-ensemble (ou un sous-ensemble strict) de Python. Chaque règle se compose de trois parties : "conditions de déclenchement + correspondance de modèles + contraintes d'expression". Les liaisons déclaratives telles que (msg : Message) et (output : ToolOutput) -> (call2 : ToolCall) dans les règles mappent automatiquement la séquence d'événements dans la trajectoire de l'agent dans un espace variable traversable.

Effet : par rapport aux solutions traditionnelles d'expressions régulières ou de liste noire de mots clés, Invariant peut identifier avec précision les attaques composées en plusieurs étapes. Par exemple, « appelez d'abord « get_website » pour obtenir du contenu externe, puis exécutez les instructions malveillantes cachées via « send_email » », qui ne peuvent pas être découvertes par détection en une seule étape, mais sont clairement identifiables du point de vue de la chaîne d'appel d'outils.

Scénarios applicables : scénarios de haute sécurité qui nécessitent un audit de la chaîne d'appels en plusieurs étapes (examen des transactions financières, contrôle d'accès aux données médicales, opérations inter-autorités des systèmes internes de l'entreprise).

Mode proxy de passerelle : intégration sans intrusion

Mécanisme : la passerelle agit comme une couche intermédiaire entre le client LLM et le fournisseur LLM, et est accessible en modifiant base_url. Lorsque toutes les demandes LLM transitent par la passerelle, elles sont automatiquement copiées en tant que traces et transmises à l'Explorateur, tout en effectuant la « pré-vérification (avant que la demande n'atteigne LLM) » et la « post-vérification (après le retour de LLM) » de la politique Guardrails.

Effet : pas besoin de modifier le code du framework de l'agent, pas besoin d'introduire un nouveau SDK ou de nouvelles dépendances. En prenant OpenAI comme exemple, il vous suffit de transmettre les deux paramètres « http_client » et « base_url » dans le constructeur « OpenAI() », et le système d'agent existant peut obtenir des capacités complètes d'observation et de sécurité.

Scénarios applicables : Équipes qui disposent déjà d'agents de niveau production mais manquent d'observations en matière de sécurité ; environnements hétérogènes où plusieurs prestataires LLM sont mélangés.

La sécurité MCP avant tout : protection frontale de la chaîne d'approvisionnement

Mécanisme : MCP-Scan effectue une analyse de sécurité avant d'accéder au serveur MCP et identifie les risques en analysant les fonctionnalités sémantiques (mode d'injection d'invite, intégration d'instructions cachées, référence d'ombre d'outil) dans le texte de description de l'outil. La fonction Tool Pinning enregistre la valeur de hachage de la description de l'outil et détecte les modifications lors des exécutions ultérieures.

Effet : faire passer la sécurité de la chaîne d'approvisionnement MCP de la « défense passive de l'État en cours d'exécution » à « le contrôle actif de l'État d'accès ». Combiné à la capacité de vérification continue de Tool Pinning, il peut détecter les attaques par « ajout de porte dérobée » pendant le fonctionnement du serveur MCP.

Scénarios applicables : applications d'agent qui utilisent des serveurs MCP tiers (telles que l'intégration MCP Claude Desktop MCP Market Cursor, la passerelle proxy MCP auto-construite).

Lien architectural

Demande d'agent
    |
    v
+------------------------------------------------+
| Passerelle invariante |
| (Modifier l'accès base_url, zéro intrusion de code) |
| |
| +--------------------------+ +--------------+ |
| | Explorateur | | Garde-corps | |
| | Collection de trajectoires | | Moteur d'exécution de politique | |
| +--------------------------+ +--------------+ |
| |
| +----------------------------------+ |
| | Proxy MCP (stdio/SSE/HTTP) | |
| +----------------------------------+ |

+------------------------------------------------+
    | |
    v v
Serveur MCP du fournisseur LLM
(OpenAI/Anthropic/ (Tiers/Auto-construit)
 Gémeaux/LiteLLM) |
                           v
                     MCP-Scan (scan avant accès)
                     Épinglage d'outil (vérification d'exécution)

Sens du flux de contrôle : demande de l'utilisateur → Passerelle → Pré-vérification des garde-corps → Appel LLM/MCP → Post-vérification des garde-corps → Retour de réponse → Placement de la piste de l'explorateur. Sens de retour des données : la passerelle transmet les traces à l'Explorateur en temps réel. Lorsqu'une règle est respectée, Guardrails associe automatiquement le contexte de preuve à la trace correspondante.

Guide des pièges d'ingénierie

Piège 1 : Boucle mortelle et contrôle de l'inflation des jetons Le moteur de règles Guardrails bloquera l'appel par défaut lorsqu'une violation est détectée, mais si la règle elle-même a une correspondance récursive (par exemple, la règle correspond à la fois à l'entrée et à la sortie de ToolCall, formant un déclencheur infini), la passerelle exécutera la règle à plusieurs reprises. Solution : définissez « max_steps » ou la limite de budget d'étape, ajoutez le paramètre « max_iterations » à chaque règle (le cas échéant) et surveillez les exceptions de temps d'exécution des règles dans l'Explorateur.

Piège 2 : surcharge de contexte DOM/Exception Lorsque Gateway proxy des appels MCP, si le serveur MCP renvoie une description d'outil trop longue (telle qu'une description d'outil qui inclut un document API complet), cela peut entraîner un débordement de la fenêtre contextuelle du moteur de règles. Solution : définissez la troncature de longueur maximale (telle que 4 096 jetons) décrite par l'outil au niveau de la couche passerelle et résumez automatiquement les parties excédentaires avant de les envoyer au moteur de règles ; ou configurez l'Explorateur pour qu'il renvoie uniquement le résumé au niveau de l'arborescence d'accessibilité.

Piège 3 : Sécurité et gouvernance ultra vires Une fois que les règles Guardrails sont mal écrites (par exemple, l'expression régulière est trop large), les demandes commerciales normales peuvent être bloquées par erreur, provoquant des accidents de production. Solution : Définir un point de confirmation (Confirmation Gate) pour les règles liées aux opérations irréversibles (suppression, paiement, libération, transfert). Par défaut, le mode d'exécution à sec est activé pour s'exécuter pendant une semaine afin de collecter des données faussement positives. Après confirmation, passez en mode blocage. Gateway prend en charge le mode lecture seule avec la granularité de l'ensemble de données. Il est recommandé d’exécuter d’abord les nouvelles règles en mode contournement de production (mode fantôme).

Comment utiliser Invariant Labs : quatre chemins d'accès

Chemin 1 : Développeur individuel – Expérience de règles locales

# Installer le package invariant-ai
pip installer invariant-ai

#Écrire le fichier de règles Policy.gr
chat > politique.gr << 'EOF'
augmenter "Désactiver l'envoi d'e-mails externes après lecture de la boîte de réception" si :
    (appel : ToolCall) -> (appel 2 : ToolCall)
    l'appel est un outil : get_inbox
    call2 est l'outil :send_email({
        à : ".*@[^company.com$].*"
    })
EOF

# Effectuer une analyse de règles dans le code Python
python3 -c "
à partir de invariant.analyzer importer LocalPolicy
politique = LocalPolicy.from_file('policy.gr')
résultat = politique.analyser (messages)
imprimer(résultat.erreurs)
"

Chemin 2 : Équipe - Accès à la passerelle (en prenant OpenAI comme exemple)

à partir du client d'importation httpx
depuis openai importer OpenAI

client = OpenAI (
    http_client=Client(
        en-têtes={
            "Invariant-Authorization": "Porteur <YOUR_INVARIANT_API_KEY>"
        },
    ),
    base_url="https://explorer.invariantlabs.ai/api/v1/gateway/<dataset-name>/openai",
)
# Tous les appels chat.completions.create suivants collecteront automatiquement des traces + exécuteront des stratégies de garde

Troisième voie : Équipe de sécurité – Analyse de la chaîne d'approvisionnement MCP

# Analysez les serveurs MCP configurés locaux en un seul clic
uvx mcp-scan@dernier

# Afficher la description détaillée de l'outil
uvx mcp-scan@dernière inspection

# Scanner le fichier de configuration MCP spécifié
uvx mcp-scan@latest --config ~/.cursor/mcp.json

Chemin 4 : Entreprise – Déploiement local de la passerelle

# Déploiement Docker
docker pull --platform linux/amd64 ghcr.io/invariantlabs-ai/invariant-gateway/gateway:latest
docker run -p 8005:8005 -e PORT=8005 --platform linux/amd64 \
  ghcr.io/invariantlabs-ai/invariant-gateway/gateway:latest

# Gateway s'exécutera sur http://localhost:8005/api/v1/gateway/

Indicateurs d'acceptation recommandés

Métriques	Descriptif	Seuils recommandés
Taux de blocage des demandes à haut risque	Proportion de requêtes à haut risque soumises aux règles Guardrails et correctement bloquées	>= 99 % (test de régression)
Taux de faux positifs	La proportion de demandes normales jugées à tort comme étant à haut risque	< 1 % (doit être ajusté en fonction des scénarios commerciaux)
Latence accrue (P99)	Latence supplémentaire introduite par Gateway	< 200 ms (en fonction de la complexité des règles)
Taux de réduction des incidents de sécurité	Taux de réduction proportionnelle des incidents de sécurité des agents après accès	Cible >= 50 % (nécessite une observation à long terme)
Couverture de l'analyse MCP	Ratio de serveurs MCP analysés par rapport à tous les serveurs MCP connectés	100%

Prix des produits Invariant Labs

Le modèle de tarification est soumis à la page officielle en temps réel. Habituellement, un système freemium ou d'abonnement est utilisé et les fonctions de base peuvent être utilisées gratuitement. Les fonctions avancées ou l'utilisation à haute fréquence nécessitent des abonnements payants, et il est conseillé aux utilisateurs d'évaluer la solution optimale en fonction de l'utilisation réelle.

Scénarios d'application d'Invariant Labs

Scénario 1 : Contrôle d'accès sécurisé par l'agent de conformité dans le secteur financier

Type de tâche : l'agent du service client de la banque doit accéder à plusieurs systèmes internes tels que les informations sur le compte client, les enregistrements de transactions, les recommandations de produits financiers, etc., et les opérations inter-autorités sont strictement interdites (par exemple, l'agent du service client ne peut pas initier de transferts).

Solution invariante : écrivez la règle « Interdire l'appel des outils de transfert après avoir lu les informations du compte » via Guardrails, Gateway intercepte tous les appels LLM vers l'outil et Explorer enregistre chaque trace d'accès pour l'audit de conformité.

Avantages : remplacez l'inspection de conformité « inspection aléatoire post-audit » par un « blocage automatique en temps réel » pour réduire le risque de violations de conformité. Déduction : la couverture d'audit manuel d'origine est de 5 à 10 %, et après accès, elle peut atteindre un contrôle d'accès automatique à 100 %.

Scénario 2 : Contrôle d'accès sécurisé des applications écologiques MCP

Type de tâche : les entreprises connectent plusieurs serveurs MCP tiers (tels que GitHub MCP, Slack MCP, base de données MCP) à des plateformes telles que Claude Desktop et Cursor. Ils doivent s’assurer qu’il n’y a pas d’instructions malveillantes cachées dans les descriptions de ces outils.

Solution invariante : intégrez mcp-scan dans le pipeline CI/CD et effectuez automatiquement une analyse de sécurité avant la connexion de chaque nouveau serveur MCP ; après avoir réussi l'analyse, le hachage de la description de l'outil sera enregistré dans la liste blanche d'épinglage d'outils et il sera vérifié en permanence pendant l'exécution.

Avantages : évitez deux types d'attaques de la chaîne d'approvisionnement : MCP Rug Pull (la description de l'outil est falsifiée et détournée) et Tool Poisoning (injection d'invite cachée). Déduction : l'analyse de sécurité est passée d'heures de travail manuel à 1 à 3 minutes en un seul clic.

Scénario 3 : Gouvernance des opérations ultra vires au sein des processus automatisés internes de l’entreprise

Type de tâche : les entreprises utilisent des frameworks multi-agents tels qu'AutoGen et CrewAI pour effectuer des tâches d'automatisation interservices (telles que le processus d'intégration des employés du système RH et l'approbation des autorisations du système informatique) et doivent empêcher les autorisations transfrontalières dans les appels de la chaîne d'agents.

Solution invariante : la passerelle est connectée en mode proxy, les règles Guardrails détectent "si l'interface sensible du système B est appelée au-delà de l'autorité après avoir appelé le système A", et Explorer enregistre la trace complète du lien pour un audit post-événement.

Avantages : la limite d'autorité du processus d'automatisation de l'agent passe de la « révision du code » à « l'exécution de la politique d'exécution », réduisant ainsi les accidents de remplacement causés par les hallucinations de l'agent.

Scénario 4 (scénario restreint) : environnement d'isolement de haute sécurité

Non applicable : le service cloud Explorer d'Invariant n'est pas disponible dans un environnement complètement hors ligne. Pour le moment, seul le mode local (« LocalPolicy ») de la bibliothèque principale Guardrails et le déploiement Docker local de la passerelle peuvent être utilisés, mais la visualisation de trajectoire et les capacités de collaboration à distance d'Explorer seront perdues. Si la politique de sécurité d'une organisation interdit tout appel d'API externe (y compris l'API Guardrails d'Invariant), les capacités d'analyse cloud de MCP-Scan seront également indisponibles.

À qui s’adresse Invariant Labs ?

• Ingénieur de sécurité IA : responsable de la rédaction et de la maintenance des règles de politique Guardrails, de l'analyse des événements de sécurité dans les traces Explorer et du réglage de l'équilibre faux positif/faux négatif. Prérequis : Comprendre le mode d'attaque en chaîne Tool Call et être familier avec le DSL de style Python.
• Développeur d'application Agent : Intégrez la passerelle dans le code de l'agent, configurez le base_url et l'en-tête d'authentification du client LLM pour garantir que la couche de sécurité ne détruit pas la fonction Agent. Pré-requis : Familiarisé avec la configuration client du framework Agent utilisé (OpenAI SDK, Anthropic SDK, AutoGen, CrewAI, etc.).
• Conformité de sécurité/personnel d'audit : vérifiez la conformité du comportement de l'agent via les journaux d'audit exportés par Explorer et examinez régulièrement la couverture de la politique Guardrails. Prérequis : Familiarisé avec les exigences des normes de conformité de l'industrie (SOC2, HIPAA, PCI-DSS, etc.) pour les systèmes d'IA.
• DevSecOps Engineer : Intégrez MCP-Scan dans le pipeline CI/CD, gérez la liste blanche d'épinglage d'outils, maintenez la gestion des versions des lignes de base de sécurité. Prérequis : Familiarité avec les chaînes d'outils CI/CD (GitHub Actions, GitLab CI, etc.) et le déploiement Docker.
• Acheteur de technologie : évaluez le coût d'intégration d'Invariant avec les piles technologiques de sécurité existantes (SIEM, SOAR, API Gateway) par rapport à la couverture des solutions concurrentes (par exemple Guardrails AI, Rebuff, LLM Guard). Prérequis : Comprendre le modèle de menace du contexte de production de l'agent.

Ne s'applique pas à la foule :

• Projet de démonstration purement expérimental (pas de données utilisateur réelles, pas de trafic de production), le retour sur investissement en sécurité n'est pas évident.
• Un simple Chatbot sans Tool Call (uniquement conversation textuelle, aucun outil externe appelé), la capacité principale d'Invariant (analyse de la chaîne d'appel d'outils) ne peut pas être utile.
• Équipes qui ont utilisé la plateforme de sécurité existante de Snyk et qui ont un minimum d'appels d'agent : doivent évaluer les progrès de l'intégration du produit après l'acquisition de Snyk pour éviter deux intégrations à court terme.
• Les organisations qui sont complètement hors ligne et n'autorisent aucune communication API externe (voir les restrictions du scénario quatre).

Résumé des laboratoires invariants et Outlook

Compétences de base : La différenciation d'Invariant dans le volet de sécurité de l'agent réside en trois points : 1) Le moteur de règles comprend nativement la chaîne d'appel d'outil et peut détecter les attaques composées en plusieurs étapes ; 2) Le mode agent Gateway réalise une intégration sans intrusion et vous pouvez obtenir des capacités complètes d'observation et de sécurité en modifiant le « base_url » du client LLM ; 3) La pré-analyse de la sécurité de la chaîne d'approvisionnement MCP (MCP-Scan) + la vérification de l'exécution (Tool Pinning) forment une combinaison.

Limites et incertitudes actuelles :

• La feuille de route du produit après son acquisition par Snyk n'a pas encore été rendue publique et les entreprises doivent confirmer le cycle de support indépendant avant d'acheter.
• L'accord de niveau de service (SLA) et l'engagement de disponibilité du service cloud Explorer ne sont pas divulgués, et les environnements de production clés doivent évaluer la maturité de la solution de déploiement local.
• Il y a un manque de benchmarks publics sur les performances du moteur de règles Guardrails lors du traitement de règles très complexes (plus de 50 conditions imbriquées).
• La précision de détection des appels d'agent multilingues (chinois, japonais et autres invites non anglaises) n'a pas été évaluée de manière indépendante.
• L'analyse cloud de MCP-Scan implique la transmission de données de description d'outil, et les termes de résidence des données doivent être vérifiés un par un.
• Il n'existe pas de rapports publics d'audit de sécurité tiers (tels que SOC2 Type II, ISO 27001) et les achats de conformité de l'entreprise doivent être obtenus auprès de l'équipe commerciale.

Points d'observation de suivi :

1. Progrès de l'intégration de Snyk : 2025-2026 La façon dont Snyk intègre la gamme de produits Invariant dans la plate-forme existante (qu'elle soit exploitée en tant que marque distincte ou fusionnée dans le module Snyk Agent Security) affecte directement les décisions d'achat.
2. Benchmark communautaire du taux de faux positifs : à mesure que la base d'utilisateurs augmente, les rapports de faux positifs/faux négatifs accumulés par la communauté deviendront un indicateur important pour évaluer la maturité du moteur de règles.
3. Évolution de la norme de sécurité écologique MCP : Si le mécanisme de sécurité du protocole MCP lui-même est amélioré (comme l'authentification au niveau du protocole, la déclaration d'autorisation de l'outil), cela affectera la valeur incrémentielle de la sécurité de la chaîne d'approvisionnement invariante.
4. Changements dans le paysage des produits concurrentiels : Si les principaux fournisseurs de cloud (AWS, Azure, GCP) lancent des services de sécurité d'agent natifs, l'espace de marché pour les outils de sécurité indépendants sera réduit.

Évaluation des risques d'approvisionnement et d'adoption : pour les équipes d'entreprise qui envisagent de déployer des agents dans des environnements de production, Invariant est une option digne d'une vérification PoC, en particulier dans les secteurs à haute conformité et les gros utilisateurs de l'écosystème MCP. Il est recommandé de commencer avec la version open source de Guardrails + Gateway, de compléter le taux de faux positifs et l'acceptation des performances dans un cycle de 2 à 4 semaines, puis de lier la décision d'achat de la version entreprise au calendrier de la feuille de route du produit après l'acquisition de Snyk pour éviter de payer des coûts de migration excessifs pendant la période de transition d'intégration de la plateforme.

Outils associés : Copilote GitHub, Curseur

Invariant Labs Comment utiliser

• Client Web : Vous pouvez l'utiliser en visitant le site officiel et en créant un compte. La plupart des fonctions ne nécessitent pas d'installation.
• Accès API : fournit une API RESTful, les développeurs peuvent obtenir la clé API et l'intégrer dans leurs propres applications.

Informations de version

• Invariant 0,8 ：Optimisez en permanence la stabilité et l’expérience des développeurs. Les fonctionnalités spécifiques sont soumises à une publication officielle en temps réel. （2026-06-11）
• première sortie publique ：Les informations sur la première version n’ont pas été entièrement divulguées. Il est recommandé de se référer au journal de mise à jour officiel. （未公开）