> 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/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-playbooks-and-scripts.md). # Manage access to playbooks and scripts Review the following: * [Manage access to objects](/cortex-xdr-5.x/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects.md) The **Playbooks** and **Scripts** pages serve as the central repositories where you can view, create, and modify automation logic for your environment. By using object-level access, you can ensure that custom (user-defined) playbooks and scripts, such as those used for sensitive remediation or specialized third-party integrations, are only accessible to authorized users and user groups. Your access is determined by your role permissions combined with object ownership; you can only interact with playbooks and scripts where you are the Owner, those explicitly shared with you (or your user group), or those marked as **Public**. {% hint style="warning" %} ### Prerequisite * **Configure tenant-level settings**: An administrator must first establish the sharing framework under **Settings** → **Configurations** → **Access Management** → **Objects**. The configuration of these settings defines the authorized sharing workflows for all custom objects, including report templates: * **Enable "Owners can Share objects they created"**: Grants owners the ability to share playbooks and scripts with specific users, user groups, and API keys. This enables the **Share** option in the right-click menu for any playbook listed on the on the **Playbooks** page or any script listed on the **Scripts** page. * **Disable "Owners can Share objects they created"**: Restricts owners to managing only **General access** (**Public** vs. **Restricted**). In this case, the **Share** option is removed from the playbook menu on the **Playbooks** page or from the script menu on the **Scripts** page, and replaced with the **Manage Access** option. For more information on configuring tenant-level settings, see [Manage access to objects](#UUID-08918f93-4ec6-0395-cbf6-3b464db51e02). * **Define Scope-Based Access Control (SBAC)**: While per-object access controls the visibility of the playbook or script itself, the actions performed during execution depend on the trigger method: * **Manual execution**: Actions are governed by the permissions and scope of the user who explicitly runs the playbook or script, as well as the defined scope of the involved integrations. * **Automated execution**: Actions performed by automation rules are executed as "system" and are governed by the defined scope and permissions of the involved integrations, regardless of the configured access of the user who created or modified the rule. As such, they should be carefully crafted such that they will affect only the intended data. For more information on defining SBAC, see [Manage user scope](#UUID-c4e04c0a-5701-9f78-1fd3-ae2c976e7908). {% endhint %}
Automation objects Automation objects in Cortex XDR are categorized by their origin, which dictates how access is managed: * **Custom objects**: Any playbook or script created by a user, whether through a new build, duplicating an existing object, or importing a file, is a custom object. Ownership and granular "access" described in this section apply only to these custom objects. * **Out-of-the-box (OOTB) objects**: These are playbooks and scripts are either included by default in Cortex XDR, installed via Marketplace, or added using the `cortex-sdk`. OOTB playbooks and scripts are **Public** and Read-Only to all users with appropriate role permissions. In the context of the broader object management framework, OOTB objects are referred to as system objects.
Understanding access to playbooks and scripts As playbooks and scripts are utilized across various platform interfaces, it is important to understand how access permissions are applied: * **Playbook Editor**: You can only open and modify the logic of playbooks or scripts where you are the **Owner** or have been granted **Editor** access. For all other shared playbooks, you have a read-only view. * **Task Library visibility**: The Task Library displays tasks that call playbooks or scripts you have access to. If you do not have at least **Viewer** access to a playbook or script, the tasks that reference them will not appear in your library. * **Access to sub-playbooks**: Sharing a parent playbook does not grant access to the sub-playbooks or scripts used within it. While the automation logic remains intact and will execute successfully regardless of a user's permissions, collaborators must be granted explicit access to the individual sub-playbooks or scripts to view or edit their underlying definitions. * **Detaching Marketplace content**: When a user detaches a system playbook or script, it becomes a custom object. The user become its **Owner**, and the object is **Restricted**. * **Selecting and running automations**: Across all the places in Cortex XDR where you can select a playbook or script, the list of available automations is filtered. You can only select playbooks or scripts to which you have the required per-object access.

Note

Any playbook can still be triggered and executed via the CLI, even if the user does not have explicit access to it, using the following methods:

