Sécurité MCP : Risques, architecture et bonnes pratiques

Le protocole MCP (Model Context Protocol) est en train de transformer la façon dont l'intelligence artificielle interagit avec les systèmes d'entreprise.

Au lieu de créer une intégration personnalisée distincte pour chaque source de données, application ou outil, les développeurs peuvent utiliser MCP pour offrir aux applications d'IA une méthode standardisée pour :

• récupérer des données contextuelles
• découvrir les outils disponibles
• invoquer les fonctions approuvées
• interagir avec des services externes
• prise en charge des flux de travail multi-agents en plusieurs étapes

Cela rend MCP précieux pour les copilotes, les assistants de programmation, les flux de travail de sécurité, l'analyse, le support client et agents d'IA autonomes.

Cela crée également une nouvelle frontière de sécurité.

Un agent utilisant MCP peut lire des fichiers, interroger des bases de données, appeler des API, mettre à jour des enregistrements, déclencher des analyses, ouvrir des tickets ou exécuter d'autres actions importantes. Si les contrôles environnants sont insuffisants, des attaquants peuvent manipuler l'agent, abuser de ses identifiants, divulguer des informations sensibles ou l'amener à utiliser un outil inapproprié.

MCP normalise la connectivité, mais ne la sécurise pas automatiquement.

Les organisations doivent sécuriser l'intégralité de l'écosystème MCP dans le cadre d'une stratégie plus globale. stratégie de sécurité et de gouvernance de l'IA, y compris l'application hôte, les clients, les serveurs, les outils, les ressources, les invites, les informations d'identification, les canaux de transport, les données d'entreprise et le comportement de l'agent.

Qu'est-ce que le protocole de contexte de modèle ?

Protocole de contexte du modèle est un protocole ouvert qui normalise la manière dont les applications d'IA se connectent aux sources de données et aux outils externes.

MCP offre une interface commune permettant à une application d'IA de découvrir les fonctionnalités disponibles, d'accéder au contexte et d'exécuter des actions approuvées. Elle réduit ainsi la nécessité de créer et de maintenir une intégration propriétaire distincte pour chaque modèle, outil ou source de données.

Le protocole peut prendre en charge les connexions à :

• systèmes de fichiers et référentiels de documents
• bases de données et plateformes de données
• dépôts de code source
• services cloud
• applications commerciales
• plateformes de sécurité
• systèmes de billetterie
• API d'entreprise

Le MCP est particulièrement important pour les agents autonomes. Ces derniers ont besoin de bien plus qu'un modèle de langage pour accomplir des tâches concrètes. Ils ont besoin de contexte, d'identifiants, d'outils et d'autorisations pour interagir avec les systèmes externes.

Cependant, chaque nouvelle connexion peut également ouvrir une nouvelle voie d'accès à des données sensibles ou à des actions privilégiées. Le protocole MCP doit donc être considéré comme faisant partie intégrante de l'architecture de sécurité des applications, de l'identité, des données et de l'IA de l'organisation.

Comment fonctionne l'architecture MCP

MCP suit une architecture hôte-client-serveur.

Un hôte peut créer plusieurs clients MCP, chacun maintenant une connexion à un serveur MCP. La sécurité de l'environnement global dépend des contrôles mis en place par l'hôte, chaque client et chaque serveur connecté.

Hôte MCP

L'hôte MCP est l'application d'IA qui coordonne l'expérience utilisateur, le modèle de langage, les clients MCP, les autorisations et les politiques de sécurité.

L'hôte décide :

• quels serveurs peuvent se connecter
• quels outils et ressources sont exposés
• Quel consentement de l'utilisateur est requis ?
• Quelles actions nécessitent une approbation ?
• comment le contexte est partagé et isolé

Problème de sécurité : Un système hôte qui expose trop d'outils ou qui approuve automatiquement les actions à fort impact peut conférer à un agent plus d'autorité que sa tâche ne l'exige.

