> 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-xsoar-8-on-prem/8.7/investigate-and-respond-to-threats/incidents-and-indicators-investigation/investigate-an-incident/limit-access-to-investigations-using-access-control.md).

# Limit access to investigations using access control

In any SOC team, there are various roles and responsibilities. For example, you may have specific teams to deal with threats, such as threat intelligence researchers, security analysts (Tier 1), senior analysts (Tier 2), SOC leads, SOC managers, and SIEM engineers. Administrators can exclude access to incident actions and investigations using role-based permissions. For example, you may want to limit the ability to change the incident status or manage the Work Plan. For more information, see [Role-based permissions](/cortex-xsoar-8-on-prem/8.7/configure-cortex-xsoar/users-and-roles-management/roles-management/role-based-permissions.md).

You can limit access to investigations by doing the following:

* Restrict an investigation
* Limit investigations according to specific user roles
* Give read-only access to certain user roles

<details>

<summary>Restrict an investigation</summary>

You can restrict an investigation to the incident owner and the team associated with the investigation.

Restrict the incident to only team members. For example, if an incident contains sensitive data, and you only want specific users to investigate the incident, you can mark the incident as restricted. Other users cannot view or access the incident. Team members are added automatically when you send them a notification in the CLI. You can remove the restricted investigation at any time.

{% hint style="info" %}

### Note

All team members have read and write permissions. If you add team members, but their roles have read-only permission, the user still has read and write permission and can access the investigation.
{% endhint %}

1. Go to the **Incidents** page and select the incident you want to restrict.
2. Select **Actions** → **Restrict incident**.

   To remove the restriction select **Actions** → **Permit incident**.

   Confirmation appears in the War Room.

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>If using the CLI, run the <code>/investigation_restrict id=``&#x3C;id number></code> or the <code>/investigation_permit id=``&#x3C;id number></code> command.</p></div>

</details>

<details>

<summary>Limit access to investigations according to specific roles</summary>

When you add a role to the incident, you restrict access to all roles other than those you have specifically added. For example, after an investigation is closed, add administrators or those with specialty roles, so only they can reopen or link incidents. The added roles have read and write permission, but all other roles do not have access (unless you have added them in the **XSOAR Read Only Roles** field).

{% hint style="info" %}

### Note

* If you add a role, but the incident has been restricted to team members, and the user is not a team member, the user cannot access the incident, regardless of the role. For example, if you restrict the incident to User A and User B team members who are Tier 1 analysts but then try to add Tier 2 analysts (none of whom are team members) to the list of roles, a Tier 2 analyst cannot access the incident.
* If no role is set for the incident, all users with read/write permissions for incidents can access and edit the incident. To access an incident, you must be assigned the same role that is assigned to the incident, even if you are the creator of the incident.
  {% endhint %}

1. On the **Incident** page, open the incident to restrict access.
2. Do one of the following:

   * If the **Roles** field is added to the incident layout, select the relevant role.
   * In the CLI, run `!setIncident roles =``<name of role>` to set the role.

     You can also run the `/incident_set command roles ``<name of role>`, which has the same effect.

   The War Room entry confirms that the role has been updated.

{% hint style="info" %}

### Note

When you create or edit an incident, you can select the required **Role**.

You can add this field to the incidents table on the **Incidents** page (you can't add roles in the table).
{% endhint %}

</details>

<details>

<summary>Give access to Read-only roles</summary>

You can add a Read-only role to the incident, which restricts access to the incident. When granting read-only access, the user can view the incident but not edit it. For example, when an incident is in triage (phase 1), you may want all Tier-2 analysts to have read-only access, so that Tier-1 can edit the incident. When the phase changes to phase 2, Tier-1 has read-only access.

Adding a team member overrides this restriction, so if you add User A (Tier 1) as a team member, even if you assign Tier-1 as a read-only role, the user still has read/write access. You need to remove the user as a Team Member.

{% hint style="info" %}

### Note

When an incident is restricted with a read-only role, existing team members automatically get read-only access. Their permissions are adjusted, allowing them to continue viewing the incident, though they will not have write permissions.
{% endhint %}

1. On the **Incident** page, open the incident to restrict access.
2. Do one of the following:

   * If the **XSOAR Read Only Roles** field is added to the incident layout, select the relevant role.
   * In the CLI, you run `!setIncident xsoarReadOnlyRoles=``<name of role>` to set the read-only role.

   The War Room entry confirms that the role has been updated.

{% hint style="info" %}

### Note

If added to the opening incident form, when editing or creating an incident, you can select the required **XSOAR Read Only Roles**.

You can add this field to the incidents table on the **Incidents** page (you can't add roles in the table).
{% endhint %}

</details>


---

# 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-xsoar-8-on-prem/8.7/investigate-and-respond-to-threats/incidents-and-indicators-investigation/investigate-an-incident/limit-access-to-investigations-using-access-control.md?ask=<question>&goal=<endgoal>
```

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