MCP servers compliance

Overview

Overview

UiPath MCP Servers allows Agents to leverage external tools and code via the Model Context Protocol (MCP).

This includes:

• UiPath: where customers can directly use as tools other UiPath components, such as processes, API workflows, etc.
• Remote: connecting to third-party services, executing custom code (CodedServers), or running scripted commands (CommandServers).

While the UiPath Platform provides secure communication and governance for these integrations, any external endpoints or custom code operate outside the core platform security boundary. This means that once data or actions leave UiPath’s controlled environment, the customer assumes responsibility for their security and compliance. In practice, UiPath ensures encryption in transit and at rest within its services and enforces role-based access, but data privacy, endpoint security, and regulatory compliance for anything outside UiPath (the external servers or code) remain the customer’s responsibility.

Important:

UiPath does not manage your external servers or code – the security and reliability of those components are under your control. Therefore, using MCP’s integrations requires careful attention to how secrets are handled, which endpoints are trusted, and what code is executed, in order to meet your organization’s compliance requirements.

Security implications of RemoteServers, CodedServers, and CommandServers

RemoteServers

A RemoteServer configuration defines a connection to an external HTTP(S) endpoint (for MCP StreamableHttp transport). The security implication is that any data sent to or received from this external service is outside UiPath’s direct control. If the RemoteServer requires authentication (API keys, tokens, etc.), users might be tempted to embed those secrets directly in the HTTP headers or URLs. Storing secrets directly in configuration is risky – although UiPath MCP service will mask such sensitive header values in the UI and encrypt them in the database at rest, they still transit through the system and could be exposed if not handled properly. Additionally, fields like the endpoint URL, body payload, or query parameters are not encrypted in the database, so no sensitive data should ever be put in those fields. Data leaving to an external endpoint could be intercepted or misused if the endpoint is compromised or if communications are not secure. In short, RemoteServers extend your automation into external networks, so you must ensure those endpoints are trustworthy and that no secrets or sensitive information leak in transit.

CodedServers and CommandServers

CodedServers refer to custom code (e.g. a Python script or program) that you package and run as part of an agent, whereas CommandServers run shell commands or scripts in a serverless runtime. Both execute user-provided logic in ephemeral, serverless containers orchestrated by UiPath. From a security perspective, this means your code runs with certain privileges within the UiPath cloud environment – notably, it runs under your organization’s context and carries an authentication token (bearer token) scoped to your org/user for calling back into UiPath services. The primary implication is that any code you run is inherently trusted with that token and potentially other environment variables. If you run malicious or unverified code, it could steal the token or other sensitive info and perform unauthorized operations. Untrusted code must never be used in CodedServers/CommandServers, because it could exfiltrate data or abuse the privileges granted. Even well-intentioned code could have vulnerabilities that attackers exploit to gain access. Additionally, these containers might have access to certain environment variables (for configuration, credentials, etc.), which should be considered sensitive surfaces – malicious code can read them in memory.

In summary, running custom code or commands means you are taking on the risks of that code’s behavior. Only highly trusted, reviewed code should be deployed, and it should follow secure coding practices.

Beyond these specific components, MCP usage introduces a shared responsibility model: UiPath provides the platform security (isolated execution containers, encryption of data at rest, network protections, and compliance certifications for the cloud platform), but you are responsible for the security of any external systems you connect and content you run. The following sections outline best practices to fulfill your side of this responsibility.

Recommended security practices

To use MCP integrations securely, and to meet compliance requirements, implement the following best practices.

1. Secure secret handling (RemoteServer headers and assets)

It is strongly recommended not to store sensitive secrets (API keys, tokens, credentials) directly in RemoteServer configurations. While the platform will encrypt secret header values at rest and mask them in the UI, this approach is not ideal. Secrets in configuration may still appear in logs or be inadvertently exposed, and no other fields except designated secret headers are encrypted. Do not place sensitive data in plain text in fields like URLs, query parameters, or request bodies.

Recommended approach

Use Orchestrator Assets of type “Secret” to manage sensitive keys, and reference them in your RemoteServer headers or parameters.

For example, store an API key in an Asset named MY_API_KEY (Assets in Orchestrator are encrypted at rest by default). In the RemoteServer header configuration, instead of entering the key value, use a placeholder reference: Authorization: Bearer %Assets/MY_API_KEY%. When the Agent runs, the platform will substitute the actual secret at runtime.

This way, the secret is never stored in plain text in the RemoteServer settings – it remains securely in the Assets vault. The UI will only show a masked placeholder. This practice helps avoid accidental exposure of secrets and aligns with the principle of not hard-coding credentials.

