# Managing access policies

> Create, edit, enable, disable, and delete access policies in Test Cloud to control process-to-process invocations within a tenant.

This page describes how to create, edit, enable, disable, and delete access policies in the **Access policies** section of the Admin area. For a conceptual overview of access policies, refer to [About access policies](about-access-policies.md).

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

## Prerequisites

Before managing access policies, make sure that:

* You are an **Organization Administrator**, or you have a role that includes the **Authorization/Access policy** permission.
* The organization's plan includes governance. For details, refer to [About access policies](about-access-policies.md).
* To use tag filters, the tags exist in the tenant. For details, refer to [Managing tags](managing-tags.md).

## Creating an access policy

Access policy creation uses a five-step wizard.

### Step 1: Scope

1. In **Admin** > **Access policies**, select **Policies**.
2. Select **Add policy**.
3. From the **Tenant** dropdown, select the tenant the policy applies to.
4. Select **Next**.

:::note
Once the policy is created, the scope cannot be changed. To apply the policy to a different tenant, create a new policy.
:::

### Step 2: Policy definition

Define the target resource and the actor.

1. In the **Target resource** card, select **Edit**. The **Configure target resource** panel opens.
   * Under **Resources**, select **Add resource** and choose one or more resource types to protect: **Agent**, **Maestro BPMN**, **RPA Workflow**, **API Workflow**, **Maestro Case**, or **Maestro Flow**.
   * For each resource type, use the toggle to select **All** (all instances), **Specific** (only the instances that you select, or all instances except the ones that you select), or **Exclude all** (no instances; the policy does not protect this resource type).
   * Optionally, under **Tag filters**, select one or more tags to narrow the scope to resources that carry those tags. Use the **Any**, **All**, or **None** toggle to specify whether the resource must match any, all, or none of the selected tags.
   * Select **Apply**.

   ![The Configure target resource panel with the Add resource list open, showing the Agent, Maestro BPMN, RPA Workflow, API Workflow, Maestro Case, and Maestro Flow resource types](https://dev-assets.cms.uipath.com/assets/images/test-cloud/access-policies-target-resource-9520f7c0.webp)

2. In the **Actor** card, select **Edit**. The **Configure actor** panel opens and shows two sections:

   **Configure Actor Process:**
   * Under **Process types**, select **Add process type** and choose one or more process types that are allowed to invoke the target resources: **Agent**, **Maestro BPMN**, **Maestro Case**, or **Maestro Flow**.
   * For each process type, use the toggle to select **All** (all instances), **Specific** (only the instances that you select, or all instances except the ones that you select), or **Exclude all** (no instances; the policy denies every caller of this process type).
   * Optionally, under **Tag filters**, select one or more tags to narrow the actor scope by tag. The tag filter applies to all selected process types.

   **Configure Actor Identity:** (optional)
   * Search for and select specific users, groups, or robots, and then select **Include** or **Exclude**. The choice applies to all selected identities, so one policy cannot include some identities and exclude others. If you leave this section empty, the policy applies regardless of the identity the calling process runs on behalf of.

   * Select **Apply**.

   ![The Configure actor panel showing the Actor Process section with process types and All, Specific, and Exclude all toggles, the Tag filters section, and the Actor Identity section](https://dev-assets.cms.uipath.com/assets/images/test-cloud/access-policies-configure-actor-1721443e.webp)

:::note
The **Access decision** is set to **Allow**, which is the only supported decision value. **Target resource** and **Actor process** must both be configured before you can proceed. **Actor identity** is optional.
:::

3. Select **Next**.

### Step 3: Name and description

1. Enter a **Name** for the policy. Policy names are not required to be unique, so a descriptive name makes policies easier to tell apart in the list and in traces.
2. Optionally, enter a **Description** to explain what the policy governs.
3. Select **Next**.

### Step 4: Enforcement mode

1. Select an enforcement mode:

   * **Simulation Mode** — evaluates invocations and records the result as a trace, but never changes the access decision. Recommended for testing a policy before enabling it in production.
   * **Enabled** — actively enforces the policy in real time.
   * **Disabled** — saves the policy without activating it.

   ![The Enforcement mode step of the policy wizard with the Simulation Mode, Enabled, and Disabled options](https://dev-assets.cms.uipath.com/assets/images/test-cloud/access-policies-enforcement-mode-05de504d.webp)

2. Select **Next**.

### Step 5: Review and save

1. Review your configuration. To change a section, select it.
2. Select **Save**.

## Editing an access policy

1. In **Admin** > **Access policies** > **Policies**, find the policy you want to edit.
2. Select the three-dot menu (**⋮**) at the end of the policy row, then select **Edit**.
3. Update the relevant fields in the wizard.
4. Select **Save**.

To enable, disable, or simulate a policy, edit it and select a different option in the **Enforcement mode** step.

## Deleting an access policy

1. Find the policy in the **Policies** list.
2. Select the three-dot menu (**⋮**) at the end of the policy row, then select **Delete**.
3. Confirm the deletion.

:::important
Deleting a policy removes all enforcement. Invocations that were previously governed by the deleted policy are no longer evaluated against it. Deletion is permanent — a deleted policy cannot be restored, and must be recreated if it is needed again.
:::

## Filtering and searching policies

Use the **Search** box to filter policies by name or description. Use the **Tenant** dropdown to filter policies by tenant. Use the **Status** dropdown to filter by enforcement mode: **All**, **Enabled**, **Simulation mode**, or **Disabled**. Use **Columns** to show or hide columns such as **Description**, **Tag filter**, **Tenant**, and **Last modified**.

## Monitoring policy activity

The summary cards at the top of the **Policies** tab show aggregated totals for **Total operations**, **Allowed**, **Denied**, and **Observed Only** (operations captured only by policies in Simulation Mode). These totals are tenant-level, so a tenant must be selected before any values appear; organization-level totals are not available. When no tenant is selected, the cards display **—**, and the policy table displays **No data to display yet.** Use the **24h**, **7d**, and **30d** buttons to change the time window; **30d** is selected by default.

Individual policies have their own summary. Select a policy to open its details, which show aggregated totals of evaluations, allowed, denied, and simulated results for that policy, over the same **24h**, **7d**, and **30d** windows. Select **View traces** at the bottom of the policy details to open the **Traces** tab with a filter for that policy already applied.

:::note
The summary cards and the trace list count different things. The cards count **operations** — a governed invocation counts once, no matter how many policies evaluated it. The **Traces** tab and the per-policy details count **evaluations** — one entry per policy per invocation — so these numbers can be higher than the card totals when several policies govern the same resources.
:::

## Reviewing access policy traces

The **Traces** tab provides a real-time audit log of every invocation evaluated by the policy engine.

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).

Select a tenant first: traces are tenant-scoped, and the remaining filters become available only after a tenant is selected. You can then filter by **Result**, **Policy**, **Actor process**, **Actor process type**, **Actor identity**, **Actor identity type**, **Target**, and **Target type**.

To investigate an individual trace, select the three-dot menu (**⋮**) on the trace row. The details panel shows related data such as the folder, the job, and the trace ID, and includes a **View full trace in Orchestrator** link that opens the corresponding Orchestrator job page.

Changes to access policies, such as creating, editing, or deleting a policy, are also recorded in the organization-level and tenant-level audit logs. For details, refer to [About logs](about-logs.md).