Client MCP

Un client MCP s'exécute sur le système hôte et maintient une connexion avec un serveur MCP spécifique. Il négocie les autorisations, échange des messages de protocole, récupère des ressources, met à disposition des outils et renvoie les résultats à l'hôte.

Problème de sécurité : Un client qui ne parvient pas à valider les réponses du serveur, les définitions d'outils, les étendues demandées ou les résultats peut transmettre des instructions malveillantes ou du contenu non sécurisé au modèle de langage.

Serveur MCP

Un serveur MCP met à disposition des ressources, des invites ou des outils exécutables à un client. Ces serveurs peuvent fonctionner localement ou à distance et se connecter aux données d'entreprise, aux applications métier, aux API ou aux systèmes de sécurité.

Problème de sécurité : Un serveur MCP peut contenir des identifiants, exposer des fonctions privilégiées, accéder à des systèmes sensibles ou influencer le comportement des agents. Les organisations doivent considérer ces serveurs comme des composants d'applications de production et non comme de simples modules complémentaires pouvant être installés sans vérification préalable.

Couches de données et de transport

MCP utilise des messages JSON-RPC pour échanger des outils, des ressources, des invites, des requêtes, des notifications et des résultats.

Le protocole actuel définit :

• stdio : Communication avec un processus serveur local via les entrées et sorties standard.
• HTTP diffusable : Communication basée sur le protocole HTTP, prenant en charge les connexions à distance et la diffusion en continu optionnelle.

Le responsable Spécifications de transport MCP Streamable HTTP exige que les serveurs valident les en-têtes Origin entrants. Il est également recommandé de lier les serveurs locaux à localhost et d'authentifier les connexions.

Problème de sécurité : Des points de terminaison exposés, une authentification faible, une gestion d'origine invalide ou des jetons porteurs divulgués peuvent permettre une interaction non autorisée avec un serveur MCP.

Que sont les primitives MCP ?

Les primitives MCP définissent les capacités que les clients et les serveurs peuvent s'offrir mutuellement.

Primitives côté serveur

Ressources fournir des données contextuelles, telles que des fichiers, des enregistrements de base de données, des schémas ou des réponses d'API.

Outils Ce sont des fonctions exécutables qui peuvent interroger des systèmes, modifier des enregistrements, créer des tickets, lancer des analyses ou effectuer d'autres actions.

Invites ce sont des modèles réutilisables qui structurent les interactions avec un modèle de langage.

Capacités côté client

Échantillonnage permet à un serveur de demander la complétion d'un modèle via le client.

Racines communiquer les limites du système de fichiers ou de l'URI dans lesquelles un serveur peut fonctionner.

Élicitation permet à un serveur de demander des informations supplémentaires ou une confirmation à un utilisateur.

Ces fonctionnalités sont puissantes, mais leurs descriptions et leurs résultats ne doivent pas être considérés comme fiables d'office. Les annotations des outils doivent être traitées avec prudence, sauf si elles proviennent d'un serveur de confiance. Les entrées doivent être validées, les sorties nettoyées et les appels consécutifs affichés à l'utilisateur avant leur exécution.

Pourquoi la sécurité MCP est importante

Les interfaces de chat IA traditionnelles renvoient principalement du texte.

Les systèmes d'IA compatibles MCP peuvent agir.

Un agent compromis ou manipulé peut être en mesure de :

• récupérer les dossiers clients
• modifier ou supprimer des fichiers
• envoyer des messages
• modifier les autorisations
• flux de travail de déclenchement
• exécuter le code
• appeler les API en aval
• combiner plusieurs outils en une seule chaîne d'actions

Une instruction malveillante peut donc influencer une action réalisée avec des identifiants d'entreprise légitimes, et pas seulement le texte d'une réponse type.