Bottom line: Keep secrets out of your agent code and configs. Centralize them in secure stores. Rotate API keys regularly and never embed secrets directly in code or HTTP requests.

2. Trusted endpoints and network controls (RemoteServer setup)

When configuring RemoteServers, only connect to trusted external endpoints. Each RemoteServer should point to a domain or service that your organization has vetted for security, privacy, and compliance. Treat a new third-party API or service as a vendor – ensure it meets your security standards (e.g. has proper certifications, uses encryption, and will handle your data appropriately).

Use HTTPS for all external calls. Always specify https:// URLs so that traffic is encrypted in transit. Enforce TLS 1.2 or higher for the connection. The platform will communicate over TLS by default; as a customer, you should verify the endpoint has a valid certificate and strong encryption. Never use plain HTTP for agent communications, as it could be intercepted.

Key point: Treat external calls as extensions of your IT environment. Verify the external service’s security (SSL/TLS enabled, no self-signed or expired certs, etc.), and only send data to it if you trust it. A compromised or rogue endpoint could steal data or inject harmful responses, so due diligence on external servers is critical.

3. Safe execution of Coded/Command servers (trusted code only)

For CodedServers and CommandServers, security largely hinges on the code you run. Never run untrusted or third-party code without a thorough review. The agent containers execute your code with an access token that can call UiPath APIs (and potentially other integrations). Malicious code could capture this bearer token or other environment secrets and exfiltrate them, or perform destructive actions via the platform APIs. It could also attempt to exploit the container runtime, although UiPath’s serverless containers are isolated and do not run with elevated privileges by default.

To mitigate these risks:

• Use internal code reviews and source verification. If you incorporate open-source libraries or samples into a coded agent, review that code for security issues (backdoors, data exfiltration logic, etc.). Only obtain libraries from official, trusted package repositories.
• Scan code and dependencies for vulnerabilities. Employ static application security testing (SAST) on your agent code and use dependency vulnerability scanners (like OWASP Dependency Check, Snyk, etc.) on any packages you use. This helps catch known flaws (e.g. a package that might allow remote code execution) before deployment. Continuous scanning is advisable, since new vulnerabilities in libraries can arise over time.
• Limit what the code can do. Although the container is ephemeral, you should still code defensively. For example, avoid passing unvalidated input to your code (to prevent injection attacks). Essentially, minimize the attack surface within the container. The code should ideally perform only its intended function and nothing more.
• Be aware of environment variables and filesystem access. Assume that any secret accessible to the container (for example, the agent’s auth token or other credentials passed in env variables) can be read by your code. Do not log these values or send them to external locations. Also, while you may have some temporary storage in the container, do not write sensitive information to disk unnecessarily, and if you do, delete it before finishing.

In summary, treat the agent’s code execution environment as you would a production server that holds sensitive access: only run trusted code, follow secure coding practices, and perform security testing. UiPath’s platform provides a secure sandbox and ensures the code runs under your account’s context, but it does not inspect or sandbox the logic of your code at a granular level – that responsibility lies with you.

4. Data handling and privacy

Avoid sending sensitive data to external tools unless absolutely necessary. Any data that leaves the UiPath platform to an external API or service should be considered at risk of exposure. Where possible, mask or redact personal data or regulated information before sending it to a RemoteServer*.* For instance, if an agent is summarizing customer data via an external AI API, consider removing or anonymizing identifiers in the prompt. This practice of data minimization ensures compliance with privacy regulations (GDPR, HIPAA, etc.) by not exposing protected data to systems that might not be governed under those agreements.

If you must send sensitive information, make sure the external provider contractually guarantees data protection (e.g. the data is not stored or used for other purposes). Verify the data residency of the external service – sending data to an endpoint in another region might violate your company’s policies if not accounted for. Always align your use of external endpoints with your organization’s compliance requirements (for example, ensure the third-party service has certifications like SOC 2, ISO 27001, or others relevant to your industry).

Within the UiPath platform, all agent activities are logged, including tool usage and data passed to tools, to the extent possible. Leverage these logs to ensure no unintended data is being sent out. Periodically review what information your agents are handling and sending externally. If you find, for example, that an agent is including a Social Security Number in a request to a RemoteServer, consider revising the agent’s logic to hash or remove such data.

If you use Coded/Command MCP servers, the logging is within your responsibillity. Never log sensitive data like PII or security information.

Also be mindful of output data from external services. An external AI or script might return sensitive info (or even malicious content). Implement validation on outputs when feasible. For example, if a RemoteServer returns a response that will be used in a decision, ensure that the response is in the expected format and range. This guards against any manipulation or unexpected behavior from external systems.

