Manage access to objects

Learn more about managing access to objects in Cortex AgentiX.

Cortex AgentiX enforces least-privileged access by allowing you to manage access for individual instances of custom (user-defined) objects. Access management for these items is handled through a common experience for per-object access, which allows you to treat these tools as distinct objects with their own access settings.

What are Objects?

Objects are the tools used to visualize, analyze, and interact with information within Cortex AgentiX. By managing access at the object level, you can isolate sensitive information between teams (such as SOC vs. Internal Threat) or departments (such as CloudOps vs. SecOps).

In Cortex AgentiX, objects are functional components or configurations. There are two primary categories of objects:

Custom objects

User-defined objects created, imported, or duplicated by users. These are the primary focus of per-object access management.

Supported custom objects include:

• Dashboards and widgets
• Report Templates
• Playbooks and Scripts
• Saved Cortex Query Language (XQL) queries (located in the Query Library)

System objects

Out-of-the-box objects provided by Palo Alto Networks. These are Public by default and are read-only; they cannot be edited or deleted, and their ownership cannot be changed. Yet, they can often be duplicated to create a custom version. System objects are available to any user who has the corresponding component (such as Dashboards & Reports → Dashboards or Investigation & Response → Automations → Playbooks) enabled in their role.

Access examples

Granular per-object access supports various organizational security requirements:

1. Use only by SOC team: A "flat" structure where all analysts can see all objects. This is the default setting for the tenant. By default, newly created custom objects, such as a specific investigation dashboard or a complex XQL saved query, are Restricted and visible only to the creator; the owner can then make them Public to allow the entire team to view or edit them based on their role permissions.
2. Both SOC team and Internal threat: Specific objects, such as sensitive dashboards and saved queries, are created by a member of the Internal Threat team and made accessible only to the Internal Threat user group. Members of the Internal Threat team create these objects and share them only with their peers or their specific user group. Members of the SOC team do not have access to these objects, as they are not visible or accessible to any users who have not been explicitly granted access.
3. Both SOC team and Cloud team: Provides department isolation. Each team only accesses its own custom objects, such as playbooks and scripts; the SOC team cannot see Cloud team objects, and vice versa.

Key concepts

Before configuring access, it is important to understand the different states and roles that define an object's security access.

General access states

The General access setting determines the baseline visibility for an object:

• Restricted (default): To ensure least privileged access, all newly created custom objects are Restricted by default. The object is visible only to the Owner and those specifically shared with.
• Public: The object is visible to all users who have that component enabled in their role permissions. Users with the additional Edit Public [Object] role permissions can also modify these custom objects.

Per-object roles

• Owner: The person who created the object. Every object has an assigned Owner responsible for managing its lifecycle and access. Owners have full control, including the ability to edit content, delete the object, and, depending on tenant-level settings, share the object with other principals (users, user groups, or API keys) as an Editor or Viewer. For more information on tenant-level settings, see Step 1: Configure tenant-level access settings below.

  Note

  Only the Owner or an Administrator can delete a custom object.
• Editor: Can view and modify the object. They can also manage access for others if permitted by tenant settings.
• Viewer: Can see the definition of the object and its results, such as see the underlying logic of a script or view a dashboard, but cannot make any changes to the configuration or access settings.
• Administrative access: Account and Instance Administrators have inherent visibility into all objects (including Restricted ones) regardless of whether they have been explicitly shared with them. They can also Change Owner for any object.

  Important

  While Per-object access controls the visibility of the object (such as a dashboard or saved query), the underlying data remains governed by Scope-Based Access Control (SBAC). A user must have the appropriate SBAC permissions to view the data available through an object.

API enforcement

Public APIs for functional objects strictly enforce these object-level permissions. To interact with a Restricted object via the API (such as using GET, INSERT, or DELETE methods), the API Key must be explicitly added to that specific object’s access list with the required Viewer or Editor role.

Sharing icons

The following icons indicate the sharing status and origin of an object in management tables:

• : A Restricted object you created that is not shared with anyone else.
• : An object you created that is currently shared with other users, groups, or API keys.
• : An object created by another user that has been shared with you.
• : A Palo Alto Networks object provided out-of-the-box. These are Public, read-only, cannot be deleted, and ownership cannot be transferred.

How to change an object owner

To ensure continuity when personnel changes occur or to hand off management of an object, the ownership of an object can be changed.

• Administrative privilege: Only Account Admins and Instance Administrators can change the owner of an object. Other users who are Owners and Editors cannot perform this action.
• Change Owner: Using the Change Owner action in the management table of the specific object, administrators can select a new user to take over full control. Once changed, the new user assumes all Owner-level rights, including the ability to edit, delete, and share with other principals (users, user groups, and API keys).

How to configure access to objects

Configuring access follows a top-down workflow:

1

Tenant-level settings

Establish the "rules of engagement" for the entire instance.

2

Role permissions

Enable specific components and define additional capabilities for those roles.

3

Per-object access

Manage visibility and access levels for specific dashboards and queries and queries.

4

Scope-Based Access Control (SBAC)

Ensure the user has the required permissions to view the underlying data available through the object.

Step 1: Configure tenant-level access settings

Administrators first establish the "rules of engagement" for all objects. These settings are located under Settings → Configurations → Access Management → Objects:

• Owners can Share objects they created: Allows the creator (Owner) of an object to share it with users, user groups, or API keys. When enabled, the Share option is available in object menus. When disabled, this is replaced with the Manage Access option.

  • Editors can also Share objects with others: Allows users with Editor access to further share the object with additional principals (users, user groups, and API keys).
• Owners and editors can change the general access (default): Allows the object owner and any user with Editor access to modify the object's General access settings (Restricted or Public) using the drop-down menu in the object's sharing settings. When disabled, only an administrator can change this state.

Step 2: Set role permissions

Once tenant-level policies are established, configure individual roles to allow users to interact with specific components. Role permissions for objects have transitioned from the legacy "None/View/View-Edit" model to a granular "Disabled/Enabled" model. To configure these:

1. Select Settings → Configurations → Access Management → Roles.
2. Right-click the relevant user role, and select Edit Role.
3. Under Components, expand each list, set the applicable component (such as Dashboards & Reports → Dashboards) to one of the following:

   • Disabled: The component is hidden from the user's navigation menu. The user cannot access any objects associated with this component, even if they were previously shared with them.
   • Enabled: The component is visible in the user's navigation menu. The user can view Public objects and any Restricted objects shared with them.
4. Define additional capabilities.

   If enabled, refine capabilities using the following checkboxes:

   • Create [Object]: Allows the user to create new instances; the user is automatically designated as the Owner of the newly created object, which grants the inherent right to edit, delete, and manage sharing for that specific object.
   • Edit Public [Object]: Allows the user to modify custom objects that have been set to Public General access, even if they are not the owner.
5. Save the changes.

Once a component is enabled using role permissions, sharing is managed at the individual object level. Owners and authorized editors can share with other principals (users, user groups, or API keys) directly on the object.

Step 3. Configure per-object access

For more information on managing visibility and access levels for specific custom objects, see the following topics:

• Manage access to dashboards
• Manage access to report templates
• Manage access to playbooks and scripts
• Manage access to saved queries

Step 4. Configure SBAC permissions

For more information on managing user scope so users have the permissions necessary to view the data available through the object, see Manage user scope.