Les organisations ont besoin gouvernance de l'accès aux données pour comprendre quels utilisateurs, agents, applications et outils peuvent accéder aux informations sensibles de l'entreprise.

La sécurité MCP exige également une visibilité sur :

• Quels serveurs et outils sont connectés ?
• qui les a approuvés et qui en sont propriétaires
• quelles identités et informations d'identification ils utilisent
• quelles données peuvent-ils accéder
• quelles actions peuvent-ils effectuer
• comment ces actions sont surveillées
• comment un accès risqué peut être révoqué

Principaux risques de sécurité MCP

1. Autorisations excessives des agents

La méthode de mise en œuvre la plus rapide pourrait consister à accorder à un serveur MCP des droits d'accès étendus ou à exposer un grand nombre d'outils. Avec le temps, ces Les autorisations peuvent s'étendre au-delà des besoins initiaux de l'entreprise..

Un agent bénéficiant de privilèges excessifs peut être en mesure de :

• lire des fichiers sensibles dont il n'a pas besoin
• modifier ou supprimer des enregistrements
• invoquer les API d'administration
• intégrer des outils individuellement sûrs dans un flux de travail dangereux
• hériter de l'accès via un compte utilisateur ou de service

Les agents d'IA fonctionnent comme identités non humaines qui s'authentifient auprès des systèmes d'entreprise, héritent des autorisations et exécutent des actions au nom des utilisateurs ou des processus métier.

Les organisations doivent cartographier chaque agent, serveur, outil, identité, droit d'accès et source de données accessible avant d'activer l'exécution autonome.

2. Injection d'invites et manipulation du contexte

Injection rapide Cela se produit lorsque du contenu malveillant ou non fiable influence les instructions d'un système d'IA.

Dans un flux de travail MCP, l'instruction peut provenir de :

• un document récupéré en tant que ressource
• une page web
• un enregistrement de base de données
• une réponse d'outil
• un serveur compromis
• un champ soumis par l'utilisateur

Par exemple, un attaquant pourrait insérer une instruction dans un document demandant à un agent de ne pas tenir compte de ses contraintes et de transférer des enregistrements sensibles vers une destination externe.

On parle d'injection indirecte d'instructions car l'attaquant manipule le contenu que l'agent récupère ultérieurement au lieu de communiquer directement avec le modèle.

L'IA incite à la sécurité, L’inspection du contenu, les restrictions d’outils et les approbations au niveau de l’action contribuent à empêcher qu’un contexte non fiable ne devienne une instruction exécutable. La protection des invites est également un élément important. AI TRiSM.

3. Empoisonnement contextuel persistant

L’empoisonnement du contexte se produit lorsqu’un attaquant compromet une source sur laquelle un agent s’appuie de manière répétée, telle que :

• un document de politique
• une base de connaissances
• mémoire de l'agent
• une base de données vectorielles
• un enregistrement de configuration
• une invite fournie par le serveur

Contrairement à une simple incitation malveillante, un contexte empoisonné peut influencer les interactions futures jusqu'à ce que l'information affectée soit découverte et corrigée.

Les organisations doivent valider la provenance des données, surveiller les sources fiables afin de détecter les modifications, limiter les personnes autorisées à modifier les données extraites et assurer la traçabilité des données tout au long des flux de travail d'IA. Ces contrôles doivent s'inscrire dans une démarche plus globale. stratégie de sécurité des modèles d'IA.

4. Empoisonnement et ombrage des outils

Un serveur malveillant ou compromis peut exposer un outil contenant :

• un nom trompeur
• une description trompeuse
• comportement caché
• paramètres par défaut non sécurisés
• instructions conçues pour manipuler la sélection des outils

Le phénomène de « masquage d'outil » se produit lorsqu'un outil non sécurisé ressemble suffisamment à un outil légitime pour qu'un hôte, un modèle ou un utilisateur sélectionne la mauvaise fonctionnalité.

