# About access policies > Fine-grained access control policies for governing which automation processes can invoke other automation resources within a Test Cloud tenant. :::important 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. ::: :::note 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](#how-access-policies-work). Access policies are available in **Admin** > **Access policies** > **Policies**. :::note Feature availability depends on the cloud platform that you use. For details, refer to the [Feature availability page](test-cloud-feature-availability.md#admin). ::: ## 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. Typical use cases include: * 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. :::tip 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: | Caller | Target | Policy 1 | Policy 2 | Final decision | |---|---|---|---|---| | Maestro BPMN tagged **Prod-ready** | Agent without **Confidential** tag | Allow | Does not apply | **Allow** | | Maestro BPMN without **Prod-ready** | Agent without **Confidential** tag | Deny | Does not apply | **Deny** | | Maestro Case | Agent without **Confidential** tag | Allow — no rule for this process type | Does not apply | **Allow** | | Maestro BPMN tagged **Prod-ready** and **Audited** | Agent tagged **Confidential** | Allow | Allow | **Allow** | | Maestro BPMN tagged **Prod-ready** only | Agent tagged **Confidential** | Allow | Deny | **Deny** | 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: * **Agent** * **Maestro BPMN** * **RPA Workflow** * **API Workflow** * **Maestro Case** * **Maestro Flow** ## Actor process types The following process types can be specified as the actor in a policy: * **Agent** * **Maestro BPMN** * **Maestro Case** * **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). ![The Traces tab for a selected tenant, showing the Time, Result, Policy, Tenant, Actor process, Actor process type, Actor identity, Actor identity type, Target, and Target type columns with filters above them](https://dev-assets.cms.uipath.com/assets/images/test-cloud/access-policies-traces-view-cdbe517e.webp) 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. ![The Policies tab of the Access policies page, showing the tenant selector, the time window buttons, the summary cards, and the list of access policies](https://dev-assets.cms.uipath.com/assets/images/test-cloud/access-policies-policies-view-f457a209.webp) ## 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](managing-tags.md).