Conformidade dos servidores MCP

Visão geral

Os servidores UiPath MCP permitem que os agentes aproveitem ferramentas externas e código por meio do Protocolo de contexto do modelo (MCP).

Isso inclui:

• UiPath: onde os clientes podem usar diretamente como ferramentas outros componentes da UiPath, como processos, fluxos de trabalho de API etc.
• Remoto: conectando-se a serviços de terceiros, executando código personalizado (CodedServers) ou executando comandos em script (CommandServers).

Embora a UiPath Platform forneça comunicação segura e governança para essas integrações, quaisquer pontos de extremidade externos ou código personalizado operam fora do limite de segurança da plataforma principal. Isso significa que, quando os dados ou ações deixam o ambiente controlado da UiPath, o cliente assume a responsabilidade por sua segurança e conformidade. Na prática, a UiPath garante a criptografia em trânsito e em repouso dentro de seus serviços e impõe o acesso baseado em funções, mas a privacidade dos dados, segurança dos pontos de extremidade e conformidade regulatória para qualquer coisa fora da UiPath (os servidores externos ou código) permanecem sob responsabilidade do cliente.

Importante:

A UiPath não gerencia seus servidores ou código externos – a segurança e a confiabilidade desses componentes estão sob seu controle. Portanto, o uso de integrações do MCP requer atenção especial para como os segredos são tratados, quais pontos de extremidade são confiáveis e qual código é executado, para atender aos requisitos de conformidade de sua organização.

Implicações de segurança de RemoteServers, CodedServers e CommandServers

RemoteServers

Uma configuração do RemoteServer define uma conexão com um ponto de extremidade HTTP(S) externo (para transporte StreamableHttp de MCP). A implicação de segurança é que quaisquer dados enviados ou recebidos desse serviço externo estão fora do controle direto da UiPath. Se o RemoteServer exigir autenticação (chaves de API, tokens etc.), os usuários podem ficar tentados a incorporar esses segredos diretamente nos cabeçalhos HTTP ou URLs. Armazenar segredos diretamente na configuração é arriscado – embora o serviço UiPath MCP mascare esses valores de cabeçalho confidenciais na interface gráfica e os criptografe no banco de dados em repouso, eles ainda transitam pelo sistema e podem ser expostos se não forem tratados corretamente.Além disso, campos como o URL do ponto de extremidade, carga do corpo ou parâmetros de consulta não são criptografados no banco de dados, portanto, nenhum dado confidencial deve ser colocado nesses campos. Os dados que saem para um ponto de extremidade externo podem ser interceptados ou usados indevidamente se o ponto de extremidade for comprometido ou se as comunicações não forem seguras.Em suma, os RemoteServers estendem sua automação para redes externas, portanto, você deve garantir que esses pontos de extremidade sejam confiáveis e que nenhum segredo ou informação confidencial vaze em trânsito.

CodedServers e CommandServers

CodedServers referem-se ao código personalizado (por exemplo, um script ou programa em Python) que você empacota e executa como parte de um agente, enquanto os CommandServers executam comandos de shell ou scripts em um runtime sem servidor. Ambos executam lógica fornecida pelo usuário em contêineres efêmeros e sem servidor orquestrados pela UiPath. De uma perspectiva de segurança, isso significa que seu código é executado com certos privilégios dentro do ambiente de nuvem da UiPath — ele é executado no contexto da sua organização e carrega um token de autenticação (token de portador) com escopo para sua organização/usuário para chamar de volta nos serviços da UiPath. A implicação principal é que qualquer código que você executar é inerentemente confiável com esse token e potencialmente outras variáveis de ambiente. Se você executar código mal-intencionado ou não verificado, ele poderá guiar o token ou outras informações confidenciais e realizar operações não autorizadas. Código não confiável nunca deve ser usado em CodedServers/CommandServers, porque ele pode exfiltrar dados ou abuso dos privilégios concedidos. Mesmo um código bem-intencionado pode ter vulnerabilidades que os invasores exploram para obter acesso. Além disso, esses contêineres podem ter acesso a determinadas variáveis de ambiente (para configuração, credenciais, etc.), que devem ser consideradas áreas confidenciais — o código mal-intencionado pode lê-las na memória.

Em resumo, executar código ou comandos personalizados significa que você está assumindo os riscos do comportamento desse código. Apenas código altamente confiável e revisado deve ser implantado e deve seguir práticas de codificação seguras.

