Governança e confiança

Como o acesso, autenticação e padrões de segurança são aplicados quando um agente de codificação atua em sua organização da UiPath.

A coding agent has no UiPath access of its own. Everything it does goes through the uip CLI, and the CLI is signed in as exactly one UiPath identity — which does not have to be your own. That choice decides what the agent can and cannot touch.

Importante:

Esta página descreve o modelo de confiança pretendido. Confirme as especificidades em relação às políticas de segurança da sua organização e o comportamento atual da plataforma antes de confiar nelas para decisões de conformidade.

Diretrizes recomendadas antes de começar

Antes de permitir que um agente de codificação aja em sua organização UiPath, recomendamos as seguintes práticas para apoiar o uso compatível e responsável.

• Autenticação. Recomenda-se uma conta dedicada e tokenizada com escopo de permissões mínimas, em vez de uma que herda seu acesso total. Isso limita o impacto se o token for comprometido e mantém as ações do agente auditáveis separadamente das suas em um ambiente controlado e rastreável.
• Configuração. O modo de execução Attended mantém um humano no loop e reduz o risco de ações autônomas não intencionais. A opção não assistido requer permissões elevadas ou irrestritas e acarreta mais risco, portanto, o modo assistido é o padrão mais seguro.
• Proteções. Proteções apropriadas no agente de codificação de terceiros, em vigor antes de receber acesso ao ambiente da UiPath, ajudam a limitar o que o agente pode fazer e reduzir o risco de comportamento inesperado ou malicioso. O escopo das permissões do agente é melhor definido cuidadosamente antes da implantação.
• Dados pessoais. Onde os dados pessoais são processados, esse processamento deve ser permitido pelas políticas da sua organização e pelos requisitos de proteção de dados aplicáveis antes que o acesso do agente seja habilitado ou expandido.
• Visão geral humana. Em qualquer etapa em que seus processos internos exijam um ponto de controle ou aprovação, a supervisão humana permanece necessária.

AVISO:

Isenção de responsabilidade: um agente de codificação não valida a conformidade do código gerado. Você é responsável por revisar todo o código gerado antes de implantá-lo na produção, de acordo com suas políticas internas.

The agent acts as the signed-in identity

The CLI signs in to one UiPath identity, in one organization and one tenant. Everything the coding agent does through it is bounded by that identity's permissions — it cannot reach resources the signed-in account cannot reach. Scoping access therefore works the same way it always has in UiPath: through roles, folders, and tenant assignment.

Which identity that is, is up to you. With your own account, the agent can do anything you can do. With a dedicated identity that holds only what the work needs, that is all the agent gets.

That identity is where the limit is set: no separate setting grants an agent less access than the identity it runs as. The recommended guidelines favor a dedicated one.

Choosing the identity

There are two ways to log the CLI in, and they produce different kinds of identity:

Login method	Identity the agent acts as	Uso típico
Interactive login — uip login, which opens your browser	The user account that logs in, with all its roles and folder assignments	Local development, where a person is present to review each action
Non-interactive authentication — uip login with a client ID, client secret, and scopes	An external OAuth application, with only the scopes and folder roles granted to it	Automated contexts, and any setup where the agent should not carry a person's permissions

Interactive login uses your browser and your organization's normal sign-in, including any multi-factor and conditional-access policies. Non-interactive authentication uses credentials you provision and control. The agent never needs your password either way; it works with the session the CLI establishes.

Interactive login does not have to mean your everyday account: a dedicated user account created for agent work logs in exactly the same way. What matters is how much permission the identity carries, not how it logs in.

Where the credential comes from

The CLI can obtain a credential from three sources: environment variables, the credentials saved by uip login, and the UiPath Robot on the same machine. Each carries its own identity. Where more than one is available, the CLI resolves them in this priority order:

1. A Robot session, when UIPATH_CLI_ENFORCE_ROBOT_AUTH is set. UiPath Studio Desktop uses this path, and it overrides every other source.
2. A token supplied through environment variables, when UIPATH_CLI_ENABLE_ENV_AUTH is set.
3. The credentials saved by uip login, from the project directory or your home directory, or from the profile named with --profile.
4. A session from the UiPath Robot on the same machine, when no saved credentials were found.

When the credential comes from the Robot, the agent acts as the account the Robot is signed in with. The Robot supplies the credential, not the identity.

Two points matter when reviewing an agent's access:

• Confirming the identity. uip login status reports which source resolved, along with the organization and tenant. It is the reliable way to establish which identity an agent acts as on a given machine.
• Pinning the identity. Naming a profile keeps the CLI on it. If that profile's credentials are missing, the CLI reports that you are not logged in rather than falling through to a different identity.

Attribution and audit

UiPath records the identity the CLI signed in as, and nothing beyond it. That cuts both ways:

