> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/automation/automation-exclusion-center.md).

# Automation Exclusion Center

Review automation exclusions that protect critical assets.

Automation exclusion policies enable you to protect critical assets from automated remediation, without having to detach and customize playbooks and scripts.

Automation exclusion policies prevent commands and scripts from performing automated remediation actions on critical assets, such as users, IP addresses, and domains. For example, a playbook task might block multiple domains, but mission-critical domains in the policy list would not be blocked.

Automation exclusion policies apply any time a relevant command or script runs, whether in a playbook task, a Quick Action, as an action executed by an AI agent, or in the CLI. If you configure a policy to allow overrides, users can manually run the command in the War Room, using the `override-policy` parameter. Any command triggered with the `override-policy` parameter appears in the Management Audit Logs. If you attempt to use the `override-policy` parameter and the policy does not allow overrides, an error entry appears in the War Room.

When an automation exclusion policy prevents a command or script from a remediation action, the exclusion appears in the issue War Room.

When a playbook task contains a command or script that is included in an automation exclusion policy, a **Policy** tab appears in the task details pane, showing the relevant policy.

To enable an automation exclusion policy, add critical assets to a list. Each policy uses one or more lists to exclude assets from remediation. By default, all policies are enabled, but lists are empty until assets are added to the list.

{% hint style="info" %}
By default, all users have read and edit permissions to lists. When creating a list of critical assets, we recommend limiting the read and edit permissions to specific roles.
{% endhint %}

**User Hard Remediation** and **User Soft Remediation** policies can also use asset groups, enabling automatic updates of critical assets without requiring you to edit a list. These remediation policies can contain lists, asset groups, or a combination of lists and asset groups.

Policies can be enabled or disabled, and lists can be edited, but you cannot add or remove policies.

Each policy can include one or more scripts or commands. Commands and scripts only appear if the content is installed. The policy affects only these scripts and commands. Scripts and commands cannot be added, edited, or removed from the policy.

By default, only admin users have access to the **Automation Exclusion Center** page. You can also provide other roles with **View** or **View/Edit** access to the Automation Exclusion Center. When creating or editing a role, the permission can be found under **Investigation & Response** → **Automations**.

Policies can be sorted, filtered, and searched using the category, status, policy, exclude, and description columns.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/detect-investigate-and-respond-to-threats/investigate-and-respond-to-cases/automation/automation-exclusion-center.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.