Orchestrator user guide

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 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.

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.

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).

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.

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.

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.

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).

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.