In short, treat external integrations as part of your data flow diagrams for compliance – document what data is leaving the platform and through which service. This will help in risk assessments and audits. Always prefer sharing the minimal amount of information required for the task (need-to-know principle for data).

5. Access control

Access to configure and use MCP integrations should itself be tightly controlled. Only administrators or highly trusted users should be able to create or modify RemoteServers, CodedServers, or CommandServers configurations*.* Leverage Orchestrator’s Role-Based Access Control (RBAC) to restrict these capabilities. For example, you might have a specific role for “Agent Integrations Manager” and only assign it to members of your Center of Excellence or IT security team. This prevents ordinary automation developers or business users from inadvertently adding insecure connections or executing arbitrary code. Every new MCP server or agent tool added should go through a review process.

When assigning roles and permissions, enforce the principle of least privilege. Define narrowly scoped roles that allow users to do only what they need for their job. For instance, if an agent only needs to read certain data or execute specific processes, ensure the account running it doesn’t have broader access to other data or administrative functions. Avoid running Agents under a full Orchestrator admin account. Instead, use a dedicated service account with minimal rights. This way, even if an agent’s token is compromised, the potential damage is limited by that account’s scope.

Monitor the execution logs of agents. All tool usage by agents is tracked and recorded in a consistent manner. By reviewing these logs, you can detect anomalies (such as an agent calling an endpoint it normally doesn’t, or running at odd times).

It’s wise to perform periodic compliance checks on MCP service configurations: export a list of all configured RemoteServers and verify they are on the approved list; check that no credentials are exposed in any descriptions or fields; verify that all coded/command servers correspond to code that has passed a security review. Maintain an inventory of these “agent tools” similar to an inventory of IT assets.

Finally, ensure your incident response plan covers MCP service scenarios. For example, if an external endpoint is breached or an API key is leaked, have a procedure to quickly revoke that RemoteServer or rotate the credential. Because UiPath will be a part of your integrated enterprise environment, your security team should be aware of these capabilities and include them in threat models and response drills.

By controlling access, monitoring activity, and promptly investigating any irregularities, you uphold your part of the shared responsibility model – maintaining security and compliance for how the platform’s powerful capabilities are used.

Segregation of responsibilities (UiPath versus customer)

Using MCP involves a shared responsibility model between UiPath and the customer. The following table summarizes which aspects of security are handled by the UiPath platform and which are the customer’s responsibility:

Table 1. UiPath vs customer responsibilities

Area	UiPath responsibility	Customer responsibility
Platform security	Secure cloud infrastructure and container isolation for agent execution. Enforcement of encryption in transit (TLS) and at rest within UiPath Cloud. Role-based access control (RBAC) and authentication within the platform.	Secure usage of the platform. Limit platform access to authorized personnel. Configure roles and permissions following least privilege. Protect external endpoints that the platform connects to (ensure they have appropriate security controls, authentication, and compliance certifications). Manage network controls so only approved traffic flows to/from UiPath.
Credential management	Encryption of credentials stored in Orchestrator Assets or Integration Service. Secrets in assets are hidden and protected by the platform. Secure injection of credentials at runtime (for example, substituting %Assets/KEY%). No secrets are persisted in logs or plaintext by the platform.	Store and manage secrets responsibly. Use the provided secure stores (Assets, etc.) – do not hardcode secrets in code or configs. Rotate your external credentials regularly and remove any unused keys. If using third-party services, manage the API keys or tokens on that side (for example, revoke if compromised). Ensure that any secret exposed to an agent (even temporarily) is treated with care on your end (for example, not reused elsewhere).
Execution environment	Provides an isolated, ephemeral container for Coded/Command servers. Ensures each execution has a scoped bearer token and cannot directly affect other tenants or host OS. Logs agent tool actions for audit. Enforces timeouts and resource limits to reduce impact of runaway code.	Code safety and integrity. Only deploy code that is secure and necessary. Do not run untrusted or unvetted code. Validate all custom logic and perform security testing (code reviews, vulnerability scans). You are liable for what your code does – if it deletes data or leaks information, that’s on your side. Treat environment variables and any in-container data as sensitive (because they may contain tokens or private data). Remediate any vulnerabilities in your code or libraries promptly (the platform won’t know if your code has a flaw – you must manage that).
Data handling	Encrypts all data in transit between agent containers and UiPath services. Provides audit logs and monitoring for data that flows through the platform (who ran what, when, and any logged inputs/outputs). Supports compliance measures like data masking, secure storage, and customer-managed encryption keys for data within the UiPath platform.	Safeguard data that leaves the platform. Determine what data is allowed to be sent to external endpoints or processed by external code. Mask or avoid sending PII/PHI unless the external system is approved for it. Ensure external endpoints follow data residency and retention requirements (once data leaves UiPath, its privacy is your responsibility). Implement additional encryption or pseudonymization for especially sensitive data before it goes to an external service.
Monitoring and response	Provides centralized logging, alerts, and audit trails for actions on the platform (configuration changes, agent runs, errors). Enables integration with SIEM tools via OpenTelemetry and other interfaces. UiPath support can assist with platform-level incidents (e.g. infrastructure outages, platform misuse) and provides audit logs to facilitate investigations.	Monitor your usage and respond to incidents. Regularly review agent run logs and audit trails for anomalies. Detect and respond to any suspicious activity (for example, an agent making unusual external calls). If an external integration is breached or misused, it’s up to you to disable that integration and handle the incident on the external side. Plan for disaster recovery and incident response involving external systems (for example, have runbooks for rotating keys or switching endpoints if needed). Any compliance reporting for the data or processes involving the agent integrations must be managed by you (UiPath can provide data on platform operations, but you report on the end-to-end process).