Além desses componentes específicos, o uso do MCP introduz um modelo de responsabilidade compartilhada: a UiPath fornece a segurança da plataforma (contêineres de execução isolados, criptografia de dados em repouso, proteções de rede e certificações de conformidade para a plataforma de cloud), mas você é responsável pela segurança de quaisquer sistemas externos que você conecta e conteúdo que executa.As seções a seguir descrevem as melhores práticas para cumprir seu lado dessa responsabilidade.

Práticas de segurança recomendadas

Para usar integrações de MCP com segurança e atender aos requisitos de conformidade, implemente as seguintes práticas recomendadas.

1. Tratamento seguro de segredos (cabeçalhos e ativos do RemoteServer)

É fortemente recomendável não armazenar segredos confidenciais (chaves de API, tokens, credenciais) diretamente em configurações do RemoteServer. Embora a plataforma criptografe valores de cabeçalhos secretos em repouso e os mascare na interface gráfica, essa abordagem não é ideal.Os segredos na configuração ainda podem aparecer em logs ou ser expostos inadvertidamente, e nenhum outro campo, exceto cabeçalhos secretos designados, é criptografado. Não coloque dados confidenciais em texto simples em campos como URLs, parâmetros de consulta ou corpos de solicitações.

Abordagem recomendada

Use Ativos do Orchestrator do tipo "Segredo" para gerenciar chaves confidenciais e faça referência a eles em seus cabeçalhos ou parâmetros do RemoteServer.

Por exemplo, armazene uma chave de API em um ativo chamado MY_API_KEY (os ativos no Orchestrator são criptografados em repouso por padrão). Na configuração do cabeçalho do RemoteServer, em vez de inserir o valor da chave, use uma referência de espaço reservado: Authorization: Bearer %Assets/MY_API_KEY%. Quando o agente for executado, a plataforma substituirá o segredo real no runtime.

Dessa forma, o segredo nunca é armazenado em texto simples nas configurações do RemoteServer – ele permanece em segurança no cofre de ativos. A interface gráfica mostrará apenas um espaço reservado mascarado. Essa prática ajuda a evitar a exposição acidental de segredos e alinha-se com o princípio de não codificar credenciais.

Em resumo: mantenha segredos fora do código e configurações do seu agente.Centralize-os em armazenamentos seguros. Gire chaves de API regularmente e nunca incorpore segredos diretamente em código ou solicitações HTTP.

2. Pontos de extremidade confiáveis e controles de rede (configuração do RemoteServer)

Ao configurar RemoteServers, conecte-se apenas a endpoints externos confiáveis. Cada RemoteServer deve apontar para um domínio ou serviço que sua organização verificou quanto a segurança, privacidade e conformidade. Trate uma nova API ou serviço de terceiros como um fornecedor – certifique-se de que ele atenda aos seus padrões de segurança (por exemplo, tenha as certificações adequadas, use criptografia e lidará com seus dados de forma adequada).

Use HTTPS para todas as chamadas externas. Sempre especifique URLs https:// para que o tráfego seja criptografado em trânsito. Aplique o TLS 1.2 ou superior para a conexão. A plataforma se comunicará por TLS por padrão; como cliente, você deve verificar que o ponto de extremidade tenha um certificado válido e criptografia. Nunca use HTTP simples para comunicações de agente, pois ele pode ser interceptado.

Ponto chave: trate as chamadas externas como extensões do seu ambiente de TI. Verifique a segurança do serviço externo (SSL/TLS habilitado, sem certificações autoassinadas ou expiradas etc.) e envie dados apenas para ele se você confiar nele. Um ponto de extremidade comprometido ou desonesto pode roubar dados ou injetar respostas prejudiciais, portanto, a devida diligência em servidores externos é crítica.

3. Execução segura de servidores de codificados/de comando (apenas código confiável)

Para CodedServers e CommandServers, a segurança depende em grande parte do código que você executa. Nunca execute código não confiável ou de terceiros sem uma revisão completa. Os contêineres do agente executam seu código com um token de acesso que pode chamar APIs da UiPath (e, potencialmente, outras integrações). O código malicioso pode capturar esse token de portador ou outros segredos de ambiente e exfiltrá-los ou realizar ações destrutivas por meio das APIs da plataforma. Ele também pode tentar explorar o runtime do contêiner, embora os contêineres sem servidor da UiPath sejam isolados e não sejam executados com privilégios elevados por padrão.

Para mitigar esses riscos:

