> 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-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects.md). # Manage access to objects Cortex XSIAM 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 XSIAM. 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 XSIAM, 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](#step-1-configure-tenant-level-access-settings).

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: * ![unshared-query-icon.png](/files/9PxebGZhhIBX5E0W53qX): A **Restricted** object you created that is not shared with anyone else. * ![query-created-by-me-shared-icon.png](/files/PRleNrzBY5qPgRAxcWNv): An object you created that is currently shared with other users, groups, or API keys. * ![query-created-by-someone-else-shared.png](/files/ZBMQH2O9k6ls1Xk1p6yH): An object created by another user that has been shared with you. * ![PANW\_Query.png](/files/oGslyMI95swQGxYzf2q0): 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](#step-1-configure-tenant-level-access-settings): Establish the "rules of engagement" for the entire instance. 2. [Role permissions](#step-2-set-role-permissions): Enable specific components and define additional capabilities for those roles. 3. [Per-object access](#step-3-configuring-per-object-access): Manage visibility and access levels for specific dashboards and queries and queries. 4. [Scope-Based Access Control (SBAC)](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope.md): 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. Configuring per-object access For more information on managing visibility and access levels for specific custom objects, see the following topics: * [Manage access to dashboards](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-custom-dashboards.md) * [Manage access to report templates](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-report-templates.md) * [Manage access to playbooks and scripts](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-playbooks-and-scripts.md) * [Manage access to saved queries](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects/manage-access-to-saved-queries.md) #### 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](/cortex-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-user-scope.md). --- # 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-xsiam/onboard-cortex-xsiam/post-deployment/manage-user-roles-and-access-management/manage-access-to-objects.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.