Directives de conformité MCP

Vue d'ensemble (Overview)

Les serveurs MCP UiPath permettent aux Agents de tirer parti d’outils et du code externes via le protocole MCP (Model Context Protocol).

Cela comprend :

• UiPath : ici, les clients peuvent utiliser directement comme outils d’autres composants UiPath tels que les Processes, les workflows d’API, etc.
• Distant : connexion à des services tiers, exécution de code personnalisé (CodedServers) ou exécution de commandes scriptées (CommandServers).

Bien que UiPath Platform garantisse une communication et une gouvernance sécurisées pour ces intégrations, tous les points de terminaison externes ou tout code personnalisé fonctionnent en dehors des limites de sécurité de la plateforme principale.Cela signifie qu’une fois que les données ou les Actions ont quitté l’environnement contrôlé d'UiPath, le client assume la responsabilité de leur sécurité et de leur conformité. En pratique, UiPath garantit le chiffrement en transit et au repos dans ses services et applique l’accès basé sur les rôles, mais la confidentialité des données, la sécurité des points de terminaison et la conformité réglementaire pour tout ce qui se trouve en dehors d’UiPath (les serveurs externes ou le code) restent la responsabilité du client.

Important : UiPath ne gère pas vos serveurs ou votre code externes - la sécurité et la fiabilité de ces composants sont sous votre contrôle. Par conséquent, l’utilisation des intégrations de MCP nécessite une attention particulière quant à la façon dont les secrets sont gérés, quels points de terminaison sont approuvés et quel code est exécuté afin de répondre aux exigences de conformité de votre organisation.

Implications de sécurité de RemoteServers, CodedServers et CommandServers

Serveurs distants

Une configuration RemoteServer définit une connexion à un point de terminaison HTTP(S) externe (pour le transport MCP StreamableHttp). Au niveau de la sécurité, toutes les données envoyées à, ou reçues de, ce service externe sont hors du contrôle direct d’UiPath.Si RemoteServer nécessite une authentification (clés API, jetons, etc.), les utilisateurs pourraient être tentés d’intégrer ces secrets directement dans les en-têtes HTTP ou les URL. Stocker les secrets directement dans la configuration est risqué - bien que le service MCP UiPath masque ces valeurs d’en-tête sensibles dans l’IU et les chiffre dans la base de données au repos, elles transitent toujours par le système et pourraient être exposées si elles ne sont pas gérées correctement.En outre, les champs tels que l’URL du point de terminaison, la charge utile du corps ou les paramètres de requête ne sont pas chiffrés dans la base de données de sorte qu'aucune donnée sensible ne doit jamais être mise dans ces champs.Les données quittant vers un point de terminaison externe pourraient être interceptées ou mal utilisées si le point de terminaison est compromis ou si les communications ne sont pas sécurisées.En bref, les RemoteServers étendent votre automatisation aux réseaux externes de sorte que vous devez vous assurer que ces points de terminaison sont fiables et qu'aucun secret ou information sensible ne fuite pendant le transit.

CodedServers et CommandServers

Les CodedServers font référence au code personnalisé (par exemple, un script ou un programme Python) que vous packagez et exécutez dans le cadre d’un agent tandis que les CommandServers exécutent des commandes shell ou des scripts dans un Runtime sans serveur.Tous deux exécutent la logique fournie par l’utilisateur dans des conteneurs éphémères sans serveur orchestrés par UiPath. Du point de vue de la sécurité, cela signifie que votre code s’exécute avec certains privilèges dans l’environnement Cloud UiPath - notamment qu’il s’exécute dans le contexte de votre organisation et qu’il transporte un jeton d’authentification (jeton porteur) qui appartient à votre organisation/utilisateur pour être rappelé dans les services UiPath.La principale implication est que tout code que vous exécutez est intrinsèquement approuvé avec ce jeton et potentiellement d’autres variables d’environnement. Si vous exécutez un code malveillant ou non vérifié, il pourrait voler le jeton ou d’autres Infos sensibles et effectuer des opérations non autorisées.Un code non approuvé ne doit jamais être utilisé dans des CodedServers/CommandServers, car il pourrait exfiltrer les données ou abuser des privilèges accordés.Même un code bien intentionné pourrait comporter des vulnérabilités que les attaquants exploitent pour obtenir l'accès. En outre, ces conteneurs pourraient avoir accès à certaines variables d’environnement (pour la configuration, les informations d’identification, etc.) qui doivent être considérées comme des surfaces sensibles - un code malveillant peut les lire en mémoire.