• Your own account keeps the record tied to a person, but hands the agent everything that person can do.
• A dedicated identity narrows what the agent can do, but the record then names the dedicated identity. If several people share one, the record cannot tell them apart.

If you need to know which person did what, one dedicated identity per person — or per agent workload — gives you both the narrow permissions and the name.

Segredos e credenciais

As credenciais e os segredos pertencem a seu armazenamento secreto ou ao gerenciamento de segredos do seu sistema CI/CD, não a solicitações, arquivos de projeto ou controle de origem. A mesma regra que você aplica a qualquer automação se aplica aqui.

Dados que coletamos

Duas origens enviam a telemetria de uso do produto para o Azure Application Insights, de propriedade da UiPath, hospedado na região da Europa Ocidental: a própria telemetria de comando da uip CLI e as habilidades da UiPath que o agente de codificação invoca por meio da CLI. Ambas chegam no mesmo recurso gerenciado pela UiPath e são marcadas com tags para que permaneçam diferenciáveis. Os dados nos ajudam a entender quais comandos e habilidades são usados e onde eles falham.

Both sources send by default — see Turning telemetry on or off below.

O que é coletado

• Uso de comando e habilidade — para cada chamada de ferramenta uip ou orientada por habilidade: o nome do comando ou ferramenta, o subcomando uip derivados (seu primeiro ou dois verbos, nunca a linha de comando completa), o nome da habilidade (Apenas para habilidades da UiPath), por quanto tempo foi executado e se foi bem-sucedido, foi interrompido ou falhou (com a mensagem de erro para comandos de CLI).
• Tipo de arquivo — a extensão do arquivo envolvida em uma chamada de ferramenta (por exemplo, .flow), nunca o caminho do arquivo.
• Ambiente — as versões de CLI e habilidades, o ambiente de nuvem derivados do seu login (por exemplo, alpha, teste ou produção) e qual agente de codificação de IA invocou a CLI (por exemplo, Claude Code, Cursor, Gemini CLI ou Código).
• Identidade — sua identidade de nuvem UiPath conectada: ID de usuário de nuvem, ID de tenant e ID da organização. Essa telemetria não é anônima; ela carrega a mesma identidade que todas uip outras atividades da CLI.
• IDs de correlação — identificadores de sessão e por chamada que vinculam as etapas de uma única execução.

O que nunca é coletado

Os seguintes nunca saem de sua máquina, mesmo que o agente e a CLI os leiam localmente para fazer seu trabalho:

• Conteúdo do arquivo, saída de comando (stdout e stderr) e transcrições do agente.
• Linhas de comando completas — apenas o verbo de subcomando derivados.
• Caminhos do arquivo e seu diretório de trabalho — apenas a extensão do arquivo.

Cada campo de telemetria é extraído de uma parte específica e limitada da carga, portanto, o conteúdo de forma livre (como saída que contém um caminho ou um nome de comando) não pode vazar para um campo. Para a própria telemetria de comando da CLI, os valores são adicionalmente editados na origem. Qualquer coisa semelhante a qualquer uma das seguintes é substituída por [REDACTED]:

• Token ou chave
• Segredo ou senha
• Credencial ou certificado

Os identificadores e os e-mails têm hash; As URLs são reduzidas para seu host.

Onde vai

Azure Application Insights, de propriedade da UiPath, na região da Europa Ocidental. A conexão é de propriedade da CLI; as habilidades nunca o suportam. Você pode rotear a telemetria para uma instância diferente com a variável de ambiente UIPATH_AI_CONNECTION_STRING , embora isso não seja necessário no uso normal.

Retenção

A retenção é regida pela configuração do espaço de trabalho do Application Insights, em vez da CLI ou das habilidades. O Azure Application Insights assume como padrão 90 dias, a menos que o espaço de trabalho esteja configurado de outra forma. Sua equipe de plataforma pode confirmar o período de retenção configurado antes de confiar nele.

Ativar ou desativar a telemetria

A single environment variable, UIPATH_TELEMETRY_DISABLED, controls both sources, and both behave the same way:

• Telemetry sends by default. With the variable unset, or set to 0 or any other value, both the CLI's command telemetry and the skills telemetry send.
• Setting UIPATH_TELEMETRY_DISABLED to 1 or true disables both. Nothing is sent, and the CLI keeps local debug logging only.

Mantendo o controle

Os agentes de codificação propõem ações e, em suas configurações padrão, exibem comandos para você aprovar antes de executá-los. Revisar o que o agente gerou — e o que ele está prestes a executar — antes de aprovar mantém um ser humano informado para qualquer coisa que mude o estado em sua organização.

Para investigar problemas quando algo dá errado, consulte Solução de problemas e perguntas frequentes.