This segregation of responsibilities aligns with the general cloud shared responsibility model: UiPath secures the platform, and you must secure how you use it and any extensions of it. Make sure your internal policies cover the use of MCP – e.g., a policy that all third-party integrations must be approved by security, all custom agent code must undergo a security review, etc. By fulfilling these responsibilities, you ensure that your implementation of MCP Service remains compliant with your organization’s security standards.

Recommended disclaimer: When using MCP Service and MCP to extend UiPath with external code or services, customers are solely responsible for securing, managing, and maintaining those external components and any data processed by them. UiPath ensures security within the platform (encryption, authentication, logging), but does not control or assume liability for data once it leaves the UiPath platform boundary. In practice, this means you should treat external endpoints and custom code with the same rigor as any other critical part of your system. Compliance checks are not a one-time effort but an ongoing duty as you evolve your agents and integrations.ew

UiPath MCP Servers allows agents to leverage external tools and code via the Model Context Protocol (MCP). This includes UiPath MCPs – where customers can directly use as tools other UiPath components, i.e. processes, API workflows, etc,  connecting to third-party services (RemoteServers), executing custom code (CodedServers), or running scripted commands (CommandServers).

While the UiPath Platform provides secure communication and governance for these integrations, any external endpoints or custom code operate outside the core platform security boundary. This means that once data or actions leave UiPath’s controlled environment, the customer assumes responsibility for their security and compliance. In practice, UiPath ensures encryption in transit and at rest within its services and enforces role-based access, but data privacy, endpoint security, and regulatory compliance for anything outside UiPath (the external servers or code) remain the customer’s responsibility.

Important:

UiPath does manage your external servers or code – the security and reliability of those components are under your control. Therefore, using MCP’s integrations requires careful attention to how secrets are handled, which endpoints are trusted, and what code is executed, in order to meet your organization’s compliance requirements.

Security implications of RemoteServers, CodedServers, and CommandServers

RemoteServers

A RemoteServer configuration defines a connection to an external HTTP(S) endpoint (for MCP StreamableHttp transport). Any data sent to or received from this external service is outside UiPath’s direct control. If the RemoteServer requires authentication (API keys, tokens, etc.), users might be tempted to embed those secrets directly in the HTTP headers or URLs.

Storing secrets directly in configuration is risky. Although UiPath MPC service will mask such sensitive header values in the UI and encrypt them in the database at rest, they still transit through the system and could be exposed if not handled properly. Additionally, fields such as the endpoint URL, body payload, or query parameters are not encrypted in the database, so never input sensitive data in those fields. Data leaving to an external endpoint could be intercepted or misused if the endpoint is compromised or if communications are not secure.

RemoteServers extend your automation into external networks, so you must ensure those endpoints are trustworthy and that no secrets or sensitive information leak in transit.

CodedServers and CommandServers

CodedServers refer to custom code (such as Python script or program) that you package and run as part of an agent, whereas CommandServers run shell commands or scripts in a serverless runtime. Both execute user-provided logic in ephemeral, serverless containers orchestrated by UiPath.

From a security perspective, this means your code runs with certain privileges within the UiPath cloud environment – notably, it runs under your organization’s context and carries an authentication token (bearer token) scoped to your org/user for calling back into UiPath services. Any code you run is inherently trusted with that token and potentially other environment variables. If you run malicious or unverified code, it could steal the token or other sensitive info and perform unauthorized operations.