Les clients doivent considérer les métadonnées des outils comme non fiables, surveiller les modifications apportées à la définition des outils, afficher les entrées sensibles avant l'exécution, valider les sorties et exiger une confirmation pour les actions qui en découlent.

5. Transmission et exposition des jetons

Le transfert de jeton se produit lorsqu'un serveur MCP accepte un jeton d'un client et transmet ce même jeton à une API en aval.

Le Spécifications officielles d'autorisation MCP exige que les jetons soient validés pour leur public cible et interdit explicitement le transfert de jetons.

Un serveur MCP appelant un service en aval doit obtenir un jeton distinct, émis spécifiquement pour ce service. À défaut, les contrôles d'accès, les limitations de débit, la surveillance et les périmètres d'audit risquent d'être contournés.

Les jetons peuvent également être exposés via :

• journaux de débogage
• URL ou chaînes de requête
• stockage local non sécurisé
• messages d'erreur
• paramètres de l'outil
• services en aval non fiables

Les jetons d'accès doivent avoir une durée de vie limitée, être stockés en toute sécurité, être liés à un public spécifique, être renouvelés le cas échéant et envoyés uniquement via des en-têtes d'autorisation sur des canaux sécurisés.

6. Attaques d'un adjoint confus

Une attaque par délégation confuse se produit lorsqu'un service plus privilégié effectue une action pour un demandeur moins privilégié sans vérifier adéquatement l'autorité de ce dernier.

Par exemple, un proxy MCP peut posséder des identifiants pour un système tiers. S'il vérifie uniquement ses propres autorisations au lieu de celles de l'utilisateur à l'origine de la requête, un attaquant peut l'amener à récupérer ou à modifier des informations auxquelles il ne pourrait pas accéder directement.

Les mesures d'atténuation comprennent :

• consentement par client
• Validation exacte de l'URI de redirection
• validation d'état
• vérifications d'audience des jetons
• identifiants en aval séparés
• vérification de l'autorité de l'utilisateur initiateur

7. Serveurs MCP malveillants ou compromis

Un serveur MCP peut être intentionnellement malveillant, compromis après son déploiement ou affaibli par une dépendance vulnérable.

Un serveur malveillant pourrait :

• retour contexte empoisonné
• dénaturer le comportement de l'outil
• recueillir des invites ou des données sensibles
• exfiltrer des données
• demander des portées excessives
• résultats de l'outil de modification

Les organisations doivent tenir à jour un inventaire des serveurs approuvés et évaluer l'identité de l'éditeur, la propriété, le code source, les dépendances, les autorisations, le stockage des informations d'identification, le comportement du réseau, la journalisation et les processus de mise à jour.

8. Risques liés au serveur local et à la chaîne d'approvisionnement

Les serveurs MCP locaux peuvent être installés via des gestionnaires de paquets, des fichiers de configuration, des dépôts de code source ou des flux de travail d'installation en un clic.

Étant donné qu'ils s'exécutent sur la machine de l'utilisateur, un paquet malveillant ou une commande de démarrage peut hériter des privilèges locaux du client MCP.

Les risques potentiels comprennent :

• exécution de code arbitraire
• vol d'identifiants et de données confidentielles
• accès non autorisé au système de fichiers
• compromis de dépendance
• exfiltration de données
• accès persistant au point de terminaison

Les organisations doivent vérifier les éditeurs, inspecter les commandes d'installation, épingler les versions approuvées, analyser les dépendances, exiger un consentement explicite et isoler les nouveaux serveurs locaux en limitant au maximum l'accès aux fichiers, aux identifiants et au réseau.

9. Supervision humaine insuffisante

Toutes les demandes d'outils ne nécessitent pas une approbation manuelle, mais les opérations à fort impact ne doivent pas être exécutées uniquement parce qu'un modèle prédit qu'elles sont appropriées.

Une approbation humaine ou réglementaire devrait être envisagée pour :

