Manage access to playbooks and scripts

Manage access to Cortex Cloud playbooks and scripts using roles and permissions.

Review the following:

• Manage access to objects

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.

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

Automation objects

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

Remote Repositories (Push/Pull)

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

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