- Get started
- Best practices
- Capabilities
- Skills
- CLI
- Examples
- Examples overview
- Recipe: build an agent
- Recipe: automate with RPA
- Recipe: enter data into a web app
- Recipe: extract data from a desktop app
- Recipe: refactor and test a workflow
- Recipe: a queue-based process with REFramework
- Recipe: build a Maestro Flow
- Recipe: coded app and API workflow
- Recipe: verify a release with Test Manager
- Recipe: extract data from documents with IXP
- Advanced
- CI/CD and automation
- Governance and trust
- Help
When a coding agent builds and runs UiPath work, it acts through the uip CLI under your signed-in identity. Understanding that boundary is what makes the workflow safe to adopt in an enterprise.
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.
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 you
The CLI authenticates as a specific UiPath identity in a specific organization and tenant. Anything your coding agent does through the CLI 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.
Authentication and identity
Interactive login uses your browser and your organization's normal sign-in, including any multi-factor and conditional-access policies. For automated contexts, non-interactive authentication uses credentials you provision and control. The agent never needs your password; it works with the session the CLI establishes.
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.
The skills telemetry is off by default — see Turning telemetry on or off below.
What is collected
- Command and skill usage — for each
uipcommand or skill-driven tool call: the command or tool name, the deriveduipsub-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
uipCLI 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 (
stdoutandstderr), 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, but their defaults differ:
- Skills telemetry is off by default. It sends only when you explicitly set
UIPATH_TELEMETRY_DISABLED=0. - The CLI's own command telemetry sends unless you opt out by setting
UIPATH_TELEMETRY_DISABLED=1. - All telemetry can be disabled by setting
UIPATH_TELEMETRY_DISABLED=1. When disabled, 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.