About access policies

Fine-grained access control policies for governing which automation processes can invoke other automation resources within a Test Cloud tenant.

Wichtig:

If an organization's plan stops including governance, the Access policies section is no longer available, access policies can no longer be viewed, created, edited, or deleted, and existing policies are no longer evaluated.

Hinweis:

Access policies are currently in Public Preview.

Access policies require an organization plan that includes governance:

• Not available on the Free, Basic, and Community plans.
• Available on the following Unified Pricing plans: Application Testing Standard and Application Testing Enterprise.

Access policies let organization administrators define fine-grained rules that control which automation processes can invoke other automation resources within a tenant. When an enabled policy protects a resource, it denies each invocation of that resource that does not match its rules, adding an enforcement layer on top of standard role-based access control. A policy checks only the process types that it lists. For details, see How access policies work.

Access policies are available in Admin > Access policies > Policies.

Hinweis:

Feature availability depends on the cloud platform that you use. For details, refer to the Feature availability page.

Why use access policies

Standard role-based access control (RBAC) governs which users and robot accounts have permissions to perform actions in the platform. However, RBAC alone cannot express conditional rules based on the type of automation invoking a resource, the attributes those automations or resources carry, or the identity on whose behalf a process runs.

Access policies provide a centralized policy engine that evaluates every invocation of a protected automation resource — whether the request comes from a UiPath agent or workflow, a pro-code application using the UiPath SDK, or a direct API call.

Resources and calling processes can be classified using tags — labels you apply in Orchestrator to organize and identify automations. For example, you might tag sensitive processes as Confidential, or mark validated automations as Prod-ready. Tags are optional: policies can also target all resources or processes of a given type without any tag filter. When a policy includes multiple tag values, you specify whether resources or processes must match any, all, or none of those tags.

Typische Anwendungsfälle sind:

• Allowing only processes tagged Prod-ready to invoke Agents tagged Confidential: the policy lists all four actor process types with a Prod-ready tag filter.
• Allowing only specific Maestro BPMNs to invoke a sensitive Agent: the policy sets Maestro BPMN to Specific, and Agent, Maestro Case, and Maestro Flow to Exclude all.
• Allowing only approved Agents to invoke a given resource: the policy sets Agent to Specific, and Maestro BPMN, Maestro Case, and Maestro Flow to Exclude all.

How access policies work

Each policy defines three things:

• Target resource — the automation resources the policy protects. You select one or more resource types (such as Agents or API Workflows) and decide, per type, whether the policy covers all instances, only the instances that you include, all instances except the ones that you exclude, or no instances (Exclude all). The policy does not protect a resource type that is set to Exclude all. Tag filters can narrow the scope further.
• Actor — who is allowed to invoke the target resource. The actor configuration has two parts:
  • Actor process — the calling automation process (such as an Agent or Maestro BPMN). As with target resources, each selected process type can cover all instances, only the instances that you include, all instances except the ones that you exclude, or no instances (Exclude all). The policy denies every caller of a process type that is set to Exclude all. An optional tag filter applies to all selected process types.
  • Actor identity — the user or robot on whose behalf the calling process runs. You select specific users, groups, or robots, and then choose Include or Exclude for all of them. With Include, the caller must be a selected user or robot, or a member of a selected group. With Exclude, the policy denies these callers.
• Access decision — the result when the target resource and the actor both match. Allow is the only supported value.

If no policy targets the invoked resource, access policies do not affect the invocation.

If an invocation is governed by multiple policies, the most restrictive decision applies (Deny takes precedence over Allow): the invocation must satisfy every enabled policy that targets the resource. A policy whose rules the caller does not satisfy denies the invocation, even if another policy allows it. A policy that does not list the caller's process type allows the invocation, unless the caller does not match the policy's Actor identity rule.

A policy evaluates only the immediate invocation: the actor is the process that invokes the target resource directly. Access policies do not evaluate a chain of nested invocations as a whole, so a separate policy is needed for each immediate invocation. For example, a Maestro BPMN invokes an Agent, and the Agent invokes an API Workflow. One policy targets the Agent with Maestro BPMN as the actor process. A second policy targets the API Workflow with Agent as the actor process.

Policy traces

All policy evaluation results are recorded as traces, which you can review on the Traces tab inside Access policies.

Example: restricting Agent access

A Center of Excellence (COE) admin wants to control which automations can invoke Agents, then apply a stricter rule to the most sensitive ones.

Stage 1 — allow only validated Maestro BPMNs

• Policy 1: target any Agent; allow Maestro BPMNs tagged Prod-ready.

Among Maestro BPMNs, only those tagged Prod-ready can invoke Agents, and a Maestro BPMN without that tag is denied. The actor rule lists only Maestro BPMN, so this policy does not restrict callers of other process types, such as a Maestro Case.