Untrusted code must never be used in CodedServers/CommandServers, because it could exfiltrate data or abuse the privileges granted. Even well-intentioned code could have vulnerabilities that attackers exploit to gain access. Additionally, these containers might have access to certain environment variables (for configuration, credentials, etc.), which should be considered sensitive surfaces – malicious code can read them in memory. In summary, running custom code or commands means you are taking on the risks of that code’s behavior. Only highly trusted, reviewed code should be deployed, and it should follow secure coding practices.

Beyond these specific components, MCP usage introduces a shared responsibility model: UiPath provides the platform security (isolated execution containers, encryption of data at rest, network protections, and compliance certifications like HIPAA, FedRAMP, ISO 27001, etc. for the cloud platform), but you are responsible for the security of any external systems you connect and content you run.

The following sections outline best practices to fulfill your side of this responsibility.

Recommended security practies

To use MCP integrations securely, and to meet compliance requirements, implement the following best practices.

Secure secret handling (RemoteServer Headers and Assets)

Do not store sensitive secrets (API keys, tokens, credentials) directly in RemoteServer configurations. The platform encrypts secret header values at rest and mask them in the UI, however this approach is not recommended. Secrets in configuration may still appear in logs or be inadvertently exposed, and no other fields except designated secret headers are encrypted. Do not place sensitive data in plain text in fields like URLs, query parameters, or request bodies.

Recommended approach

Use Orchestrator assets of type Secret to manage sensitive keys, and reference them in your RemoteServer headers or parameters.

For example, store an API key in an asset named MY_API_KEY (assets in Orchestrator are encrypted at rest by default). In the RemoteServer header configuration, instead of entering the key value, use a placeholder reference: Authorization: Bearer %Assets/MY_API_KEY%. When the agent runs, the platform substitutes the actual secret at runtime.

This way, the secret is never stored in plain text in the RemoteServer settings, as it remains securely in the Assets vault. The UI only displays a masked placeholder. This practice helps avoid accidental exposure of secrets and aligns with the principle of not hard-coding credentials.

Important:

Keep secrets out of your agent code and configs. Centralize them in secure stores. Rotate API keys regularly and never embed secrets directly in code or HTTP requests.

Trusted endpoints and network controls (RemoteServer setup)

When configuring RemoteServers, only connect to trusted external endpoints. Each RemoteServer should point to a domain or service that your organization has vetted for security, privacy, and compliance. Treat a new third-party API or service as a vendor and ensure it meets your security standards (e.g. has proper certifications, uses encryption, and handles your data appropriately).

Use HTTPS for all external calls. Always specify https://` URLs so that traffic is encrypted in transit. Enforce TLS 1.2 or higher for the connection. The platform will communicate over TLS by default; as a customer, you should verify the endpoint has a valid certificate and strong encryption. Never use plain HTTP for agent communications, as it could be intercepted.

Treat external calls as extensions of your IT environment. Verify the external service’s security (SSL/TLS enabled, no self-signed or expired certs, etc.), and only send data to it if you trust it. A compromised or rogue endpoint could steal data or inject harmful responses, so due diligence on external servers is critical.

Safe execution of coded/command Servers (trusted code only)

For CodedServers and CommandServers, security largely hinges on the code you run. Never run untrusted or third-party code without a thorough review. The agent containers execute your code with an access token that can call UiPath APIs (and potentially other integrations). Malicious code could capture this bearer token or other environment secrets and exfiltrate them, or perform destructive actions via the platform APIs. It could also attempt to exploit the container runtime, although UiPath’s serverless containers are isolated and do not run with elevated privileges by default.

To mitigate these risks:

• Use internal code reviews and source verification. If you incorporate open-source libraries or samples into a coded agent, review that code for security issues (backdoors, data exfiltration logic, etc.). Only obtain libraries from official, trusted package repositories.

• Scan code and dependencies for vulnerabilities. Employ static application security testing (SAST) on your agent code and use dependency vulnerability scanners (like OWASP Dependency Check, Snyk, etc.) on any packages you use. This helps catch known flaws (e.g. a package that might allow remote code execution) before deployment. Continuous scanning is advisable, since new vulnerabilities in libraries can arise over time.

• Limit what the code can do. Although the container is ephemeral, you should still code defensively. For example, avoid passing unvalidated to your code (to prevent injection attacks). Essentially, minimize the attack surface within the container. The code should ideally perform only its intended function and nothing more.

• Be aware of environment variables and filesystem access. Assume that any secret accessible to the container (e.g. the agent’s auth token or other credentials passed in env variables) can be read by your code. Do not log these values or send them to external locations. Also, while you may have some temporary storage in the container, do not write sensitive information to disk unnecessarily, and if you do, delete it before finishing.

