From uipath
Authors UiPath ToolUsePolicy access policies via `uip gov access-policy` CLI to govern tool/resource use when actor processes invoke child resources.
npx claudepluginhub uipath/skills --plugin uipathThis skill is limited to using the following tools:
> **Preview** — skill is under active development; surface and behavior may change.
references/access-policy-commands.mdreferences/planning-arch.mdreferences/planning-impl.mdreferences/plugins/actor/impl.mdreferences/plugins/actor/planning.mdreferences/plugins/executable/impl.mdreferences/plugins/executable/planning.mdreferences/plugins/selector/impl.mdreferences/plugins/selector/planning.mdreferences/plugins/tags/impl.mdreferences/plugins/tags/planning.mdreferences/policy-manage-guide.mdreferences/resource-lookup-guide.mdreferences/sample-policy-guide.mdManages UiPath AOps governance policies: create/update/delete/list/deploy to users/groups/tenants via `uip gov aops-policy` CLI. Maps natural-language intent to enforce rules (block/restrict/require) on Studio, Robot, Assistant.
Govern Power Automate flows and Power Apps at scale using FlowStudio MCP: classify by business impact, detect orphaned resources, audit connectors, enforce compliance, manage notifications, compute governance scores.
Creates ZPA access policy rules using v2 conditions for identity (SAML/SCIM), device (platform/posture), network (country/trusted), and risk factors. Guides requirement gathering, attribute lookup, payload building, and rule creation with examples.
Share bugs, ideas, or general feedback.
Preview — skill is under active development; surface and behavior may change.
Skill for authoring UiPath access policies of type ToolUsePolicy via the uip gov access-policy CLI. The ToolUsePolicy type governs tool-use / resource-use inside Agents and workflow automations: when an Actor Process tries to invoke a child Resource/Tool, the policy decides whether the call is allowed. The uip gov access-policy surface returns other policy types as well, but they are out of scope for this skill.
When an Actor Process (an executable workflow — Maestro, Flow, Case Management, or Agent) invokes a child Resource/Tool (another Agent, Maestro, Flow, Case Management, API Workflow, or RPA) as a tool use, the PDP evaluates every applicable access policy and returns an aggregate Allow / Deny decision. This skill authors those policies.
A policy decides its per-call outcome from three rule blocks — Selection Rule (selectors[]), Actor Process Rule (executableRule), and Actor Identity Rule (actorRule). See Key Concepts § The three rule blocks for the full structural shape and constraints.
Evaluation flow for a single tool-use request:
Allow; otherwise it does not contribute (no-match).Allow, the final enforcement is Allow. Otherwise the request falls through to the runtime default (Deny / NoOp). enforcement: "Deny" is not authorable — Deny is the runtime default when no Allow policy matches (Critical Rule #2).status: "Simulated" are evaluated but excluded from aggregation (see Key Concepts § Enforcement and status).Terminology. A Governance Access Policy is the broad category —
uip gov access-policycan list, get, evaluate, or delete policies of multiple types. This skill authors theToolUsePolicytype, which gates resource-vs-executable tool use. Access policies are distinct from Automation Ops Governance Policies (product runtime / design-time behavior for Studio, StudioX, Assistant, Robot, AI Trust Layer, …), handled by the siblinguipath-gov-aops-policyskill. For product settings, route there.
Activate on both explicit access-policy requests and natural-language tool-use / resource-use governance intent.
Explicit requests:
uip gov access-policy, ToolUsePolicy, or tool-use policyTool-use / resource-use governance intent:
<sub-agent / flow / process>, allow/block it" — tool-use governance at the Actor Process ↔ Resource boundary<Actor Process> should be able to invoke <Resource>"<Actor Process> to use <Resource>" — e.g. "allow the Production Maestro to invoke the Production Agent"<tag> <Resource> from <Actor Process>" — silently translate to an Allow shape (Critical Rule #2). The Spec narrative shows only the Allow framing; do not surface the translation to the user.<user / robot user / group / admin> can trigger <tool-use>" — Actor Identity governance (emit actorRule; only User and Group types — robots resolve to User, ExternalApplication is unsupported)<tag-or-UUID> resources from <Actor Process>" — flip via the None operator on tags, values, or bothSibling redirect: if the user wants to govern product settings (Studio, StudioX, AI Trust Layer, Robot feature flags), that is the uip gov aops-policy surface — hand off to uipath-gov-aops-policy.
Map intent phrases to the three policy blocks. These priors feed directly into Phase 1 (planning-arch.md):
| User says... | Likely block(s) | Plugin |
|---|---|---|
"When <Actor Process> invokes <Resource>..." (tool-use) | selectors[] + executableRule | selector + executable |
"Only <tagged> resources" / "limit tool use to <tag>" | selectors[N].tags with Or operator | tags |
"Block / deny / restrict / exclude <tag> resources" | selectors[N].tags with None operator | tags |
"Specific resource UUIDs <id1>, <id2>" | selectors[N].values: ["<id>", ...] | selector |
"All agents except <id>" / "all except <tag>" | values or tags with None operator | selector + tags |
"Any caller type except <type>" (e.g. "any caller except Agent") | executableRule.values[] — single entry of the excluded type with operator: "None" and values: ["*"]; omit every other type | executable — Excluding a caller type |
"Only <user> / <robot user> / <group> can..." | actorRule (Actor Identity) | actor |
"On behalf of <user>" / "when <robot> triggers..." | actorRule with type: "User" (Robot User resolves to User UUID) | actor |
Workflow for intent-based requests:
impl.md.impl.md files are the only authoritative source for block-level shape (Critical Rule #6).uip login status --output json before any uip gov access-policy command. If not logged in, ask the user to run uip login (or uip login --authority <URL> for non-prod environments).policyType is always "ToolUsePolicy"; enforcement is always "Allow". Never emit "Deny".
enforcement: "Deny"; Deny is the runtime default when no Allow policy matches, so blocking is expressed as the complement of an Allow set.(flipped) badge, no "enforcement: Deny is not authorable" caveat). See plugins/tags/planning.md — Deny-to-Allow flip for the decision logic.organizationId and tenantId from ~/.uipath/.auth (see planning-impl.md — Step 1). Never hardcode tenant or organization UUIDs.actorRule is optional. A ToolUsePolicy access policy is composed of Selection Rule (selectors[]), Actor Process Rule (executableRule), and Actor Identity Rule (actorRule). The first two are mandatory; actorRule is emitted only when the user expressed actor-shaped intent — its absence means "any identity passes".values is required on every entry; tags only on selectors[] / executableRule.
values returns 400 Bad Request; actorRule does not accept a tags block today (the API rejects actorRule.tags).selectors[], executableRule.values[], and actorRule.values[] — use ["*"] for "all of this type" even when tags narrow the scope. Never emit actorRule.tags.impl.md for block-level JSON.yes / no review precedes each create, update, or delete call. The gate must show: (a) the Scope — the organization name / tenant name plus their UUIDs, read from ~/.uipath/.auth — so the user sees which environment is about to be mutated; (b) the complete policy JSON in chat; (c) clickable markdown links to both the Spec file (/tmp/access-policy-<slug>.spec.md, written by Phase 1) and the JSON working file (/tmp/access-policy-<slug>.json, written by Phase 2) using their resolved absolute paths (run realpath — never a relative path, a <WORKING_FILE> placeholder, or a ~/ path). For update flows the Spec file does not exist (Critical Rule #8) — show the Scope, the diff, and the JSON working file only. See Confirmation-gate wording.update: always get first and start from Data verbatim. Update is a full replacement.
actorRule block); a fresh Phase 1 Spec would silently wipe fields the user did not re-specify.Data object verbatim as the starting state, then strip audit fields (isBuiltIn, isTemplate, createdBy, createdOn, modifiedBy, modifiedOn, deletedBy, deletedOn).delete: always get and show a summary, then require an explicit yes to the verbatim prompt. Deletion is permanent. Multiple UUIDs may be deleted in one call.uip gov access-policy command in a scripted flow uses --output json.all, default tag filter (none), default status Simulated, etc.). Treat any value the user already supplied as final — never re-confirm. Surface Open questions only when there is no defensible default. The user changes whatever they want during the review loop.evaluate is user-initiated only and tenant-scoped. Do NOT call evaluate with synthetic/dummy UUIDs after create — dummy UUIDs with no Resource Catalog tags or no matching actor identity correctly return NoOp / Deny and confuse the user into thinking the policy is broken. Only run evaluate when the user explicitly asks. The login MUST target a specific tenant (not just an organization); if the PDP rejects with a tenant-context error, route the user to re-login with --tenant. See access-policy-commands.md — evaluate.status: "Simulated". Create in Simulated first; prompt the user to Activate after review via the post-create Activate this policy option. Emit Active at create time only when the user explicitly asks. See Key Concepts § Enforcement and status for the meaning of Simulated.executableRule, actorRule, AgenticProcess, RPAWorkflow) are implementation details that confuse end users.AgenticProcess / "Agentic Process"), RPA (not RPAWorkflow / "RPA Workflow"). JSON names appear only inside ```json code blocks, working file paths, plugin shape templates, API enum tables, CLI flag enum lists, or CLI error messages.uip or folders list FIRST. Translate the type string — Orchestrator's --process-type is NOT the same as the access-policy enum (AgenticProcess→ProcessOrchestration, RPAWorkflow→Process, APIWorkflow→Api); see the mapping table. For robots, see Critical Rule #16 — they resolve to a User UUID via resource-lookup-guide.md § Robots.actorRule.values[] accepts at most two entries — one User, one Group.
User and Group, and ExternalApplication.actorRule block.
values[] array.User and Group are present, operators must match (both Or or both None); mixed-operator intent splits into two policies.ExternalApplication is unsupported — refuse and route to User / Group / no-actor.User / Robot User / Group, but JSON always emits type: "User". Look up the robot via resource-lookup-guide.md § Robots, resolve to the linked User UUID, and merge into the single User entry. Never emit type: "Robot" or type: "ExternalApplication".These steps cover creating a new access policy from scratch. For existing policies or targeted operations, jump to the Task Navigation table below.
uip CLIwhich uip && uip --version
If not installed:
npm install -g @uipath/uipcli
See access-policy-commands.md — Authentication for the login flow (uip login status, uip login, non-production --authority, tenant scoping for evaluate).
Hand off to planning-arch.md. It builds a Policy Spec with two synchronized parts:
description field at create time.actorRule does not support tags today.The user reviews the pre-filled Spec and changes any row they want; the agent re-derives the narrative after every round so the two parts stay in sync. Phase 1 ends when every Open question is closed and the user approves with yes.
If the user has no concrete intent ("just create an access policy", "help me make one") or supplied only one of the four phrase categories (Resource / Actor Process / Actor Identity / Tag), Phase 1 routes through sample-policy-guide.md FIRST — it surfaces a canonical Spec narrative + JSON and offers the user three paths: adopt as-is, adapt one block, or describe from scratch. The chosen path seeds the Spec; the user still iterates rows and approves before Phase 2.
Hand off to planning-impl.md. It reads organizationId and tenantId from ~/.uipath/.auth, then walks each row of the approved Spec Components Table and reads the matching plugin's impl.md:
selectors[] entry via plugins/selector/impl.mdexecutableRule.values[] entry via plugins/executable/impl.mdactorRule.values[] entry via plugins/actor/impl.md. No tag filter — actorRule.tags is unsupported (Critical Rule #5).tags sub-object via plugins/tags/impl.mdPhase 2 reuses the slug Phase 1 used for the Spec file and writes the assembled PolicyDefinition to /tmp/access-policy-<slug>.json, so the Spec (.spec.md) and JSON (.json) sit side by side. Phase 2 hands back both paths.
Show a short human-readable summary that includes:
Organization "<NAME>" / Tenant "<NAME>" plus the matching organizationId / tenantId UUIDs read from ~/.uipath/.auth — so the user always sees which environment they are about to mutate before approving.Resources, Actor Process, Actor Identity — with the per-entry technical breakdown tucked inside a collapsible <details> section.Then output the complete JSON as a ```json code block in the chat (do not rely on the file links alone — the user may not be able to open them), plus clickable markdown links to both files using their resolved absolute paths (Critical Rule #7):
/tmp/access-policy-<slug>.spec.md — the human-readable Policy Spec from Phase 1/tmp/access-policy-<slug>.json — the JSON payload Phase 2 will submitSee policy-manage-guide.md — Create Step 4 for the exact layout, the ~/.uipath/.auth source-mapping for the Scope line, and the phrasing rules. Use the canonical wording from Confirmation-gate wording below. This is the only confirmation gate in the create flow.
uip gov access-policy create --file /tmp/access-policy-<slug>.json --output json
Record Data.upsertedPolicy.id as the new policy UUID. If Data.errors is non-null, surface the error and route back to Step 4 (keep editing).
uip gov access-policy get <POLICY_ID> --output json
Display the raw server-stored JSON to the user.
Render next steps as a numbered Markdown list under a ### What would you like to do next? heading so the user can reply with the number. Do NOT use AskUserQuestion. The list is conditional on the policy's status — if the policy is Simulated (the default), the first option is Activate this policy so the user can flip it to effective. See Completion Output below for the exact lists. Do NOT offer Evaluate and do NOT auto-run evaluate (Critical Rule #12).
Non-obvious mistakes the Critical Rules don't already cover by name. (Restatements of Critical Rules — hardcoded org/tenant, enforcement: "Deny", missing values, auto-running evaluate, stacking confirmation gates — live with the rules themselves.)
impl.md files are the only authoritative JSON source.actorRule whenever identity intent is expressed.actorRule when the user gave no actor constraint — adding an unrequested actorRule narrows scope silently.selectors[] entry per resourceType, one executableRule.values[] entry per executable type. (For actorRule, same-type identities merge — see Critical Rule #16.)RPAWorkflow or APIWorkflow in executableRule.values[].type — they are resource-only.operator: "And" on values — only Or / None. And is only valid on tags.tags.values — different arrays.Data is the source of truth (Critical Rule #8).| I need to... | Read these |
|---|---|
| Author a Policy Spec from intent | Quick Start + planning-arch.md — narrative paragraph + Spec Components Table |
| Start from a sample when the user has no concrete intent | sample-policy-guide.md — canonical Spec narrative + JSON with a 3-option picker (use as-is / adapt / from scratch) |
| Compose the concrete JSON from an approved Spec | planning-impl.md + the relevant plugin impl.md |
| Create a policy (end-to-end) | policy-manage-guide.md — Create |
| Update a policy | policy-manage-guide.md — Update — start from server Data, NOT a fresh Phase 1 Spec (Rule #9) |
| Delete a policy | policy-manage-guide.md — Delete — show summary + explicit yes (Rule #10) |
| List policies | policy-manage-guide.md — List |
| Get a single policy by UUID | policy-manage-guide.md — Get |
| Evaluate a policy against a request context | access-policy-commands.md — evaluate — user-initiated only (Rule #13) |
| Resolve a process / agent / flow / user / robot name to a UUID | resource-lookup-guide.md — uip or processes list / uip or folders list / uip or users list; robot lookups use the REST fallback then resolve to a User UUID |
Compose a selectors[] entry (Selection Rule) | plugins/selector/planning.md + plugins/selector/impl.md |
Compose the executableRule block (Actor Process Rule) | plugins/executable/planning.md + plugins/executable/impl.md |
Compose the actorRule block (Actor Identity Rule) | plugins/actor/planning.md + plugins/actor/impl.md |
| Pick tag operators / flip Deny→Allow | plugins/tags/planning.md + plugins/tags/impl.md |
| Look up CLI flags and output shapes | access-policy-commands.md |
Every policy this skill mutates is of type ToolUsePolicy. The API exposes other policy types but they are out of scope — this skill treats any non-ToolUsePolicy response from get as read-only.
A ToolUsePolicy access policy is structured as three rule blocks evaluated against a tool-use request:
| Block | Governs | Required? | Shape |
|---|---|---|---|
selectors[] — Selection Rule | The child Resource/Tool being invoked | Yes | Array — one entry per resource type. Each entry has values + optional tags. |
executableRule — Actor Process Rule | The calling workflow (Actor Process) | Yes | Object with values[] (one entry per executable type) + optional shared tags. |
actorRule — Actor Identity Rule | The identity running the Actor Process (User or Group) | Optional | Object with values[] carrying at most two entries — one User, one Group. When both are present, their operator must match. No tags — not supported on actorRule today (Critical Rule #5). |
Resource/Tool types (selectors[].resourceType): Agent, AgenticProcess, RPAWorkflow, APIWorkflow, CaseManagement, Flow.
Actor Process types (executableRule.values[].type): Agent, AgenticProcess, CaseManagement, Flow. (RPA and API workflows are resource-only — they cannot be callers.)
Actor Identity types (actorRule.values[].type): User, Group only. actorRule.values[] carries at most two entries — one User entry, one Group entry — and when both are present their operator must match (both Or or both None). Multiple users / groups go inside the single entry's values[] array, never as duplicate entries of the same type. ExternalApplication is not supported today. Design-time / Spec terminology distinguishes "User" from "Robot User" (a robot is a kind of user), but both serialize as type: "User" in the JSON — the skill never emits type: "Robot". See Critical Rule #16.
The CLI wraps two endpoints:
list / get / create / update / delete operate on policy records in the catalog.evaluate asks the service to resolve the effective decision for a concrete request context. evaluate requires tenant-scoped login (Critical Rule #12).Per-request decision flow:
NoOp for that policy).Allow → final enforcement Allow.Allow → request falls through to the runtime default (Deny / NoOp).enforcement: "Deny" is not authorable (Critical Rule #2) — Deny is the default outcome when no Allow policy matches. To "block" something, write an Allow policy that targets the complement of what should be blocked (or use operator: "None" on tags / values).status: "Simulated" policies are excluded from aggregation (see Enforcement and status).Tags are named labels attached to resources in the UiPath Resource Catalog. Used inside selectors[].tags and executableRule.tags to narrow scope. Operators: Or (any), And (all), None (exclude). The None operator is also how Deny intents get flipped into Allow policies — see plugins/tags/planning.md. actorRule does NOT support tags today — never emit actorRule.tags (Critical Rule #5 / plugins/actor/).
enforcement: always "Allow" — "Deny" is not authorable (Critical Rule #2). The runtime delivers Deny by default when no Allow policy matches, so "blocking" intent is expressed by writing an Allow policy targeting the complement of what should be blocked.status: Active (counted in runtime aggregation) or Simulated (the policy IS evaluated, but its verdict is excluded from aggregation — it shows up in evaluationDetails for debugging only). Default Simulated for newly created policies (Critical Rule #13) — it is the safe way to preview a rule before flipping to Active. Do not conflate Simulated with "disabled" or "draft". Other places in the skill that refer to "Simulated" link back here for the meaning.enforcement: "Deny" is not authorable (Critical Rule #2). The agent silently translates Deny intent into an Allow shape and never exposes the mechanic to the user. See plugins/tags/planning.md — Deny-to-Allow flip for the decision logic and worked examples.
Two paired files live in /tmp for every create flow:
| File | Written by | Purpose |
|---|---|---|
/tmp/access-policy-<slug>.spec.md | Phase 1 (planning-arch.md — Spec file convention) | Human-readable Policy Spec — narrative paragraph + Spec Components Table. Re-written on every Phase 1 iteration round once the policy name (Spec row 1) is set. |
/tmp/access-policy-<slug>.json | Phase 2 (planning-impl.md — Step 4) | Raw PolicyDefinition JSON submitted to uip gov access-policy create. |
The slug is computed from the policy name and is identical across both files — they sit side by side in /tmp so the user can diff .spec.md against .json to confirm Phase 2 didn't drift from the approved Spec. Show both paths in the review gate as clickable markdown links using their resolved absolute paths (run realpath — Critical Rule #7).
For update flows the file is /tmp/access-policy-<id>-working.json only — there is no .spec.md because the existing server-stored definition is the source of truth (Critical Rule #8), not a freshly-authored Spec.
Every mutation runs through a single yes / no review (Critical Rule #7). Use these templates verbatim so wording stays consistent across the skill:
| Operation | Template |
|---|---|
| Create | Create access policy "<POLICY_NAME>"? (yes / no / keep editing) |
| Update | Apply update to access policy "<POLICY_NAME>"? (yes / no / keep editing) |
| Delete (single) | Delete access policy "<POLICY_NAME>"? This cannot be undone. (yes / no) |
| Delete (multi) | Delete <N> access policies (<POLICY_NAME_1>, <POLICY_NAME_2>, ...)? This cannot be undone. (yes / no) |
keep editing is treated the same as no — route the user back to the step that owns the field being changed (metadata → policy-manage-guide.md — Create Step 3; a specific block → the matching plugin's impl.md; intent itself → planning-arch.md) and re-enter the gate only after the change is applied.
When you finish a mutating operation, report:
Created access policy "<NAME>" (ID: <POLICY_ID>) — Resources: <RESOURCE_SUMMARY> · Actor Process: <ACTOR_PROCESS_SUMMARY> · Actor Identity: <ACTOR_IDENTITY_SUMMARY or "any identity">. Use plain-English phrasing ("all Agent resources tagged 'Production'"), not JSON terms like resourceType / operator.Simulated, print: ⚠️ This policy is in Simulated mode — it is evaluated but does NOT affect enforcement. Activate it when you want it to take effect.create: both /tmp/access-policy-<slug>.spec.md (the approved Policy Spec) and /tmp/access-policy-<slug>.json (the submitted JSON).update: /tmp/access-policy-<id>-working.json only.
The user can re-open these to inspect what was sent.<details><summary>Show technical details</summary>…</details> block so it is collapsed by default. (Omit after delete.)### What would you like to do next? heading so the user can reply with the number. Do NOT use AskUserQuestion, do NOT render as a table, and do NOT wrap the list in <details>. The "Something else" option is always last. Options depend on the current status of the policy:After create or update where status == "Simulated" (the default):
### What would you like to do next?
1. **Activate this policy** — re-run `update` with the working file patched to `status: "Active"` via [policy-manage-guide.md — Update](./references/policy-manage-guide.md#update-a-policy). Recommended follow-up — Simulated policies do not enforce anything.
2. **List policies to verify** — run `uip gov access-policy list --output json` and show the new/updated entry.
3. **Update this policy** — jump to [policy-manage-guide.md — Update](./references/policy-manage-guide.md#update-a-policy) with this policy ID.
4. **Create another policy** — return to Quick Start Step 2.
5. **Something else** — accept free-form string input and act on it.
Reply with the number.
After create or update where status == "Active":
### What would you like to do next?
1. **List policies to verify** — run `uip gov access-policy list --output json` and show the new/updated entry.
2. **Update this policy** — jump to [policy-manage-guide.md — Update](./references/policy-manage-guide.md#update-a-policy) with this policy ID.
3. **Create another policy** — return to Quick Start Step 2.
4. **Something else** — accept free-form string input and act on it.
Reply with the number.
After delete: offer only:
### What would you like to do next?
1. **List policies to verify** — run `uip gov access-policy list --output json`.
2. **Something else** — accept free-form string input and act on it.
Reply with the number.
Do NOT offer Evaluate this policy in the post-mutation list — end users creating or updating a policy do not need to dry-run it, and dummy-UUID evaluations produce confusing results (Critical Rule #12). evaluate remains available on demand only when the user explicitly asks; route via access-policy-commands.md — evaluate (real UUIDs + tenant-scoped login required — Critical Rule #12).
Do not run any of these actions automatically. Wait for the user's selection.
uip gov access-policy subcommand, its flags, input/output shapes, and authentication. Every other guide links here for command details rather than inlining them.uip or processes list / uip or folders list / uip or users list lookups to resolve human-readable names to the UUIDs required by selectors[].values, executableRule.values[].values, and actorRule.values[].values. Route here whenever the user names a process, folder, or user without supplying a UUID.PolicyDefinition JSON by reading ~/.uipath/.auth for identity and each plugin's impl.md for block-level JSON.selectors[] (Selection Rule): resource/tool types (Agent, AgenticProcess, RPAWorkflow, APIWorkflow, CaseManagement, Flow), targeting modes, tag filters.executableRule (Actor Process Rule): executable types (Agent, AgenticProcess, CaseManagement, Flow), targeting modes, shared tag filter.actorRule (Actor Identity Rule): identity types (User, Group only — ExternalApplication not supported; robot intent serializes as User), targeting modes. No tag filter today — emitting actorRule.tags is rejected by the API. Optional block — emit only when the user supplies actor-shaped intent.tags sub-object with Or / And / None operators and the Deny-to-Allow flip.