• suppression des données
• modification des autorisations
• transfert de documents sensibles
• exécution du code de production
• effectuer des transactions financières
• modification des infrastructures critiques

Les exigences d'approbation doivent être fondées sur le risque et l'impact. Les organisations peuvent utiliser Gestion des risques liés à l'IA identifier les systèmes et les actions qui nécessitent une surveillance renforcée.

10. Journalisation et auditabilité incomplètes

Les agents peuvent appeler plusieurs outils successivement. Sans télémétrie détaillée, les équipes de sécurité risquent de ne pas pouvoir reconstituer :

• quel utilisateur a initié la requête
• quel agent et quelle identité ont agi
• Quel élément déclencheur a influencé l'action
• Quelles ressources ont été récupérées ?
• quel outil a été sélectionné
• Quels paramètres ont été soumis ?
• quels systèmes en aval ont changé

Les journaux doivent conserver l'intégralité du flux d'activités tout en évitant le stockage inutile d'identifiants, de secrets et de données sensibles.

Risques et mesures d'atténuation en matière de sécurité MCP

Meilleures pratiques de sécurité MCP

Exiger une authentification et une autorisation fortes

Les serveurs MCP distants doivent authentifier chaque connexion et vérifier que les jetons ont été émis spécifiquement pour le serveur qui les reçoit.

Pour l'autorisation basée sur HTTP, utilisez :

• jetons d'accès liés à l'audience
• en-têtes d'autorisation plutôt que paramètres de requête
• PKCE pour la protection du code d'autorisation
• HTTPS pour les points de terminaison d'autorisation
• URI de redirection validées
• stockage sécurisé des jetons
• Durée de vie courte des jetons lorsque cela est approprié

L'autorisation reste facultative au niveau du protocole, car les déploiements locaux ou restreints peuvent utiliser d'autres modèles de sécurité. Pour les serveurs en réseau accédant aux systèmes d'entreprise, une authentification et une autorisation fortes sont obligatoires.

Éliminer le transfert de jetons

Ne transmettez pas directement un jeton reçu d'un client MCP à une API en aval.

Le serveur MCP doit valider le jeton qui lui est destiné et s'authentifier séparément auprès du service en aval à l'aide d'identifiants valides. Ceci garantit le respect des limites d'accès, le consentement de l'utilisateur, les limitations de débit, la validation des requêtes, l'auditabilité et les politiques spécifiques au service.

Appliquer le principe du moindre privilège partout

moindre privilège devrait s'appliquer à :

• utilisateurs humains
• Agents d'intelligence artificielle
• Clients et serveurs MCP
• comptes de service
• outils
• API en aval

Distinguez les outils de lecture seule de ceux qui modifient les données. Limitez l'utilisation des outils à des ressources, actions, environnements et périodes spécifiques.

Examiner régulièrement permissions héritées et supprimer les accès obsolètes ou inutiles.

Valider les outils et exiger une approbation fondée sur les risques

Les serveurs doivent valider chaque entrée par rapport à un schéma strict et appliquer une autorisation avant exécution.

Les clients devraient :

• vérifier les définitions des outils et les éditeurs
• Surveiller les descriptions et les schémas pour détecter les modifications
• afficher les entrées sensibles avant l'exécution
• nettoyer et valider les résultats
• définir des délais d'expiration et des limites de ressources
• l'outil de journalisation utilise

Les actions à haut risque peuvent également nécessiter une confirmation de l'utilisateur, l'approbation du responsable, une évaluation des politiques, une autorisation à deux personnes ou une authentification renforcée.

Sandbox Nouveaux serveurs et protection des sessions

Tester les nouveaux composants MCP ou les composants non fiables dans des environnements isolés avec des restrictions :

• connectivité réseau
• accès au système de fichiers
• variables d'environnement
• informations d'identification
• outils en aval
• données de production