• use revisões de código internas e verificação de origem. Se você incorporar bibliotecas ou amostras de código aberto em um agente codificado, revise esse código em busca de problemas de segurança (backdoors, lógica de exfiltração de dados etc.). Obtenha bibliotecas apenas de repositórios de pacotes oficiais e confiáveis.
• Verifique o código e as dependências em busca de vulnerabilidades. Empregue testes de segurança de aplicativos estáticos (SAST) no seu código de agente e use scanners de vulnerabilidade de dependência (como OWASP Dependency Check, SNYK, etc.) em todos os pacotes que você usar. Isso ajuda a detectar falhas conhecidas (por exemplo, um pacote que pode permitir a execução remota de código) antes da implantação. A verificação contínua é aconselhável, pois novas vulnerabilidades em bibliotecas podem surgir ao longo do tempo.
• Limite o que o código pode fazer. Embora o contêiner seja efêmero, você ainda deve codificar defensivamente. Por exemplo, evite passar entradas não validadas para seu código (para evitar ataques de injeção). Essencialmente, minimize a superfície de ataque dentro do contêiner. O código deve idealmente executar apenas sua função pretendida e nada mais.
• Esteja ciente de variáveis de ambiente e acesso ao sistema de arquivos. Suponha que qualquer segredo acessível ao contêiner (por exemplo, o token de autenticação do agente ou outras credenciais passadas em variáveis de ambiente) possa ser lido pelo seu código. Não registre esses valores ou os envie para locais externos. Além disso, embora você possa ter algum armazenamento temporário no contêiner, não grave informações confidenciais em um disco desnecessariamente e, se você fizer isso, exclua-as antes de finalizar.

Em resumo, trate o ambiente de execução de código do agente como se fosse um servidor de produção que contém acesso confidencial: execute apenas código confiável, siga práticas de codificação seguras e realize testes de segurança. A plataforma da UiPath fornece uma sandbox segura e garante que o código seja executado no contexto da sua conta, mas não inspeciona ou aplica sandbox à lógica do seu código em um nível granular – essa responsabilidade é sua.

4. Tratamento de dados e privacidade

Evite enviar dados confidenciais para ferramentas externas, a menos que seja absolutamente necessário. Quaisquer dados que sairem do UiPath Platform para uma API ou serviço externo devem ser considerados em risco de exposição. Quando possível, mascarar ou editar dados pessoais ou informações regulamentadas antes de enviá-las para um RemoteServer*.* Por exemplo, se um agente estiver resumindo dados do cliente por meio de uma API de IA externa, considere remover ou anonimizar identificadores na solicitação. Essa prática de minimização de dados garante a conformidade com os regulamentos de privacidade (GDPR, HIPAA, etc.) ao não expor dados protegidos a sistemas que podem não ser regidos por esses acordos.

Se você precisar enviar informações confidenciais, certifique-se de que o provedor externo garanta contratualmente a proteção dos dados (por exemplo, os dados não são armazenados ou usados para outros fins). Verifique a residência de dados do serviço externo – enviar dados para um endpoint em outra região pode violar as políticas da sua empresa se não for contabilizado. Sempre alinhe seu uso de pontos de extremidade externos com os requisitos de conformidade de sua organização (por exemplo, certifique-se de que o serviço de terceiros tenha certificações como SOC 2, ISO 27001 ou outras relevantes para o seu setor).

Dentro da UiPath Platform, todas as atividades do agente são registradas, incluindo o uso de ferramentas e dados passados para ferramentas, na medida do possível. Aproveite esses logs para garantir que nenhum dado não intencional esteja sendo enviado. Revise periodicamente quais informações seus agentes estão tratando e enviando externamente. Se você descobrir, por exemplo, que um agente está incluindo um Número de Seguro Social em uma solicitação para um RemoteServer, considere revisar a lógica do agente para hash ou remover esses dados.

Se você usar servidores MCP codificados/de comando, o registro está dentro de sua responsabilidade. Nunca registre dados confidenciais como PII ou informações de segurança.

Esteja também atento aos dados de saída de serviços externos. Uma IA ou script externo pode retornar informações confidenciais (ou até mesmo conteúdo malicioso). Implemente a validação em saídas quando viável. Por exemplo, se um RemoteServer retornar uma resposta que será usada em uma decisão, certifique-se de que a resposta esteja no formato e intervalo esperados. Isso protege contra qualquer manipulação ou comportamento inesperado de sistemas externos.

Em suma, trate integrações externas como parte de seus diagramas de fluxo de dados para conformidade - documente quais dados estão saindo da plataforma e por meio de qual serviço. Isso ajudará em avaliações de riscos e auditorias. Sempre prefira compartilhar a quantidade mínima de informações necessárias para a tarefa (princípio da necessidade de saber com relação a dados).

5. Controle de acesso