Treat the agent’s code execution environment as you would a production server that holds sensitive access: only run trusted code, follow secure coding practices, and perform security testing. UiPath’s platform provides a secure sandbox and ensures the code runs under your account’s context, but it does not inspect or sandbox the logic of your code at a granular level.

Data handling and privacy

Avoid sending sensitive data to external tools unless absolutely necessary. Any data that leaves the UiPath platform to an external API or service should be considered at risk of exposure. Where possible, mask or redact personal data or regulated information before sending it to a RemoteServer. For instance, if an agent is summarizing customer data via an external AI API, consider removing or anonymizing identifiers in the prompt. This practice of data minimization ensures compliance with privacy regulations (GDPR, HIPAA, etc.) by not exposing protected data to systems that might not be governed under those agreements.

If you must send sensitive information, make sure the external provider contractually guarantees data protection (e.g. the data is not stored or used for other purposes). Verify the data residency of the external service – sending data to an endpoint in another region might violate your company’s policies if not accounted for. Always align your use of external endpoints with your organization’s compliance requirements (for example, ensure the third-party service has certifications like SOC 2, ISO 27001, or others relevant to your industry).

Within the UiPath platform, all agent activities are logged, including tool usage and data passed to tools, to the extent possible. Leverage these logs to ensure no unintended data is being sent out. Periodically review what information your agents are handling and sending externally. If you find, for example, that an agent is including a Social Security Number in a request to a RemoteServer, consider revising the agent’s logic to hash or remove such data.

Also be mindful of output data from external services. An external AI or script might return sensitive info (or even malicious content). Implement validation on outputs when feasible. For example, if a RemoteServer returns a response that will be used in a decision, ensure that the response is in the expected format and range. This guards against any manipulation or unexpected behavior from external systems.

Treat external integrations as part of your data flow diagrams for compliance – document what data is leaving the platform and through which service. This will help in risk assessments and audits. Always prefer sharing the minimal amount of information required for the task (need-to-know principle for data).

Access control

Access to configure and use MCP integrations should itself be tightly controlled. Only administrators or highly trusted users should be able to create or modify RemoteServers, CodedServers, or CommandServers configurations. Leverage Orchestrator’s Role-Based Access Control (RBAC) to restrict these capabilities. For example, you might have a specific role for “Agent Integrations Manager” and only assign it to members of your Center of Excellence or IT security team. This prevents ordinary automation developers or business users from inadvertently adding insecure connections or executing arbitrary code. Every new MCP server or agent tool added should go through a review process.

When assigning roles and permissions, enforce the principle of least privilege. Define narrowly scoped roles that allow users to do only what they need for their job. For instance, if an agent only needs to read certain data or execute specific processes, ensure the account running it doesn’t have broader access to other data or administrative functions. Avoid running Agents under a full Orchestrator admin account. Instead, use a dedicated service account with minimal rights. This way, even if an agent’s token is compromised, the potential damage is limited by that account’s scope.

On the auditing side, UiPath provides extensive logging and monitoring capabilities. Audit logs can show who created or changed an MCP configuration (e.g., who added a new RemoteServer and when). Review these logs regularly, and enable alerting for key events – for example, if a new external endpoint is configured, you might have a process to automatically flag it for security review. Additionally, monitor the execution logs of agents. All tool usage by agents is tracked and recorded in a consistent manner. By reviewing these logs, you can detect anomalies (such as an agent calling an endpoint it normally doesn’t, or running at odd times).

Perform periodic compliance checks on MCP service configurations: export a list of all configured RemoteServers and verify they are on the approved list; check that no credentials are exposed in any descriptions or fields; verify that all coded/command servers correspond to code that has passed a security review. Maintain an inventory of these “agent tools” similar to an inventory of IT assets.

Finally, ensure your incident response plan covers MCP service scenarios. For example, if an external endpoint is breached or an API key is leaked, have a procedure to quickly revoke that RemoteServer or rotate the credential. Because UiPath will be a part of your integrated enterprise environment, your security team should be aware of these capabilities and include them in threat models and response drills.

By controlling access, monitoring activity, and promptly investigating any irregularities, you uphold your part of the shared responsibility model – maintaining security and compliance for how the platform’s powerful capabilities are used.

Segregation of responsibilities (UiPath vs. customer)

Using MCP involves a shared responsibility model between UiPath and the customer. The table below summarizes which aspects of security are handled by the UiPath platform and which are the customer’s responsibility:

