Manage access to playbooks and scripts - Learn more about managing access to playbooks and scripts in Cortex XSIAM. - Administrator Guide - Cortex XSIAM - Cortex

Manage access to playbooks and scripts - Learn more about managing access to playbooks and scripts in Cortex XSIAM. - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM 3.x Documentation

Product

Cortex XSIAM

Creation date

2025-07-15

Last date published

2026-06-11

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.
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.
- Automated execution (automation rules): Actions are performed by Cortex XSIAM; they are not restricted by the scope of the user who triggered the case, but remain governed by the defined scope of the involved integrations.
For more information on defining SBAC, see Manage user scope.

Automation objects in Cortex XSIAM 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 XSIAM, 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.

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 XSIAM 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:
- Invoking the playbook in the Automation Playground utilizing the ! command.
- Utilizing the setPlaybook command within the War Room by manually entering the exact playbook name as a string.
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.
Job scheduling: Currently, only Administrators can create and manage scheduled jobs. As Administrators have full access to all objects, they can schedule any playbook within the system.
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.

When utilizing remote repositories for content management, access to synchronization actions is governed by a combination of role-level capabilities and object-level visibility:

Note

For more information, see Push and pull content.

Push: Initiating a push synchronizes all custom content (user-defined playbooks and scripts) in the tenant to the remote repository, regardless of the object-level access permissions of the user who initiated the action.
Pull: When pulling content from a remote repository, Cortex XSIAM handles ownership differently depending on whether the content is new or already exists in the environment:
- Existing playbooks and scripts: If an object already exists in the target environment, the content is updated, but the current ownership and access configuration remain unchanged.
- New content owner: For playbooks and scripts that do not yet exist in the environment, the assignment of the Owner depends on the settings in the Remote Repository Settings.
  - Keep the original owner: Select this when the user managing access is the same in both tenants. This user is designated as the Owner in the production tenant. Recommended option when the same users exist in both the pushing tenant and the pulling one.
  - Owner is the user pulling content into the production tenant (default): Select this when users pulling content should also manage their access. The user who manually triggers the pull action is designated as the Owner.
  - Assign new content to this user: Select this when a specific user is responsible for managing access to new content. An administrator specifies a specific user as the Owner of all playbooks and scripts included in the pull.
Note
In a production (pull) tenant, be aware of the following:
- Users cannot be granted Editor permissions.
- Any existing Editor permissions (set before the tenant was configured for remote repository synchronization) are effectively treated as Viewer access.

Role permissions define the functional capabilities for automations and determine what actions a user can take.

Select Settings → Configurations → Access Management → Roles.
Right-click the relevant user role, and select Edit Role.
Under Components, expand Investigation & Response, and under Automations, locate Playbooks or Scripts.
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.
If Enabled, assign specific capabilities:
- For playbooks:
  - Create Playbooks: Enables all methods for adding playbooks to Cortex XSIAM. 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 XSIAM. 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
- To detach a playbook or script, a user must have both the Create and the Edit Public sub-permissions assigned to their role.
- Reattaching an existing automation to a Marketplace content pack can be performed by the playbook or script Owner or an Administrator.
Click Save.

Once a custom playbook or script exists, the Owner (or an authorized Editor) defines its visibility.

Select Investigation & Response → Automation → Playbooks or Investigation & Response → Automation → Scripts.
Locate the custom playbook or script you want to share in the table.
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.
(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).
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.
Click Save.