* **Automation rules management**: All automation rules are visible to users with the appropriate role permissions. Yet, managing these rules (creating or editing them) is restricted: you can only select or configure a rule to use a playbook if you have at least **Viewer** access to that specific playbook. * **Export bundles (JSON/ZIP)**: To export a custom content bundle, the user role must have **Integrations** (under **Configurations** → **Data Collection**) set to **View**. Additionally, **Scripts** and **Playbooks** (under **Investigation & Response** → **Automations**) set to **Enabled**. A user can only export the playbooks and scripts to which they have access. * **Import bundles (JSON/ZIP)**: To import a bundle, the user role must have **Integrations** (under **Configurations** → **Data Collection**) set to **View/Edit**. Additionally, **Scripts** and **Playbooks** (under **Investigation & Response** → **Automations**) set to **Enabled** (with the **Edit Public** sub-permission selected for both). * **Importing new objects**: When a playbook or script is imported that does not already exist in the environment, the user performing the import is designated as the new **Owner**, and the playbook or script state defaults to **Restricted**. * **Importing existing objects**: If the playbook or script already exists in the environment, only content the user is authorized to access will be updated. The import preserves existing ownership. Only the playbooks and scripts the user has access to are imported. * **Credential dependencies in Automation**: The ability to execute a playbook or script is independent of the ability to access the secrets it uses. If a playbook or script relies on the user's context to fetch a credential, such as for authenticating against a third-party tool like Jira or Active Directory, the execution will fail if the user's role has the **Credentials** permission set to **None**. In this state, users are prohibited from passing secrets to scripts or external vaults.
Change owner of a playbook or script To ensure continuity when personnel changes occur, administrators can change the ownership of custom playbooks and scripts, or assign an **Owner** if the playbook or script doesn't have one. 1. Select **Investigation & Response** → **Automation** → **Playbooks** or **Investigation & Response** → **Automation** → **Scripts**. 2. Right-click the custom playbook or script in the table and select **Change owner**. 3. Select the new owner from the list of users, and click **Change**.
Automation execution and response The ability to view the execution of a playbook is independent to the access of playbooks and scripts being called during execution. All playbook tasks, including those of sub-playbooks and scripts to which the user does not have access, will be visible to the user in both the War Room and the Issue Work Plan.
How to configure access to playbooks and scripts **Task 1. Set role-level permissions** Role permissions define the functional capabilities for automations and determine what actions a user can take. 1. Select **Settings** → **Configurations** → **Access Management** → **Roles**. 2. Right-click the relevant user role, and select **Edit Role**. 3. Under **Components**, expand **Investigation & Response**, and under **Automations**, locate **Playbooks** or **Scripts**. 4. Configure the access state: * **Disabled**: Users cannot navigate to the **Playbooks** or **Scripts** pages. Playbooks or scripts cannot be shared with this role. * **Enabled**: Allows automations to be accessed and managed according to defined sub-permissions.

Note

Playbooks can only be Enabled when Scripts are Enabled first.

5. If **Enabled**, assign specific capabilities: * For playbooks: * **Create Playbooks**: Enables all methods for adding playbooks to Cortex XDR. This includes the **Build New Playbook** button, as well as the ability to **Duplicate** or **Detach** playbooks. The user who performs these actions is automatically designated as the **Owner**. * **Edit Public Playbooks**: Allows the user to modify custom playbooks set to **Public**, even if they are not the Owner. Additionally, this permission is required to **Detach** a system playbook and is necessary for users to set or to modify the settings, such as input and output parameters, for tasks that point to system playbooks. * For scripts: * **Create Scripts**: Enables all methods for adding scripts to Cortex XDR. This includes the **New Script** button, as well as the ability to **Duplicate** or **Detach** scripts. The user who performs these actions is automatically designated as the **Owner**. * **Edit Public Scripts**: Allows the user to modify custom scripts set to **Public**, even if they are not the Owner.

Note

6. Click **Save**. **Task 2. Manage sharing for a playbook or script** Once a custom playbook or script exists, the Owner (or an authorized Editor) defines its visibility. 1. Select **Investigation & Response** → **Automation** → **Playbooks** or **Investigation & Response** → **Automation** → **Scripts**. 2. Locate the custom playbook or script you want to share in the table. 3. Right-click the custom playbook or script and select the available access option. The menu option you see depends on your tenant-level settings: * **Share**: Use this if your admin enabled sharing. It allows you to grant access to specific users/groups and change the **General access** (**Public**/**Restricted**). * **Manage Access**: Use this if sharing is disabled. It is a restricted view that only allows you to toggle the **General access** between **Public** and **Restricted**. You cannot grant access to specific individuals. 4. (If sharing is enabled) Search for the **User**, **User Group**, or **API Key** and assign the access level: **Viewer** (read-only) or **Editor** (can modify and share). 5. Set the **General access** state: * **Restricted** (default): Private to the Owner and specifically invited principals. * **Public**: Visible to all users who have the **Playbooks** or **Scripts** component enabled in their role. 6. Click **Save**.
--- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-5.x/onboard-cortex-xdr/post-deployment-steps/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-playbooks-and-scripts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.