Area	UiPath responsibility	Customer responsibility
Platform Security	Secure cloud infrastructure and container isolation for agent execution. Enforcement of encryption in transit (TLS) and at rest within UiPath Cloud. Role-based access control (RBAC) and authentication within the platform. Meets various industry compliance standards (e.g. SOC 2, HIPAA, FedRAMP, ISO) for the platform itself.	Secure usage of the platform. Limit platform access to authorized personnel. Configure roles and permissions following least privilege. Protect external endpoints that the platform connects to (ensure they have appropriate security controls, authentication, and compliance certifications). Manage network controls so only approved traffic flows to/from UiPath.
Credential management	Encryption of credentials stored in Orchestrator Assets or Integration Service. Secrets in assets are hidden and protected by the platform. Secure injection of credentials at runtime (e.g. substituting %Assets/KEY%). No secrets are persisted in logs or plaintext by the platform.	Store and manage secrets responsibly: Use the provided secure stores (Assets, etc.) – do not hardcode secrets in code or configs. Rotate your external credentials regularly and remove any unused keys. If using third-party services, manage the API keys or tokens on that side (e.g. revoke if compromised). Ensure that any secret exposed to an agent (even temporarily) is treated with care on your end (e.g. not reused elsewhere).
Execution environment	Provides an isolated, ephemeral container for Coded/Command servers. Ensures each execution has a scoped bearer token and cannot directly affect other tenants or host OS. Logs agent tool actions for audit. Enforces timeouts and resource limits to reduce impact of runaway code.	Code safety and integrity: Only deploy code that is secure and necessary. Do not run untrusted or unvetted code. Validate all custom logic and perform security testing (code reviews, vulnerability scans). You are liable for what your code does – if it deletes data or leaks information, that’s on your side. Treat environment variables and any in-container data as sensitive (because they may contain tokens or private data). Remediate any vulnerabilities in your code or libraries promptly (the platform won’t know if your code has a flaw – you must manage that).
Data handling	Encrypts all data in transit between agent containers and UiPath services. Provides audit logs and monitoring for data that flows through the platform (who ran what, when, and any logged inputs/outputs). Supports compliance measures like data masking, secure storage, and customer-managed encryption keys for data within the UiPath platform.	Safeguard data that leaves the platform: Determine what data is allowed to be sent to external endpoints or processed by external code. Mask or avoid sending PII/PHI unless the external system is approved for it. Ensure external endpoints follow data residency and retention requirements (once data leaves UiPath, its privacy is your responsibility). Implement additional encryption or pseudonymization for especially sensitive data before it goes to an external service.
Monitoring and response	Provides centralized logging, alerts, and audit trails for actions on the platform (configuration changes, agent runs, errors). Enables integration with SIEM tools via OpenTelemetry and other interfaces. UiPath support can assist with platform-level incidents (e.g. infrastructure outages, platform misuse) and provides audit logs to facilitate investigations.	Monitor your usage and respond to incidents: Regularly review agent run logs and audit trails for anomalies. Detect and respond to any suspicious activity (e.g. an agent making unusual external calls). If an external integration is breached or misused, it’s up to you to disable that integration and handle the incident on the external side. Plan for disaster recovery and incident response involving external systems (for example, have runbooks for rotating keys or switching endpoints if needed). Any compliance reporting for the data/processes involving the agent integrations must be managed by you (UiPath can provide data on platform operations, but you report on the end-to-end process).

This segregation of responsibilities aligns with the general cloud shared responsibility model: UiPath secures the platform, and you must secure how you use it and any extensions of it. Make sure your internal policies cover the use of MCP – e.g., a policy that all third-party integrations must be approved by security, all custom agent code must undergo a security review, etc. By fulfilling these responsibilities, you ensure that your implementation of MCP Service remains compliant with your organization’s security standards.

Compliance checklist for MCP Service and MCP usage

To help your team comply with security best practices, use the following checklist when enabling MCP Service and MCP integrations:

