# Governance and trust > How access, authentication, and safe defaults apply when a coding agent acts on your UiPath organization. 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. :::important This page describes the intended trust model. Confirm the specifics against your organization's security policies and the current platform behavior before relying on them for compliance decisions. ::: ## Recommended guidelines before you start Before you let a coding agent act on your UiPath organization, we recommend the following practices to support compliant and responsible use. - **Authentication.** A dedicated, tokenized account scoped to minimal permissions is recommended, rather than one that inherits your full access. This limits the impact if the token is ever compromised, and keeps the agent's actions auditable separately from yours in a controlled, traceable environment. - **Configuration.** Attended execution mode keeps a human in the loop and reduces the risk of unintended autonomous actions. The unattended option requires elevated or unrestricted permissions and carries more risk, so attended mode is the safer default. - **Guardrails.** Appropriate guardrails on the third-party coding agent, in place before it is given access to the UiPath environment, help limit what the agent can do and reduce the risk of unexpected or malicious behavior. The scope of the agent's permissions is best defined carefully before deployment. - **Personal data.** Where personal data is processed, such processing should be permitted under your organization's policies and applicable data protection requirements before the agent's access is enabled or expanded. - **Human oversight.** At any step where your internal processes require a control point or approval, human oversight remains necessary. :::warning **Disclaimer:** A coding agent does not validate the compliance of generated code. You are responsible for reviewing all generated code before deploying it to production, in accordance with your internal policies. ::: ## 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](#recommended-guidelines-before-you-start) 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 | Typical use | |---|---|---| | **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. ## Secrets and credentials Credentials and secrets belong in your secret store or your CI/CD system's secret management, not in prompts, project files, or source control. The same discipline you apply to any automation applies here. ## Data we collect Two sources send product usage telemetry to UiPath-owned Azure Application Insights, hosted in the West Europe region: the `uip` CLI's own command telemetry, and the UiPath skills the coding agent invokes through the CLI. Both land in the same UiPath-managed resource and are tagged so they stay distinguishable. The data helps us understand which commands and skills are used and where they fail. Both sources send by default — see **Turning telemetry on or off** below. ### What is collected - **Command and skill usage** — for each `uip` command or skill-driven tool call: the command or tool name, the derived `uip` sub-command (its first one or two verbs, never the full command line), the skill name (UiPath skills only), how long it ran, and whether it succeeded, was interrupted, or failed (with the error message for CLI commands). - **File type** — the file extension involved in a tool call (for example, `.flow`), never the file path. - **Environment** — the CLI and skills versions, the cloud environment derived from your sign-in (for example, alpha, staging, or production), and which AI coding agent invoked the CLI (for example, Claude Code, Cursor, Gemini CLI, or Codex). - **Identity** — your signed-in UiPath cloud identity: cloud user ID, tenant ID, and organization ID. This telemetry is **not anonymous**; it carries the same identity as all other `uip` CLI activity. - **Correlation IDs** — session and per-call identifiers that link the steps of a single run. ### What is never collected The following never leave your machine, even though the agent and CLI read them locally to do their work: - File contents, command output (`stdout` and `stderr`), and agent transcripts. - Full command lines — only the derived sub-command verb. - File paths and your working directory — only the file extension. Each telemetry field is extracted from a specific, bounded part of the payload, so free-form content (such as output that happens to contain a path or a command name) cannot leak into a field. For the CLI's own command telemetry, values are additionally redacted at the source. Anything resembling any of the following is replaced with `[REDACTED]`: - Token or key - Secret or password - Credential or certificate Identifiers and emails are hashed; URLs are reduced to their host. ### Where it goes UiPath-owned Azure Application Insights, in the West Europe region. The connection is owned by the CLI; the skills never hold it. You can route telemetry to a different instance with the `UIPATH_AI_CONNECTION_STRING` environment variable, though this is not needed in normal use. ### Retention Retention is governed by the Application Insights workspace configuration rather than by the CLI or the skills. Azure Application Insights defaults to 90 days unless the workspace is configured otherwise. Your platform team can confirm the configured retention period before you rely on it. ### Turning telemetry on or off 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. ## Staying in control Coding agents propose actions and, in their standard configurations, surface commands for you to approve before running them. Reviewing what the agent generated — and what it is about to run — before you approve keeps a human in the loop for anything that changes state in your organization. To investigate issues when something does go wrong, see [Troubleshooting and FAQ](troubleshooting.md).