En résumé, exécuter du code ou des commandes personnalisés signifie que vous assumez les risques du comportement de ce code.Seul un code hautement approuvé et examiné doit être déployé, et il doit suivre des pratiques de codage sécurisées.

Au-delà de ces composants spécifiques, l’utilisation de MCP introduit un modèle de responsabilité partagée : UiPath fournit la sécurité de la plateforme (conteneurs d’exécution isolés, chiffrement des données au repos, protections réseau et certifications de conformité pour la plateforme Cloud), mais vous êtes responsable de la sécurité de tous les systèmes externes que vous connectez et du contenu que vous exécutez. Les sections suivantes décrivent les meilleures pratiques afin de vous acquitter de votre côté de cette responsabilité.

Pratiques de sécurité recommandées

Pour utiliser les intégrations MCP en toute sécurité et répondre aux exigences de conformité, implémentez les meilleures pratiques suivantes.

1. Gestion sécurisée des secrets (en-têtes et ressources RemoteServer)

Il est fortement recommandé de ne pas stocker les secrets sensibles (clés API, jetons, informations d’identification) directement dans les configurations RemoteServer. Bien que la plateforme chiffre les valeurs de l’en-tête secret au repos et les masque dans l’IU, cette approche n’est pas idéale. Les secrets en cours de configuration peuvent toujours apparaître dans les journaux ou être exposés par inadvertance, et aucun autre champ, à l’exception des en-têtes secrets désignés, n’est chiffré. Ne placez pas de données sensibles en Text brut dans des champs tels que les URL, les paramètres de requête ou les corps de la requête.

Approche recommandée

Utilisez les ressources d'Orchestrator de type « Secret » pour gérer les clés sensibles et référencez-les dans vos en-têtes ou paramètres RemoteServer.

Par exemple, stockez une clé API dans une ressource nommée MY_API_KEY (les ressources dans Orchestrator sont chiffrées au repos par défaut). Dans la configuration de l'en-tête RemoteServer, au lieu d'entrer la valeur de la clé, utilisez une référence d'espace réservé : Autorisation : Bearer %Assets/MY_API_KEY%. Lorsque l’agent s'exécute, la plateforme remplacera le secret réel lors du Runtime.

De cette façon, le secret n'est jamais stocké en Text brut dans les paramètres de RemoteServer - il reste en toute sécurité dans le coffre des ressources.L’IU affichera uniquement un espace réservé masqué.Cette pratique permet d’éviter l’exposition accidentelle des secrets et s’aligne sur le principe de non-codage en dur des informations d’identification.

Argument ultime : maintenez les secrets hors du code et des configurations de votre agent. Centralisez-les dans des magasins sécurisés. Faites régulièrement pivoter les clés API et n’intégrez jamais de secrets directement dans le code ou les requêtes HTTP.

2. Contrôles des points de terminaison et réseau approuvés (configuration RemoteServer)

Lors de la configuration de RemoteServers, connectez-vous uniquement à des points de terminaison externes approuvés.Chaque RemoteServer doit pointer vers un domaine ou un service dont votre Organization a validé la sécurité, la confidentialité et la conformité.Traitez une nouvelle API ou un nouveau service tiers comme un fournisseur - assurez-vous qu’il répond à vos normes de sécurité (par exemple, il dispose des certifications appropriées, utilise le chiffrement et gèrera vos données de manière appropriée).

Utilisez HTTPS pour tous les appels externes.Spécifiez toujours des URL https:// afin que le trafic soit chiffré en transit. Appliquez TLS 1.2 ou une version ultérieure pour la connexion. La plateforme communiquera sur TLS par défaut ; en tant que client, vous devez vérifier que le point de terminaison dispose d'un certificat valide et d'un chiffrement fort. N’utilisez jamais HTTP simple pour les communications de l’agent, car il pourrait être intercepté.