O acesso para configurar e usar integrações do MCP deve ser rigorosamente controlado. Apenas administradores ou usuários altamente confiáveis devem poder criar ou modificar as configurações de RemoteServers, CodedServers ou CommandServers*.* Aproveite o Controle de Acesso Baseado em Função (RBAC) do Orchestrator para restringir esses recursos. Por exemplo, você pode ter uma função específica para “Gerente de Integrações de Agente” e atribuí-la apenas a membros do seu Centro de Excelência ou equipe de segurança de TI. Isso impede que desenvolvedores de automação comuns ou usuários de negócios adicionem inadvertidamente conexões não seguras ou executem código arbitrário. Todo novo servidor MCP ou ferramenta de agente adicionada deve passar por um processo de revisão.

Ao atribuir funções e permissões, imponha o princípio do mínimo privilégio. Defina funções restritas que permitam que os usuários façam apenas o que precisam para o trabalho deles. Por exemplo, se um agente apenas precisar ler certos dados ou executar processos específicos, certifique-se de que a conta que o executa não tenha acesso mais amplo a outros dados ou funções administrativas. Evite executar agentes em uma conta de administrador completa do Orchestrator. Em vez disso, use uma conta de serviço dedicada com direitos mínimos. Dessa forma, mesmo que o token de um agente seja comprometido, os possíveis danos são limitados pelo escopo dessa conta.

Monitore os logs de execução dos agentes. Todos os usos de ferramentas por agentes são rastreados e registrados de maneira consistente. Ao revisar esses logs, você pode detectar anomalias (como um agente chamando um ponto de extremidade que normalmente não chama ou sendo executado em momentos fora do comum).

É aconselhável realizar verificações periódicas de conformidade em configurações de serviço MCP: exportar uma lista de todos os RemoteServers configurados e verificar se eles estão na lista aprovada; verificar se nenhuma credencial é exposta em quaisquer descrições ou campos; verificar se todos os servidores codificados/de comando correspondem a códigos que foram aprovados em uma revisão de segurança. Mantenha um inventário dessas "ferramentas de agente" semelhante a um inventário de ativos de TI.

Por fim, certifique-se de que seu plano de resposta a incidentes cobre cenários de serviço do MCP. Por exemplo, se um ponto de extremidade externo for violado ou uma chave de API for vazada, tenha um procedimento para revogar rapidamente esse RemoteServer ou girar a credential. Como a UiPath fará parte do seu ambiente empresarial integrado, sua equipe de segurança deve estar ciente desses recursos e incluí-los em modelos de ameaças e exercícios de resposta.

Ao controlar o acesso, monitorar atividades e investigar prontamente quaisquer irregularidades, você mantém sua parte do modelo de responsabilidade compartilhada – mantendo a segurança e a conformidade de como os recursos avançados da plataforma são usados.

Segregação de responsabilidades (UiPath versus cliente)

O uso de MCP envolve um modelo de responsabilidade compartilhada entre a UiPath e o cliente. A tabela a seguir resume quais aspectos da segurança são tratados pela UiPath Platform e quais são de responsabilidade do cliente:

Tabela 1. Responsabilidades da UiPath versus o cliente