Pour les serveurs HTTP locaux, connectez-vous à localhost et validez les en-têtes Origin.

Les serveurs doivent authentifier chaque requête entrante et ne pas considérer l'identifiant de session comme une preuve d'identité. Il convient de générer des identifiants imprévisibles, d'associer les sessions aux utilisateurs authentifiés, de les faire expirer de manière appropriée et de se prémunir contre les attaques par rejeu ou injection d'événements.

Protégez les données sensibles avant d'exposer le contexte

Avant de rendre le contexte d'entreprise disponible via MCP, il est important de comprendre :

• Quelles données existent ?
• où résident les données sensibles
• quelles ressources l'exposent
• quels agents peuvent le récupérer
• si l'accès est nécessaire
• comment les informations sont utilisées après leur récupération

Découverte et classification des données Fournir le contexte nécessaire pour restreindre l'accès en fonction de la sensibilité, de la réglementation, de la propriété et des objectifs commerciaux.

Surveiller l'activité d'exécution MCP

Tenir un inventaire des hôtes, clients, serveurs, outils, ressources, identités, identifiants et permissions.

Surveiller :

• chaînes d'outils inhabituelles
• accès inattendu à des données sensibles
• serveurs nouveaux ou non approuvés
• description des outils modifiée
• élévation de privilèges
• échecs d'autorisation répétés
• activité en dehors du but prévu par l'agent

Élaborer un plan de réponse aux incidents MCP

Les procédures d'incident doivent couvrir :

• révocation des identifiants du serveur et de l'agent
• désactiver les outils compromis
• déconnexion des serveurs malveillants
• isolement des hôtes affectés
• examen de l'historique des invites et des appels d'outils
• identification des données exposées
• restauration du contexte de confiance
• documentation des mesures correctives

Comment BigID sécurise l'accès MCP d'entreprise

Le serveur MCP de BigID offre aux agents d'IA un accès contrôlé aux données contextuelles et aux informations de l'entreprise.

Au lieu d'exposer des données brutes d'entreprise sans restriction, BigID fournit aux agents autorisés des métadonnées et des informations telles que :

• classifications de données
• sensibilité
• lignée
• possession
• risque
• rétention
• contexte de conformité
• recommandations de remédiation

BigID utilise l'authentification par jeton et le contrôle d'accès basé sur les rôles afin que les agents ne reçoivent que les métadonnées et les informations accessibles à l'utilisateur authentifié. Ceci étend les contrôles de sécurité et de gouvernance existants aux flux de travail compatibles avec MCP.

Avec BigID MCP Server, les organisations peuvent :

• connecter les agents d'IA aux données d'entreprise gouvernées
• Interroger le contexte des données en utilisant le langage naturel
• découvrir les risques liés aux données sensibles
• générer des rapports et des tableaux de bord contextuels
• Étendre les politiques de données aux flux de travail d'IA
• préserver les restrictions d'accès basées sur les rôles
• soutenir les opérations auditables assistées par l'IA

À travers BigID sans interface graphique, Les flux de travail d'IA approuvés peuvent également invoquer des capacités de découverte, de classification, de contrôle d'accès, d'étiquetage, de rédaction et de correction régies via des API et des points de terminaison MCP tout en restant soumis aux contrôles RBAC et d'audit.

L'essentiel

MCP peut rendre les applications d'IA plus utiles en les connectant aux outils et aux données de l'entreprise.

Cela peut également donner aux systèmes d'IA accès à des ressources sensibles et à des actions importantes.

La sécurisation de MCP ne se limite pas au chiffrement de la connexion. Les organisations doivent maîtriser les serveurs, les outils, les identités, les autorisations, les jetons, les données, les invites et les comportements autonomes liés à chaque intégration.

Les programmes de sécurité MCP les plus performants combinent :

• Inventaires approuvés des serveurs et des outils
• authentification et autorisation fortes
• accréditations destinées au public
• accès au moindre privilège
• protection rapide et contextuelle
• surveillance humaine
• surveillance continue en temps réel
• application des politiques tenant compte des données