• Secrets in secure store: All API keys, tokens, and credentials used by agents are stored in Orchestrator assets (or Integration Service connections). Do not hard code secrets in agent configuration or code. Secret assets are used via %Assets/Name% references in agent configuration.
• Limit configuration access: Only admin or authorized users can create or modify RemoteServer, CodedServer, or CommandServer configurations in Orchestrator. Proper RBAC is in place to prevent unauthorized changes.
• Approved endpoints only: Every external endpoint (RemoteServer URL) has been vetted and approved. The endpoint uses HTTPS (TLS 1.2+) and has up-to-date security certificates. No calls to random IPs or insecure domains are configured. If possible, network rules restrict agent traffic to known endpoints.
• Trusted code only: All code deployed in CodedServers/CommandServers is reviewed and tested for security. No unreviewed open-source scripts or binaries are used. Dependencies are scanned for vulnerabilities, and any high-risk findings are addressed before deployment.
• Least privilege principle: Agent processes run under accounts with only the necessary permissions. We have avoided using high-privilege accounts for agent execution. The scope of access for each agent is well-defined and limited (e.g. folder-level permissions, specific data access only).
• Data minimization: Agents are not sending sensitive personal data to external services unless absolutely required. We have mechanisms to anonymize or truncate data where possible. We have confirmed that external services handling our data have appropriate privacy and security commitments.
• Audit logging enabled: We are capturing and reviewing logs of agent activities. Key events (like configuration changes, failures, or unusual usage patterns) are monitored. The team knows how to access UiPath’s audit logs and is integrating them with our SIEM for continuous monitoring.
• Regular reviews: We conduct periodic reviews (e.g. quarterly) of all MCP Service configurations against this checklist. Stale or unused integrations are removed or disabled. API keys are rotated on schedule. Any new integration passes a security assessment before going live.
• Incident plan ready: In case of a security incident involving an agent (e.g. a leaked credential or compromised endpoint), we have a response plan. This includes revoking secrets from Assets, disabling the agent or tool, and notifying relevant stakeholders. We also include MCP Service usage in our vendor risk management program, treating external APIs and code as we would any third-party vendor.
• Documentation and training: We have documented the use of Agents, MCP servers, and associated risks for our compliance audits. The team using these features has been trained on these best practices and understands the shared responsibility model.

By following this checklist, you can greatly reduce the attack surface and compliance risks associated with MCP Service and MCP. Always keep security and compliance in mind at each step – from design, to implementation, to maintenance of your agents. UiPath provides the tools and secure framework, but how you use them determines the overall security of your solution.

Important:

When using MCP Service and MCP to extend UiPath with external code or services, customers are solely responsible for securing, managing, and maintaining those external components and any data processed by them. UiPath ensures security within the platform (encryption, authentication, logging), but does not control or assume liability for data once it leaves the UiPath platform boundary. In practice, this means you should treat external endpoints and custom code with the same rigor as any other critical part of your system. Compliance checks are not a one-time effort but an ongoing duty as you evolve your agents and integrations.

Additional references

The following points are derived from external best practices and are provided for consideration in strengthening the above guidance.

• Principle of least privilege: Ensure agents and their associated accounts operate under the minimal rights required. For example, do not run agent containers with global admin tokens if not necessary The Jit.io security guidelines for AI agents emphasize narrowly scoped roles and restricting agents to only the resources they need. Applying least privilege reduces the impact of a compromised token or malicious agent action.
• Dependency and code scanning: Regularly scan your agent code and any third-party libraries for vulnerabilities. Given that AI agents often pull in many dependencies, continuous code and dependency scanning is a must. Tools and services (e.g. SAST, SCA scanners) can automate this. This helps catch issues like outdated libraries that could be exploited.
• Use of secure channels for secrets: The use of environment variables for injecting secrets is convenient but can be risky if the running code is not trusted. Docker security discussions note that secrets in env variables could be exposed if someone has access to the container or orchestrator inspect capabilities. Wherever possible, use official secret management features (like Orchestrator Assets or Vault) rather than plain env vars. Docker’s documentation on secrets vs. env variables highlights that secrets mounted from a secure store are not viewable by container inspect commands. In UiPath’s context, Assets serve a similar purpose by not exposing secret values to the user or logs.
• Prompt injection risks: If your agents use LLMs or dynamic prompts (especially via External MCP servers that are LLM APIs), be aware of prompt injection attacks as a new threat vector. An OWASP reference notes that attackers can craft inputs that trick AI agents into revealing secrets like environment variables or credentials. To mitigate this, sanitize inputs to your agents (e.g. strip out known malicious patterns) and constrain the agent’s actions. While prompt security is a broader topic, it intersects with compliance if an injected prompt could cause an agent to disclose sensitive info.
• Continuous monitoring and updates: The landscape of threats evolves quickly. Stay updated on UiPath’s security advisories and updates for MCP Service/MCP. Subscribe to notifications for patches or new security features. For example, if UiPath introduces a feature to restrict certain API calls or a scanning tool for agent code, adopt it. External resources like the Practical DevSecOps list of container security risks and secure supply chain framework can offer insights into emerging best practices that might apply to your use of containers and external integrations.

Each of these points is aimed at reinforcing the principle that extensibility must be accompanied by vigilance. By combining internal guidelines with external best practices, you can create a robust security posture for your MCP Service deployments.