Area	Responsabilidade da UiPath	Responsabilidade do cliente
Segurança da plataforma	Proteja a infraestrutura de cloud e o isolamento de container para a execução do agente.Imposição de criptografia em trânsito (TLS) e em repouso dentro do UiPath Cloud. Controle de acesso baseado em funções (RBAC) e autenticação dentro da plataforma.	Uso seguro da plataforma. Limite o acesso à plataforma a pessoal autorizado. Configurar funções e permissões seguindo o privilégio mínimo. Proteja os pontos de extremidade externos aos quais a plataforma se conecta (certifique-se de que eles tenham controles de segurança apropriados, autenticação e certificações de conformidade). Gerencie controles de rede para que apenas tráfego aprovado flua para a UiPath e da UiPath.
Gerenciamento de credenciais	Criptografia de credenciais armazenadas em ativos do Orchestrator ou Integration Service. Os segredos em ativos são ocultos e protegidos pela plataforma. Injeção segura de credenciais no runtime (por exemplo, substituindo %Assets/KEY%).Nenhum segredo é mantido em logs ou texto simples pela plataforma.	Armazene e gerencie segredos de forma responsável. Use os armazenamentos seguros fornecidos (ativos etc.) – não insira segredos diretamente em código ou configurações. Altere suas credenciais externas regularmente e remova quaisquer chaves que não estejam sendo usadas.Se estiver usando serviços de terceiros, gerencie as chaves de API ou tokens desse lado (por exemplo, revogue-os se comprometidos). Certifique-se de que qualquer segredo exposto a um agente (mesmo temporariamente) seja tratado com cuidado de sua parte (por exemplo, não reutilizado em outro lugar).
Ambiente de execução	Fornece um contêiner isolado e efêmero para servidores codificados/de comando. Garante que cada execução tenha um token de portador com escopo e não possa afetar diretamente outros tenants ou sistema operacional do host. Registra ações de ferramenta do agente para auditoria. Impõe limites de tempo e de recursos para reduzir o impacto do código descontrolado.	Segurança e integridade do código. Apenas implante código que seja seguro e necessário. Não execute código que não seja confiável ou examinado. Valide toda a lógica personalizada e realize testes de segurança (revisões de códigos, verificações de vulnerabilidades). Você é responsável pelo que seu código faz – se ele excluir dados ou vazar informações, isso fica do seu lado. Trate variáveis de ambiente e quaisquer dados no contêiner como confidenciais (porque eles podem conter tokens ou dados privados). Corrija quaisquer vulnerabilidades em seu código ou bibliotecas imediatamente (a plataforma não saberá se seu código tem uma falha – você deve gerenciar isso).
Tratamento de dados	Criptografa todos os dados em trânsito entre contêineres de agentes e os serviços da UiPath. Fornece logs de auditoria e monitoramento para dados que fluem pela plataforma (quem executou o que, quando e quaisquer entradas/saídas registradas). Oferece suporte a medidas de conformidade como mascaramento de dados, armazenamento seguro e chaves de criptografia gerenciadas pelo cliente para dados dentro da UiPath Platform.	Proteja dados que deixam a plataforma. Determine quais dados podem ser enviados para pontos de extremidade externos ou processados por código externo. Mascare ou evite o envio de PII/PHI, a menos que o sistema externo seja aprovado para isso. Certifique-se de que os pontos de extremidade externos sigam os requisitos de residência e retenção de dados (quando os dados saem da UiPath, a privacidade deles é sua responsabilidade). Implemente criptografia adicional ou pseudonimização para dados especialmente confidenciais antes que eles sejam enviados para um serviço externo.
Monitoramento e resposta	Fornece registro centralizado, alertas e trilhas de auditoria para ações na plataforma (alterações de configuração, execuções de agentes, erros). Habilita a integração com ferramentas de SIEM por meio de OpenTelemetry e outras interfaces. O suporte da UiPath pode ajudar com incidentes no nível da plataforma (por exemplo, interrupções de infraestrutura, uso indevido da plataforma) e fornece logs de auditoria para facilitar as investigações.	Monitore seu uso e responda a incidentes. Revise regularmente logs de execução do agente e trilhas de auditoria em busca de anomalias. Detecte e responda a qualquer atividade suspeita (por exemplo, um agente fazendo chamadas externas incomuns). Se uma integração externa for violada ou usada incorretamente, cabe a você desabilitar essa integração e lidar com o incidente no lado externo. Plano para Disaster Recovery e resposta a incidentes envolvendo sistemas externos (por exemplo, tenha runbooks para girar chaves ou alternar pontos de extremidade, se necessário). Qualquer relatório de conformidade para os dados ou processos que envolvam as integrações de agentes deve ser gerenciado por você (a UiPath pode fornecer dados sobre operações de plataforma, mas você relata o processo de ponta a ponta).

Essa segregação de responsabilidades se alinha ao modelo geral de responsabilidade compartilhada de nuvem: a UiPath protege a plataforma, e você deve proteger como a usa e quaisquer extensões dela. Certifique-se de que suas políticas internas cubram o uso do MCP — por exemplo, uma política de que todas as integrações de terceiros devem ser aprovadas pela segurança, todo o código de agentes personalizado deve passar por uma revisão de segurança, etc. Ao cumprir essas responsabilidades, você garante que sua implementação do Serviço MCP permaneça compatível com os padrões de segurança de sua organização.

Isenção de responsabilidade recomendada: ao usar o MCP Service e MCP para estender a UiPath com código ou serviços externos, os clientes são os únicos responsáveis por proteger, gerenciar e manter esses componentes externos e quaisquer dados processados por eles. A UiPath garante segurança dentro da plataforma (Criptografia, autenticação, registo), mas não controla ou assume responsabilidade por Dados quando eles saem do limite da UiPath Platform.Na prática, isso significa que você deve tratar pontos de extremidade externos e código personalizado com o mesmo rigor que qualquer outra parte crítica de seu sistema. As verificações de conformidade não são um esforço único, mas um dever contínuo à medida que você evolui seus Agents e integrações.