uipath-governance

name: uipath-governance description: "UiPath governance via uip gov — author and deploy policies on two layers. AOps product policies (uip gov aops-policy): block/restrict/enforce features in Studio, StudioX, Assistant, Robot, AI Trust Layer, Agent Builder; deploy to user/group/tenant. Access ToolUsePolicy (uip gov access-policy): allow/deny when one workflow invokes another as a tool (Agent→Agent/Maestro/Flow/RPA/API/Case), gated by tag, caller, or actor (User/Group). Skill classifies product-layer vs resource/tool-use intent before authoring. Operate: deploy/undeploy policies to user/group/tenant, query effective deployed policy, list deployment subjects. Diagnose: investigate policy not taking effect, debug deployment precedence (user>group>tenant), evaluate access-policy rules, troubleshoot blocked tool invocations. For platform ops→uipath-platform." allowed-tools: Bash, Read, Write, Edit, Grep, Glob

UiPath Governance

Uber skill for UiPath governance authoring. Two backing CLI surfaces:

Both surfaces share verbs (block, restrict, deny, allow, require, enforce). The same English sentence often maps to either layer, so this skill classifies first and only then routes to the matching mechanic.

When to Use This Skill

Activate on any governance / policy / rule intent — even when the user did not name the underlying CLI:

• policy / rule / guardrail / govern / gate / control requests
• block / restrict / deny / disable / disallow an action, model, app, URL, agent, flow, or process
• require / enforce / mandate a behavior or rule
• allow only / permit only / limit to / restrict to X
• who can / which … can / on behalf of — actor- or identity-shaped governance
• compliance / posture / audit framing on top of policies

Troubleshoot

• Investigate why a governance policy isn't taking effect
• Debug deployment precedence (user > group > tenant override)
• Evaluate access-policy rules against test scenarios (access-policy evaluate)
• Troubleshoot blocked tool/workflow invocations
• Audit which policies are deployed and to whom
• Identify license-type / product mismatch causing silent no-ops

Sibling redirects:

• Platform ops (auth, Orchestrator resources, packaging, deploy) → uipath-platform
• Authoring agents / workflows / RPA themselves → uipath-agents / uipath-rpa / uipath-maestro-flow

Critical Rules

1. Classify before authoring. First action on any governance request is to classify intent into Branch A (AOps) or Branch B (Access). Use the priors in references/disambiguation-guide.md. Never start create / update / delete until classification is settled — by user wording or by the disambiguation question.
2. Classification lives at the top. Mechanic libraries assume the branch is chosen. Do not let those flows ask "did you mean the other branch?" — that question belongs here.
3. One branch per mutation. A single user request produces a policy on one branch only. If the user wants both, run two sequential flows with two confirmation gates.
4. Each mechanic owns its own Critical Rules. Once routed, follow the branch's rules — do not relax them from this top level.
5. Always uip login before any uip gov … command. evaluate (Access) additionally requires tenant-scoped login — see access-policy-overview-guide.md § Critical Rules.
6. Never fabricate UUIDs. Resolve every named user / group / process / agent / flow / robot / tenant via the relevant branch's lookups.

Workflow

1. Classify the intent. Read references/disambiguation-guide.md — it lists the strong signals for each branch, the phrase patterns that need disambiguation, and the canonical worked example. If a strong signal matches, route silently. If the phrasing is ambiguous (matches both branches), ask the disambiguation question and wait for a digit reply. If the user replies with anything other than 1 or 2, treat it as a re-statement of intent and re-classify. Do not run any CLI command before classification is settled — the disambiguation question itself does not need uip, and an unrelated request (platform ops, agent authoring) must redirect to a sibling skill before any setup happens here.
2. Verify uip and login (only after classification routes to a governance branch).

   which uip && uip --version
   uip login status --output json
   

   If not installed: npm install -g @uipath/uipcli. If not logged in: uip login (--authority <URL> for non-prod). For Access evaluate, login MUST be tenant-scoped.
3. Route to the chosen mechanic and follow its flow end-to-end.
   • Branch A → references/aops-policy/aops-policy-overview-guide.md
   • Branch B → references/access-policy/access-policy-overview-guide.md

Disambiguation Question

When the user's intent fits both branches, render exactly this numbered list (no AskUserQuestion, no table) and wait for a digit reply:

### Which layer should this rule govern?

1. **Govern the product** — control what Studio / StudioX / Assistant / Robot / AI Trust Layer / Agent Builder *can do* (e.g. block ChatGPT inside Studio, enforce Workflow Analyzer, disable a Marketplace widget). Backed by `uip gov aops-policy`.
2. **Govern resource/tool use** — control which Actor Processes / identities can *invoke* which child Resource as a tool (e.g. block agents tagged `Sandbox` from being called, only let the finance group trigger this Flow). Backed by `uip gov access-policy`.

Reply with the number.

The canonical ambiguous prompt is "Block ChatGPT for my finance team using Studio." See references/disambiguation-guide.md for the worked-out reasoning of why both interpretations produce a working but different artifact.

Reference Navigation

Anti-patterns

• Do NOT skip the disambiguation question when the phrasing fits both branches. Mechanic libraries assume the branch is chosen and will not catch wrong-branch routing.
• Do NOT hand off to a mechanic, then ask "did you mean the other branch?". That question must happen at this top level.
• Do NOT merge AOps and Access intent into one policy. Different artifacts, different CLIs, different schemas.
• Do NOT activate this skill for platform ops. Route to uipath-platform.
• Do NOT propose skill edits when intent doesn't map to either branch. Ask the user to clarify.