Point clé : traitez les appels externes comme des extensions de votre environnement informatique. Vérifiez la sécurité du service externe (SSL/TLS activé, aucun certificat auto-signé ou expiré, etc.) et envoyez-lui uniquement des données si vous lui faites confiance. Un point de terminaison compromis ou malveillant pourrait voler des données ou injecter des réponses préjudiciables de sorte qu'une diligence raisonnable est critique concernant les serveurs externes.

3. Exécution sûre de CodedServers/CommandServers (code approuvé uniquement)

Pour CodedServers et CommandServers, la sécurité dépend largement du code que vous exécutez.N’exécutez jamais un code non approuvé ou tiers sans un examen approfondi. Les conteneurs d’agent exécutent votre code avec un jeton d’accès qui peut appeler les API UiPath (et potentiellement d’autres intégrations). Un code malveillant pourrait capturer ce jeton porteur ou d’autres secrets d’environnement et les exfiltrer, ou effectuer des actions destructrices via les API de la plateforme.Il pourrait également tenter d’exploiter le Runtime du conteneur bien que les conteneurs sans serveur d’UiPath soient isolés et ne s’exécutent pas avec des privilèges élevés par défaut.

Pour atténuer ces risques :

• Utilisez des examens de code internes et la vérification des sources. Si vous incorporez des bibliothèques ou des exemples open source dans un agent codé, examinez ce code pour détecter les problèmes de sécurité (portes dérobées, logique d’exfiltration des données, etc.). Obtenez uniquement les bibliothèques à partir de référentiels de package officiels approuvés.
• Analysez le code et les dépendances à la recherche de vulnérabilités. Employez les tests de sécurité des applications statiques (SAST) sur votre code d’agent et utilisez des scanners de vulnérabilités de dépendance (comme OWASP Dependency Check, Snyk, etc.) sur tous les packages que vous utilisez.Cela permet de détecter les failles connues (par exemple, un package qui pourrait permettre l’exécution de code à distance) avant le déploiement. Il est conseillé d’effectuer une analyse continue étant donné que de nouvelles vulnérabilités dans les bibliothèques peuvent survenir au fil du temps.
• Limitez ce que le code peut faire. Bien que le conteneur soit éphémère, vous devez toujours coder de manière défensive. Par exemple, évitez de transmettre une entrée non validée à votre code (pour éviter les attaques par injection). En principe, minimisez la surface d’attaque dans le conteneur.Idéalement, le code doit uniquement effectuer sa fonction prévue et rien de plus.
• Soyez conscient des variables d’environnement et de l’accès au système de fichiers. Supposons que tout secret accessible au conteneur (par exemple, le jeton d’authentification de l’agent ou autres informations d’identification transmises dans les variables d'environnement) peut être lu par votre code.Ne journalisez pas ces valeurs et ne les envoyez pas vers des emplacements externes.De plus, tandis que vous pouvez disposer d’un espace de stockage temporaire dans le conteneur, n’écrivez pas inutilement d’informations sensibles sur le disque et, si vous le faites, supprimez-les avant de terminer.

En résumé, traitez l’environnement d’exécution de code de l’agent comme vous le feriez avec un serveur de production ayant un accès sensible : exécutez uniquement un code approuvé, suivez des pratiques de codage sécurisées et effectuez des tests de sécurité. La plateforme d’UiPath fournit une sandbox sécurisée et garantit que le code s’exécute dans le contexte de votre compte, mais elle n’inspecte pas ni ne met en sandbox la logique de votre code au niveau granulaire - cette responsabilité vous incombe.

4. Gestion et confidentialité des données

Évitez d’envoyer des données sensibles à des outils externes sauf si cela est absolument nécessaire.Toutes les données qui quittent UiPath Platform vers une API ou un service externe doivent être considérées comme étant à risque d’exposition.Dans la mesure du possible, masquez ou rédigez les données personnelles ou les informations réglementées avant de les envoyer à un RemoteServer. Par exemple, si un agent résume les données client via une API d’IA externe, envisagez de supprimer ou d’anonymiser les identificateurs dans l’invite.Cette pratique de minimisation des données garantit la conformité avec les réglementations sur la confidentialité (RGPD, HIPAA, etc.) en n’exposant pas les données protégées à des systèmes pouvant ne pas être régis par ces accords.

Si vous devez envoyer des informations sensibles, assurez-vous que le fournisseur externe garantit contractuellement la protection des données (par exemple, les données ne sont pas stockées ou utilisées à d’autres fins). Vérifiez la résidence des données du service externe - envoyer des données à un point de terminaison situé dans une autre région pourrait violer les politiques de votre entreprise si cette opération n'est pas prise en compte.Alignez toujours votre utilisation de points de terminaison externes sur les exigences de conformité de votre organisation (par exemple, assurez-vous que le service tiers dispose de certifications telles que SOC 2, ISO 27001 ou d’autres certifications pertinentes pour votre secteur).

Sur UiPath Platform, toutes les activités de l’agent sont journalisées, y compris l’utilisation des outils et les données transmises aux outils, dans la mesure du possible.Exploitez ces journaux pour vous assurer qu’aucune donnée involontaire n’est envoyée. Examinez périodiquement les informations que vos Agents gèrent et envoient en externe.Si vous constatez, par exemple, qu’un agent inclut un numéro de sécurité sociale dans une demande envoyée à un RemoteServer, envisagez de réviser la logique de l’agent pour hacher ou supprimer ces données.

Si vous utilisez des CodedServers/Command Servers MCP, la journalisation relève de votre responsabilité.Ne journalisez jamais de données sensibles telles que les PII ou les informations de sécurité.

Tenez également compte des données de sortie des services externes. Une IA ou un script externe pourrait renvoyer des Infos sensibles (ou même du contenu malveillant).Implémentez la validation des sorties lorsque cela est faisable.Par exemple, si un RemoteServer renvoie une réponse qui sera utilisée dans une décision, assurez-vous que la réponse est dans le format et la plage attendus. Cela vous protège contre toute manipulation ou 0tout comportement inattendu de la part de systèmes externes.

En bref, traitez les intégrations externes comme faisant partie de vos diagrammes de flux de données à des fins de conformité - documentez quelles données quittent la plateforme et via quel service.Cela vous aidera à évaluer les risques et à effectuer des audits.Préférez toujours partager la quantité minimale d’informations requises pour la tâche (principe du besoin de savoir pour les données).

5. Contrôle d'accès

L’accès pour configurer et utiliser des intégrations MCP doit lui-même être étroitement contrôlé. Seuls les Administrators ou les utilisateurs hautement approuvés doivent être capables de créer ou modifier les configurations RemoteServers, CodedServers ou CommandServers. Exploitez le contrôle d’accès basé sur les rôles (RBAC) d’Orchestrator pour restreindre ces fonctionnalités. Par exemple, vous pourriez avoir un rôle spécifique pour « Gestionnaire des intégrations d’agent » et l’affecter uniquement aux membres de votre équipe du Center of Excellence ou de sécurité informatique.Cela empêche les Automation Developers ou les utilisateurs métier ordinaires d’ajouter par inadvertance des connexions insécurisées ou d’exécuter un code arbitraire.Chaque nouvel outil de serveur MCP ou d'agent ajouté doit passer par un processus d'examen.

Lors de l’affectation de rôles et d’autorisations, appliquez le principe du moindre privilège. Définissez des rôles de portée étroite qui permettent aux utilisateurs de faire uniquement ce dont ils ont besoin pour leur tâche.Par exemple, si un agent doit uniquement lire certaines données ou exécuter des Processes spécifiques, assurez-vous que le compte l'exécutant ne dispose pas d’un accès plus large à d’autres données ou fonctions administratives.Évitez d’exécuter des Agents sous un compte administrateur Orchestrator complet. Utilisez plutôt un compte de service dédié avec des droits minimaux. De cette façon, même si le jeton d’un agent est compromis, les dommages potentiels sont limités par l’étendue de ce compte.

Surveillez les journaux d’exécution des Agents. L’utilisation de tous les outils par les Agents est suivie et enregistrée de manière cohérente. En examinant ces journaux, vous pouvez détecter des anomalies (telles qu’un agent appelant un point de terminaison qu’il n’appelle normalement pas ou s’exécutant à des heures impaires).

Il est sage d’effectuer des vérifications de conformité périodiques sur les configurations de service MCP : exportez une liste de tous les RemoteServers configurés et vérifiez qu’ils figurent sur la liste approuvée ; vérifiez qu’aucune information d’identification n’est exposée dans les descriptions ou les champs ; vérifiez que tous les CodedServers/CommandServers correspondent au code qui a réussi un examen de sécurité.Maintenez un inventaire de ces « outils d’agent » semblable à un inventaire des ressources informatiques.

Enfin, assurez-vous que votre plan de réponse aux incidents couvre les scénarios de service MCP. Par exemple, si un point de terminaison externe est violé ou une clé API est divulguée, disposez d'une procédure pour révoquer rapidement ce RemoteServer ou faire pivoter le Credential.Étant donné qu’UiPath fera partie de votre environnement Enterprise intégré, votre équipe de sécurité doit connaître ces fonctionnalités et les inclure dans les modèles de menace et les exercices de réponse.

En contrôlant l’accès, en surveillant l’activité et en enquêtant rapidement sur toute irrégularité, vous préservez votre part du modèle de responsabilité partagée - maintenant la sécurité et la conformité de la façon dont les puissantes fonctionnalités de la plateforme sont utilisées.

Ségrégation des responsabilités (UiPath versus client)

L'utilisation de MCP implique un modèle de responsabilité partagée entre UiPath et le client. La table suivante résume les aspects de la sécurité qui sont gérés par UiPath Platform et ceux qui sont sous la responsabilité du client :

Tableau 1. UiPath vs responsabilités du client

Area	Responsabilité d’UiPath	Responsabilité du client
Sécurité de la plateforme	Infrastructure Cloud sécurisée et isolation des conteneurs pour l’exécution de l’agent. Application du chiffrement en transit (TLS) et au repos dans UiPath Cloud. Contrôle d’accès basé sur les rôles (RBAC) et authentification au sein de la plateforme.	Utilisation sécurisée de la plateforme.Limitez l’accès à la plateforme au personnel autorisé.Configurez les rôles et les autorisations suivant le moindre privilège. Protégez les points de terminaison externes auxquels la plateforme se connecte (assurez-vous qu’ils disposent des contrôles de sécurité, de l’authentification et des certifications de conformité appropriés). Gérez les contrôles réseau afin que seul le trafic approuvé circule vers/depuis UiPath.
Gestion des informations d'identification	Chiffrement des informations d’identification stockées dans les ressources d'Orchestrator ou Integration Service. Les secrets dans les ressources sont masqués et protégés par la plateforme.Injection sécurisée des informations d’identification au moment du Runtime (par exemple, substitution de %Assets/KEY%). Aucun secret n’est conservé dans les journaux ou le texte brut par la plateforme.	Stockez et gérez les secrets de manière responsable. Utilisez les magasins sécurisés fournis (ressources, etc.) - ne codez pas les secrets en dur dans le code ou les configurations.Faites régulièrement pivoter vos informations d’identification externes et supprimez toutes les clés inutilisées.Si vous utilisez des services tiers, gérez les clés API ou les jetons de ce côté (par exemple, révoquez-les s'ils sont compromis).Assurez-vous que tout secret exposé à un agent (même temporairement) est traité avec soin de votre côté (par exemple, non réutilisé ailleurs).
Environnement d’exécution	Fournit un conteneur éphémère isolé pour CodedServers/CommandServers.Garantit que chaque exécution dispose d’un jeton porteur à l'échelle et ne peut pas affecter directement d’autres locataires ou le SE hôte.Journalise les actions de l’outil d'agent à des fins d’audit.Applique les délais d’expiration et les limites de ressources pour réduire l’impact du code absent.	Sécurité et intégrité du code.Déployer uniquement un code qui est sécurisé et nécessaire.N'exécutez pas de code non approuvé ou non vérifié.Validez toute la logique personnalisée et effectuez des tests de sécurité (examens de code, analyses de vulnérabilités). Vous êtes responsable des actions de votre code - s’il supprime des données ou divulgue des informations, c’est votre responsabilité.Traitez les variables d’environnement et toutes les données dans un conteneur comme sensibles (car elles peuvent contenir des jetons ou des données privées). Remédiez rapidement à toute vulnérabilité de votre code ou de vos bibliothèques (la plateforme ne saura pas si votre code comporte une faille – vous devez la gérer).
Gestion des données	Chiffre toutes les données en transit entre les conteneurs d’agent et les services UiPath. Fournit des journaux d’audit et la surveillance des données qui transitent par la plateforme (qui a exécuté quoi, quand et toutes les entrées/sorties journalisées).Prend en charge les mesures de conformité telles que le masquage des données, le stockage sécurisé et les clés de chiffrement gérées par le client pour les données au sein d'UiPath platform.	Protégez les données qui quittent la plateforme.Déterminez les données pouvant être envoyées aux points de terminaison externes ou traitées par un code externe. Masquez ou évitez d’envoyer les PII/PHI à moins que le système externe ne soit approuvé à cet effet.Assurez-vous que les points de terminaison externes suivent les exigences de résidence et de rétention des données (une fois que les données quittent UiPath, leur confidentialité est votre responsabilité). Implémentez un chiffrement ou une pseudonymisation supplémentaire pour les données particulièrement sensibles avant qu’elles ne soient envoyées à un service externe.
Surveillance et réponse	Fournit une journalisation centralisée, des alertes et des pistes d’audit pour les Actions sur la plateforme (modifications de configuration, exécutions d’agent, erreurs).Permet l’intégration aux outils SIEM via OpenTelemetry et d’autres interfaces. L’assistance UiPath peut aider en cas d’incidents au niveau de la plateforme (par exemple, pannes d'infrastructure, utilisation abusive de la plateforme) et fournit des journaux d'audit pour faciliter les investigations.	Surveillez votre utilisation et répondez aux incidents. Examinez régulièrement les journaux d’exécution de l’agent et les pistes d’audit pour détecter les anomalies. Détectez et répondez à toute activité suspecte (par exemple, un agent effectuant des appels externes inhabituels). Si une intégration externe est violée ou mal utilisée, c'est à vous de désactiver cette intégration et de gérer l'incident du côté externe. Planifiez Disaster Recovery et la réponse aux incidents impliquant des systèmes externes (par exemple, disposez de runbooks pour faire pivoter les clés ou changer de points de terminaison si nécessaire).Vous devez gérer tout rapport de conformité relatif aux données ou aux Processes impliquant les intégrations d’agent (UiPath peut fournir des données sur les opérations de la plateforme, mais vous signalez le processus de bout en bout).

Cette ségrégation des responsabilités s'aligne sur le modèle général de responsabilité partagée du Cloud : UiPath sécurise la plateforme et vous devez sécuriser la façon dont vous l'utilisez et toutes ses extensions. Assurez-vous que vos politiques internes couvrent l'utilisation de MCP, par exemple une politique selon laquelle toutes les intégrations tierces doivent être approuvées par sécurité, tout le code d'agent personnalisé doit faire l'objet d'un examen de sécurité, etc. En remplissant ces responsabilités, vous garantissez que votre mise en œuvre du service MCP reste conforme aux normes de sécurité de votre organisation.

Avertissement recommandé : lors de l'utilisation du service MCP et de MCP pour étendre UiPath avec du code ou des services externes, les clients sont seuls responsables de la sécurisation, de la gestion et de la maintenance de ces composants externes et de toutes les données qu'ils traitent. UiPath garantit la sécurité au sein de la plateforme (chiffrement, authentification, journalisation), mais ne contrôle ni n'assume la responsabilité des données une fois qu'elles quittent les limites de UiPath plateforme.En pratique, cela signifie que vous devez traiter les points de terminaison externes et le code personnalisé avec la même rigueur que toute autre partie critique de votre système. Les vérifications de conformité ne sont pas un effort ponctuel mais une tâche continue à mesure que vous faites évoluer vos agents et vos intégrations.