Le MCP devrait fournir aux agents d'IA le contexte dont ils ont besoin, et non un accès illimité à tout ce que possède l'entreprise.

Foire aux questions sur la sécurité MCP

Qu'est-ce que la sécurité MCP ?

La sécurité MCP consiste à protéger les hôtes, les clients, les serveurs, les outils, les ressources, les informations d'identification, les données, les sessions et les actions des agents impliqués dans les intégrations du protocole de contexte modèle.

Le protocole MCP (Model Context Protocol) est-il sécurisé ?

MCP fournit un protocole de connexion standardisé, mais ne garantit pas la sécurité à lui seul. Les déploiements sécurisés nécessitent l'authentification, l'autorisation, le principe du moindre privilège, la validation des outils, le contrôle des données, la surveillance et le consentement de l'utilisateur.

Quels sont les principaux risques de sécurité liés aux MCP ?

Les principaux risques comprennent l'injection rapide, l'empoisonnement du contexte, les autorisations excessives des agents, les serveurs malveillants, l'empoisonnement des outils, l'exposition des jetons, le transfert de jetons, les attaques par procuration confuse, la compromission de la chaîne d'approvisionnement et une surveillance insuffisante.

Qu'est-ce que le token passthrough dans MCP ?

Le transfert de jeton se produit lorsqu'un serveur MCP accepte un jeton client et le transmet à un service en aval. La spécification MCP interdit ce modèle car il affaiblit la validation de l'audience, les contrôles de sécurité, le consentement et l'auditabilité.

Comment le principe du moindre privilège améliore-t-il la sécurité des MCP ?

Le principe du moindre privilège limite chaque utilisateur, agent, serveur et outil aux données et actions nécessaires à une tâche approuvée. Cela réduit l'impact potentiel des identifiants compromis, des invites malveillantes et des actions autonomes non intentionnelles.

Comment les organisations peuvent-elles prévenir l'injection rapide de MCP ?

Les organisations peuvent réduire le risque d'injection de prompts en traitant le contenu externe comme non fiable, en séparant les instructions des données, en inspectant le contexte récupéré, en limitant l'accès aux outils, en validant les résultats et en exigeant une approbation pour les actions sensibles.

Qu’est-ce que l’empoisonnement des outils dans MCP ?

L’empoisonnement d’outils se produit lorsqu’un serveur malveillant ou compromis fournit des noms, des descriptions, des paramètres, des annotations ou un comportement d’outil trompeurs destinés à manipuler une application d’IA pour qu’elle invoque une capacité non sécurisée.

MCP est-il sûr pour une utilisation en entreprise ?

MCP peut être utilisé en toute sécurité dans les environnements d'entreprise lorsque les organisations approuvent et inventorient les serveurs, appliquent des contrôles d'identité stricts, limitent les autorisations des outils, protègent les données sensibles, valident les informations d'identification, surveillent l'activité d'exécution et exigent une supervision des actions conséquentes.

En quoi la sécurité MCP diffère-t-elle de la sécurité API ?

La sécurité des API traditionnelles se concentre principalement sur les points de terminaison, l'authentification, l'autorisation, la validation des entrées et la protection du trafic. La sécurité des MCP doit également prendre en compte la sélection d'outils basée sur un modèle, le contexte récupéré non fiable, l'injection de prompts, les chaînes d'actions autonomes, la découverte dynamique des capacités et les identités des agents.

Comment BigID prend-il en charge la sécurité MCP ?

BigID offre aux agents d'IA un accès contrôlé au contexte et aux métadonnées des données d'entreprise, tout en appliquant une authentification par jeton, des contrôles d'accès basés sur les rôles, des informations sur la sensibilité des données, des contrôles de politique et les autorisations de gouvernance des données existantes.