Tipp:

A policy checks process instances and tags only for the process types that you select as the Actor process. Callers of other process types pass this check, and the policy allows them unless they fail its Actor identity rule. Restricting an additional process type requires adding it as an Actor process and specifying which instances or tags have access.

Stage 2 — add a stricter rule for sensitive Agents

Agents tagged Confidential need a further guardrail. The admin adds a second policy, leaving Policy 1 unchanged:

• Policy 2: target Agents tagged Confidential; allow Maestro BPMNs tagged Audited.

Policy 2 targets only Agents tagged Confidential, so it has no effect on any other Agent. Where both policies apply, the most restrictive decision wins:

Anrufer	Ziel	Policy 1	Policy 2	Final decision
Maestro BPMN tagged Prod-ready	Agent without Confidential tag	Zulassen	Does not apply	Zulassen
Maestro BPMN without Prod-ready	Agent without Confidential tag	Verweigern	Does not apply	Verweigern
Maestro-Fall	Agent without Confidential tag	Allow — no rule for this process type	Does not apply	Zulassen
Maestro BPMN tagged Prod-ready and Audited	Agent tagged Confidential	Zulassen	Zulassen	Zulassen
Maestro BPMN tagged Prod-ready only	Agent tagged Confidential	Zulassen	Verweigern	Verweigern

Policy 1 governs every Agent, while Policy 2 governs only Agents tagged Confidential. Where both apply, the most restrictive decision wins (Deny over Allow), so the caller must satisfy both. Adding a policy therefore narrows access rather than widening it. To allow additional instances or tags of a listed process type, the actor rule of the existing policy can be extended instead.

Target resource types

The following resource types can be protected by an access policy:

• Mitarbeiter
• Maestro-BPMN
• RPA-Workflow
• API-Workflow
• Maestro-Fall
• Maestro-Flow

Actor process types

The following process types can be specified as the actor in a policy:

• Mitarbeiter
• Maestro-BPMN
• Maestro-Fall
• Maestro-Flow

You can further refine the actor with the Actor identity rule, which includes or excludes specific users, groups, or robots. One Include or Exclude choice applies to all selected identities.

Policy enforcement modes

When creating or editing a policy, you choose an enforcement mode:

• Simulation Mode — the policy evaluates invocations and records the result as a trace, but never changes the access decision. This mode is recommended for testing a policy before enabling it in production. In the policies list, this appears as Simulation mode.
• Enabled — the policy is active and access decisions are applied in real time.
• Disabled — the policy is saved but has no effect on invocations.

Limits

• A tenant can have up to 30 access policies, and an organization can have up to 300. Enabled, Simulation Mode, and Disabled policies count toward these limits.
• A policy name can have up to 256 characters, and a description up to 1024 characters.
• The actor tag filter can have up to 50 tags.
• The Actor identity rule can have up to 50 groups.
• Access policies are not evaluated when you run a process in debug mode in Studio Web.

Traces and activity summary

The Traces tab in Access policies shows the result of every evaluated invocation. Each trace entry includes the following columns:

• Time — when the invocation was evaluated.
• Result — Allow, Deny, Simulated allow, or Simulated deny.
• Policy — the name of the policy that produced the result.
• Tenant — the tenant where the evaluation occurred.
• Actor process — the calling process.
• Actor process type — the type of the calling process (for example, Agent or Maestro BPMN).
• Actor identity — the specific user, group, or robot making the call.
• Actor identity type — the type of actor identity (for example, User, Group, or Robot).
• Target — the resource being invoked.
• Target type — the type of the target resource (for example, Agent or RPA Workflow).

Traces are tenant-scoped, and filters become available only after a tenant is selected. The available filters are Result, Policy, Actor process, Actor process type, Actor identity, Actor identity type, Target, and Target type.

The summary cards at the top of the Policies tab show an aggregate summary of Total operations, Allowed, Denied, and Observed Only (operations captured only by policies in Simulation Mode). These totals are tenant-level, and organization-level totals are not available. Values appear only after a tenant is selected; when no tenant is selected, each card displays —. The 24h, 7d, and 30d buttons control the time window, and 30d is selected by default.

Relationship to other governance features

Access policies complement but do not replace the following existing features, which remain applicable:

• RBAC — to grant permissions to users based on roles.
• AI Trust Layer policies — to govern the use of AI features and LLMs within the platform.
• Automation Ops governance policies — to govern product-specific policies that restrict certain settings and behaviors.

Required roles

Only users with the Organization Administrator role, or with a role that includes the Authorization/Access policy permission, can view, create, edit, enable, disable, or delete access policies.

To use tag filters in a policy, the tags must already exist in the tenant, or you cannot save the policy. A tag filter matches only the resources and processes that carry the tag in Orchestrator. For information on creating and applying tags, refer to Managing tags.