Documentation — August 25, 2026

187 files changed, 899 insertions, 5183 deletions — view the commit on the mirror.

The duplicate SaaS Security tree was deleted — 64 pages gone and its app connection links left broken

64 pages were deleted: the entire SaaS Security sub-book nested under Cloud AI Security, a duplicate of the surviving top-level tree. The Cortex XSIAM book drops from 2,283 to 2,219 pages.
Five SaaS Security index pages now point at broken-reference instead of the deleted copies — including the SaaS app connection table, where roughly forty per-app onboarding links are dead.
Cloud security gained an Attack Path (Legacy) rule type: the rule table entry and the page title were both relabelled.
The Cortex CLI docs were restructured: connect-cortex-cli dropped its inline install instructions for links to existing subpages, and new SCA runtime requirements (Node.js v22+ plus a per-ecosystem toolchain) were documented.
“Cortex Cloud AI Security” became “Cloud AI Security” throughout, and every AI Security licence hint was condensed to name the same three entitlements in one line.

Highlights

The SaaS Security sub-book under Cloud AI Security was deleted — 64 pages

Every page under cortex-cloud-ai-security/cortex-cloud-saas-security was removed, including all 38 per-app onboarding pages and the SaaS AI agent security section; the equivalent pages under cloud-security/cortex-cloud-saas-security survive.
The SaaS app connection table's per-app links are now broken-reference

Roughly forty rows that pointed at the deleted onboarding pages were rewritten to broken-reference, even though the surviving connect-a-saas-application subpages exist and were left in place.
Attack path rules were relabelled Attack Path (Legacy)

The cloud security rule type table and the page title both changed, and the navigation manifest carries the new title.
SCA scans now document a Node.js v22+ baseline and a per-ecosystem toolchain

A new module-specific requirements section states Node.js v22+ is enforced to boot the SCA engine, plus a table of native toolchains needed per project type — JDK with mvn or gradle, .NET SDK, Python with pip or pipenv, Ruby with bundler, and the Go toolchain.
The Code Security CLI authentication flag was corrected to --api-key-id

The documented third required flag changed from --auth-id / $CORTEX_AUTH_ID to --api-key-id / $CORTEX_API_KEY_ID, matching the common reference guide.
A new --ignore-existing-secrets flag was added to the AppSec CLI reference

In CI/CD scans it reports only newly introduced secrets, filtering findings whose fingerprints already exist in the Cortex Cloud backlog; three log and version flags also gained documented environment variables.

Changes

187 files listed, 15 written up and shaded below.

▸ ▾ Onboard Intercom modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-intercom

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect an Intercom instance to detect posture risks and compliance

Connect an Intercom instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard Intercom

# Onboard Intercom

For SaaS Security to detect posture risks in your Intercom instance, you must onboard your Intercom instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Intercom API by using an access token that you generate from the Intercom Developer Hub. After connecting to the Intercom API, SaaS Security scans your Intercom instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your Intercom instance, you must onboard your Intercom instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Intercom API by using an access token that you generate from the Intercom Developer Hub. After connecting to the Intercom API, SaaS Security scans your Intercom instance for misconfigured settings and account risks.

To access your Intercom instance, SaaS Security requires the following information, which you specify during the onboarding process.

To access your Intercom instance, SaaS Security requires the following information, which you specify during the onboarding process.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect an Intercom instance to detect posture risks and compliance
-  violations.
+  Connect an Intercom instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Intercom
 
 For SaaS Security to detect posture risks in your Intercom instance, you must onboard your Intercom instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Intercom API by using an access token that you generate from the Intercom Developer Hub. After connecting to the Intercom API, SaaS Security scans your Intercom instance for misconfigured settings and account risks.
 
 To access your Intercom instance, SaaS Security requires the following information, which you specify during the onboarding process.
 
```
▸ ▾ Onboard Jamf Pro modified +3 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-jamf-pro

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Jamf Pro instance to detect posture risks and compliance violations.

description: >-

Connect a Jamf Pro instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Jamf Pro

# Onboard Jamf Pro

For SaaS Security to detect posture risks in your Jamf Pro instance, you must onboard your Jamf Pro instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Jamf Pro API and, through the API, scans your Jamf Pro instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your Jamf Pro instance, you must onboard your Jamf Pro instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Jamf Pro API and, through the API, scans your Jamf Pro instance for misconfigured settings and account risks.

SaaS Security gets access to your Jamf Pro instance through an OAuth 2.0 client that you create. During onboarding, you supply SaaS Security with the application credentials (Client ID and Client Secret) for your OAuth 2.0 client. SaaS Security uses these credentials to access the Jamf Pro API through the OAuth 2.0 client.

SaaS Security gets access to your Jamf Pro instance through an OAuth 2.0 client that you create. During onboarding, you supply SaaS Security with the application credentials (Client ID and Client Secret) for your OAuth 2.0 client. SaaS Security uses these credentials to access the Jamf Pro API through the OAuth 2.0 client.

@@ -77,9 +79,8 @@ By adding a Jamf Pro app in Cortex, you enable SaaS Security to connect to your

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

3. Click the Jamf Pro tile.

3. Click the Jamf Pro tile.

4. Under Capabilities, enter a name for your application.

4. Under Capabilities, enter a name for your application.

5. Select Security Posture under Default Capabilities and click Next.

5. Select Security Posture under Default Capabilities and click Next.

6. Under Connections, enter your instance URL and the application credentials (Client ID and Client Secret).

6. Under Connections, enter your instance URL and the application credentials (Client ID and Client Secret).

7. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

7. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

8. Click Next to complete the onboarding validation process.

8. Click Next to complete the onboarding validation process.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Jamf Pro instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Jamf Pro instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Jamf Pro
 
 For SaaS Security to detect posture risks in your Jamf Pro instance, you must onboard your Jamf Pro instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Jamf Pro API and, through the API, scans your Jamf Pro instance for misconfigured settings and account risks.
 
 SaaS Security gets access to your Jamf Pro instance through an OAuth 2.0 client that you create. During onboarding, you supply SaaS Security with the application credentials (Client ID and Client Secret) for your OAuth 2.0 client. SaaS Security uses these credentials to access the Jamf Pro API through the OAuth 2.0 client.
 
@@ -77,9 +79,8 @@ By adding a Jamf Pro app in Cortex, you enable SaaS Security to connect to your
 1. Log in to Cortex.
 2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the app you want to connect to.
 3. Click the Jamf Pro tile.
 4. Under **Capabilities**, enter a name for your application.
 5. Select Security Posture under Default Capabilities and click Next.
 6. Under **Connections**, enter your instance URL and the application credentials (Client ID and Client Secret).
 7. Under **Configurations**, select a **Sync Interval**. Choose a meaningful **Tag** to distinguish between various applications in different environments.
 8. Click **Next** to complete the onboarding validation process.
-
```
▸ ▾ Onboard JumpCloud modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-jumpcloud

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a JumpCloud instance to detect posture risks and compliance

Connect a JumpCloud instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard JumpCloud

# Onboard JumpCloud

For SaaS Security to detect posture risks in your JumpCloud instance, you must onboard your JumpCloud instance to SaaS Security. Through the onboarding process, SaaS Security connects to a JumpCloud API by using an API key that you generate from the JumpCloud Admin Portal. After connecting to the JumpCloud API, SaaS Security scans your JumpCloud instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your JumpCloud instance, you must onboard your JumpCloud instance to SaaS Security. Through the onboarding process, SaaS Security connects to a JumpCloud API by using an API key that you generate from the JumpCloud Admin Portal. After connecting to the JumpCloud API, SaaS Security scans your JumpCloud instance for misconfigured settings and account risks.

To access your JumpCloud instance, SaaS Security requires the following information, which you specify during the onboarding process.

To access your JumpCloud instance, SaaS Security requires the following information, which you specify during the onboarding process.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a JumpCloud instance to detect posture risks and compliance
-  violations.
+  Connect a JumpCloud instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard JumpCloud
 
 For SaaS Security to detect posture risks in your JumpCloud instance, you must onboard your JumpCloud instance to SaaS Security. Through the onboarding process, SaaS Security connects to a JumpCloud API by using an API key that you generate from the JumpCloud Admin Portal. After connecting to the JumpCloud API, SaaS Security scans your JumpCloud instance for misconfigured settings and account risks.
 
 To access your JumpCloud instance, SaaS Security requires the following information, which you specify during the onboarding process.
 
```
▸ ▾ Onboard Kustomer modified +4 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-kustomer

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Kustomer instance to detect posture risks and compliance violations.

description: >-

Connect a Kustomer instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Kustomer

# Onboard Kustomer

For SaaS Security to detect posture risks in your Kustomer instance, you must onboard your Kustomer instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Kustomer API and, through the API, scans your Kustomer instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

For SaaS Security to detect posture risks in your Kustomer instance, you must onboard your Kustomer instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Kustomer API and, through the API, scans your Kustomer instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

SaaS Security gets access to your Kustomer instance through an API access key. During the onboarding process, SaaS Security prompts you for the API access key and related information for your Kustomer instance.

SaaS Security gets access to your Kustomer instance through an API access key. During the onboarding process, SaaS Security prompts you for the API access key and related information for your Kustomer instance.

@@ -33,17 +35,17 @@ As you complete the following steps, make note of the values of the items descri

1. Click the settings icon (gear icon) in the lower-left corner of the window and select SECURITY > API Keys.

1. Click the settings icon (gear icon) in the lower-left corner of the window and select SECURITY > API Keys.

2. Click + Add API Key.

2. Click + Add API Key.

3. Fill in the fields of the ADD API KEY dialog:

3. Fill in the fields of the ADD API KEY dialog:

1. Enter a name for the new API key.

1. Enter a name for the new API key.

2. In the Roles field, specify org.permission. Required permissions: The key must be configured with the org.permission role.

2. In the Roles field, specify org.permission. Required permissions: The key must be configured with the org.permission role.

3. Specify an expiration date for the key.

3. Specify an expiration date for the key.

4. Click Create. Kustomer generates and displays your new key.

4. Click Create. Kustomer generates and displays your new key.

5. Copy the API key and paste it into a text file.

5. Copy the API key and paste it into a text file.

**Note**: Do not continue to the next step unless you have copied the API key. You must provide this key to SaaS Security during the onboarding process.

**Note**: Do not continue to the next step unless you have copied the API key. You must provide this key to SaaS Security during the onboarding process.

4. Identify the region (United States or European Union) where your organization instance was deployed. Because API calls are region-specific, you must provide this information to SaaS Security during the onboarding process.

4. Identify the region (United States or European Union) where your organization instance was deployed. Because API calls are region-specific, you must provide this information to SaaS Security during the onboarding process.

### Step 2: Connect SaaS Security to Your Kustomer Instance

### Step 2: Connect SaaS Security to Your Kustomer Instance
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Kustomer instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Kustomer instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Kustomer
 
 For SaaS Security to detect posture risks in your Kustomer instance, you must onboard your Kustomer instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Kustomer API and, through the API, scans your Kustomer instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.
 
 SaaS Security gets access to your Kustomer instance through an API access key. During the onboarding process, SaaS Security prompts you for the API access key and related information for your Kustomer instance.
 
@@ -33,17 +35,17 @@ As you complete the following steps, make note of the values of the items descri
 
     1. Click the settings icon (gear icon) in the lower-left corner of the window and select SECURITY > API Keys.
     2. Click + Add API Key.
     3. Fill in the fields of the ADD API KEY dialog:
        1. Enter a name for the new API key.
        2. In the Roles field, specify org.permission. Required permissions: The key must be configured with the org.permission role.
        3. Specify an expiration date for the key.
     4. Click Create. Kustomer generates and displays your new key.
-    5. Copy the API key and paste it into a text file.&#x20;
+    5. Copy the API key and paste it into a text file.
 
     **Note**: Do not continue to the next step unless you have copied the API key. You must provide this key to SaaS Security during the onboarding process.
 4. Identify the region (United States or European Union) where your organization instance was deployed. Because API calls are region-specific, you must provide this information to SaaS Security during the onboarding process.
 
 ***
 
 ### Step 2: Connect SaaS Security to Your Kustomer Instance
 
```
▸ ▾ Onboard Microsoft Entra ID modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-microsoft-entra-id

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a Microsoft Entra ID instance to detect posture risks and compliance

Connect a Microsoft Entra ID instance in Cortex XSIAM to detect posture risks

violations.

and compliance violations.

---

---

# Onboard Microsoft Entra ID

# Onboard Microsoft Entra ID

For SaaS Security to detect posture risks in your Microsoft Entra ID instance, you must onboard your Microsoft Entra ID instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Microsoft Graph API and, through the API, scans your Microsoft Entra ID instance at regular intervals.

For SaaS Security to detect posture risks in your Microsoft Entra ID instance, you must onboard your Microsoft Entra ID instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Microsoft Graph API and, through the API, scans your Microsoft Entra ID instance at regular intervals.

SaaS Security gets access to your Microsoft Entra ID instance through a service principal, which represents a Microsoft Entra application that you create. You configure this application's permissions to enable SaaS Security to access only the API scopes it requires to complete its scans. When you register this application, Microsoft Entra creates the associated service principal that SaaS Security uses to connect to the API.

SaaS Security gets access to your Microsoft Entra ID instance through a service principal, which represents a Microsoft Entra application that you create. You configure this application's permissions to enable SaaS Security to access only the API scopes it requires to complete its scans. When you register this application, Microsoft Entra creates the associated service principal that SaaS Security uses to connect to the API.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a Microsoft Entra ID instance to detect posture risks and compliance
-  violations.
+  Connect a Microsoft Entra ID instance in Cortex XSIAM to detect posture risks
+  and compliance violations.
 ---
 
 # Onboard Microsoft Entra ID
 
 For SaaS Security to detect posture risks in your Microsoft Entra ID instance, you must onboard your Microsoft Entra ID instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Microsoft Graph API and, through the API, scans your Microsoft Entra ID instance at regular intervals.
 
 SaaS Security gets access to your Microsoft Entra ID instance through a service principal, which represents a Microsoft Entra application that you create. You configure this application's permissions to enable SaaS Security to access only the API scopes it requires to complete its scans. When you register this application, Microsoft Entra creates the associated service principal that SaaS Security uses to connect to the API.
 
```
▸ ▾ Onboard Monday.com modified +2 −3 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-monday.com

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a Monday.com instance to detect posture risks and compliance

Connect a Monday.com instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard Monday.com

# Onboard Monday.com

For SaaS Security to detect posture risks in your monday.com instance, you must onboard your monday.com instance to SaaS Security. Through the onboarding process, SaaS Security logs in to monday.com using administrator account credentials. SaaS Security uses this account to scan your monday.com instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

For SaaS Security to detect posture risks in your monday.com instance, you must onboard your monday.com instance to SaaS Security. Through the onboarding process, SaaS Security logs in to monday.com using administrator account credentials. SaaS Security uses this account to scan your monday.com instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

To onboard your monday.com instance, complete the following actions:

To onboard your monday.com instance, complete the following actions:

@@ -66,9 +66,8 @@ By adding a monday.com app in Cortex, you enable SaaS Security to connect to you

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

3. Click the monday.com tile.

3. Click the monday.com tile.

4. Under Capabilities, enter a name for your application.

4. Under Capabilities, enter a name for your application.

5. Select Security Posture under Default Capabilities and click Next.

5. Select Security Posture under Default Capabilities and click Next.

6. Under Connections, enter the administrator login credentials, your account domain, and, optionally, the MFA secret key.

6. Under Connections, enter the administrator login credentials, your account domain, and, optionally, the MFA secret key.

7. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

7. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

8. Click Next to complete the onboarding validation process.

8. Click Next to complete the onboarding validation process.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a Monday.com instance to detect posture risks and compliance
-  violations.
+  Connect a Monday.com instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Monday.com
 
 For SaaS Security to detect posture risks in your monday.com instance, you must onboard your monday.com instance to SaaS Security. Through the onboarding process, SaaS Security logs in to monday.com using administrator account credentials. SaaS Security uses this account to scan your monday.com instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.
 
 To onboard your monday.com instance, complete the following actions:
 
@@ -66,9 +66,8 @@ By adding a monday.com app in Cortex, you enable SaaS Security to connect to you
 1. Log in to Cortex.
 2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the app you want to connect to.
 3. Click the monday.com tile.
 4. Under **Capabilities**, enter a name for your application.
 5. Select Security Posture under Default Capabilities and click Next.
 6. Under **Connections**, enter the administrator login credentials, your account domain, and, optionally, the MFA secret key.
 7. Under **Configurations**, select a **Sync Interval**. Choose a meaningful **Tag** to distinguish between various applications in different environments.
 8. Click **Next** to complete the onboarding validation process.
-
```
▸ ▾ Onboard MongoDB Atlas modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-mongodb-atlas

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a MongoDB Atlas instance to detect posture risks and compliance

Connect a MongoDB Atlas instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard MongoDB Atlas

# Onboard MongoDB Atlas

For SaaS Security to detect posture risks in your MongoDB Atlas instance, you must onboard your MongoDB Atlas instance to SaaS Security. Through the onboarding process, SaaS Security connects to the MongoDB Atlas Administration API by using programmatic credentials (Client ID and Client Secret) that you provide. After connecting to the MongoDB Atlas Administration API, SaaS Security scans your MongoDB Atlas organization for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your MongoDB Atlas instance, you must onboard your MongoDB Atlas instance to SaaS Security. Through the onboarding process, SaaS Security connects to the MongoDB Atlas Administration API by using programmatic credentials (Client ID and Client Secret) that you provide. After connecting to the MongoDB Atlas Administration API, SaaS Security scans your MongoDB Atlas organization for misconfigured settings and account risks.

To access your MongoDB Atlas instance, SaaS Security requires the following information, which you specify during the onboarding process.

To access your MongoDB Atlas instance, SaaS Security requires the following information, which you specify during the onboarding process.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a MongoDB Atlas instance to detect posture risks and compliance
-  violations.
+  Connect a MongoDB Atlas instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard MongoDB Atlas
 
 For SaaS Security to detect posture risks in your MongoDB Atlas instance, you must onboard your MongoDB Atlas instance to SaaS Security. Through the onboarding process, SaaS Security connects to the MongoDB Atlas Administration API by using programmatic credentials (Client ID and Client Secret) that you provide. After connecting to the MongoDB Atlas Administration API, SaaS Security scans your MongoDB Atlas organization for misconfigured settings and account risks.
 
 To access your MongoDB Atlas instance, SaaS Security requires the following information, which you specify during the onboarding process.
 
```
▸ ▾ Onboard MuleSoft modified +3 −3 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-mulesoft

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a MuleSoft instance to detect posture risks and compliance violations.

description: >-

Connect a MuleSoft instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard MuleSoft

# Onboard MuleSoft

For SaaS Security to detect posture risks in your MuleSoft instance, you must onboard your MuleSoft instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Anypoint Platform API and, through the API, scans your MuleSoft instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your MuleSoft instance, you must onboard your MuleSoft instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Anypoint Platform API and, through the API, scans your MuleSoft instance for misconfigured settings and account risks.

SaaS Security gets access to your MuleSoft instance through an OAuth 2.0 application that you create. In the Anypoint Platform, an OAuth 2.0 application is called a Connected App. During onboarding, you supply SaaS Security with the application credentials (Client ID and Client Secret) for your Connected App. SaaS Security uses these credentials to access the Anypoint Platform API.

SaaS Security gets access to your MuleSoft instance through an OAuth 2.0 application that you create. In the Anypoint Platform, an OAuth 2.0 application is called a Connected App. During onboarding, you supply SaaS Security with the application credentials (Client ID and Client Secret) for your Connected App. SaaS Security uses these credentials to access the Anypoint Platform API.

@@ -29,18 +31,16 @@ Identify the Anypoint Platform account that you will use to create your Connecte

Required Permissions: To create the Connected App, you must use an Anypoint Platform account assigned to the Organization Administrator role.

Required Permissions: To create the Connected App, you must use an Anypoint Platform account assigned to the Organization Administrator role.

### Step 2: Log In to the Anypoint Platform

### Step 2: Log In to the Anypoint Platform

Open a web browser to the MuleSoft Anypoint Platform login page and log in to the Organization Administrator account you identified.

Open a web browser to the MuleSoft Anypoint Platform login page and log in to the Organization Administrator account you identified.

### Step 3: Identify Your Hosted Region

### Step 3: Identify Your Hosted Region

Use the following table to determine your region based on the MuleSoft URL displayed in your browser's address bar. You will provide this region information to SaaS Security during onboarding.

Use the following table to determine your region based on the MuleSoft URL displayed in your browser's address bar. You will provide this region information to SaaS Security during onboarding.

URL│Region

URL│Region

| ------------------------- | ------------------------------- |

| ------------------------- | ------------------------------- |
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a MuleSoft instance to detect posture risks and compliance violations.
+description: >-
+  Connect a MuleSoft instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard MuleSoft
 
 For SaaS Security to detect posture risks in your MuleSoft instance, you must onboard your MuleSoft instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Anypoint Platform API and, through the API, scans your MuleSoft instance for misconfigured settings and account risks.
 
 SaaS Security gets access to your MuleSoft instance through an OAuth 2.0 application that you create. In the Anypoint Platform, an OAuth 2.0 application is called a Connected App. During onboarding, you supply SaaS Security with the application credentials (Client ID and Client Secret) for your Connected App. SaaS Security uses these credentials to access the Anypoint Platform API.
 
@@ -29,18 +31,16 @@ Identify the Anypoint Platform account that you will use to create your Connecte
 Required Permissions: To create the Connected App, you must use an Anypoint Platform account assigned to the Organization Administrator role.
 
 ***
 
 ### Step 2: Log In to the Anypoint Platform
 
 Open a web browser to the [MuleSoft Anypoint Platform login page](https://anypoint.mulesoft.com/login/) and log in to the Organization Administrator account you identified.
 
-
-
 ***
 
 ### Step 3: Identify Your Hosted Region
 
 Use the following table to determine your region based on the MuleSoft URL displayed in your browser's address bar. You will provide this region information to SaaS Security during onboarding.
 
 | URL                       | Region                          |
 | ------------------------- | ------------------------------- |
```
▸ ▾ Onboard Mural modified +3 −1 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-mural

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Mural instance to detect posture risks and compliance violations.

description: >-

Connect a Mural instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Mural

# Onboard Mural

For SaaS Security to detect posture risks in your Mural instance, you must onboard your Mural instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Mural API by using an Enterprise API key. You generate this key from the Company Dashboard in Mural. After connecting to the Mural API, SaaS Security scans your Mural instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your Mural instance, you must onboard your Mural instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Mural API by using an Enterprise API key. You generate this key from the Company Dashboard in Mural. After connecting to the Mural API, SaaS Security scans your Mural instance for misconfigured settings and account risks.

The supported Mural account plan for SaaS Security scans is the Enterprise plan. This plan is required for you to create an Enterprise API key.

The supported Mural account plan for SaaS Security scans is the Enterprise plan. This plan is required for you to create an Enterprise API key.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Mural instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Mural instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Mural
 
 For SaaS Security to detect posture risks in your Mural instance, you must onboard your Mural instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Mural API by using an Enterprise API key. You generate this key from the Company Dashboard in Mural. After connecting to the Mural API, SaaS Security scans your Mural instance for misconfigured settings and account risks.
 
 The supported Mural account plan for SaaS Security scans is the Enterprise plan. This plan is required for you to create an Enterprise API key.
 
```
▸ ▾ Onboard Office 365 modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-office-365

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect an Office 365 instance to detect posture risks and compliance

Connect an Office 365 instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard Office 365

# Onboard Office 365

For SaaS Security to detect posture risks in your Office 365 instance, you must onboard your Office 365 instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Microsoft API and, through the API, scans your Office 365 instance at regular intervals. You can onboard an Office 365 app by using OAuth 2.0 authorization or by using a Microsoft Entra (formerly Azure) service principal.

For SaaS Security to detect posture risks in your Office 365 instance, you must onboard your Office 365 instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Microsoft API and, through the API, scans your Office 365 instance at regular intervals. You can onboard an Office 365 app by using OAuth 2.0 authorization or by using a Microsoft Entra (formerly Azure) service principal.

Note: Connecting to Office 365 enables SaaS Security to scan settings at a high level based on Microsoft's Secure Score. For greater visibility into a particular application in the Office 365 product family, onboard the individual product app. To scan more settings for Microsoft Word, Microsoft PowerPoint, and Microsoft Excel, onboard Office 365 - Productivity Apps. Other products in the Office 365 product family have their own tiles on the Applications page and can be onboarded separately.

Note: Connecting to Office 365 enables SaaS Security to scan settings at a high level based on Microsoft's Secure Score. For greater visibility into a particular application in the Office 365 product family, onboard the individual product app. To scan more settings for Microsoft Word, Microsoft PowerPoint, and Microsoft Excel, onboard Office 365 - Productivity Apps. Other products in the Office 365 product family have their own tiles on the Applications page and can be onboarded separately.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect an Office 365 instance to detect posture risks and compliance
-  violations.
+  Connect an Office 365 instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Office 365
 
 For SaaS Security to detect posture risks in your Office 365 instance, you must onboard your Office 365 instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Microsoft API and, through the API, scans your Office 365 instance at regular intervals. You can onboard an Office 365 app by using OAuth 2.0 authorization or by using a Microsoft Entra (formerly Azure) service principal.
 
 **Note**: Connecting to Office 365 enables SaaS Security to scan settings at a high level based on Microsoft's Secure Score. For greater visibility into a particular application in the Office 365 product family, onboard the individual product app. To scan more settings for Microsoft Word, Microsoft PowerPoint, and Microsoft Excel, onboard Office 365 - Productivity Apps. Other products in the Office 365 product family have their own tiles on the Applications page and can be onboarded separately.
 
```
▸ ▾ Onboard Okta modified +3 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-okta

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect an Okta instance to detect posture risks and compliance violations.

description: >-

Connect an Okta instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Okta

# Onboard Okta

For SaaS Security to detect posture risks in your Okta instance, you must onboard your Okta instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Okta API by using an API token that you generate from Okta's administrator console. After connecting to the Okta API, SaaS Security scans your Okta instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

For SaaS Security to detect posture risks in your Okta instance, you must onboard your Okta instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Okta API by using an API token that you generate from Okta's administrator console. After connecting to the Okta API, SaaS Security scans your Okta instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

During onboarding, SaaS Security gives you an option to connect with read-only permissions or with read and write permissions:

During onboarding, SaaS Security gives you an option to connect with read-only permissions or with read and write permissions:

@@ -55,9 +57,8 @@ By adding an Okta app in Cortex, you enable SaaS Security to connect to your Okt

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

3. Click the Okta tile.

3. Click the Okta tile.

4. Under Capabilities, enter a name for your application.

4. Under Capabilities, enter a name for your application.

5. Select Security Posture under Default Capabilities and click Next.

5. Select Security Posture under Default Capabilities and click Next.

6. Under Connections, enter your API token and your administrator instance URL.

6. Under Connections, enter your API token and your administrator instance URL.

7. Specify whether you want SaaS Security to connect with Read Permissions only or with Read and Write permissions. The onboarding page lists the API scopes that SaaS Security will access to complete its various scans and to perform remediation.

7. Specify whether you want SaaS Security to connect with Read Permissions only or with Read and Write permissions. The onboarding page lists the API scopes that SaaS Security will access to complete its various scans and to perform remediation.

8. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

8. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

9. Click Next to complete the onboarding validation process.

9. Click Next to complete the onboarding validation process.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect an Okta instance to detect posture risks and compliance violations.
+description: >-
+  Connect an Okta instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Okta
 
 For SaaS Security to detect posture risks in your Okta instance, you must onboard your Okta instance to SaaS Security. Through the onboarding process, SaaS Security connects to an Okta API by using an API token that you generate from Okta's administrator console. After connecting to the Okta API, SaaS Security scans your Okta instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.
 
 During onboarding, SaaS Security gives you an option to connect with read-only permissions or with read and write permissions:
 
@@ -55,9 +57,8 @@ By adding an Okta app in Cortex, you enable SaaS Security to connect to your Okt
 2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the app you want to connect to.
 3. Click the Okta tile.
 4. Under **Capabilities**, enter a name for your application.
 5. Select Security Posture under Default Capabilities and click Next.
 6. Under **Connections**, enter your API token and your administrator instance URL.
 7. Specify whether you want SaaS Security to connect with Read Permissions only or with Read and Write permissions. The onboarding page lists the API scopes that SaaS Security will access to complete its various scans and to perform remediation.
 8. Under **Configurations**, select a **Sync Interval**. Choose a meaningful **Tag** to distinguish between various applications in different environments.
 9. Click **Next** to complete the onboarding validation process.
-
```
▸ ▾ Onboard PagerDuty modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-pagerduty

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a PagerDuty instance to detect posture risks and compliance

Connect a PagerDuty instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard PagerDuty

# Onboard PagerDuty

For SaaS Security to detect posture risks in your PagerDuty instance, you must onboard your PagerDuty instance to SaaS Security. Through the onboarding process, SaaS Security logs in to PagerDuty using administrator account credentials. SaaS Security uses this account to scan your PagerDuty instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

For SaaS Security to detect posture risks in your PagerDuty instance, you must onboard your PagerDuty instance to SaaS Security. Through the onboarding process, SaaS Security logs in to PagerDuty using administrator account credentials. SaaS Security uses this account to scan your PagerDuty instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.

To onboard your PagerDuty instance, complete the following actions:

To onboard your PagerDuty instance, complete the following actions:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a PagerDuty instance to detect posture risks and compliance
-  violations.
+  Connect a PagerDuty instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard PagerDuty
 
 For SaaS Security to detect posture risks in your PagerDuty instance, you must onboard your PagerDuty instance to SaaS Security. Through the onboarding process, SaaS Security logs in to PagerDuty using administrator account credentials. SaaS Security uses this account to scan your PagerDuty instance for misconfigured settings. If there are misconfigured settings, SaaS Security suggests a remediation action based on best practices.
 
 To onboard your PagerDuty instance, complete the following actions:
 
```
▸ ▾ Onboard Redis Labs modified +3 −3 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-redis-labs

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a Redis Labs instance to detect posture risks and compliance

Connect a Redis Labs instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard Redis Labs

# Onboard Redis Labs

For SaaS Security to detect posture risks in your Redis Labs instance, you must onboard your Redis Labs instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Redis Cloud REST API by using a pair of API keys that you generate within Redis Labs. After connecting to the Redis Cloud REST API, SaaS Security scans your Redis Labs instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your Redis Labs instance, you must onboard your Redis Labs instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Redis Cloud REST API by using a pair of API keys that you generate within Redis Labs. After connecting to the Redis Cloud REST API, SaaS Security scans your Redis Labs instance for misconfigured settings and account risks.

To onboard your Redis Labs instance, SaaS Security requires the following information, which you specify during the onboarding process.

To onboard your Redis Labs instance, SaaS Security requires the following information, which you specify during the onboarding process.

@@ -70,17 +70,17 @@ By adding a Redis Labs app in Cortex, you enable SaaS Security to connect to you

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the app you want to connect to.

3. Click the Redis Labs tile.

3. Click the Redis Labs tile.

4. Under Capabilities, enter a name for your application.

4. Under Capabilities, enter a name for your application.

5. Select Security Posture under Default Capabilities and click Next.

5. Select Security Posture under Default Capabilities and click Next.

6. Under Connections, enter your API account key and API user key.

6. Under Connections, enter your API account key and API user key.

7. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

7. Under Configurations, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.

8. Click Next to complete the onboarding validation process.

8. Click Next to complete the onboarding validation process.

#### Onboard a Redis Labs App to SaaS Security

#### Onboard a Redis Labs App to SaaS Security

Connect a Redis Labs instance to SaaS Security to detect posture risks.

Connect a Redis Labs instance to SaaS Security to detect posture risks.

SaaS Security connects to the Redis Cloud REST API using a pair of API keys that you generate in Redis Labs. After connecting, SaaS Security scans your Redis Labs instance for misconfigured settings and account risks.

SaaS Security connects to the Redis Cloud REST API using a pair of API keys that you generate in Redis Labs. After connecting, SaaS Security scans your Redis Labs instance for misconfigured settings and account risks.

The onboarding process requires the following credentials:

The onboarding process requires the following credentials:

Item│Description

Item│Description
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a Redis Labs instance to detect posture risks and compliance
-  violations.
+  Connect a Redis Labs instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Redis Labs
 
 For SaaS Security to detect posture risks in your Redis Labs instance, you must onboard your Redis Labs instance to SaaS Security. Through the onboarding process, SaaS Security connects to the Redis Cloud REST API by using a pair of API keys that you generate within Redis Labs. After connecting to the Redis Cloud REST API, SaaS Security scans your Redis Labs instance for misconfigured settings and account risks.
 
 To onboard your Redis Labs instance, SaaS Security requires the following information, which you specify during the onboarding process.
 
@@ -70,17 +70,17 @@ By adding a Redis Labs app in Cortex, you enable SaaS Security to connect to you
 2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the app you want to connect to.
 3. Click the Redis Labs tile.
 4. Under **Capabilities**, enter a name for your application.
 5. Select Security Posture under Default Capabilities and click Next.
 6. Under **Connections**, enter your API account key and API user key.
 7. Under **Configurations**, select a Sync Interval. Choose a meaningful Tag to distinguish between various applications in different environments.
 8. Click **Next** to complete the onboarding validation process.
 
-#### &#x20;Onboard a Redis Labs App to SaaS Security
+#### Onboard a Redis Labs App to SaaS Security
 
 Connect a Redis Labs instance to SaaS Security to detect posture risks.
 
 SaaS Security connects to the Redis Cloud REST API using a pair of API keys that you generate in Redis Labs. After connecting, SaaS Security scans your Redis Labs instance for misconfigured settings and account risks.
 
 The onboarding process requires the following credentials:
 
 | Item        | Description                                                                                                                                                                           |
```
▸ ▾ Onboard Salesforce modified +2 −6 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-salesforce

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a Salesforce instance to detect posture risks and compliance

Connect a Salesforce instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard Salesforce

# Onboard Salesforce

For SaaS Security to detect posture risks in your Salesforce instance, you must onboard your Salesforce instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Salesforce API and, through the API, scans your Salesforce instance for misconfigured settings and account risks.

For SaaS Security to detect posture risks in your Salesforce instance, you must onboard your Salesforce instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Salesforce API and, through the API, scans your Salesforce instance for misconfigured settings and account risks.

You can onboard your Salesforce instance through an interactive OAuth 2.0 Authorization flow or through a Salesforce External Client App.

You can onboard your Salesforce instance through an interactive OAuth 2.0 Authorization flow or through a Salesforce External Client App.

@@ -56,18 +56,16 @@ Permissions for Read Access (configuration scans, identity scans, risky account

Additional Permissions for Write Access (third-party plugin scans and automated remediation):

Additional Permissions for Write Access (third-party plugin scans and automated remediation):

Scan Type / Remediation│Required Permission

Scan Type / Remediation│Required Permission

| ------------------------- | ------------------------------------------------------------- |

| ------------------------- | ------------------------------------------------------------- |

Configuration Remediation│API Enabled, View Health Check, Download AppExchange Packages

Configuration Remediation│API Enabled, View Health Check, Download AppExchange Packages

Third-Party Plugins│API Enabled, Download AppExchange Packages

Third-Party Plugins│API Enabled, Download AppExchange Packages

To grant permissions to the user account, add the permissions to a permission set and assign the permission set to the Salesforce user account:

To grant permissions to the user account, add the permissions to a permission set and assign the permission set to the Salesforce user account:

1. From the setup home page, select Users > Permission Sets.

1. From the setup home page, select Users > Permission Sets.

2. Create a new permission set or edit an existing one.

2. Create a new permission set or edit an existing one.

3. On the setup page for the permission set, locate the System area and navigate to System Permissions.

3. On the setup page for the permission set, locate the System area and navigate to System Permissions.

4. Enable the required permissions and save.

4. Enable the required permissions and save.

5. Assign the permission set to the Salesforce user account.

5. Assign the permission set to the Salesforce user account.

@@ -90,18 +88,16 @@ By adding a Salesforce app in Cortex, you enable SaaS Security to connect to you

5. Select Security Posture under Default Capabilities and click Next.

5. Select Security Posture under Default Capabilities and click Next.

6. Select the option for OAuth 2.0.

6. Select the option for OAuth 2.0.

7. Enter your Instance URL.

7. Enter your Instance URL.

8. Specify whether you want SaaS Security to connect with Read Permissions only or with Read and Write Permissions. The onboarding page lists the API scopes that SaaS Security will access.

8. Specify whether you want SaaS Security to connect with Read Permissions only or with Read and Write Permissions. The onboarding page lists the API scopes that SaaS Security will access.

9. Click Connect with Salesforce. SaaS Security redirects you to the Salesforce login page.

9. Click Connect with Salesforce. SaaS Security redirects you to the Salesforce login page.

10. Log in to the Salesforce account. Salesforce displays a consent form that details the access permissions that SaaS Security requires.

10. Log in to the Salesforce account. Salesforce displays a consent form that details the access permissions that SaaS Security requires.

11. Review the consent form and allow the requested permissions. SaaS Security connects to your Salesforce instance and displays whether it was able to access the required API scopes.

11. Review the consent form and allow the requested permissions. SaaS Security connects to your Salesforce instance and displays whether it was able to access the required API scopes.

### Method 2: External Client App

### Method 2: External Client App

The External Client App approach authenticates using application credentials (Client ID and Client Secret). This method offers long-term stability by creating a persistent, system-to-system link that does not rely on OAuth refresh tokens.

The External Client App approach authenticates using application credentials (Client ID and Client Secret). This method offers long-term stability by creating a persistent, system-to-system link that does not rely on OAuth refresh tokens.

Required information:

Required information:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a Salesforce instance to detect posture risks and compliance
-  violations.
+  Connect a Salesforce instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Salesforce
 
 For SaaS Security to detect posture risks in your Salesforce instance, you must onboard your Salesforce instance to SaaS Security. Through the onboarding process, SaaS Security connects to a Salesforce API and, through the API, scans your Salesforce instance for misconfigured settings and account risks.
 
 You can onboard your Salesforce instance through an interactive OAuth 2.0 Authorization flow or through a Salesforce External Client App.
 
@@ -56,18 +56,16 @@ Permissions for Read Access (configuration scans, identity scans, risky account
 
 Additional Permissions for Write Access (third-party plugin scans and automated remediation):
 
 | Scan Type / Remediation   | Required Permission                                           |
 | ------------------------- | ------------------------------------------------------------- |
 | Configuration Remediation | API Enabled, View Health Check, Download AppExchange Packages |
 | Third-Party Plugins       | API Enabled, Download AppExchange Packages                    |
 
-
-
 To grant permissions to the user account, add the permissions to a permission set and assign the permission set to the Salesforce user account:
 
 1. From the setup home page, select Users > Permission Sets.
 2. Create a new permission set or edit an existing one.
 3. On the setup page for the permission set, locate the System area and navigate to System Permissions.
 4. Enable the required permissions and save.
 5. Assign the permission set to the Salesforce user account.
 
@@ -90,18 +88,16 @@ By adding a Salesforce app in Cortex, you enable SaaS Security to connect to you
 5. Select Security Posture under Default Capabilities and click Next.
 6. Select the option for OAuth 2.0.
 7. Enter your Instance URL.
 8. Specify whether you want SaaS Security to connect with Read Permissions only or with Read and Write Permissions. The onboarding page lists the API scopes that SaaS Security will access.
 9. Click Connect with Salesforce. SaaS Security redirects you to the Salesforce login page.
 10. Log in to the Salesforce account. Salesforce displays a consent form that details the access permissions that SaaS Security requires.
 11. Review the consent form and allow the requested permissions. SaaS Security connects to your Salesforce instance and displays whether it was able to access the required API scopes.
 
-
-
 ***
 
 ### Method 2: External Client App
 
 The External Client App approach authenticates using application credentials (Client ID and Client Secret). This method offers long-term stability by creating a persistent, system-to-system link that does not rely on OAuth refresh tokens.
 
 Required information:
 
```
▸ ▾ Onboard SAP Ariba modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-sap-ariba

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a SAP Ariba instance to detect posture risks and compliance

Connect an SAP Ariba instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard SAP Ariba

# Onboard SAP Ariba

SaaS Security connects to your SAP Ariba instance using administrator credentials and your realm name. You can connect directly with credentials or through Microsoft Azure AD (which adds MFA using one-time passcodes).

SaaS Security connects to your SAP Ariba instance using administrator credentials and your realm name. You can connect directly with credentials or through Microsoft Azure AD (which adds MFA using one-time passcodes).

The onboarding process requires the following information:

The onboarding process requires the following information:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a SAP Ariba instance to detect posture risks and compliance
-  violations.
+  Connect an SAP Ariba instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard SAP Ariba
 
 SaaS Security connects to your SAP Ariba instance using administrator credentials and your realm name. You can connect directly with credentials or through Microsoft Azure AD (which adds MFA using one-time passcodes).
 
 The onboarding process requires the following information:
 
```
▸ ▾ Onboard Sentry modified +3 −1 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-sentry

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Sentry instance to detect posture risks and compliance violations.

description: >-

Connect a Sentry instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Sentry

# Onboard Sentry

SaaS Security connects to the Sentry API using a personal access token that you generate from a Sentry account. After connecting, SaaS Security scans your Sentry instance for misconfigured settings and account risks.

SaaS Security connects to the Sentry API using a personal access token that you generate from a Sentry account. After connecting, SaaS Security scans your Sentry instance for misconfigured settings and account risks.

Note: The supported Sentry account plan for SaaS Security scans is the Business Plan.

Note: The supported Sentry account plan for SaaS Security scans is the Business Plan.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Sentry instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Sentry instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Sentry
 
 SaaS Security connects to the Sentry API using a personal access token that you generate from a Sentry account. After connecting, SaaS Security scans your Sentry instance for misconfigured settings and account risks.
 
 **Note**: The supported Sentry account plan for SaaS Security scans is the Business Plan.
 
```
▸ ▾ Onboard ServiceNow modified +2 −6 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-servicenow

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a ServiceNow instance to detect posture risks and compliance

Connect a ServiceNow instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard ServiceNow

# Onboard ServiceNow

SaaS Security connects to ServiceNow using OAuth 2.0 authorization. Before onboarding, you register an OAuth 2.0 application in ServiceNow. During onboarding, SaaS Security redirects you to ServiceNow to log in and grant access. After connecting, SaaS Security scans your ServiceNow instance for misconfigured settings, third-party plugins, and account risks.

SaaS Security connects to ServiceNow using OAuth 2.0 authorization. Before onboarding, you register an OAuth 2.0 application in ServiceNow. During onboarding, SaaS Security redirects you to ServiceNow to log in and grant access. After connecting, SaaS Security scans your ServiceNow instance for misconfigured settings, third-party plugins, and account risks.

You can also use the same OAuth 2.0 application to enable ServiceNow ticketing from SaaS Security. Onboarding for scans and linking for ticketing are separate procedures, but the OAuth 2.0 application can include redirect URLs for both.

You can also use the same OAuth 2.0 application to enable ServiceNow ticketing from SaaS Security. Onboarding for scans and linking for ticketing are separate procedures, but the OAuth 2.0 application can include redirect URLs for both.

@@ -19,18 +19,16 @@ The onboarding process requires the following credentials:

Instance URL│The unique URL for your ServiceNow instance.

Instance URL│The unique URL for your ServiceNow instance.

#### Step 1 — Get the redirect URL from Cortex

#### Step 1 — Get the redirect URL from Cortex

Before registering your OAuth 2.0 application in ServiceNow, retrieve the redirect URL that SaaS Security requires.

Before registering your OAuth 2.0 application in ServiceNow, retrieve the redirect URL that SaaS Security requires.

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New and click the ServiceNow tile.

2. Select Settings > Data Sources and Integrations > Add New and click the ServiceNow tile.

3. On the Capabilities tab, enter a name for this instance.

3. On the Capabilities tab, enter a name for this instance.

4. Under Default Capabilities, confirm Security Posture is selected.

4. Under Default Capabilities, confirm Security Posture is selected.

5. Click Next.

5. Click Next.

6. On the Connections tab, select OAuth 2.0. SaaS Security displays the Redirect URL value on the configuration page.

6. On the Connections tab, select OAuth 2.0. SaaS Security displays the Redirect URL value on the configuration page.

7. Copy the redirect URL and save it to a text file.

7. Copy the redirect URL and save it to a text file.

@@ -86,18 +84,16 @@ By default, an OAuth token grants full access to all REST APIs the ServiceNow ac

#### Step 4 — Verify ServiceNow table access

#### Step 4 — Verify ServiceNow table access

SaaS Security must be able to access the following ServiceNow tables via the REST Table API:

SaaS Security must be able to access the following ServiceNow tables via the REST Table API:

sys_plugins, sys_properties, sys_scope, sys_user, sys_user_has_role, sys_user_role, oauth_entity, oauth_credential, v_plugin, sys_db_object, pwd_reset_request

sys_plugins, sys_properties, sys_scope, sys_user, sys_user_has_role, sys_user_role, oauth_entity, oauth_credential, v_plugin, sys_db_object, pwd_reset_request

For each table:

For each table:

1. Navigate to System Definition > Tables.

1. Navigate to System Definition > Tables.

2. Locate the table record and click its name to open it.

2. Locate the table record and click its name to open it.

3. Select the Application Access tab.

3. Select the Application Access tab.

4. Verify that Allow access to this table via web services is selected. If not, select it and click Update.

4. Verify that Allow access to this table via web services is selected. If not, select it and click Update.

#### Step 5 — Connect SaaS Security to ServiceNow

#### Step 5 — Connect SaaS Security to ServiceNow
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a ServiceNow instance to detect posture risks and compliance
-  violations.
+  Connect a ServiceNow instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard ServiceNow
 
 SaaS Security connects to ServiceNow using OAuth 2.0 authorization. Before onboarding, you register an OAuth 2.0 application in ServiceNow. During onboarding, SaaS Security redirects you to ServiceNow to log in and grant access. After connecting, SaaS Security scans your ServiceNow instance for misconfigured settings, third-party plugins, and account risks.
 
 You can also use the same OAuth 2.0 application to enable ServiceNow ticketing from SaaS Security. Onboarding for scans and linking for ticketing are separate procedures, but the OAuth 2.0 application can include redirect URLs for both.
 
@@ -19,18 +19,16 @@ The onboarding process requires the following credentials:
 | Instance URL  | The unique URL for your ServiceNow instance.                                                 |
 
 ***
 
 #### Step 1 — Get the redirect URL from Cortex
 
 Before registering your OAuth 2.0 application in ServiceNow, retrieve the redirect URL that SaaS Security requires.
 
-
-
 1. Log in to [Cortex](https://cortex.paloaltonetworks.com).
 2. Select **Settings > Data Sources and Integrations > Add New** and click the ServiceNow tile.
 3. On the **Capabilities** tab, enter a name for this instance.
 4. Under Default Capabilities, confirm Security Posture is selected.
 5. Click Next.
 6. On the **Connections** tab, select OAuth 2.0. SaaS Security displays the Redirect URL value on the configuration page.
 7. Copy the redirect URL and save it to a text file.
 
@@ -86,18 +84,16 @@ By default, an OAuth token grants full access to all REST APIs the ServiceNow ac
 #### Step 4 — Verify ServiceNow table access
 
 SaaS Security must be able to access the following ServiceNow tables via the REST Table API:
 
 sys\_plugins, sys\_properties, sys\_scope, sys\_user, sys\_user\_has\_role, sys\_user\_role, oauth\_entity, oauth\_credential, v\_plugin, sys\_db\_object, pwd\_reset\_request
 
 For each table:
 
-
-
 1. Navigate to System Definition > Tables.
 2. Locate the table record and click its name to open it.
 3. Select the Application Access tab.
 4. Verify that Allow access to this table via web services is selected. If not, select it and click Update.
 
 ***
 
 #### Step 5 — Connect SaaS Security to ServiceNow
```
▸ ▾ Onboard Shopify modified +3 −1 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-shopify

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Shopify instance to detect posture risks and compliance violations.

description: >-

Connect a Shopify instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Shopify

# Onboard Shopify

SaaS Security connects to the Shopify API using an API token generated from a custom Shopify app. Creating a custom app ensures the token is scoped to only the permissions SaaS Security requires. After connecting, SaaS Security scans your Shopify store for misconfigured settings and account risks.

SaaS Security connects to the Shopify API using an API token generated from a custom Shopify app. Creating a custom app ensures the token is scoped to only the permissions SaaS Security requires. After connecting, SaaS Security scans your Shopify store for misconfigured settings and account risks.

Note: These steps onboard a single Shopify store. To scan multiple stores, onboard each store separately. The supported Shopify account plan for SaaS Security scans is the Shopify Plus plan.

Note: These steps onboard a single Shopify store. To scan multiple stores, onboard each store separately. The supported Shopify account plan for SaaS Security scans is the Shopify Plus plan.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Shopify instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Shopify instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Shopify
 
 SaaS Security connects to the Shopify API using an API token generated from a custom Shopify app. Creating a custom app ensures the token is scoped to only the permissions SaaS Security requires. After connecting, SaaS Security scans your Shopify store for misconfigured settings and account risks.
 
 **Note**: These steps onboard a single Shopify store. To scan multiple stores, onboard each store separately. The supported Shopify account plan for SaaS Security scans is the Shopify Plus plan.
 
```
▸ ▾ Onboard Slack Enterprise modified +3 −3 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-slack-enterprise

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,25 +1,25 @@

---

---

description: Connect a Slack instance to detect posture risks and compliance violations.

description: >-

Connect a Slack instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Slack Enterprise

# Onboard Slack Enterprise

SaaS Security connects to the Slack Enterprise API using a User OAuth Token generated from a Slack org-wide app that you create. A Slack org-wide app is deployed across all workspaces in your organization.

SaaS Security connects to the Slack Enterprise API using a User OAuth Token generated from a Slack org-wide app that you create. A Slack org-wide app is deployed across all workspaces in your organization.

Note: The Slack Enterprise connector was updated in May 2025 to support the Identity Security dashboard. If you onboarded your Slack Enterprise instance before this update and want to view account risks in the Identity Security dashboard, you must re-onboard your Slack instance. Before re-onboarding, add the admin.users:read OAuth scope to your existing org-wide app.

Note: The Slack Enterprise connector was updated in May 2025 to support the Identity Security dashboard. If you onboarded your Slack Enterprise instance before this update and want to view account risks in the Identity Security dashboard, you must re-onboard your Slack instance. Before re-onboarding, add the admin.users:read OAuth scope to your existing org-wide app.

Onboarding consists of two tasks:

Onboarding consists of two tasks:

1. Create an org-wide app and generate a User OAuth Token

1. Create an org-wide app and generate a User OAuth Token

2. Connect SaaS Security to your Slack Enterprise instance

2. Connect SaaS Security to your Slack Enterprise instance

#### Task 1 — Create an App for Accessing Your Slack Enterprise Instance

#### Task 1 — Create an App for Accessing Your Slack Enterprise Instance

Step 1 — Identify the administrator account

Step 1 — Identify the administrator account

Identify the Slack administrator account you will use to create the org-wide app.

Identify the Slack administrator account you will use to create the org-wide app.
Show markdown source
```
@@ -1,25 +1,25 @@
 ---
-description: Connect a Slack instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Slack instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Slack Enterprise
 
 SaaS Security connects to the Slack Enterprise API using a User OAuth Token generated from a Slack org-wide app that you create. A Slack org-wide app is deployed across all workspaces in your organization.
 
 **Note**: The Slack Enterprise connector was updated in May 2025 to support the Identity Security dashboard. If you onboarded your Slack Enterprise instance before this update and want to view account risks in the Identity Security dashboard, you must re-onboard your Slack instance. Before re-onboarding, add the admin.users:read OAuth scope to your existing org-wide app.
 
 Onboarding consists of two tasks:
 
 1. Create an org-wide app and generate a User OAuth Token
 2. Connect SaaS Security to your Slack Enterprise instance
 
-
-
 ***
 
 #### Task 1 — Create an App for Accessing Your Slack Enterprise Instance
 
 **Step 1 — Identify the administrator account**
 
 Identify the Slack administrator account you will use to create the org-wide app.
 
```
▸ ▾ Onboard Sumo Logic modified +2 −2 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-sumo-logic

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect a Sumo Logic instance to detect posture risks and compliance

Connect a Sumo Logic instance in Cortex XSIAM to detect posture risks and

violations.

compliance violations.

---

---

# Onboard Sumo Logic

# Onboard Sumo Logic

SaaS Security connects to the Sumo Logic API using an access key that you generate as the Sumo Logic account owner. After connecting, SaaS Security Checks scans your Sumo Logic instance for misconfigured settings and account risks.

SaaS Security connects to the Sumo Logic API using an access key that you generate as the Sumo Logic account owner. After connecting, SaaS Security Checks scans your Sumo Logic instance for misconfigured settings and account risks.

Note: The supported Sumo Logic account plan for SaaS Security scans is the Enterprise plan.

Note: The supported Sumo Logic account plan for SaaS Security scans is the Enterprise plan.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect a Sumo Logic instance to detect posture risks and compliance
-  violations.
+  Connect a Sumo Logic instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Sumo Logic
 
 SaaS Security connects to the Sumo Logic API using an access key that you generate as the Sumo Logic account owner. After connecting, SaaS Security Checks scans your Sumo Logic instance for misconfigured settings and account risks.
 
 Note: The supported Sumo Logic account plan for SaaS Security scans is the Enterprise plan.
 
```
▸ ▾ Onboard Workday modified +3 −4 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-workday

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Workday instance to detect posture risks and compliance violations.

description: >-

Connect a Workday instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Workday

# Onboard Workday

SaaS Security connects to Workday using OAuth 2.0 authorization via an API Client for Integrations. To enable secure background scanning, you create a non-human integration system user account and associate it with the API client. SaaS Security also pulls data from a custom report that you expose as a web service.

SaaS Security connects to Workday using OAuth 2.0 authorization via an API Client for Integrations. To enable secure background scanning, you create a non-human integration system user account and associate it with the API client. SaaS Security also pulls data from a custom report that you expose as a web service.

Onboarding consists of four tasks:

Onboarding consists of four tasks:

@@ -137,18 +139,16 @@ SaaS Security pulls data from a custom report exposed as a web service. Complete

Processed Transaction│Entry Moment│Entry_Moment

Processed Transaction│Entry Moment│Entry_Moment

Processed Transaction│Secured Task Executed│Secured_Task_Executed

Processed Transaction│Secured Task Executed│Secured_Task_Executed

Processed Transaction│Processed Transaction│Processed_Transaction

Processed Transaction│Processed Transaction│Processed_Transaction

Processed Transaction│System Account│System_Account

Processed Transaction│System Account│System_Account

Attributes that Changed│Changed Attribute│Changed_Attribute

Attributes that Changed│Changed Attribute│Changed_Attribute

Attributes that Changed│Previous Value│Previous_Value

Attributes that Changed│Previous Value│Previous_Value

Attributes that Changed│Value│Value

Attributes that Changed│Value│Value

4. Under Group Column Headings, add the Attributes that Changed business object.

4. Under Group Column Headings, add the Attributes that Changed business object.

5. Select the Filters tab and add filters for the Task Behavior field. Add an Or condition for each of the following values (operator: exact match with the selection list, type: Value specified in this filter):

5. Select the Filters tab and add filters for the Task Behavior field. Add an Or condition for each of the following values (operator: exact match with the selection list, type: Value specified in this filter):

• Edit Tenant Setup - HCM

• Edit Tenant Setup - HCM

• Edit Tenant Setup - Global

• Edit Tenant Setup - Global

• Edit Tenant Setup - Security

• Edit Tenant Setup - Security

• Edit Tenant Setup - System

• Edit Tenant Setup - System

• Edit Tenant Setup - Reporting and Analytics

• Edit Tenant Setup - Reporting and Analytics

@@ -206,9 +206,8 @@ Note: Do not proceed until you have copied the JSON web service URL.

• Refresh Token

• Refresh Token

• Custom Audit Log Report Web Service URL (JSON format)

• Custom Audit Log Report Web Service URL (JSON format)

8. Click Next.

8. Click Next.

9. On the Configurations tab:

9. On the Configurations tab:

1. Set the Sync Interval.

1. Set the Sync Interval.

2. (Optional) Add a Tag.

2. (Optional) Add a Tag.

10. Click Next to complete onboarding.

10. Click Next to complete onboarding.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Workday instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Workday instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Workday
 
 SaaS Security connects to Workday using OAuth 2.0 authorization via an API Client for Integrations. To enable secure background scanning, you create a non-human integration system user account and associate it with the API client. SaaS Security also pulls data from a custom report that you expose as a web service.
 
 Onboarding consists of four tasks:
 
@@ -137,18 +139,16 @@ SaaS Security pulls data from a custom report exposed as a web service. Complete
 | Processed Transaction   | Entry Moment          | Entry\_Moment                     |
 | Processed Transaction   | Secured Task Executed | Secured\_Task\_Executed           |
 | Processed Transaction   | Processed Transaction | Processed\_Transaction            |
 | Processed Transaction   | System Account        | System\_Account                   |
 | Attributes that Changed | Changed Attribute     | Changed\_Attribute                |
 | Attributes that Changed | Previous Value        | Previous\_Value                   |
 | Attributes that Changed | Value                 | Value                             |
 
-
-
 4. Under Group Column Headings, add the Attributes that Changed business object.
 5. Select the Filters tab and add filters for the Task Behavior field. Add an Or condition for each of the following values (operator: exact match with the selection list, type: Value specified in this filter):
 
 * Edit Tenant Setup - HCM
 * Edit Tenant Setup - Global
 * Edit Tenant Setup - Security
 * Edit Tenant Setup - System
 * Edit Tenant Setup - Reporting and Analytics
@@ -206,9 +206,8 @@ Note: Do not proceed until you have copied the JSON web service URL.
 * Refresh Token
 * Custom Audit Log Report Web Service URL (JSON format)
 
 8. Click Next.
 9. On the Configurations tab:
    1. Set the Sync Interval.
    2. (Optional) Add a Tag.
 10. Click Next to complete onboarding.
-
```
▸ ▾ Onboard Wrike modified +3 −3 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-wrike

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a Wrike instance to detect posture risks and compliance violations.

description: >-

Connect a Wrike instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard Wrike

# Onboard Wrike

SaaS Security connects to Wrike using OAuth 2.0 authorization. Before onboarding, you create an OAuth 2.0 integration app in Wrike. During onboarding, SaaS Security redirects you to Wrike to log in and grant access.

SaaS Security connects to Wrike using OAuth 2.0 authorization. Before onboarding, you create an OAuth 2.0 integration app in Wrike. During onboarding, SaaS Security redirects you to Wrike to log in and grant access.

Onboarding consists of two tasks:

Onboarding consists of two tasks:

@@ -30,18 +32,16 @@ Before creating your OAuth 2.0 integration app in Wrike, retrieve the redirect U

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New and click the Wrike tile.

2. Select Settings > Data Sources and Integrations > Add New and click the Wrike tile.

3. On the Capabilities tab, enter a name for this instance.

3. On the Capabilities tab, enter a name for this instance.

4. Under Default Capabilities, confirm Security Posture is selected.

4. Under Default Capabilities, confirm Security Posture is selected.

5. Click Next.

5. Click Next.

6. On the Connections tab, the Redirect URL value is displayed.

6. On the Connections tab, the Redirect URL value is displayed.

7. Copy the redirect URL and save it to a text file.

7. Copy the redirect URL and save it to a text file.

Note: Do not complete the onboarding flow yet. Return to the Add Data Source page and proceed to create the OAuth app in Wrike.

Note: Do not complete the onboarding flow yet. Return to the Add Data Source page and proceed to create the OAuth app in Wrike.

Step 2 — Identify the Wrike administrator account

Step 2 — Identify the Wrike administrator account

Identify the Wrike administrator account you will use to create the OAuth 2.0 integration.

Identify the Wrike administrator account you will use to create the OAuth 2.0 integration.

Required permissions: The OAuth 2.0 integration must be created by an Account Administrator.

Required permissions: The OAuth 2.0 integration must be created by an Account Administrator.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a Wrike instance to detect posture risks and compliance violations.
+description: >-
+  Connect a Wrike instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard Wrike
 
 SaaS Security connects to Wrike using OAuth 2.0 authorization. Before onboarding, you create an OAuth 2.0 integration app in Wrike. During onboarding, SaaS Security redirects you to Wrike to log in and grant access.
 
 Onboarding consists of two tasks:
 
@@ -30,18 +32,16 @@ Before creating your OAuth 2.0 integration app in Wrike, retrieve the redirect U
 1. Log in to [Cortex](https://cortex.paloaltonetworks.com).
 2. Select **Settings > Data Sources and Integrations > Add New** and click the Wrike tile.
 3. On the **Capabilities** tab, enter a name for this instance.
 4. Under Default Capabilities, confirm Security Posture is selected.
 5. Click Next.
 6. On the **Connections** tab, the Redirect URL value is displayed.
 7. Copy the redirect URL and save it to a text file.
 
-
-
 **Note**: Do not complete the onboarding flow yet. Return to the Add Data Source page and proceed to create the OAuth app in Wrike.
 
 **Step 2 — Identify the Wrike administrator account**
 
 Identify the Wrike administrator account you will use to create the OAuth 2.0 integration.
 
 Required permissions: The OAuth 2.0 integration must be created by an Account Administrator.
 
```
▸ ▾ Onboard YouTrack modified +3 −1 xsiam/cloud-security/cortex-cloud-saas-security/connect-a-saas-application/onboard-youtrack

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Connect a YouTrack instance to detect posture risks and compliance violations.

description: >-

Connect a YouTrack instance in Cortex XSIAM to detect posture risks and

compliance violations.

---

---

# Onboard YouTrack

# Onboard YouTrack

SaaS Security connects to the YouTrack API using a permanent token that you generate from a YouTrack administrator account. After connecting, SaaS Security scans your YouTrack instance for misconfigured settings.

SaaS Security connects to the YouTrack API using a permanent token that you generate from a YouTrack administrator account. After connecting, SaaS Security scans your YouTrack instance for misconfigured settings.

Onboarding consists of two tasks:

Onboarding consists of two tasks:
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Connect a YouTrack instance to detect posture risks and compliance violations.
+description: >-
+  Connect a YouTrack instance in Cortex XSIAM to detect posture risks and
+  compliance violations.
 ---
 
 # Onboard YouTrack
 
 SaaS Security connects to the YouTrack API using a permanent token that you generate from a YouTrack administrator account. After connecting, SaaS Security scans your YouTrack instance for misconfigured settings.
 
 Onboarding consists of two tasks:
 
```
▸ ▾ Create and monitor tickets modified +3 −1 xsiam/cloud-security/cortex-cloud-saas-security/create-and-monitor-tickets

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Learn more about creating a synced ticket to remediate an issue.

description: >-

Create and monitor synced tickets in Cortex XSIAM to remediate SaaS Security

issues.

---

---

# Create and monitor tickets

# Create and monitor tickets

Integrate SaaS Security with Jira or ServiceNow to streamline misconfiguration remediation. This integration allows security teams to delegate manual remediation tasks directly to SaaS application administrators using your organization's existing issue tracking system.

Integrate SaaS Security with Jira or ServiceNow to streamline misconfiguration remediation. This integration allows security teams to delegate manual remediation tasks directly to SaaS application administrators using your organization's existing issue tracking system.
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Learn more about creating a synced ticket to remediate an issue.
+description: >-
+  Create and monitor synced tickets in Cortex XSIAM to remediate SaaS Security
+  issues.
 ---
 
 # Create and monitor tickets
 
 Integrate SaaS Security with Jira or ServiceNow to streamline misconfiguration remediation. This integration allows security teams to delegate manual remediation tasks directly to SaaS application administrators using your organization's existing issue tracking system.
 
 ***
 
```
▸ ▾ Detection Rules modified +6 −6 xsiam/cloud-security/cortex-cloud-saas-security/detection-rules

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,17 +1,17 @@

---

---

description: View Cloud Security Posture Rules

description: >-

View Cloud Security Posture Rules in Cortex XSIAM to detect SaaS application

risks.

---

---

# Detection Rules

# Detection Rules

Detection Rules help you identify policies that are already in place and available out-of-the-box to help you remediate configuration issues with SaaS applications. Follow the steps below to view SaaS Detection Rules.

Detection Rules help you identify policies that are already in place and available out-of-the-box to help you remediate configuration issues with SaaS applications. Follow the steps below to view SaaS Detection Rules.

1. Navigate to Modules > SaaS Security > Detection Rules. This takes you to the Cloud Posture Security Rules page.

1. Navigate to Modules > SaaS Security > Detection Rules. This takes you to the Cloud Posture Security Rules page.

2. Here you can select SaaS or AI > Filter In to see a full list of available out-of-the-box rules.

2. Here you can select SaaS or AI > Filter In to see a full list of available out-of-the-box rules.

3. Select a Rule to view more details. Options include:

3. Select a Rule to view more details. Options include:

4. Rule Details: Displays a detailed description of the Rule and outlines execution scope.

4. Rule Details: Displays a detailed description of the Rule and outlines execution scope.

5. Compliance Controls: Maps this rule's execution logic to framework controls (such as SOC 2, ISO 27001, or CIS Benchmarks) for compliance audits.

5. Compliance Controls: Maps this rule's execution logic to framework controls (such as SOC 2, ISO 27001, or CIS Benchmarks) for compliance audits.
Show markdown source
```
@@ -1,17 +1,17 @@
 ---
-description: View Cloud Security Posture Rules
+description: >-
+  View Cloud Security Posture Rules in Cortex XSIAM to detect SaaS application
+  risks.
 ---
 
 # Detection Rules
 
 Detection Rules help you identify policies that are already in place and available out-of-the-box to help you remediate configuration issues with SaaS applications. Follow the steps below to view SaaS Detection Rules.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2Fq32WuSgWAUXhh3Moe8N3%2Funknown.png?alt=media&#x26;token=929b18e2-458e-4a74-8712-85f5ba853ebe" alt="" height="312" width="624">
 
-
-
-1. Navigate to **Modules > SaaS Security > Detection Rules**. This takes you to the Cloud Posture Security Rules page.&#x20;
+1. Navigate to **Modules > SaaS Security > Detection Rules**. This takes you to the Cloud Posture Security Rules page.
 2. Here you can select **SaaS or AI > Filter In** to see a full list of available out-of-the-box rules.
 3. Select a Rule to view more details. Options include:
-4. **Rule Details**: Displays a detailed description of the Rule and outlines execution scope.&#x20;
-5. **Compliance Controls**: Maps this rule's execution logic to framework controls (such as SOC 2, ISO 27001, or CIS Benchmarks) for compliance audits.&#x20;
+4. **Rule Details**: Displays a detailed description of the Rule and outlines execution scope.
+5. **Compliance Controls**: Maps this rule's execution logic to framework controls (such as SOC 2, ISO 27001, or CIS Benchmarks) for compliance audits.
```
▸ ▾ Provider Instances Security Check modified +6 −6 xsiam/cloud-security/cortex-cloud-saas-security/provider-instances-security-check

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,32 +1,32 @@

---

---

description: >-

description: >-

This page consolidates application security posture data across all onboarded

Use Provider Instances Security Check in Cortex XSIAM to assess security

instances

posture across application instances.

---

---

# Provider Instances Security Check

# Provider Instances Security Check

The Provider Instances page provides a high-level aggregation of tenant security scores and an interactive, list view for analyzing and remediating individual instances.

The Provider Instances page provides a high-level aggregation of tenant security scores and an interactive, list view for analyzing and remediating individual instances.

\

\

This page consolidates SaaS application security posture data across all onboarded instances:

This page consolidates SaaS application security posture data across all onboarded instances:

• Overall Security Check Score: Displays the global average posture score across all integrated instances. Applications are further categorized into three security score-based buckets:

• Overall Security Check Score: Displays the global average posture score across all integrated instances. Applications are further categorized into three security score-based buckets:

• Up to 50% (Red): Severe posture gaps

• Up to 50% (Red): Severe posture gaps

• Between 50%–75% (Yellow): Moderate posture alignment

• Between 50%–75% (Yellow): Moderate posture alignment

• Over 75% (Green): High posture alignment

• Over 75% (Green): High posture alignment

• Providers (Distribution Tiles): Lists onboarded SaaS Applications with active instance count for each provider.

• Providers (Distribution Tiles): Lists onboarded SaaS Applications with active instance count for each provider.

Instance Inventory List

Instance Inventory List

The table displays granular telemetry for each active SaaS application.

The table displays granular telemetry for each active SaaS application.

Provider Instances: The unique, user-defined identifier/name for the specific SaaS tenant. These are hyperlinked to route administrators to the deep-dive configuration and issues page for that specific instance.

Provider Instances: The unique, user-defined identifier/name for the specific SaaS tenant. These are hyperlinked to route administrators to the deep-dive configuration and issues page for that specific instance.

• Provider Type: The underlying third-party SaaS vendor platform associated with the instance (e.g., Mural, Cisco Meraki).

• Provider Type: The underlying third-party SaaS vendor platform associated with the instance (e.g., Mural, Cisco Meraki).

• Application Tag: Custom metadata tags assigned to instances to categorize environments for scoped policies and reporting.

• Application Tag: Custom metadata tags assigned to instances to categorize environments for scoped policies and reporting.

• Connector Status: The operational state of the API integration. A green Connected status indicates active, authorized data ingestion.

• Connector Status: The operational state of the API integration. A green Connected status indicates active, authorized data ingestion.

• Overall Security Check Score: The normalized security score (0–100%) computed for the individual instance.

• Overall Security Check Score: The normalized security score (0–100%) computed for the individual instance.
Show markdown source
```
@@ -1,32 +1,32 @@
 ---
 description: >-
-  This page consolidates application security posture data across all onboarded
-  instances
+  Use Provider Instances Security Check in Cortex XSIAM to assess security
+  posture across application instances.
 ---
 
 # Provider Instances Security Check
 
 The **Provider Instances** page provides a high-level aggregation of tenant security scores and an interactive, list view for analyzing and remediating individual instances.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2Fx9JcEbsgHuDFKPWsALgl%2Funknown.png?alt=media&#x26;token=3516186e-f6fb-4d79-b1ab-b179e6fac8b9" alt="" height="383" width="624">
 
 \
 This page consolidates SaaS application security posture data across all onboarded instances:
 
 * Overall Security Check Score: Displays the global average posture score across all integrated instances. Applications are further categorized into three security score-based buckets:
-* Up to 50% (Red): Severe posture gaps &#x20;
-* Between 50%–75% (Yellow): Moderate posture alignment&#x20;
-* Over 75% (Green): High posture alignment &#x20;
+* Up to 50% (Red): Severe posture gaps
+* Between 50%–75% (Yellow): Moderate posture alignment
+* Over 75% (Green): High posture alignment
 * Providers (Distribution Tiles): Lists onboarded SaaS Applications with active instance count for each provider.
 
 **Instance Inventory List**
 
-The table displays granular telemetry for each active SaaS application.&#x20;
+The table displays granular telemetry for each active SaaS application.
 
 Provider Instances: The unique, user-defined identifier/name for the specific SaaS tenant. These are hyperlinked to route administrators to the deep-dive configuration and issues page for that specific instance.
 
 * Provider Type: The underlying third-party SaaS vendor platform associated with the instance (e.g., Mural, Cisco Meraki).
 * Application Tag: Custom metadata tags assigned to instances to categorize environments for scoped policies and reporting.
 * Connector Status: The operational state of the API integration. A green Connected status indicates active, authorized data ingestion.
 * Overall Security Check Score: The normalized security score (0–100%) computed for the individual instance.
 
```
▸ ▾ Remediation Actions modified +4 −4 xsiam/cloud-security/cortex-cloud-saas-security/remediation-actions

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,19 +1,19 @@

---

---

description: Learn more about actions available to remediate Issues.

description: Use remediation actions in Cortex XSIAM to resolve SaaS Security issues.

---

---

# Remediation Actions

# Remediation Actions

Review remediation actions to see a prioritized list of steps you can take to resolve posture issues originating from SaaS Applications. Follow the steps below to view all the Remediation options:

Review remediation actions to see a prioritized list of steps you can take to resolve posture issues originating from SaaS Applications. Follow the steps below to view all the Remediation options:

1. Navigate to Modules > SaaS Security > Security Issues > Posture to view a list of all issues with vulnerabilities originating from SaaS Application Posture.

1. Navigate to Modules > SaaS Security > Security Issues > Posture to view a list of all issues with vulnerabilities originating from SaaS Application Posture.

2. Click on any Issue to be taken to the Issue view.

2. Click on any Issue to be taken to the Issue view.

3. Select the Issue you wish to investigate. This opens the Remediation Actions side panel.

3. Select the Issue you wish to investigate. This opens the Remediation Actions side panel.

4. The detailed side panel provides the following investigation and remediation options:

4. The detailed side panel provides the following investigation and remediation options:

1. The Overview tab on the Vulnerability Issues panel captures all the relevant details to further investigate the vulnerability including Summary, Details, Affected Assets, and Evidence.

1. The Overview tab on the Vulnerability Issues panel captures all the relevant details to further investigate the vulnerability including Summary, Details, Affected Assets, and Evidence.

2. Select Resolution to view remediation options including Remediation Guidance. Detailed manual steps are listed to resolve the issue.

2. Select Resolution to view remediation options including Remediation Guidance. Detailed manual steps are listed to resolve the issue.

3. Click War Room for real-time investigation capabilities. In the War Room you can capture case context from different sources and collaborate and execute remote actions across integrated products.

3. Click War Room for real-time investigation capabilities. In the War Room you can capture case context from different sources and collaborate and execute remote actions across integrated products.

4. Work Plan is available when you select an autonomous playbook in an issue's resolution tab. This view presents only the executed key tasks and their defined outputs, providing a focused view of resolution actions.

4. Work Plan is available when you select an autonomous playbook in an issue's resolution tab. This view presents only the executed key tasks and their defined outputs, providing a focused view of resolution actions.

5. Ticketing and Notifications: Jira, Slack, and Service Now integrations are available to create a ticket to resolve any issue. Webhook notification routing is also available for your auditing requirements.

5. Ticketing and Notifications: Jira, Slack, and Service Now integrations are available to create a ticket to resolve any issue. Webhook notification routing is also available for your auditing requirements.
Show markdown source
```
@@ -1,19 +1,19 @@
 ---
-description: Learn more about actions available to remediate Issues.
+description: Use remediation actions in Cortex XSIAM to resolve SaaS Security issues.
 ---
 
 # Remediation Actions
 
 Review remediation actions to see a prioritized list of steps you can take to resolve posture issues originating from SaaS Applications. Follow the steps below to view all the Remediation options:
 
 <figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FSBidnXL0Nq0WkaHZTEoe%2Fimage.png?alt=media&#x26;token=4e0d0c5f-0d5b-4047-9bc3-3294d0787f22" alt=""><figcaption></figcaption></figure>
 
-1. Navigate to **Modules > SaaS Security > Security Issues > Posture** to view a list of all issues with vulnerabilities originating from SaaS Application Posture.&#x20;
-2. Click on any Issue to be taken to the Issue view.&#x20;
+1. Navigate to **Modules > SaaS Security > Security Issues > Posture** to view a list of all issues with vulnerabilities originating from SaaS Application Posture.
+2. Click on any Issue to be taken to the Issue view.
 3. Select the Issue you wish to investigate. This opens the Remediation Actions side panel.
 4. The detailed side panel provides the following investigation and remediation options:
    1. The **Overview** tab on the Vulnerability Issues panel captures all the relevant details to further investigate the vulnerability including Summary, Details, Affected Assets, and Evidence.
    2. Select **Resolution** to view remediation options including Remediation Guidance. Detailed manual steps are listed to resolve the issue.
    3. Click **War Room** for real-time investigation capabilities. In the War Room you can capture case context from different sources and collaborate and execute remote actions across integrated products.
    4. **Work Plan** is available when you select an autonomous playbook in an issue's resolution tab. This view presents only the executed key tasks and their defined outputs, providing a focused view of resolution actions.
-   5. **Ticketing and Notifications**: Jira, Slack, and Service Now integrations are available to create a ticket to resolve any issue. Webhook notification routing is also available for your auditing requirements.&#x20;
+   5. **Ticketing and Notifications**: Jira, Slack, and Service Now integrations are available to create a ticket to resolve any issue. Webhook notification routing is also available for your auditing requirements.
```

▸ SaaS AI Agent Security modified +9 −9 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

description: >-

SaaS AI Agent Security helps you secure AI agents deployed across enterprise

Use SaaS AI Agent Security in Cortex XSIAM to secure enterprise SaaS AI

SaaS environments.

agents.

---

# SaaS AI Agent Security

Cortex's AI Security Posture Management (AISPM) module surfaces SaaS AI Agent data to help you tackle the unique challenges of securing AI agents deployed across enterprise SaaS environments. It provides your security teams with comprehensive visibility, proactive threat detection, and automated enforcement mechanisms specifically tailored for agentic platforms. To get started, see Setup SaaS Security for AISPM.

hint info

Note: SaaS AI Agent Security is currently in Beta with limited availability. Contact your Customer Service Representative to activate AI Agent Security in your environment.

@@ -22,19 +22,19 @@ AISPM helps protect the autonomous workflows in your cloud environment with foll

• Exposes Threats such as vulnerabilities that may lead to injection attacks via System Prompts, Tools or Skills.

#### Supported Agent Platforms

AISPM is designed to onboard and secure a wide array of modern enterprise AI agent platforms, including:

• Atlassian Rovo

• Box AI Agents

• ChatGPT Enterprise

• Cursor Enterprise

• Gemini Enterprise

• Microsoft 365 Copilot and Copilot Studio

• ServiceNow AI Platform

AISPM provides a comprehensive view of all SaaS agents, their configurations, and security postures, offering end-to-end auditability and high-level dashboards for governance across your organization.

Show markdown source

@@ -1,12 +1,12 @@
 ---
 description: >-
-  SaaS AI Agent Security helps you secure AI agents deployed across enterprise
-  SaaS environments.
+  Use SaaS AI Agent Security in Cortex XSIAM to secure enterprise SaaS AI
+  agents.
 ---
 
 # SaaS AI Agent Security
 
 Cortex's [AI Security Posture Management (AISPM)](../cortex-cloud-ai-security) module surfaces SaaS AI Agent data to help you tackle the unique challenges of securing AI agents deployed across enterprise SaaS environments. It provides your security teams with comprehensive visibility, proactive threat detection, and automated enforcement mechanisms specifically tailored for agentic platforms. To get started, see [Setup SaaS Security for AISPM](saas-ai-agent-security/setup-saas-security-for-aispm).
 
 {% hint style="info" %}
 Note: SaaS AI Agent Security is currently in Beta with limited availability. Contact your Customer Service Representative to activate AI Agent Security in your environment.
@@ -22,19 +22,19 @@ AISPM helps protect the autonomous workflows in your cloud environment with foll
 * Exposes Threats such as vulnerabilities that may lead to injection attacks via System Prompts, Tools or Skills.
 
 <figure><img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FZ2JWDH5pHy0Fp3X0W3vf%2Fimage.png?alt=media&#x26;token=ef2ee3e7-fe2d-4ab8-8cc5-23d2ad2411b9" alt=""><figcaption></figcaption></figure>
 
 #### Supported Agent Platforms
 
 AISPM is designed to onboard and secure a wide array of modern enterprise AI agent platforms, including:
 
-* [Atlassian Rovo](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-atlassian-rovo)
-* [Box AI Agents](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-box-ai-agents)
-* [ChatGPT Enterprise](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-chatgpt-enterprise)
-* [Cursor Enterprise](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-cursor-enterprise)
-* [Gemini Enterprise](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-gemini-enterprise)
-* [Microsoft 365 Copilot](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-m365-copilot) and [Copilot Studio](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-microsoft-copilot-studio)
-* [ServiceNow AI Platform](../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-service-now)
+* [Atlassian Rovo](broken-reference)
+* [Box AI Agents](broken-reference)
+* [ChatGPT Enterprise](broken-reference)
+* [Cursor Enterprise](broken-reference)
+* [Gemini Enterprise](broken-reference)
+* [Microsoft 365 Copilot](broken-reference) and [Copilot Studio](broken-reference)
+* [ServiceNow AI Platform](broken-reference)
 
 AISPM provides a comprehensive view of all SaaS agents, their configurations, and security postures, offering end-to-end auditability and high-level dashboards for governance across your organization.
 
 <br>

▸ ▾ Manage SaaS AI Agents modified +6 −0 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/manage-saas-ai-agents

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,5 +1,11 @@

---

description: >-

Manage SaaS AI agents in Cortex XSIAM, including agents, datasets, and

connected tools.

---

# Manage SaaS AI Agents

# Manage SaaS AI Agents

AISPM provides comprehensive management tools to monitor and control your AI agent ecosystem. Through centralized visibility, you can track agent activity, assess security posture, and perform targeted remediation to mitigate risks associated with autonomous workflows.

AISPM provides comprehensive management tools to monitor and control your AI agent ecosystem. Through centralized visibility, you can track agent activity, assess security posture, and perform targeted remediation to mitigate risks associated with autonomous workflows.
Show markdown source
```
@@ -1,5 +1,11 @@
+---
+description: >-
+  Manage SaaS AI agents in Cortex XSIAM, including agents, datasets, and
+  connected tools.
+---
+
 # Manage SaaS AI Agents
 
 AISPM provides comprehensive management tools to monitor and control your AI agent ecosystem. Through centralized visibility, you can track agent activity, assess security posture, and perform targeted remediation to mitigate risks associated with autonomous workflows.
 
 <br>
```
▸ ▾ View Agent Tools modified +2 −4 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/manage-saas-ai-agents/view-agent-tools

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,24 +1,22 @@

---

---

description: >-

description: View tools connected to SaaS AI agents in Cortex XSIAM.

SaaS Agent Tools go beyond traditional scans that focus on an inventory of

previously vendor vetted, underlying tools.

---

---

# View Agent Tools

# View Agent Tools

The SaaS Agent Tools security page moves beyond assessment of tools to the real security surface the—Tool Wrapper (or "Agent Tool" instance). This is the configuration layer where an agent author defines how a tool is used. This analysis often reveals risks like overprivileged access, or insecure credentialing that arise here and not in the underlying function code.

The SaaS Agent Tools security page moves beyond assessment of tools to the real security surface the—Tool Wrapper (or "Agent Tool" instance). This is the configuration layer where an agent author defines how a tool is used. This analysis often reveals risks like overprivileged access, or insecure credentialing that arise here and not in the underlying function code.

An Agent Tool is a specific instance of a tool being utilized by a specific agent. It acts as a wrapper that encapsulates:

An Agent Tool is a specific instance of a tool being utilized by a specific agent. It acts as a wrapper that encapsulates:

1. Metadata Aliases: Custom names and descriptions provided by the agent author Configuration Settings: How the tool is pointed at specific data stores or environments

1. Metadata Aliases: Custom names and descriptions provided by the agent author Configuration Settings: How the tool is pointed at specific data stores or environments

2. Authentication/Identity: Whether the tool executes using a System Credential, a specific Service Account, or prompts the User on-the-fly.

2. Authentication/Identity: Whether the tool executes using a System Credential, a specific Service Account, or prompts the User on-the-fly.

The SaaS Agent Tool page and dashboard focuses exclusively on posture risks introduced by the misconfiguration of the Agent Tool Wrapper layer.

The SaaS Agent Tool page and dashboard focuses exclusively on posture risks introduced by the misconfiguration of the Agent Tool Wrapper layer.

Utilize the SaaS Agent tools widgets to view the potential risks introduced. These widgets provide insights into the total number of Providers and the Risk Breakdown. Select any provider from the page view to see a detailed breakdown of the following:

Utilize the SaaS Agent tools widgets to view the potential risks introduced. These widgets provide insights into the total number of Providers and the Risk Breakdown. Select any provider from the page view to see a detailed breakdown of the following:

• Overview: Provides detailed information information on the tool Metadata

• Overview: Provides detailed information information on the tool Metadata

• AI Ecosystem: This node-based graph shows the specific Parent Agent and all the Datastores and API connections accessed by the Tool.

• AI Ecosystem: This node-based graph shows the specific Parent Agent and all the Datastores and API connections accessed by the Tool.

• Related Agents: Lists linked agents using this specific tool configuration.

• Related Agents: Lists linked agents using this specific tool configuration.
Show markdown source
```
@@ -1,24 +1,22 @@
 ---
-description: >-
-  SaaS Agent Tools go beyond traditional scans that  focus on an inventory of
-  previously vendor vetted, underlying tools.
+description: View tools connected to SaaS AI agents in Cortex XSIAM.
 ---
 
 # View Agent Tools
 
 The SaaS Agent Tools security page moves beyond assessment of tools to the real security surface the—Tool Wrapper (or "Agent Tool" instance). This is the configuration layer where an agent author defines how a tool is used. This analysis often reveals risks like overprivileged access, or insecure credentialing that arise here and not in the underlying function code.
 
 An Agent Tool is a specific instance of a tool being utilized by a specific agent. It acts as a wrapper that encapsulates:
 
 1. Metadata Aliases: Custom names and descriptions provided by the agent author Configuration Settings: How the tool is pointed at specific data stores or environments
 2. Authentication/Identity: Whether the tool executes using a System Credential, a specific Service Account, or prompts the User on-the-fly.
 
-The SaaS Agent Tool page and dashboard focuses exclusively on posture risks introduced by the misconfiguration of the Agent Tool Wrapper layer.&#x20;
+The SaaS Agent Tool page and dashboard focuses exclusively on posture risks introduced by the misconfiguration of the Agent Tool Wrapper layer.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FEFjdVlNgadB1hh9hGVo3%2Funknown.png?alt=media&#x26;token=ac5762a3-f0a9-4cc6-ad51-8968247b3c00" alt="" height="361" width="624">
 
 Utilize the SaaS Agent tools widgets to view the potential risks introduced. These widgets provide insights into the total number of Providers and the Risk Breakdown. Select any provider from the page view to see a detailed breakdown of the following:
 
 * Overview: Provides detailed information information on the tool Metadata
 * AI Ecosystem: This node-based graph shows the specific Parent Agent and all the Datastores and API connections accessed by the Tool.
 * Related Agents: Lists linked agents using this specific tool configuration.
```
▸ ▾ View AI Agents modified +8 −4 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/manage-saas-ai-agents/view-ai-agents

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,22 +1,26 @@

---

description: View SaaS AI agents in Cortex XSIAM to assess their security context.

---

# View AI Agents

# View AI Agents

AISPM provides you with a holistic view of all the agents deployed in your cloud environments. Start with a high-level view of all the agents deployed across all agentic platforms and drill down further to view all the active agents for a single platform.

AISPM provides you with a holistic view of all the agents deployed in your cloud environments. Start with a high-level view of all the agents deployed across all agentic platforms and drill down further to view all the active agents for a single platform.

### View Agents Security Posture

### View Agents Security Posture

You can view SaaS Agents assets and other actionable data from the SaaS Security Overview page. Follow the steps below to view Agent activity:

You can view SaaS Agents assets and other actionable data from the SaaS Security Overview page. Follow the steps below to view Agent activity:

1. SaaS Agents Overview

1. SaaS Agents Overview

1. Navigate to Home > Modules > SaaS Security > Saas Security Overview.

1. Navigate to Home > Modules > SaaS Security > Saas Security Overview.

2. Hover over the AI Security icon to view Assets at Risk and their severity level, Overprivileged Agents, Agents with Sensitive Data, Inactive Agents.

2. Hover over the AI Security icon to view Assets at Risk and their severity level, Overprivileged Agents, Agents with Sensitive Data, Inactive Agents.

3. Select View Assets to go to the Agents list view.

3. Select View Assets to go to the Agents list view.

4. Navigate to Home > Modules > SaaS Security > AI Agents to view all agents by agentic platform. Click on any agentic platform such as Service Now to view all agents currently deployed. You can further filter this list to double click on activity such dormant periods or delegation authority.

4. Navigate to Home > Modules > SaaS Security > AI Agents to view all agents by agentic platform. Click on any agentic platform such as Service Now to view all agents currently deployed. You can further filter this list to double click on activity such dormant periods or delegation authority.

5. From the all AI Agents list view you can also click on any agent to view all available actions you can take to remediate non-compliant agents.

5. From the all AI Agents list view you can also click on any agent to view all available actions you can take to remediate non-compliant agents.

3. Select the Dashboard link on the AI Agents list view page to be redirected to the complete Asset Inventory dashboard that provides a comprehensive look at all AI Assets including details such as Risk Breakdown, Providers, and Insights.

3. Select the Dashboard link on the AI Agents list view page to be redirected to the complete Asset Inventory dashboard that provides a comprehensive look at all AI Assets including details such as Risk Breakdown, Providers, and Insights.
Show markdown source
```
@@ -1,22 +1,26 @@
+---
+description: View SaaS AI agents in Cortex XSIAM to assess their security context.
+---
+
 # View AI Agents
 
-AISPM provides you with a holistic view of all the agents deployed in your cloud environments. Start with a high-level view of all the agents deployed across all agentic platforms and drill down further to view all the active agents for a single platform.&#x20;
+AISPM provides you with a holistic view of all the agents deployed in your cloud environments. Start with a high-level view of all the agents deployed across all agentic platforms and drill down further to view all the active agents for a single platform.
 
 ### View Agents Security Posture
 
 You can view SaaS Agents assets and other actionable data from the SaaS Security Overview page. Follow the steps below to view Agent activity:
 
 1. SaaS Agents Overview
    1. Navigate to **Home > Modules > SaaS Security > Saas Security Overview**.
    2. Hover over the AI Security icon to view Assets at Risk and their severity level, Overprivileged Agents, Agents with Sensitive Data, Inactive Agents.
-   3. Select **View Assets** to go to the Agents list view.&#x20;
-   4. Navigate to **Home > Modules > SaaS Security > AI Agents** to view all agents by agentic platform. Click on any agentic platform such as Service Now to view all agents currently deployed. You can further filter this list to double click on activity such dormant periods or delegation authority.&#x20;
+   3. Select **View Assets** to go to the Agents list view.
+   4. Navigate to **Home > Modules > SaaS Security > AI Agents** to view all agents by agentic platform. Click on any agentic platform such as Service Now to view all agents currently deployed. You can further filter this list to double click on activity such dormant periods or delegation authority.
    5. From the all AI Agents list view you can also click on any agent to view all available actions you can take to remediate non-compliant agents.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2F2wMvAZrKE6qOFfOJPwGK%2Funknown.png?alt=media&#x26;token=02a835d8-9098-43e3-aca1-9c1c4db6f4cf" alt="" height="393" width="624">
 
-3. Select the Dashboard link on the AI Agents list view page to be redirected to the complete Asset Inventory dashboard that provides a comprehensive look at all AI Assets including details such as Risk Breakdown, Providers, and Insights.&#x20;
+3. Select the Dashboard link on the AI Agents list view page to be redirected to the complete Asset Inventory dashboard that provides a comprehensive look at all AI Assets including details such as Risk Breakdown, Providers, and Insights.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FVWhiJAa3P0dV7xRRIaHg%2Funknown.png?alt=media&#x26;token=12ba98e2-5267-48e5-94bf-45cf14643796" alt="" height="385" width="624">
 
 <br>
```
▸ ▾ View Datasets modified +4 −4 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/manage-saas-ai-agents/view-datasets

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,20 +1,20 @@

---

---

description: The Datasets view provides a detailed look at the Inference Datasets.

description: View inference datasets in Cortex XSIAM SaaS AI Agent Security.

---

---

# View Datasets

# View Datasets

A Dataset is a collection of unseen, raw data, used by SaaS Agents to generate predictions, classifications, or recommendations. The Datasets view within the SaaS Security module (Modules > SaaS Security > Asset Inventory > Datasets) provides an aggregated overview and granular table of Cloud Datasets as well as datasets ingested, generated, or utilized by connected SaaS applications and AI agents.

A Dataset is a collection of unseen, raw data, used by SaaS Agents to generate predictions, classifications, or recommendations. The Datasets view within the SaaS Security module (Modules > SaaS Security > Asset Inventory > Datasets) provides an aggregated overview and granular table of Cloud Datasets as well as datasets ingested, generated, or utilized by connected SaaS applications and AI agents.

The top section contains three analytical widgets summarizing the current security and provider posture of the dataset inventory. Widgets include:

The top section contains three analytical widgets summarizing the current security and provider posture of the dataset inventory. Widgets include:

• Risk Breakdown: Displays the proportion of monitored datasets containing unresolved security vulnerabilities, policy violations, or anomalous access patterns.

• Risk Breakdown: Displays the proportion of monitored datasets containing unresolved security vulnerabilities, policy violations, or anomalous access patterns.

• Providers: Tracks datasets exposed to the public internet or accessible outside authorized organizational boundaries.

• Providers: Tracks datasets exposed to the public internet or accessible outside authorized organizational boundaries.

From the List View you can click on any Dataset to view the entire Agent ecosystem. Select any option below to investigate further:

From the List View you can click on any Dataset to view the entire Agent ecosystem. Select any option below to investigate further:

• Overview: Provides details such as Provider name, Owner, and Descriptions.

• Overview: Provides details such as Provider name, Owner, and Descriptions.

• AI Ecosystem: Provides a graphical view of the tools connected to the Dataset.

• AI Ecosystem: Provides a graphical view of the tools connected to the Dataset.

• Related Agents: Includes agent identity insights, tracking of dormant agents, as well as a breakdown of risks associated with agents connected to the Dataset.

• Related Agents: Includes agent identity insights, tracking of dormant agents, as well as a breakdown of risks associated with agents connected to the Dataset.
Show markdown source
```
@@ -1,20 +1,20 @@
 ---
-description: The Datasets view provides a detailed look at the Inference Datasets.
+description: View inference datasets in Cortex XSIAM SaaS AI Agent Security.
 ---
 
 # View Datasets
 
-A Dataset is a collection of unseen, raw data, used by SaaS Agents to generate predictions, classifications, or recommendations. The Datasets view within the SaaS Security module (**Modules > SaaS Security > Asset Inventory > Datasets**) provides an aggregated overview and granular table of Cloud Datasets as well as datasets ingested, generated, or utilized by connected SaaS applications and AI agents.&#x20;
+A Dataset is a collection of unseen, raw data, used by SaaS Agents to generate predictions, classifications, or recommendations. The Datasets view within the SaaS Security module (**Modules > SaaS Security > Asset Inventory > Datasets**) provides an aggregated overview and granular table of Cloud Datasets as well as datasets ingested, generated, or utilized by connected SaaS applications and AI agents.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2F4lNDIitKkLLLQiikPSQ6%2Funknown.png?alt=media&#x26;token=c3bd45c0-eae2-419b-b32a-c0eaa04bd2b7" alt="" height="361" width="624">
 
 The top section contains three analytical widgets summarizing the current security and provider posture of the dataset inventory. Widgets include:
 
-* Risk Breakdown: Displays the proportion of monitored datasets containing unresolved security vulnerabilities, policy violations, or anomalous access patterns.&#x20;
-* Providers: Tracks datasets exposed to the public internet or accessible outside authorized organizational boundaries.&#x20;
+* Risk Breakdown: Displays the proportion of monitored datasets containing unresolved security vulnerabilities, policy violations, or anomalous access patterns.
+* Providers: Tracks datasets exposed to the public internet or accessible outside authorized organizational boundaries.
 
 From the List View you can click on any Dataset to view the entire Agent ecosystem. Select any option below to investigate further:
 
 * Overview: Provides details such as Provider name, Owner, and Descriptions.
 * AI Ecosystem: Provides a graphical view of the tools connected to the Dataset.
 * Related Agents: Includes agent identity insights, tracking of dormant agents, as well as a breakdown of risks associated with agents connected to the Dataset.
```

▸ Onboard SaaS AI Agents modified +9 −9 The index of supported AI agent platforms now links to broken-reference for every entry. xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,20 +1,20 @@

---

description: Learn more about how to onboard specific AI Agents.

description: Learn how to onboard supported SaaS AI agents in Cortex XSIAM.

---

# Onboard SaaS AI Agents

As you increasingly integrate AI agents—software powered by Large Language Models (LLMs) that connect to your enterprise systems and utilize memory to execute workflows—you also introduce new attack vectors. Effectively onboarding your AI agent platforms into a comprehensive AISPM framework is the critical first step to managing these risks.

Onboard your new and existing SaaS-based agent platforms to establish a secure, compliant cloud environment. Select a specific SaaS AI Agent to onboard:

• Atlassian Rovo

• Box AI Agents

• ChatGPT Enterprise

• Cursor Enterprise

• Gemini Enterprise

• Microsoft 365 Copilot

• Microsoft Copilot Studio

• ServiceNow AI Platform

Show markdown source

@@ -1,20 +1,20 @@
 ---
-description: Learn more about how to onboard specific AI Agents.
+description: Learn how to onboard supported SaaS AI agents in Cortex XSIAM.
 ---
 
 # Onboard SaaS AI Agents
 
 As you increasingly integrate AI agents—software powered by Large Language Models (LLMs) that connect to your enterprise systems and utilize memory to execute workflows—you also introduce new attack vectors. Effectively onboarding your AI agent platforms into a comprehensive AISPM framework is the critical first step to managing these risks.
 
 Onboard your new and existing SaaS-based agent platforms to establish a secure, compliant cloud environment. Select a specific SaaS AI Agent to onboard:
 
-* [Atlassian Rovo](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-atlassian-rovo)
-* [Box AI Agents](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-box-ai-agents)
-* [ChatGPT Enterprise](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-chatgpt-enterprise)
-* [Cursor Enterprise](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-cursor-enterprise)
-* [Gemini Enterprise](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-gemini-enterprise)
-* [Microsoft 365 Copilot](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-m365-copilot)
-* [Microsoft Copilot Studio](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-microsoft-copilot-studio)
-* [ServiceNow AI Platform](../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-service-now)
+* [Atlassian Rovo](broken-reference)
+* [Box AI Agents](broken-reference)
+* [ChatGPT Enterprise](broken-reference)
+* [Cursor Enterprise](broken-reference)
+* [Gemini Enterprise](broken-reference)
+* [Microsoft 365 Copilot](broken-reference)
+* [Microsoft Copilot Studio](broken-reference)
+* [ServiceNow AI Platform](broken-reference)
 
 <br>

▸ ▾ Onboard Atlassian Rovo modified +5 −7 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-atlassian-rovo

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,41 +1,39 @@

---

---

description: >-

description: >-

Connect Atlassian Rovo to SaaS Agent Security to gain total visibility and

Connect Atlassian Rovo in Cortex XSIAM SaaS Agent Security for visibility and

control over your AI ecosystem.

control across your AI ecosystem.

---

---

# Onboard Atlassian Rovo

# Onboard Atlassian Rovo

To access your Atlassian instance, AISPM requires the following information, which you will specify during the onboarding process.

To access your Atlassian instance, AISPM requires the following information, which you will specify during the onboarding process.

Admin Email│The login email address of the Atlassian Org Admin who created the API token and API key.

Admin Email│The login email address of the Atlassian Org Admin who created the API token and API key.

| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

API Token│A token, generated by an Atlassian Org Admin, enables SSPM to authenticate to the administrator account.

API Token│A token, generated by an Atlassian Org Admin, enables SSPM to authenticate to the administrator account.

API Key│A key, generated by an Atlassian Org Admin, that enables SSPM to scan and update organization settings and user accounts. SSPM uses this key to identify and manage the third-party plugins that users have connected to Jira or Confluence.

API Key│A key, generated by an Atlassian Org Admin, that enables SSPM to scan and update organization settings and user accounts. SSPM uses this key to identify and manage the third-party plugins that users have connected to Jira or Confluence.

Organization ID│A unique, automatically generated identifier for your Atlassian Cloud account, serving as the primary identifier for managing users, products, billing, and settings centrally within the Atlassian ecosystem. Unlike organization names, which aren't unique, the Organization ID guarantees each organization has its own distinct identifier for use in the URL, API, and various integrations.

Organization ID│A unique, automatically generated identifier for your Atlassian Cloud account, serving as the primary identifier for managing users, products, billing, and settings centrally within the Atlassian ecosystem. Unlike organization names, which aren't unique, the Organization ID guarantees each organization has its own distinct identifier for use in the URL, API, and various integrations.

1. Generate and Copy an Administrator API Token.

1. Generate and Copy an Administrator API Token.

1. Log in to Atlassian using Org Admin credentials.

1. Log in to Atlassian using Org Admin credentials.

2. From the Atlassian account profile, navigate to the API tokens page for the account (select Security > Create and manage API tokens or go to id.atlassian.com/manage-profile/security/api-tokens).

2. From the Atlassian account profile, navigate to the API tokens page for the account (select Security > Create and manage API tokens or go to id.atlassian.com/manage-profile/security/api-tokens).

3. Click Create API Token.

3. Click Create API Token.

4. Specify a name and an expiry date for your API token and click Create.

4. Specify a name and an expiry date for your API token and click Create.

5. Copy the generated API token. Do not continue to the next step unless you have copied it, as you must provide this token during the onboarding process.

5. Copy the generated API token. Do not continue to the next step unless you have copied it, as you must provide this token during the onboarding process.

2. Generate and Copy an API Key and an Organization ID.

2. Generate and Copy an API Key and an Organization ID.

1. Log in to the Atlassian Admin Portal (admin.atlassian.com) using Org Admin credentials.

1. Log in to the Atlassian Admin Portal (admin.atlassian.com) using Org Admin credentials.

2. If you administer more than one Atlassian organization, select the organization you want SSPM to scan.

2. If you administer more than one Atlassian organization, select the organization you want SSPM to scan.

3. Select Organization settings > API keys.

3. Select Organization settings > API keys.

4. Click Create API key.

4. Click Create API key.

5. In the "Before you begin" page, choose "API key without scopes" and click Next.

5. In the "Before you begin" page, choose "API key without scopes" and click Next.

6. Specify a name and an expiry date for the key and click Next.

6. Specify a name and an expiry date for the key and click Next.

7. Review your API Key details and click Create API key.

7. Review your API Key details and click Create API key.

8. Copy the Organization ID and the API key. Do not continue to the next step unless you have copied both, as you must provide this information during the onboarding process.

8. Copy the Organization ID and the API key. Do not continue to the next step unless you have copied both, as you must provide this information during the onboarding process.

3. Onboard Atlassian Rovo Platform to Cortex.

3. Onboard Atlassian Rovo Platform to Cortex.

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Atlassian connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Atlassian connector.

3. Click on the Atlassian tile and select the Add Another Instance.

3. Click on the Atlassian tile and select the Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select the Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select the Agent Security scanning capability.

5. Under Connections, provide Admin Email and Organization ID to authorize the connection. In addition, under Agent Security Scanning, provide the API Key and API Token to authenticate the application.

5. Under Connections, provide Admin Email and Organization ID to authorize the connection. In addition, under Agent Security Scanning, provide the API Key and API Token to authenticate the application.

6. Once Cortex validates the credentials and permissions, the onboarding process is complete.

6. Once Cortex validates the credentials and permissions, the onboarding process is complete.

4. Validation and Scanning: Cortex will immediately begin scanning your onboarded platform. Note that scan time varies based on the amount of data; it takes at least one hour to display data in the AISPM dashboard.

4. Validation and Scanning: Cortex will immediately begin scanning your onboarded platform. Note that scan time varies based on the amount of data; it takes at least one hour to display data in the AISPM dashboard.
Show markdown source
```
@@ -1,41 +1,39 @@
 ---
 description: >-
-  Connect Atlassian Rovo to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect Atlassian Rovo in Cortex XSIAM SaaS Agent Security for visibility and
+  control across your AI ecosystem.
 ---
 
 # Onboard Atlassian Rovo
 
 To access your Atlassian instance, AISPM requires the following information, which you will specify during the onboarding process.
 
 | Admin Email     | <p>The login email address of the Atlassian Org Admin who created the API token and API key.</p><p><br></p>                                                                                                                                                                                                                                                                                        |
 | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | API Token       | A token, generated by an Atlassian Org Admin, enables SSPM to authenticate to the administrator account.                                                                                                                                                                                                                                                                                           |
 | API Key         | A key, generated by an Atlassian Org Admin, that enables SSPM to scan and update organization settings and user accounts. SSPM uses this key to identify and manage the third-party plugins that users have connected to Jira or Confluence.                                                                                                                                                       |
 | Organization ID | A unique, automatically generated identifier for your Atlassian Cloud account, serving as the primary identifier for managing users, products, billing, and settings centrally within the Atlassian ecosystem. Unlike organization names, which aren't unique, the Organization ID guarantees each organization has its own distinct identifier for use in the URL, API, and various integrations. |
 
-
-
 1. Generate and Copy an Administrator API Token.
    1. Log in to Atlassian using Org Admin credentials.
    2. From the Atlassian account profile, navigate to the API tokens page for the account (select Security > Create and manage API tokens or go to [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens)).
    3. Click Create API Token.
    4. Specify a name and an expiry date for your API token and click Create.
    5. Copy the generated API token. Do not continue to the next step unless you have copied it, as you must provide this token during the onboarding process.
 2. Generate and Copy an API Key and an Organization ID.
    1. Log in to the [Atlassian Admin Portal](http://admin.atlassian.com/) (admin.atlassian.com) using Org Admin credentials.
    2. If you administer more than one Atlassian organization, select the organization you want SSPM to scan.
    3. Select Organization settings > API keys.
    4. Click Create API key.
    5. In the "Before you begin" page, choose "API key without scopes" and click Next.
    6. Specify a name and an expiry date for the key and click Next.
    7. Review your API Key details and click Create API key.
    8. Copy the Organization ID and the API key. Do not continue to the next step unless you have copied both, as you must provide this information during the onboarding process.
 3. Onboard Atlassian Rovo Platform to Cortex.
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the Atlassian connector.
-   3. Click on the Atlassian tile and select the Add Another Instance.&#x20;
-   4. On the **Capabilities** page, provide an Instance Name and select the Agent Security scanning capability.&#x20;
+   3. Click on the Atlassian tile and select the Add Another Instance.
+   4. On the **Capabilities** page, provide an Instance Name and select the Agent Security scanning capability.
    5. Under **Connections**, provide **Admin Email** and **Organization ID** to authorize the connection. In addition, under **Agent Security Scanning**, provide the API Key and API Token to authenticate the application.
    6. Once Cortex validates the credentials and permissions, the onboarding process is complete.
 4. **Validation and Scanning**: Cortex will immediately begin scanning your onboarded platform. Note that scan time varies based on the amount of data; it takes at least one hour to display data in the AISPM dashboard.
```
▸ ▾ Onboard Box AI Agents modified +6 −6 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-box-ai-agents

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,28 +1,28 @@

---

---

description: >-

description: >-

Connect Box AI Agents to SaaS Agent Security to gain total visibility and

Connect Box AI Agents in Cortex XSIAM SaaS Agent Security for visibility and

control over your AI ecosystem.

control across your AI ecosystem.

---

---

# Onboard Box AI Agents

# Onboard Box AI Agents

Prerequisites

Prerequisites

• Ensure you have the necessary administrative privileges in your Box instance, including the ability to access the Admin and Dev console.

• Ensure you have the necessary administrative privileges in your Box instance, including the ability to access the Admin and Dev console.

• To access Box AI Studio and start building custom agents, your organization must have a Box - Enterprise Advanced license. If you would like to explore these capabilities, coordinate with your IT Administrator or Box Sales representative to ensure the proper licensing is in place.

• To access Box AI Studio and start building custom agents, your organization must have a Box - Enterprise Advanced license. If you would like to explore these capabilities, coordinate with your IT Administrator or Box Sales representative to ensure the proper licensing is in place.

Note: Box AI Studio is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.

Note: Box AI Studio is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.

• Ensure you have enabled Box AI. To do this, go to your Box instance > Box AI > Settings and click Enable Box AI.

• Ensure you have enabled Box AI. To do this, go to your Box instance > Box AI > Settings and click Enable Box AI.

1. Create and Configure a Custom Box App

1. Create and Configure a Custom Box App

1. Sign in to your Box instance.

1. Sign in to your Box instance.

2. From the left navigation pane, select Dev Console > Create Platform App > Custom App.

2. From the left navigation pane, select Dev Console > Create Platform App > Custom App.

3. On the Custom App page, enter the following information:

3. On the Custom App page, enter the following information:

1. Give a suitable App Name.

1. Give a suitable App Name.

2. Give a suitable Description (optional).

2. Give a suitable Description (optional).

3. For Purpose, choose Automation from the drop-down and click Next.

3. For Purpose, choose Automation from the drop-down and click Next.

4. Select Server Authentication (Client Credentials Grant) for the authentication method and click Create App.

4. Select Server Authentication (Client Credentials Grant) for the authentication method and click Create App.

5. On the newly created app page, select the Configuration tab.

5. On the newly created app page, select the Configuration tab.

6. In the OAuth 2.0 Credentials section, copy the Client ID and the Client Secret (Fetch Client Secret) and keep it handy for use during onboarding.

6. In the OAuth 2.0 Credentials section, copy the Client ID and the Client Secret (Fetch Client Secret) and keep it handy for use during onboarding.

7. In the App Access Level section, choose App+Enterprise Access.

7. In the App Access Level section, choose App+Enterprise Access.

@@ -38,15 +38,15 @@ description: >-

2. On the Server Authentication Apps list, find the app you created and select ... > Authorize App > Authorize.

2. On the Server Authentication Apps list, find the app you created and select ... > Authorize App > Authorize.

3. Retrieve the Enterprise ID

3. Retrieve the Enterprise ID

1. Go Back to My Account > Dev Console and select the app you created.

1. Go Back to My Account > Dev Console and select the app you created.

2. Copy the Enterprise ID (available in the General Settings tab).

2. Copy the Enterprise ID (available in the General Settings tab).

**Note**: Ensure you repeat the authorization process again if you modify any settings during configuration.

**Note**: Ensure you repeat the authorization process again if you modify any settings during configuration.

4. Onboard Box AI Agents to Cortex:

4. Onboard Box AI Agents to Cortex:

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Box connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Box connector.

3. You may find multiple Box tiles, select the Box titled Box integration for SaaS Data and Posture Security for Box. Click on the tile and select the Add Another Instance.

3. You may find multiple Box tiles, select the Box titled Box integration for SaaS Data and Posture Security for Box. Click on the tile and select the Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select the Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select the Agent Security scanning capability.

5. On the Connections page, provide your Instance URL and select the Recommended authentication method. Provide your Client ID and Client Secret for the authentication flow.

5. On the Connections page, provide your Instance URL and select the Recommended authentication method. Provide your Client ID and Client Secret for the authentication flow.

6. Once Cortex validates the credentials and permissions, the onboarding process is complete.

6. Once Cortex validates the credentials and permissions, the onboarding process is complete.

5. Validation and Scanning: Cortex validates the credentials and permissions. After the validation is successful, you will see a confirmation message. Scanning begins immediately after a successful validation. The amount of time Cortex takes to scan varies based on the amount of scan data. At a minimum, it takes at least one hour to scan and display data in the Cortex dashboard.

5. Validation and Scanning: Cortex validates the credentials and permissions. After the validation is successful, you will see a confirmation message. Scanning begins immediately after a successful validation. The amount of time Cortex takes to scan varies based on the amount of scan data. At a minimum, it takes at least one hour to scan and display data in the Cortex dashboard.
Show markdown source
```
@@ -1,28 +1,28 @@
 ---
 description: >-
-  Connect Box AI Agents to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect Box AI Agents in Cortex XSIAM SaaS Agent Security for visibility and
+  control across your AI ecosystem.
 ---
 
 # Onboard Box AI Agents
 
 **Prerequisites**
 
 * Ensure you have the necessary administrative privileges in your Box instance, including the ability to access the Admin and Dev console.
 * To access Box AI Studio and start building custom agents, your organization must have a Box - Enterprise Advanced license. If you would like to explore these capabilities, coordinate with your IT Administrator or Box Sales representative to ensure the proper licensing is in place.
 
 **Note**: Box AI Studio is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.
 
 * Ensure you have enabled Box AI. To do this, go to your **Box instance > Box AI > Settings** and click **Enable Box AI**.
 
 1. Create and Configure a Custom Box App
    1. Sign in to your Box instance.
-   2. From the left navigation pane, select Dev Console > Create Platform App > Custom App.&#x20;
+   2. From the left navigation pane, select Dev Console > Create Platform App > Custom App.
    3. On the Custom App page, enter the following information:
       1. Give a suitable App Name.
       2. Give a suitable Description (optional).
       3. For Purpose, choose Automation from the drop-down and click Next.
    4. Select Server Authentication (Client Credentials Grant) for the authentication method and click Create App.
    5. On the newly created app page, select the Configuration tab.
    6. In the OAuth 2.0 Credentials section, copy the Client ID and the Client Secret (Fetch Client Secret) and keep it handy for use during onboarding.
    7. In the App Access Level section, choose App+Enterprise Access.
@@ -38,15 +38,15 @@ description: >-
    2. On the Server Authentication Apps list, find the app you created and select ... > Authorize App > Authorize.
 3.  Retrieve the Enterprise ID
 
     1. Go Back to My Account > Dev Console and select the app you created.
     2. Copy the Enterprise ID (available in the General Settings tab).
 
     **Note**: Ensure you repeat the authorization process again if you modify any settings during configuration.
 4. Onboard Box AI Agents to Cortex:
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the Box connector.
-   3. You may find multiple Box tiles, select the Box titled **Box integration for SaaS Data** and **Posture Security for Box**. Click on the tile and select the Add Another Instance.&#x20;
-   4. On the **Capabilities** page, provide an Instance Name and select the Agent Security scanning capability.&#x20;
+   3. You may find multiple Box tiles, select the Box titled **Box integration for SaaS Data** and **Posture Security for Box**. Click on the tile and select the Add Another Instance.
+   4. On the **Capabilities** page, provide an Instance Name and select the Agent Security scanning capability.
    5. On the **Connections** page, provide your Instance URL and select the Recommended authentication method. Provide your Client ID and Client Secret for the authentication flow.
    6. Once Cortex validates the credentials and permissions, the onboarding process is complete.
 5. **Validation and Scanning**: Cortex validates the credentials and permissions. After the validation is successful, you will see a confirmation message. Scanning begins immediately after a successful validation. The amount of time Cortex takes to scan varies based on the amount of scan data. At a minimum, it takes at least one hour to scan and display data in the Cortex dashboard.
```
▸ ▾ Onboard ChatGPT Enterprise modified +5 −5 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-chatgpt-enterprise

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,38 +1,38 @@

---

---

description: >-

description: >-

Connect Box AI Agents to SaaS Agent Security to gain total visibility and

Connect ChatGPT Enterprise in Cortex XSIAM SaaS Agent Security for visibility

control over your AI ecosystem.

and control across your AI ecosystem.

---

---

# Onboard ChatGPT Enterprise

# Onboard ChatGPT Enterprise

1. ChatGPT Enterprise & OpenAI Configuration

1. ChatGPT Enterprise & OpenAI Configuration

1. Sign in to your ChatGPT Enterprise instance.

1. Sign in to your ChatGPT Enterprise instance.

2. Fetch the Organization ID and Workspace ID from ChatGPT Settings:

2. Fetch the Organization ID and Workspace ID from ChatGPT Settings:

1. Select ChatGPT > Manage Workspace > Settings and keep them handy.

1. Select ChatGPT > Manage Workspace > Settings and keep them handy.

3. To fetch the Secret Key, go to the OpenAI API-Keys site and click + Create new secret key.

3. To fetch the Secret Key, go to the OpenAI API-Keys site and click + Create new secret key.

1. In the Create new secret key page, enter the required details and click Create secret key.

1. In the Create new secret key page, enter the required details and click Create secret key.

2. During key generation, ensure that the Permissions is set to All. (OpenAI will revoke it in the subsequent steps).

2. During key generation, ensure that the Permissions is set to All. (OpenAI will revoke it in the subsequent steps).

4. Ensure that this key is generated in the same Organization as your ChatGPT tenant. To confirm this, select Settings on the OpenAI website and ensure the Org ID is the same as what you fetched previously.

4. Ensure that this key is generated in the same Organization as your ChatGPT tenant. To confirm this, select Settings on the OpenAI website and ensure the Org ID is the same as what you fetched previously.

5. Copy the new key and keep it handy.

5. Copy the new key and keep it handy.

6. To enable the generated key for the Compliance API scopes, send an email to support@openai.com with the following information:

6. To enable the generated key for the Compliance API scopes, send an email to support@openai.com with the following information:

1. Last 4 characters of the generated API Key

1. Last 4 characters of the generated API Key

2. Key Name

2. Key Name

3. Created By Name

3. Created By Name

4. Requested Scope - Read. Ensure that the generated key is unique for AISPM and not used in any other product. For example, you cannot use the same key for both Data Security and AISPM since the scope is different for both of them.

4. Requested Scope - Read. Ensure that the generated key is unique for AISPM and not used in any other product. For example, you cannot use the same key for both Data Security and AISPM since the scope is different for both of them.

5. Organization ID

5. Organization ID

**Note**: Further instructions are available in the ChatGPT API Reference.

**Note**: Further instructions are available in the ChatGPT API Reference.

2. After OpenAI enables the key for the Compliance API, proceed to add the ChatGPT Enterprise connector.

2. After OpenAI enables the key for the Compliance API, proceed to add the ChatGPT Enterprise connector.

3. Onboarding ChatGPT to Cortex:

3. Onboarding ChatGPT to Cortex:

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the ChatGPT connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the ChatGPT connector.

3. Click on the ChatGPT tile and select the Add Another Instance.

3. Click on the ChatGPT tile and select the Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

5. On the Connections page, provide your Instance URL and select the Recommended authentication method, enter the following information (that you gathered in the steps above and click Complete:

5. On the Connections page, provide your Instance URL and select the Recommended authentication method, enter the following information (that you gathered in the steps above and click Complete:

1. Organization ID

1. Organization ID

2. Workspace ID

2. Workspace ID

3. API Key

3. API Key

6. Once Cortex validates the credentials and permissions, the onboarding process is complete.

6. Once Cortex validates the credentials and permissions, the onboarding process is complete.

4. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. After the validation is successful, you will see a confirmation message. Scan periods vary based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.

4. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. After the validation is successful, you will see a confirmation message. Scan periods vary based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
Show markdown source
```
@@ -1,38 +1,38 @@
 ---
 description: >-
-  Connect Box AI Agents to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect ChatGPT Enterprise in Cortex XSIAM SaaS Agent Security for visibility
+  and control across your AI ecosystem.
 ---
 
 # Onboard ChatGPT Enterprise
 
 1. ChatGPT Enterprise & OpenAI Configuration
    1. Sign in to your ChatGPT Enterprise instance.
    2. Fetch the Organization ID and Workspace ID from ChatGPT Settings:
       1. Select ChatGPT > Manage Workspace > Settings and keep them handy.
    3. To fetch the Secret Key, go to the OpenAI API-Keys site and click + Create new secret key.
       1. In the Create new secret key page, enter the required details and click Create secret key.
-      2. &#x20;During key generation, ensure that the Permissions is set to All. (OpenAI will revoke it in the subsequent steps).
+      2. During key generation, ensure that the Permissions is set to All. (OpenAI will revoke it in the subsequent steps).
    4. Ensure that this key is generated in the same Organization as your ChatGPT tenant. To confirm this, select Settings on the OpenAI website and ensure the Org ID is the same as what you fetched previously.
    5. Copy the new key and keep it handy.
    6.  To enable the generated key for the Compliance API scopes, send an email to support@openai.com with the following information:
 
        1. Last 4 characters of the generated API Key
        2. Key Name
        3. Created By Name
        4. Requested Scope - Read. Ensure that the generated key is unique for AISPM and not used in any other product. For example, you cannot use the same key for both Data Security and AISPM since the scope is different for both of them.
        5. Organization ID
 
        **Note**: Further instructions are available in the ChatGPT API Reference.
 2. After OpenAI enables the key for the Compliance API, proceed to add the ChatGPT Enterprise connector.
 3. Onboarding ChatGPT to Cortex:
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select **Settings > Data Sources and Integrations > Add New.** You can use the Search bar to find the ChatGPT connector.
-   3. Click on the ChatGPT tile and select the **Add Another Instance**.&#x20;
+   3. Click on the ChatGPT tile and select the **Add Another Instance**.
    4. On the **Capabilities** page, provide an Instance Name and select Agent Security scanning capability.
    5. On the **Connections** page, provide your Instance URL and select the Recommended authentication method, enter the following information (that you gathered in the steps above and click Complete:
       1. Organization ID
       2. Workspace ID
       3. API Key
    6. Once Cortex validates the credentials and permissions, the onboarding process is complete.
 4. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. After the validation is successful, you will see a confirmation message. Scan periods vary based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
```
▸ ▾ Onboard Cursor Enterprise modified +4 −6 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-cursor-enterprise

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,25 +1,23 @@

---

---

description: >-

description: >-

Connect Cursor Enterprise to SaaS Agent Security to gain total visibility and

Connect Cursor Enterprise in Cortex XSIAM SaaS Agent Security for visibility

control over your AI ecosystem.

and control across your AI ecosystem.

---

---

# Onboard Cursor Enterprise

# Onboard Cursor Enterprise

Cursor Enterprise is the secure, scalable version of Cursor, an AI-powered code editor built on VS Code. It is designed for large organizations needing advanced features like SSO, audit logs, usage analytics, and data privacy controls to manage AI-assisted software development for complex codebases. It provides features such as IP allowlisting, team management, centralized security, and compliance tools (GDPR, CCPA, SOC 2) to meet enterprise security and governance needs, allowing teams to build faster and more efficiently.

Cursor Enterprise is the secure, scalable version of Cursor, an AI-powered code editor built on VS Code. It is designed for large organizations needing advanced features like SSO, audit logs, usage analytics, and data privacy controls to manage AI-assisted software development for complex codebases. It provides features such as IP allowlisting, team management, centralized security, and compliance tools (GDPR, CCPA, SOC 2) to meet enterprise security and governance needs, allowing teams to build faster and more efficiently.

Important: Due to Cursor Enterprise API restrictions, any discovery for Tools and Knowledge Bases is limited to the last 30 days. If you want to increase this duration, contact Technical Support.

Important: Due to Cursor Enterprise API restrictions, any discovery for Tools and Knowledge Bases is limited to the last 30 days. If you want to increase this duration, contact Technical Support.

1. Create an Admin API Key in Cursor Enterprise.

1. Create an Admin API Key in Cursor Enterprise.

1. Go to the Cursor Enterprise dashboard and select Settings > API Keys > New API Key.

1. Go to the Cursor Enterprise dashboard and select Settings > API Keys > New API Key.

2. Copy the generated Admin API Key and keep it handy for the onboarding steps.

2. Copy the generated Admin API Key and keep it handy for the onboarding steps.

2. Onboard Cursor Enterprise to Cortex.

2. Onboard Cursor Enterprise to Cortex.

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Cursor connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Cursor connector.

3. Click on the Cursor tile and select Add Another Instance.

3. Click on the Cursor tile and select Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

5. On the Connections page, provide your Instance URL and enter your API Key to initiate the authentication flow.

5. On the Connections page, provide your Instance URL and enter your API Key to initiate the authentication flow.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

3. Validation and Scanning: Cortex establishes the connection and validates the credentials and permissions. After successful validation, you will see a confirmation message. The amount of time Cortex takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.

3. Validation and Scanning: Cortex establishes the connection and validates the credentials and permissions. After successful validation, you will see a confirmation message. The amount of time Cortex takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
Show markdown source
```
@@ -1,25 +1,23 @@
 ---
 description: >-
-  Connect Cursor Enterprise to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect Cursor Enterprise in Cortex XSIAM SaaS Agent Security for visibility
+  and control across your AI ecosystem.
 ---
 
 # Onboard Cursor Enterprise
 
 Cursor Enterprise is the secure, scalable version of Cursor, an AI-powered code editor built on VS Code. It is designed for large organizations needing advanced features like SSO, audit logs, usage analytics, and data privacy controls to manage AI-assisted software development for complex codebases. It provides features such as IP allowlisting, team management, centralized security, and compliance tools (GDPR, CCPA, SOC 2) to meet enterprise security and governance needs, allowing teams to build faster and more efficiently.
 
 **Important**: Due to Cursor Enterprise API restrictions, any discovery for Tools and Knowledge Bases is limited to the last 30 days. If you want to increase this duration, contact Technical Support.
 
-
-
 1. Create an Admin API Key in Cursor Enterprise.
    1. Go to the Cursor Enterprise dashboard and select Settings > API Keys > New API Key.
    2. Copy the generated Admin API Key and keep it handy for the onboarding steps.
 2. Onboard Cursor Enterprise to Cortex.
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the Cursor connector.
-   3. Click on the Cursor tile and select **Add Another Instance**.&#x20;
+   3. Click on the Cursor tile and select **Add Another Instance**.
    4. On the **Capabilities** page, provide an Instance Name and select Agent Security scanning capability.
    5. On the **Connections** page, provide your Instance URL and enter your API Key to initiate the authentication flow.
    6. Once AISPM validates the credentials and permissions, the onboarding process is complete.
 3. Validation and Scanning: Cortex establishes the connection and validates the credentials and permissions. After successful validation, you will see a confirmation message. The amount of time Cortex takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
```
▸ ▾ Onboard Gemini Enterprise modified +6 −14 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-gemini-enterprise

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,44 +1,36 @@

---

---

description: >-

description: >-

Connect Gemini Enterprise to SaaS Agent Security to gain total visibility and

Connect Gemini Enterprise in Cortex XSIAM SaaS Agent Security for visibility

control over your AI ecosystem.

and control across your AI ecosystem.

---

---

# Onboard Gemini Enterprise

# Onboard Gemini Enterprise

Gemini allows employees to use pre-built agents or create their own custom agents to perform tasks, analyze data, and automate workflows by securely connecting to company data and applications like Google Workspace and Salesforce. The platform aims to shift employees from tedious tasks to high-impact work while providing central governance and security.

Gemini allows employees to use pre-built agents or create their own custom agents to perform tasks, analyze data, and automate workflows by securely connecting to company data and applications like Google Workspace and Salesforce. The platform aims to shift employees from tedious tasks to high-impact work while providing central governance and security.

To access your Gemini Enterprise instance, AISPM requires the following specific information during the configuration process:

To access your Gemini Enterprise instance, AISPM requires the following specific information during the configuration process:

Item│Description

Item│Description

| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

Service Account Email│A service account email in Gemini Enterprise is a special non-human account. Applications and virtual machines use this account to authenticate and access Google Cloud resources securely. It provides a secure identity for programmatic access to the Gemini for Google Cloud API and related services.

Service Account Email│A service account email in Gemini Enterprise is a special non-human account. Applications and virtual machines use this account to authenticate and access Google Cloud resources securely. It provides a secure identity for programmatic access to the Gemini for Google Cloud API and related services.

Project ID│A Project ID in Gemini Enterprise is a unique identifier for a Google Cloud project. Gemini Enterprise uses the Google Cloud platform, so its services and resources are organized within the same project structure. A Project ID is needed for authentication, billing, and access control when working with Gemini models and related services.

Project ID│A Project ID in Gemini Enterprise is a unique identifier for a Google Cloud project. Gemini Enterprise uses the Google Cloud platform, so its services and resources are organized within the same project structure. A Project ID is needed for authentication, billing, and access control when working with Gemini models and related services.

Location│In Google Cloud's Gemini Enterprise, a "location" is a specific geographic area for creating, processing, and storing data. Location selection allows enterprises to control data residency. This control is important for data privacy, compliance, and meeting requirements in different regions.

Note: New locations created by Gemini Enterprise will be added by AISPM in a phased manner.

Location│In Google Cloud's Gemini Enterprise, a "location" is a specific geographic area for creating, processing, and storing data. Location selection allows enterprises to control data residency. This control is important for data privacy, compliance, and meeting requirements in different regions.

Note: New locations created by Gemini Enterprise will be added by AISPM in a phased manner.

1. Configure Google Cloud Console.

1. Configure Google Cloud Console.

1. Go to your project home page (where you developed your agent) in the Google Cloud console. Copy your project ID and project number and keep it handy for onboarding later.

1. Go to your project home page (where you developed your agent) in the Google Cloud console. Copy your project ID and project number and keep it handy for onboarding later.

2. From the Google Cloud console, select Menu > APIs & Services > Enabled APIs & Services > +Enable APIs and services.

2. From the Google Cloud console, select Menu > APIs & Services > Enabled APIs & Services > +Enable APIs and services.

3. To create a new service account, select Menu > IAM & Admin > Service Accounts > +Create service account.

3. To create a new service account, select Menu > IAM & Admin > Service Accounts > +Create service account.

4. In the list of service accounts, click on the service account that you just created. The service account details are displayed. Copy the service account email address and keep it handy for onboarding later.

4. In the list of service accounts, click on the service account that you just created. The service account details are displayed. Copy the service account email address and keep it handy for onboarding later.

5. Select Principals with access > View by principals > Grant access.

5. Select Principals with access > View by principals > Grant access.

6. In the Add principals section, specify the name of the principal.

6. In the Add principals section, specify the name of the principal.

7. In the Assign roles section, select the Service Account Token Creator role and click Save.

7. In the Assign roles section, select the Service Account Token Creator role and click Save.

2. Onboard Platform to AISPM

2. Onboard Platform to AISPM

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Gemini Enterprise connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Gemini Enterprise connector.

3. Click on the Gemini Enterprise tile and select Add Another Instance.

3. Click on the Gemini Enterprise tile and select Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

5. On the Connections page enter the following information that you gathered in Step 1:

5. On the Connections page enter the following information that you gathered in Step 1:

1. Project ID (You can use either the project ID or the project number.)

1. Project ID (You can use either the project ID or the project number.)

2. Service Account Email

2. Service Account Email

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

3. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. Cortex immediately begins to scan your onboarded agentic platform after a successful validation. The amount of time Cortex takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.

3. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. Cortex immediately begins to scan your onboarded agentic platform after a successful validation. The amount of time Cortex takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
Show markdown source
```
@@ -1,44 +1,36 @@
 ---
 description: >-
-  Connect Gemini Enterprise to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect Gemini Enterprise in Cortex XSIAM SaaS Agent Security for visibility
+  and control across your AI ecosystem.
 ---
 
 # Onboard Gemini Enterprise
 
 Gemini allows employees to use pre-built agents or create their own custom agents to perform tasks, analyze data, and automate workflows by securely connecting to company data and applications like Google Workspace and Salesforce. The platform aims to shift employees from tedious tasks to high-impact work while providing central governance and security.
 
 To access your Gemini Enterprise instance, AISPM requires the following specific information during the configuration process:
 
-
-
 | Item                  | Description                                                                                                                                                                                                                                                                                                                                                                                                  |
 | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | Service Account Email | A service account email in Gemini Enterprise is a special non-human account. Applications and virtual machines use this account to authenticate and access Google Cloud resources securely. It provides a secure identity for programmatic access to the Gemini for Google Cloud API and related services.                                                                                                   |
 | Project ID            | A Project ID in Gemini Enterprise is a unique identifier for a Google Cloud project. Gemini Enterprise uses the Google Cloud platform, so its services and resources are organized within the same project structure. A Project ID is needed for authentication, billing, and access control when working with Gemini models and related services.                                                           |
 | Location              | <p>In Google Cloud's Gemini Enterprise, a "location" is a specific geographic area for creating, processing, and storing data. Location selection allows enterprises to control data residency. This control is important for data privacy, compliance, and meeting requirements in different regions.</p><p>Note: New locations created by Gemini Enterprise will be added by AISPM in a phased manner.</p> |
 
 1. Configure Google Cloud Console.
    1. Go to your project home page (where you developed your agent) in the Google Cloud console. Copy your project ID and project number and keep it handy for onboarding later.
    2. From the Google Cloud console, select Menu > APIs & Services > Enabled APIs & Services > +Enable APIs and services.
    3. To create a new service account, select Menu > IAM & Admin > Service Accounts > +Create service account.
    4. In the list of service accounts, click on the service account that you just created. The service account details are displayed. Copy the service account email address and keep it handy for onboarding later.
    5. Select Principals with access > View by principals > Grant access.
    6. In the Add principals section, specify the name of the principal.
    7. In the Assign roles section, select the Service Account Token Creator role and click Save.
-
-
-
 2. Onboard Platform to AISPM
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Gemini Enterprise connector.
-   3. Click on the Gemini Enterprise tile and select Add Another Instance.&#x20;
-   4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.&#x20;
+   3. Click on the Gemini Enterprise tile and select Add Another Instance.
+   4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.
    5. On the Connections page enter the following information that you gathered in Step 1:
       1. Project ID (You can use either the project ID or the project number.)
       2. Service Account Email
    6. Once AISPM validates the credentials and permissions, the onboarding process is complete.
-
-
-
-3. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. Cortex  immediately begins to scan your onboarded agentic platform after a successful validation. The amount of time Cortex  takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
+3. Validation and Scanning: Cortex establishes the API connection and validates the credentials and permissions. Cortex immediately begins to scan your onboarded agentic platform after a successful validation. The amount of time Cortex takes to scan varies based on the amount of data it is required to scan. At a minimum, it takes at least one hour to scan and display data in the AISPM dashboard.
```
▸ ▾ Onboard M365 Copilot modified +6 −8 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-m365-copilot

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,34 +1,32 @@

---

---

description: >-

description: >-

Connect M365 Copilot to SaaS Agent Security to gain total visibility and

Connect M365 Copilot in Cortex XSIAM SaaS Agent Security for visibility and

control over your AI ecosystem.

control across your AI ecosystem.

---

---

# Onboard M365 Copilot

# Onboard M365 Copilot

Microsoft 365 Copilot is an AI-powered assistant integrated into Word, Excel, PowerPoint, Outlook, Teams, and other Microsoft 365 apps. It uses Large Language Models (LLMs) and your organization's data to help with tasks like drafting content, analyzing data, summarizing meetings, and generating ideas. It acts as a "copilot" by streamlining workflows, boosting creativity, and increasing productivity by turning natural language prompts into actions and insights within your familiar work environment.

Microsoft 365 Copilot is an AI-powered assistant integrated into Word, Excel, PowerPoint, Outlook, Teams, and other Microsoft 365 apps. It uses Large Language Models (LLMs) and your organization's data to help with tasks like drafting content, analyzing data, summarizing meetings, and generating ideas. It acts as a "copilot" by streamlining workflows, boosting creativity, and increasing productivity by turning natural language prompts into actions and insights within your familiar work environment.

Prerequisites

Prerequisites

• To access M365 Copilot and start building custom agents, your organization must have a Microsoft 365 Copilot license. If you would like to explore these capabilities, coordinate with your IT Administrator or Microsoft Sales representative to ensure the proper licensing is in place.

• To access M365 Copilot and start building custom agents, your organization must have a Microsoft 365 Copilot license. If you would like to explore these capabilities, coordinate with your IT Administrator or Microsoft Sales representative to ensure the proper licensing is in place.

Note: M365 Copilot is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.

Note: M365 Copilot is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.

• To manage Microsoft 365 Copilot agents and settings, your account must be assigned a specific administrative role. You can verify your current access level by viewing the agent list. While a Global Administrator has full control over the entire organization, Microsoft recommends using the AI Administrator role. This is a dedicated persona designed specifically for managing Copilot features and agent governance without granting unnecessary access to other parts of your system. If you only need to monitor the environment, the Global Reader role provides "view-only" access, allowing you to see agent status and availability without the ability to make changes or upload new packages. Consult your internal IT team to ensure one of these roles is assigned to your account and you list agents via the URL mentioned above.

• To manage Microsoft 365 Copilot agents and settings, your account must be assigned a specific administrative role. You can verify your current access level by viewing the agent list. While a Global Administrator has full control over the entire organization, Microsoft recommends using the AI Administrator role. This is a dedicated persona designed specifically for managing Copilot features and agent governance without granting unnecessary access to other parts of your system. If you only need to monitor the environment, the Global Reader role provides "view-only" access, allowing you to see agent status and availability without the ability to make changes or upload new packages. Consult your internal IT team to ensure one of these roles is assigned to your account and you list agents via the URL mentioned above.

• In the Setting tab, select Active for assignment type and Permanently assigned for assignment duration. Add a justification for your settings and Assign.

• In the Setting tab, select Active for assignment type and Permanently assigned for assignment duration. Add a justification for your settings and Assign.

1. Configure OATH Token Authentication Methods in Microsoft

1. Configure OATH Token Authentication Methods in Microsoft

To ensure a standardized login experience and support automated data extraction, configure Microsoft Entra ID to use Open Authentication (OATH) Time-based One-Time Password (TOTP) methods for the dedicated administrative account.

To ensure a standardized login experience and support automated data extraction, configure Microsoft Entra ID to use Open Authentication (OATH) Time-based One-Time Password (TOTP) methods for the dedicated administrative account.

Note: To avoid a misconfiguration, ensure that you complete the following steps EXACTLY in the sequence provided. Deviating from this order can lead to authentication errors or service disruption.

Note: To avoid a misconfiguration, ensure that you complete the following steps EXACTLY in the sequence provided. Deviating from this order can lead to authentication errors or service disruption.

Part A: Extract the Secret Key

Part A: Extract the Secret Key

1. During the multi-factor authentication (MFA) setup for your service/admin account on the Scan the QR code page, select the Can't scan QR code? link.

1. During the multi-factor authentication (MFA) setup for your service/admin account on the Scan the QR code page, select the Can't scan QR code? link.

2. Record the Account name and the Secret key.

2. Record the Account name and the Secret key.

3. Store the secret key in a secure location, such as a password manager, for later use during onboarding or recovery (this acts as your TOTP Secret).

3. Store the secret key in a secure location, such as a password manager, for later use during onboarding or recovery (this acts as your TOTP Secret).

4. Click Next.

4. Click Next.

@@ -56,19 +54,19 @@ Prerequisite: Ensure you have the Microsoft Authenticator app installed on your

Part D: Confirm the Default Sign-in Method

Part D: Confirm the Default Sign-in Method

16. Return to the Microsoft Entra admin center and select Users > Authentication methods.

16. Return to the Microsoft Entra admin center and select Users > Authentication methods.

17. Verify that the Software OATH token is listed under the authentication records.

17. Verify that the Software OATH token is listed under the authentication records.

18. Select Add authentication method or Change default manual method (if available) to ensure that the Third-party software OATH token option is configured as the primary requirement for compliance.

18. Select Add authentication method or Change default manual method (if available) to ensure that the Third-party software OATH token option is configured as the primary requirement for compliance.

2. Onboard M365 Copilot to AISPM

2. Onboard M365 Copilot to AISPM

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Microsoft 365 Copilot connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Microsoft 365 Copilot connector.

3. Click on the Microsoft 365 Copilot tile and select Add Another Instance.

3. Click on the Microsoft 365 Copilot tile and select Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

5. On the Connections page, provide your Instance URL.

5. On the Connections page, provide your Instance URL.

6. Under Authentication, the CREDENTIALS authentication method is selected by default. Click Next.

6. Under Authentication, the CREDENTIALS authentication method is selected by default. Click Next.

7. On the Onboard Agent Platform page, enter your admin account credentials and provide the Secret Key (OATH TOTP Secret) you recorded during Step 1.

7. On the Onboard Agent Platform page, enter your admin account credentials and provide the Secret Key (OATH TOTP Secret) you recorded during Step 1.

8. Once Cortex validates the credentials and permissions, the onboarding process is complete.

8. Once Cortex validates the credentials and permissions, the onboarding process is complete.

3. Validation and Scanning:

3. Validation and Scanning:
Show markdown source
```
@@ -1,34 +1,32 @@
 ---
 description: >-
-  Connect M365 Copilot to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect M365 Copilot in Cortex XSIAM SaaS Agent Security for visibility and
+  control across your AI ecosystem.
 ---
 
 # Onboard M365 Copilot
 
 Microsoft 365 Copilot is an AI-powered assistant integrated into Word, Excel, PowerPoint, Outlook, Teams, and other Microsoft 365 apps. It uses Large Language Models (LLMs) and your organization's data to help with tasks like drafting content, analyzing data, summarizing meetings, and generating ideas. It acts as a "copilot" by streamlining workflows, boosting creativity, and increasing productivity by turning natural language prompts into actions and insights within your familiar work environment.
 
 **Prerequisites**
 
 * To access M365 Copilot and start building custom agents, your organization must have a Microsoft 365 Copilot license. If you would like to explore these capabilities, coordinate with your IT Administrator or Microsoft Sales representative to ensure the proper licensing is in place.
 
 **Note**: M365 Copilot is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.
 
 * To manage Microsoft 365 Copilot agents and settings, your account must be assigned a specific administrative role. You can verify your current access level by viewing the agent list. While a Global Administrator has full control over the entire organization, Microsoft recommends using the AI Administrator role. This is a dedicated persona designed specifically for managing Copilot features and agent governance without granting unnecessary access to other parts of your system. If you only need to monitor the environment, the Global Reader role provides "view-only" access, allowing you to see agent status and availability without the ability to make changes or upload new packages. Consult your internal IT team to ensure one of these roles is assigned to your account and you list agents via the URL mentioned above.
-* In the Setting tab, select Active for assignment type and Permanently assigned for assignment duration. Add a justification for your settings and Assign.&#x20;
-
-
+* In the Setting tab, select Active for assignment type and Permanently assigned for assignment duration. Add a justification for your settings and Assign.
 
 1. Configure OATH Token Authentication Methods in Microsoft
 
 To ensure a standardized login experience and support automated data extraction, configure Microsoft Entra ID to use Open Authentication (OATH) Time-based One-Time Password (TOTP) methods for the dedicated administrative account.
 
-Note: To avoid a misconfiguration, ensure that you complete the following steps EXACTLY in the sequence provided. Deviating from this order can lead to authentication errors or service disruption.&#x20;
+Note: To avoid a misconfiguration, ensure that you complete the following steps EXACTLY in the sequence provided. Deviating from this order can lead to authentication errors or service disruption.
 
 **Part A: Extract the Secret Key**
 
 1. During the multi-factor authentication (MFA) setup for your service/admin account on the Scan the QR code page, select the Can't scan QR code? link.
 2. Record the Account name and the Secret key.
 3. Store the secret key in a secure location, such as a password manager, for later use during onboarding or recovery (this acts as your TOTP Secret).
 4. Click Next.
 
@@ -56,19 +54,19 @@ Prerequisite: Ensure you have the Microsoft Authenticator app installed on your
 **Part D: Confirm the Default Sign-in Method**
 
 16. Return to the Microsoft Entra admin center and select Users > Authentication methods.
 17. Verify that the Software OATH token is listed under the authentication records.
 18. Select Add authentication method or Change default manual method (if available) to ensure that the Third-party software OATH token option is configured as the primary requirement for compliance.
 
 2\. Onboard M365 Copilot to AISPM
 
-1. Log in to Cortex.&#x20;
+1. Log in to Cortex.
 2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the Microsoft 365 Copilot connector.
-3. Click on the Microsoft 365 Copilot tile and select Add Another Instance.&#x20;
+3. Click on the Microsoft 365 Copilot tile and select Add Another Instance.
 4. On the **Capabilities** page, provide an Instance Name and select Agent Security scanning capability.
 5. On the **Connections** page, provide your Instance URL.
 6. Under Authentication, the CREDENTIALS authentication method is selected by default. Click Next.
 7. On the Onboard Agent Platform page, enter your admin account credentials and provide the Secret Key (OATH TOTP Secret) you recorded during Step 1.
 8. Once Cortex validates the credentials and permissions, the onboarding process is complete.
 
 3\. Validation and Scanning:
 
```
▸ ▾ Onboard Microsoft Copilot Studio modified +5 −7 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-microsoft-copilot-studio

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,26 +1,24 @@

---

---

description: >-

description: >-

Connect Microsoft Copilot Studio to SaaS Agent Security to gain total

Connect Microsoft Copilot Studio in Cortex XSIAM SaaS Agent Security for

visibility and control over your AI ecosystem.

visibility and control across your AI ecosystem.

---

---

# Onboard Microsoft Copilot Studio

# Onboard Microsoft Copilot Studio

Prerequisites

Prerequisites

• Licensing: To access Microsoft Copilot Studio and start building custom agents, your organization must have an active Microsoft Copilot Studio license. Coordinate with your IT Administrator or Microsoft Sales representative to ensure the proper licensing is in place. Note: Copilot Studio is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.

• Licensing: To access Microsoft Copilot Studio and start building custom agents, your organization must have an active Microsoft Copilot Studio license. Coordinate with your IT Administrator or Microsoft Sales representative to ensure the proper licensing is in place. Note: Copilot Studio is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.

• Azure Permissions: Ensure you have Administrative privileges in the Microsoft Azure portal to register apps and grant API permissions. To perform onboarding, you must have an Application Administrator role. This role manages application settings and permissions within Microsoft Entra ID (Azure AD) and has the ability to restart provisioning of an enterprise application.

• Azure Permissions: Ensure you have Administrative privileges in the Microsoft Azure portal to register apps and grant API permissions. To perform onboarding, you must have an Application Administrator role. This role manages application settings and permissions within Microsoft Entra ID (Azure AD) and has the ability to restart provisioning of an enterprise application.

• Power Platform Permissions: Ensure you have a System Administrator or Power Platform Administrator role to add app users to the relevant environment.

• Power Platform Permissions: Ensure you have a System Administrator or Power Platform Administrator role to add app users to the relevant environment.

• Environment Settings: Ensure you disable Administration mode in the Power Platform Admin Center.

• Environment Settings: Ensure you disable Administration mode in the Power Platform Admin Center.

1. Configure Permissions in Microsoft Azure.

1. Configure Permissions in Microsoft Azure.

Create an app registration in your Microsoft Azure Portal to grant Palo Alto Networks® secure, read-only access to your Microsoft Copilot Studio environment.

Create an app registration in your Microsoft Azure Portal to grant Palo Alto Networks® secure, read-only access to your Microsoft Copilot Studio environment.

1. Register a new app in Microsoft Azure

1. Register a new app in Microsoft Azure

1. Log in to the Microsoft Azure Portal.

1. Log in to the Microsoft Azure Portal.

2. Navigate to or search for App registrations.

2. Navigate to or search for App registrations.

3. Click + New Registration.

3. Click + New Registration.

4. Enter a descriptive Name for the app (for example: PaloAltoNetworks_Agent_Security_Connector).

4. Enter a descriptive Name for the app (for example: PaloAltoNetworks_Agent_Security_Connector).

@@ -52,19 +50,19 @@ Create an app registration in your Microsoft Azure Portal to grant Palo Alto Net

6. Click Create to finalize the app access privileges.

6. Click Create to finalize the app access privileges.

5. Gather the required configuration values

5. Gather the required configuration values

1. Before moving to the next step, ensure you have gathered and copied the following variables:

1. Before moving to the next step, ensure you have gathered and copied the following variables:

1. Environment URL: Found on the environment's main page in the Microsoft Power Platform Admin Center.

1. Environment URL: Found on the environment's main page in the Microsoft Power Platform Admin Center.

2. Application (Client) ID: Displayed in the app Overview tab in the Microsoft Azure Portal.

2. Application (Client) ID: Displayed in the app Overview tab in the Microsoft Azure Portal.

3. Directory (Tenant) ID: Displayed in the app Overview tab in the Microsoft Azure Portal.

3. Directory (Tenant) ID: Displayed in the app Overview tab in the Microsoft Azure Portal.

4. Client Secret Value: The secret value you securely stored in Step 3.

4. Client Secret Value: The secret value you securely stored in Step 3.

6. Onboard Microsoft Copilot Studio to AISPM. Establish the API connection between the Palo Alto Networks platform and your Microsoft Copilot Studio environment using the gathered credentials.

6. Onboard Microsoft Copilot Studio to AISPM. Establish the API connection between the Palo Alto Networks platform and your Microsoft Copilot Studio environment using the gathered credentials.

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Microsoft Copilot Studio connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the Microsoft Copilot Studio connector.

3. Click on the Microsoft Copilot Studio tile and select Add Another Instance.

3. Click on the Microsoft Copilot Studio tile and select Add Another Instance.

1. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

1. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

4. On the Connections page, provide your Instance URL and select an authentication method. Input the following:

4. On the Connections page, provide your Instance URL and select an authentication method. Input the following:

1. Tenant ID

1. Tenant ID

1. Power Platform Environment URL

1. Power Platform Environment URL

5. Under Agent Security Scanning, provide the Client ID and Client Secret.

5. Under Agent Security Scanning, provide the Client ID and Client Secret.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

7. Validation and Scanning: Cortex will process the credentials and notify you once onboarding is complete. The amount of time required to complete the scan varies depending on your tenant's total volume of data. At a minimum, expect it to take at least one hour to process logs and display security telemetry inside the AISPM dashboard.

7. Validation and Scanning: Cortex will process the credentials and notify you once onboarding is complete. The amount of time required to complete the scan varies depending on your tenant's total volume of data. At a minimum, expect it to take at least one hour to process logs and display security telemetry inside the AISPM dashboard.
Show markdown source
```
@@ -1,26 +1,24 @@
 ---
 description: >-
-  Connect Microsoft Copilot Studio to SaaS Agent Security to gain total
-  visibility and control over your AI ecosystem.
+  Connect Microsoft Copilot Studio in Cortex XSIAM SaaS Agent Security for
+  visibility and control across your AI ecosystem.
 ---
 
 # Onboard Microsoft Copilot Studio
 
 **Prerequisites**
 
 * Licensing: To access Microsoft Copilot Studio and start building custom agents, your organization must have an active Microsoft Copilot Studio license. Coordinate with your IT Administrator or Microsoft Sales representative to ensure the proper licensing is in place. Note: Copilot Studio is a Microsoft-native product, not a feature developed or managed by Palo Alto Networks.
 * Azure Permissions: Ensure you have Administrative privileges in the Microsoft Azure portal to register apps and grant API permissions. To perform onboarding, you must have an Application Administrator role. This role manages application settings and permissions within Microsoft Entra ID (Azure AD) and has the ability to restart provisioning of an enterprise application.
 * Power Platform Permissions: Ensure you have a System Administrator or Power Platform Administrator role to add app users to the relevant environment.
 * Environment Settings: Ensure you disable Administration mode in the Power Platform Admin Center.
 
-
-
-1. Configure Permissions in Microsoft Azure.&#x20;
+1. Configure Permissions in Microsoft Azure.
 
 Create an app registration in your Microsoft Azure Portal to grant Palo Alto Networks® secure, read-only access to your Microsoft Copilot Studio environment.
 
 1. Register a new app in Microsoft Azure
    1. Log in to the Microsoft Azure Portal.
    2. Navigate to or search for App registrations.
    3. Click + New Registration.
    4. Enter a descriptive Name for the app (for example: PaloAltoNetworks\_Agent\_Security\_Connector).
@@ -52,19 +50,19 @@ Create an app registration in your Microsoft Azure Portal to grant Palo Alto Net
    6. Click Create to finalize the app access privileges.
 5. Gather the required configuration values
    1. Before moving to the next step, ensure you have gathered and copied the following variables:
       1. Environment URL: Found on the environment's main page in the Microsoft Power Platform Admin Center.
       2. Application (Client) ID: Displayed in the app Overview tab in the Microsoft Azure Portal.
       3. Directory (Tenant) ID: Displayed in the app Overview tab in the Microsoft Azure Portal.
       4. Client Secret Value: The secret value you securely stored in Step 3.
 6. Onboard Microsoft Copilot Studio to AISPM. Establish the API connection between the Palo Alto Networks platform and your Microsoft Copilot Studio environment using the gathered credentials.
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the Microsoft Copilot Studio connector.
-   3. Click on the Microsoft Copilot Studio tile and select **Add Another Instance**.&#x20;
+   3. Click on the Microsoft Copilot Studio tile and select **Add Another Instance**.
       1. On the **Capabilities** page, provide an Instance Name and select Agent Security scanning capability.
    4. On the **Connections** page, provide your Instance URL and select an authentication method. Input the following:
       1. Tenant ID
          1. Power Platform Environment URL
    5. Under **Agent Security Scanning**, provide the Client ID and Client Secret.
    6. Once AISPM validates the credentials and permissions, the onboarding process is complete.
 7. Validation and Scanning: Cortex will process the credentials and notify you once onboarding is complete. The amount of time required to complete the scan varies depending on your tenant's total volume of data. At a minimum, expect it to take at least one hour to process logs and display security telemetry inside the AISPM dashboard.
 
```
▸ ▾ Onboard Service Now modified +5 −7 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-service-now

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Connect Service Now to SaaS Agent Security to gain total visibility and

Connect ServiceNow in Cortex XSIAM SaaS Agent Security for visibility and

control over your AI ecosystem.

control across your AI ecosystem.

---

---

# Onboard Service Now

# Onboard Service Now

To secure access to your ServiceNow data and successfully onboard to Cortex, you must complete two main phases:

To secure access to your ServiceNow data and successfully onboard to Cortex, you must complete two main phases:

1. Create an application registry that the platform will use to access your ServiceNow data via the REST API. The configuration consists of creating a user, creating an authentication scope, and using them to create an application registry.

1. Create an application registry that the platform will use to access your ServiceNow data via the REST API. The configuration consists of creating a user, creating an authentication scope, and using them to create an application registry.

2. Onboard the ServiceNow platform to AISPM via Strata Cloud Manager.

2. Onboard the ServiceNow platform to AISPM via Strata Cloud Manager.

@@ -32,35 +32,33 @@ To secure access to your ServiceNow data and successfully onboard to Cortex, you

Note: Before creating the OAuth 2.0 integration, create a scope that limits AISPM's access to only the Table API.

Note: Before creating the OAuth 2.0 integration, create a scope that limits AISPM's access to only the Table API.

1. Navigate to the Authentication Scopes table (sys_auth_scope.list) by using the filter navigator.

1. Navigate to the Authentication Scopes table (sys_auth_scope.list) by using the filter navigator.

2. Click New to define the authentication scope.

2. Click New to define the authentication scope.

3. Specify a meaningful Name for your authentication scope, such as SaaS_Agent_Security_Scope or SSPM Agentic Scope.

3. Specify a meaningful Name for your authentication scope, such as SaaS_Agent_Security_Scope or SSPM Agentic Scope.

4. (Optional) Specify a Description. Click Submit.

4. (Optional) Specify a Description. Click Submit.

Note: Keep the authentication scope name handy, as it is required when configuring the REST API Auth Scope and OAuth 2.0 integration.

Note: Keep the authentication scope name handy, as it is required when configuring the REST API Auth Scope and OAuth 2.0 integration.

3. Create the Application Registry (OAuth Client)\

3. Create the Application Registry (OAuth Client)\

Standard Release Instructions:

Standard Release Instructions:

1. Log in to ServiceNow as an administrator.

1. Log in to ServiceNow as an administrator.

2. Navigate to the Application Registries page (System OAuth > Application Registry).

2. Navigate to the Application Registries page (System OAuth > Application Registry).

3. Select New > Create an OAuth API endpoint for external clients.

3. Select New > Create an OAuth API endpoint for external clients.

4. Copy the auto-generated Client ID and Client Secret and keep them handy.

4. Copy the auto-generated Client ID and Client Secret and keep them handy.

5. Ensure the following additional details are filled in correctly:

5. Ensure the following additional details are filled in correctly:

6. Set the Application to Global.

6. Set the Application to Global.

7. Ensure it's accessible from all application scopes.

7. Ensure it's accessible from all application scopes.

8. Ensure the Active check box is selected.

8. Ensure the Active check box is selected.

9. OAuth Application User: Enter the user you created in Step 1.

9. OAuth Application User: Enter the user you created in Step 1.

10. Default grant type: Choose Client Credentials. (Ensure that the system property glide.oauth.inbound.client.credential.grant_type.enabled is set to true).

10. Default grant type: Choose Client Credentials. (Ensure that the system property glide.oauth.inbound.client.credential.grant_type.enabled is set to true).

11. Specify your OAuth Scope that you created in Step 2.

11. Specify your OAuth Scope that you created in Step 2.

12. Click Submit.

12. Click Submit.

4. Onboard ServiceNow Platform to Cortex.

4. Onboard ServiceNow Platform to Cortex.

1. Log in to Cortex.

1. Log in to Cortex.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the ServiceNow connector.

2. Select Settings > Data Sources and Integrations > Add New. You can use the Search bar to find the ServiceNow connector.

3. Click on the ServiceNow tile and select Add Another Instance.

3. Click on the ServiceNow tile and select Add Another Instance.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

4. On the Capabilities page, provide an Instance Name and select Agent Security scanning capability.

5. On the Connections page, provide your Instance URL and select an authentication method. Enter the information you gathered (Client ID, Client Secret, etc.) during Step 1 in the corresponding fields.

5. On the Connections page, provide your Instance URL and select an authentication method. Enter the information you gathered (Client ID, Client Secret, etc.) during Step 1 in the corresponding fields.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

6. Once AISPM validates the credentials and permissions, the onboarding process is complete.

#### Troubleshooting

#### Troubleshooting

If you see errors after onboarding, this is likely due to incomplete permissions. Return to the application registry creation procedure and verify that the assigned role possesses a read-only ACL rule for every single required table. Also, ensure that this role is correctly assigned to the service user you created.

If you see errors after onboarding, this is likely due to incomplete permissions. Return to the application registry creation procedure and verify that the assigned role possesses a read-only ACL rule for every single required table. Also, ensure that this role is correctly assigned to the service user you created.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Connect Service Now to SaaS Agent Security to gain total visibility and
-  control over your AI ecosystem.
+  Connect ServiceNow in Cortex XSIAM SaaS Agent Security for visibility and
+  control across your AI ecosystem.
 ---
 
 # Onboard Service Now
 
 To secure access to your ServiceNow data and successfully onboard to Cortex, you must complete two main phases:
 
 1. Create an application registry that the platform will use to access your ServiceNow data via the REST API. The configuration consists of creating a user, creating an authentication scope, and using them to create an application registry.
 2. Onboard the ServiceNow platform to AISPM via Strata Cloud Manager.
@@ -32,35 +32,33 @@ To secure access to your ServiceNow data and successfully onboard to Cortex, you
     Note: Before creating the OAuth 2.0 integration, create a scope that limits AISPM's access to only the Table API.
 
     1. Navigate to the Authentication Scopes table (sys\_auth\_scope.list) by using the filter navigator.
     2. Click New to define the authentication scope.
     3. Specify a meaningful Name for your authentication scope, such as SaaS\_Agent\_Security\_Scope or SSPM Agentic Scope.
     4. (Optional) Specify a Description. Click Submit.
 
     Note: Keep the authentication scope name handy, as it is required when configuring the REST API Auth Scope and OAuth 2.0 integration.
-
-
 3. Create the Application Registry (OAuth Client)\
    Standard Release Instructions:
    1. Log in to ServiceNow as an administrator.
    2. Navigate to the Application Registries page (System OAuth > Application Registry).
    3. Select New > Create an OAuth API endpoint for external clients.
    4. Copy the auto-generated Client ID and Client Secret and keep them handy.
    5. Ensure the following additional details are filled in correctly:
    6. Set the Application to Global.
    7. Ensure it's accessible from all application scopes.
    8. Ensure the Active check box is selected.
    9. OAuth Application User: Enter the user you created in Step 1.
    10. Default grant type: Choose Client Credentials. (Ensure that the system property glide.oauth.inbound.client.credential.grant\_type.enabled is set to true).
    11. Specify your OAuth Scope that you created in Step 2.
    12. Click Submit.
 4. Onboard ServiceNow Platform to Cortex.
-   1. Log in to Cortex.&#x20;
+   1. Log in to Cortex.
    2. Select **Settings > Data Sources and Integrations > Add New**. You can use the Search bar to find the ServiceNow connector.
-   3. Click on the ServiceNow tile and select Add Another Instance.&#x20;
+   3. Click on the ServiceNow tile and select Add Another Instance.
    4. On the **Capabilities** page, provide an Instance Name and select Agent Security scanning capability.
    5. On the **Connections** page, provide your Instance URL and select an authentication method. Enter the information you gathered (Client ID, Client Secret, etc.) during Step 1 in the corresponding fields.
    6. Once AISPM validates the credentials and permissions, the onboarding process is complete.
 
-#### &#x20;Troubleshooting
+#### Troubleshooting
 
 If you see errors after onboarding, this is likely due to incomplete permissions. Return to the application registry creation procedure and verify that the assigned role possesses a read-only ACL rule for every single required table. Also, ensure that this role is correctly assigned to the service user you created.
```

▸ Setup SaaS Security for AISPM modified +6 −6 xsiam/cloud-security/cortex-cloud-saas-security/saas-ai-agent-security/setup-saas-security-for-aispm

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,13 +1,13 @@

---

description: Get started with SaaS Agent Security.

description: Get started with SaaS AI Agent Security in Cortex XSIAM.

---

# Setup SaaS Security for AISPM

Learn more about how SaaS security can help your security team reliably manage usage policies, close visibility gaps, and secure sensitive data housed across your entire cloud portfolio.

Take Action│Start Here

| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Get Started with AISPM│

Required Cortex License: SaaS Security requires one of the following Cortex Licenses:
Enable Access: Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.

Get Started with AISPM│

Required Cortex License: SaaS Security requires one of the following Cortex Licenses:
Enable Access: Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.

Onboard SaaS Agents│

Administration│

Manage SaaS AI Agents

Administration│

Manage SaaS AI Agents

Show markdown source

@@ -1,13 +1,13 @@
 ---
-description: Get started with SaaS Agent Security.
+description: Get started with SaaS AI Agent Security in Cortex XSIAM.
 ---
 
 # Setup SaaS Security for AISPM
 
 Learn more about how SaaS security can help your security team reliably manage usage policies, close visibility gaps, and secure sensitive data housed across your entire cloud portfolio.
 
-| Take Action            | Start Here                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Get Started with AISPM | <ul><li><p>Required Cortex License: SaaS Security requires one of the following Cortex Licenses:</p><ul><li><a href="https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-3.x-Documentation/Cortex-XSIAM-product-licenses">Cortex XSIAM</a></li><li><a href="https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Runtime-Security-Documentation/Understand-license-plans">Cortex Runtime Security</a></li><li><a href="https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Posture-Management-Documentation/Understand-license-plans">Cortex Posture Security</a></li></ul></li><li><a href="../../../onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/enable-access-to-required-panw-resources">Enable Access</a>: Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| Onboard SaaS Agents    | <ul><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-atlassian-rovo">Atlassian Rovo</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-box-ai-agents">Box AI Agents</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-chatgpt-enterprise">ChatGPT Enterprise</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-cursor-enterprise">Cursor Enterprise</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-gemini-enterprise">Gemini Enterprise</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-m365-copilot">Microsoft 365 Copilot</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-microsoft-copilot-studio">Microsoft Copilot Studio</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/onboard-saas-ai-agents/onboard-service-now">ServiceNow AI Platform</a></li></ul> |
-| Administration         | <ul><li><p><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/manage-saas-ai-agents">Manage SaaS AI Agents</a></p><ul><li><a href="manage-saas-ai-agents/view-ai-agents">View AI Agents</a></li><li><a href="manage-saas-ai-agents/view-datasets">View Datasets</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-ai-agent-security/manage-saas-ai-agents/view-agent-tools">View Agent Tools</a></li><li><a href="../../cortex-cloud-ai-security/cortex-cloud-saas-security/remediation-actions">Remediation Actions</a></li></ul></li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| Take Action            | Start Here                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Get Started with AISPM | <ul><li><p>Required Cortex License: SaaS Security requires one of the following Cortex Licenses:</p><ul><li><a href="https://docs-cortex.paloaltonetworks.com/r/Cortex-XSIAM/Cortex-XSIAM-3.x-Documentation/Cortex-XSIAM-product-licenses">Cortex XSIAM</a></li><li><a href="https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Runtime-Security-Documentation/Understand-license-plans">Cortex Runtime Security</a></li><li><a href="https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Posture-Management-Documentation/Understand-license-plans">Cortex Posture Security</a></li></ul></li><li><a href="../../../onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/enable-access-to-required-panw-resources">Enable Access</a>: Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.</li></ul> |
+| Onboard SaaS Agents    | <ul><li><a href="broken-reference">Atlassian Rovo</a></li><li><a href="broken-reference">Box AI Agents</a></li><li><a href="broken-reference">ChatGPT Enterprise</a></li><li><a href="broken-reference">Cursor Enterprise</a></li><li><a href="broken-reference">Gemini Enterprise</a></li><li><a href="broken-reference">Microsoft 365 Copilot</a></li><li><a href="broken-reference">Microsoft Copilot Studio</a></li><li><a href="broken-reference">ServiceNow AI Platform</a></li></ul>                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Administration         | <ul><li><p><a href="broken-reference">Manage SaaS AI Agents</a></p><ul><li><a href="manage-saas-ai-agents/view-ai-agents">View AI Agents</a></li><li><a href="manage-saas-ai-agents/view-datasets">View Datasets</a></li><li><a href="broken-reference">View Agent Tools</a></li><li><a href="broken-reference">Remediation Actions</a></li></ul></li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |

▸ ▾ SaaS Security Checks modified +4 −2 xsiam/cloud-security/cortex-cloud-saas-security/saas-security-checks

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,15 +1,17 @@

---

---

description: The dashboard captures key metrics to help you remediate SaaS assets at risk

description: >-

Use SaaS Security Checks in Cortex XSIAM to identify at-risk assets and

prioritize remediation.

---

---

# SaaS Security Checks

# SaaS Security Checks

SaaS Security Checks provides security telemetry for posture misconfigurations, vulnerabilities, and compliance in one unified view. This consolidated dashboard provides a queryable, prioritized view of your attack surface, accelerating automated triage, incident response, and compliance auditing.

SaaS Security Checks provides security telemetry for posture misconfigurations, vulnerabilities, and compliance in one unified view. This consolidated dashboard provides a queryable, prioritized view of your attack surface, accelerating automated triage, incident response, and compliance auditing.

The dashboard captures the following key metrics to help you remediate assets at risk:

The dashboard captures the following key metrics to help you remediate assets at risk:

• SaaS Security Check Score: Renders the current, aggregate security posture score as a normalized percentage, while also tracking score volatility over a rolling 90-day window to monitor long-term posture drift.

• SaaS Security Check Score: Renders the current, aggregate security posture score as a normalized percentage, while also tracking score volatility over a rolling 90-day window to monitor long-term posture drift.

• Overall Compliance: Monitors adherence to mapped compliance standards and frameworks.

• Overall Compliance: Monitors adherence to mapped compliance standards and frameworks.

• Provider Instances by Security Check Score: Categorizes individual SaaS tenant configurations (such as Salesforce, Mural, or Google Workspace) to identify low-performing integrations, based on their security scores.

• Provider Instances by Security Check Score: Categorizes individual SaaS tenant configurations (such as Salesforce, Mural, or Google Workspace) to identify low-performing integrations, based on their security scores.
Show markdown source
```
@@ -1,15 +1,17 @@
 ---
-description: The dashboard captures key metrics to help you remediate SaaS assets at risk
+description: >-
+  Use SaaS Security Checks in Cortex XSIAM to identify at-risk assets and
+  prioritize remediation.
 ---
 
 # SaaS Security Checks
 
-SaaS Security Checks provides security telemetry for posture misconfigurations, vulnerabilities, and compliance in one unified view. This consolidated dashboard provides a queryable, prioritized view of your attack surface, accelerating automated triage, incident response, and compliance auditing.&#x20;
+SaaS Security Checks provides security telemetry for posture misconfigurations, vulnerabilities, and compliance in one unified view. This consolidated dashboard provides a queryable, prioritized view of your attack surface, accelerating automated triage, incident response, and compliance auditing.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FsTN50fsPyBbITq1HaqvK%2Funknown.png?alt=media&#x26;token=d3ff0626-c7d7-4232-8aec-c948bb6f5f3c" alt="" height="429" width="624">
 
 The dashboard captures the following key metrics to help you remediate assets at risk:
 
 * SaaS Security Check Score: Renders the current, aggregate security posture score as a normalized percentage, while also tracking score volatility over a rolling 90-day window to monitor long-term posture drift.
 * Overall Compliance: Monitors adherence to mapped compliance standards and frameworks.
 * Provider Instances by Security Check Score: Categorizes individual SaaS tenant configurations (such as Salesforce, Mural, or Google Workspace) to identify low-performing integrations, based on their security scores.
```
▸ ▾ SaaS Security Overview modified +4 −7 xsiam/cloud-security/cortex-cloud-saas-security/saas-security-overview

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,34 +1,31 @@

---

---

description: >-

description: >-

This dashboard aggregates and presents security data from all four core SaaS

Use the SaaS Security Overview in Cortex XSIAM to monitor posture, identity,

Security pillars including: SSPM (Posture), SaaS Identity Security, SaaS Data

data, and AI agent security.

Security, and SaaS Agent Security.

---

---

# SaaS Security Overview

# SaaS Security Overview

The SaaS Overview dashboard provides unified visibility into your multi-SaaS security posture to streamline daily operations. The dashboard seamlessly aggregates and presents security data from all four core SaaS Security pillars including: SaaS Security Posture Management, SaaS Identity Security, SaaS Data Security, and SaaS Agent Security. Leverage this view to:

The SaaS Overview dashboard provides unified visibility into your multi-SaaS security posture to streamline daily operations. The dashboard seamlessly aggregates and presents security data from all four core SaaS Security pillars including: SaaS Security Posture Management, SaaS Identity Security, SaaS Data Security, and SaaS Agent Security. Leverage this view to:

• Triage Threats: Detect and investigate active security events in real time.

• Triage Threats: Detect and investigate active security events in real time.

• Manage Posture: Surface and prioritize misconfigurations across connected applications and assets.

• Manage Posture: Surface and prioritize misconfigurations across connected applications and assets.

• Provide Executive Reporting: Track aggregate risk scores and compliance trends for stakeholder updates.

• Provide Executive Reporting: Track aggregate risk scores and compliance trends for stakeholder updates.

Review the descriptions below for a detailed breakdown of interactive widgets:

Review the descriptions below for a detailed breakdown of interactive widgets:

1. The application inventory header bar displays high-level statistics for monitored applications and assets along with state sync indicators. This high-level indicator provides you with a comprehensive view of all your SaaS applications and impacted assets.

1. The application inventory header bar displays high-level statistics for monitored applications and assets along with state sync indicators. This high-level indicator provides you with a comprehensive view of all your SaaS applications and impacted assets.

2. The central interactive visual graph maps security domains to aggregated issues and severity classifications. This helps you gauge the overall health of your security operations and ensure that your team is maintaining a positive burn-down rate of vulnerabilities.

2. The central interactive visual graph maps security domains to aggregated issues and severity classifications. This helps you gauge the overall health of your security operations and ensure that your team is maintaining a positive burn-down rate of vulnerabilities.

3. Domain Security Nodes: Hover over or click a domain node to highlight tracked vulnerability data, such as Agents with Sensitive Data, and view domain-specific asset inventories.

3. Domain Security Nodes: Hover over or click a domain node to highlight tracked vulnerability data, such as Agents with Sensitive Data, and view domain-specific asset inventories.

4. Summarizes Findings into two operational buckets:

4. Summarizes Findings into two operational buckets:

• Active Threat Issues

• Active Threat Issues

• Posture Issues

• Posture Issues

5. Top Active Threats to Address: Displays a prioritized list of specific threat alerts to help you identify and investigate high-risk activities that could lead to a breach.

5. Top Active Threats to Address: Displays a prioritized list of specific threat alerts to help you identify and investigate high-risk activities that could lead to a breach.

6. Top Posture Issues to Address: Lists the most critical configuration issues and vulnerabilities, categorized by asset type (Data, Identity, API) and the number of impacted assets, to help your team remediate the most widespread risks to your organization’s security posture.

6. Top Posture Issues to Address: Lists the most critical configuration issues and vulnerabilities, categorized by asset type (Data, Identity, API) and the number of impacted assets, to help your team remediate the most widespread risks to your organization’s security posture.

7. Compliance Summary: Tracks compliance percentage across specific global standards, to help you report out regulatory readiness to stakeholders and prioritize efforts to close specific compliance gaps.

7. Compliance Summary: Tracks compliance percentage across specific global standards, to help you report out regulatory readiness to stakeholders and prioritize efforts to close specific compliance gaps.
Show markdown source
```
@@ -1,34 +1,31 @@
 ---
 description: >-
-  This dashboard aggregates and presents security data from all four core SaaS
-  Security pillars including: SSPM (Posture), SaaS Identity Security, SaaS Data
-  Security, and SaaS Agent Security.
+  Use the SaaS Security Overview in Cortex XSIAM to monitor posture, identity,
+  data, and AI agent security.
 ---
 
 # SaaS Security Overview
 
 The SaaS Overview dashboard provides unified visibility into your multi-SaaS security posture to streamline daily operations. The dashboard seamlessly aggregates and presents security data from all four core SaaS Security pillars including: SaaS Security Posture Management, SaaS Identity Security, SaaS Data Security, and SaaS Agent Security. Leverage this view to:
 
 * Triage Threats: Detect and investigate active security events in real time.
 * Manage Posture: Surface and prioritize misconfigurations across connected applications and assets.
 * Provide Executive Reporting: Track aggregate risk scores and compliance trends for stakeholder updates.
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FtsDAHRj1KQ8JtZHhcrcZ%2Funknown.png?alt=media&#x26;token=8098a3df-78d9-48c2-81e0-96229cf30af2" alt="" height="349" width="624">
 
 Review the descriptions below for a detailed breakdown of interactive widgets:
 
-
-
 1. The application inventory header bar displays high-level statistics for monitored applications and assets along with state sync indicators. This high-level indicator provides you with a comprehensive view of all your SaaS applications and impacted assets.
 2. The central interactive visual graph maps security domains to aggregated issues and severity classifications. This helps you gauge the overall health of your security operations and ensure that your team is maintaining a positive burn-down rate of vulnerabilities.
-3. Domain Security Nodes: Hover over or click a domain node to highlight tracked vulnerability data, such as Agents with Sensitive Data, and view domain-specific asset inventories.&#x20;
+3. Domain Security Nodes: Hover over or click a domain node to highlight tracked vulnerability data, such as Agents with Sensitive Data, and view domain-specific asset inventories.
 4. Summarizes Findings into two operational buckets:
 
-* Active Threat Issues&#x20;
+* Active Threat Issues
 * Posture Issues
 
 <img src="https://2786854933-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAEIjuYE3RXcIfmuQnBbm%2Fuploads%2FMOPqXOoD9uQ2WpgPWu6P%2Funknown.png?alt=media&#x26;token=ee8a72ef-832d-46b6-8134-3cba0859924e" alt="" height="392" width="624">
 
 5. Top Active Threats to Address: Displays a prioritized list of specific threat alerts to help you identify and investigate high-risk activities that could lead to a breach.
 6. Top Posture Issues to Address: Lists the most critical configuration issues and vulnerabilities, categorized by asset type (Data, Identity, API) and the number of impacted assets, to help your team remediate the most widespread risks to your organization’s security posture.
 7. Compliance Summary: Tracks compliance percentage across specific global standards, to help you report out regulatory readiness to stakeholders and prioritize efforts to close specific compliance gaps.
```

▸ Setup SaaS Security modified +4 −4 Links to the deleted SaaS Security copies were replaced with broken-reference. xsiam/cloud-security/cortex-cloud-saas-security/setup-saas-security

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,13 +1,13 @@

---

description: Get started with SaaS Security.

description: Get started with SaaS Security in Cortex XSIAM.

---

# Setup SaaS Security

Learn more about how SaaS security can help your security team reliably manage usage policies, close visibility gaps, and secure sensitive data housed across your entire cloud portfolio.

Get Started with SaaS Security│

Required Cortex License - SaaS Security requires one of the following Cortex Licenses:
Allow List of IP Addresses - Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.

Get Started with SaaS Security│

Required Cortex License - SaaS Security requires one of the following Cortex Licenses:
Allow List of IP Addresses - Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.

| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Configure SaaS Security│

Show markdown source

@@ -1,13 +1,13 @@
 ---
-description: Get started with SaaS Security.
+description: Get started with SaaS Security in Cortex XSIAM.
 ---
 
 # Setup SaaS Security
 
 Learn more about how SaaS security can help your security team reliably manage usage policies, close visibility gaps, and secure sensitive data housed across your entire cloud portfolio.
 
-| Get Started with SaaS Security | <ul><li><p>Required Cortex License - SaaS Security requires one of the following Cortex Licenses:</p><ul><li><a href="../../learn-about-cortex-xsiam/cortex-xsiam-product-licenses">Cortex XSIAM</a></li><li><a href="../../learn-about-cortex-xsiam/cortex-xsiam-product-licenses">Cortex Runtime Security</a></li><li><a href="../../learn-about-cortex-xsiam/cortex-xsiam-product-licenses">Cortex Posture Security</a></li></ul></li><li><a href="../../onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/enable-access-to-required-panw-resources">Allow List of IP Addresses</a> - Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.</li></ul>                                                                                                                                                                                                                                                                                                                                       |
-| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Configure SaaS Security        | <ul><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/onboard-a-supported-saas-application">Onboard a Supported SaaS Application</a></li><li><p><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security">SaaS Security</a></p><ul><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-security-overview">SaaS Security Overview</a></li><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/saas-security-checks">SaaS Security Checks</a></li><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/provider-instances-security-check">Provider Instances Security Check</a></li><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/remediation-actions">Remediation Actions</a></li><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/detection-rules">Detection Rules</a></li><li><a href="../cortex-cloud-ai-security/cortex-cloud-saas-security/create-and-monitor-tickets">Create and monitor tickets</a></li></ul></li></ul> |
+| Get Started with SaaS Security | <ul><li><p>Required Cortex License - SaaS Security requires one of the following Cortex Licenses:</p><ul><li><a href="../../learn-about-cortex-xsiam/cortex-xsiam-product-licenses">Cortex XSIAM</a></li><li><a href="../../learn-about-cortex-xsiam/cortex-xsiam-product-licenses">Cortex Runtime Security</a></li><li><a href="../../learn-about-cortex-xsiam/cortex-xsiam-product-licenses">Cortex Posture Security</a></li></ul></li><li><a href="../../onboard-cortex-xsiam/deployment-steps/activate-cortex-xsiam/enable-access-to-required-panw-resources">Allow List of IP Addresses</a> - Ensure that you have whitelisted the required IPs to ensure optimal onboarding and connectivity.</li></ul> |
+| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Configure SaaS Security        | <ul><li><a href="broken-reference">Onboard a Supported SaaS Application</a></li><li><p><a href="broken-reference">SaaS Security</a></p><ul><li><a href="broken-reference">SaaS Security Overview</a></li><li><a href="broken-reference">SaaS Security Checks</a></li><li><a href="broken-reference">Provider Instances Security Check</a></li><li><a href="broken-reference">Remediation Actions</a></li><li><a href="broken-reference">Detection Rules</a></li><li><a href="broken-reference">Create and monitor tickets</a></li></ul></li></ul>                                                                                                                                                             |
 
 *

▸ ▾ Network exposure detection modified +2 −2 xsiam/cloud-security/network-exposure-detection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Identify, prioritize, and remediate internet, outbound, and lateral network

Discover how to identify, prioritize, and remediate internet, outbound, and

exposure risks in public cloud environments.

lateral network exposure risks in Cortex XSIAM.

---

---

# Network exposure detection

# Network exposure detection

Cortex XSIAM improves network security posture in your public cloud environments. It identifies assets exposed to the internet so you can prioritize and remediate risks.

Cortex XSIAM improves network security posture in your public cloud environments. It identifies assets exposed to the internet so you can prioritize and remediate risks.

Cortex XSIAM publishes network exposure findings and issues based on out-of-the-box and custom cloud security rules and policies. Security teams can review these findings and issues to gain visibility into network exposures, finding answers to the following questions:

Cortex XSIAM publishes network exposure findings and issues based on out-of-the-box and custom cloud security rules and policies. Security teams can review these findings and issues to gain visibility into network exposures, finding answers to the following questions:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Identify, prioritize, and remediate internet, outbound, and lateral network
-  exposure risks in public cloud environments.
+  Discover how to identify, prioritize, and remediate internet, outbound, and
+  lateral network exposure risks in Cortex XSIAM.
 ---
 
 # Network exposure detection
 
 Cortex XSIAM improves network security posture in your public cloud environments. It identifies assets exposed to the internet so you can prioritize and remediate risks.
 
 Cortex XSIAM publishes network exposure findings and issues based on out-of-the-box and custom [cloud security rules and policies](cloud-security-rules-and-policies). Security teams can review these findings and issues to gain visibility into network exposures, finding answers to the following questions:
 
```
▸ ▾ Configure trusted IPs modified +2 −2 xsiam/cloud-security/network-exposure-detection/configure-trusted-ips

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Configure trusted public IP ranges excluded from CNA internet exposure

Configure trusted public IP ranges in Cortex XSIAM to exclude approved

evaluations.

addresses from Cloud Network Analyzer internet exposure evaluations.

---

---

# Configure trusted IPs

# Configure trusted IPs

You can define specific public IP ranges (CIDR blocks) that belong to your company, partners, or trusted services. By designating these networks as "trusted," the system will exclude them from Cloud Network Analyzer (CNA) internet exposure evaluations. This prevents assets from being flagged as "internet exposed" when they are only accessible to known and trusted external networks, reducing unnecessary security findings and noise.

You can define specific public IP ranges (CIDR blocks) that belong to your company, partners, or trusted services. By designating these networks as "trusted," the system will exclude them from Cloud Network Analyzer (CNA) internet exposure evaluations. This prevents assets from being flagged as "internet exposed" when they are only accessible to known and trusted external networks, reducing unnecessary security findings and noise.

The following restrictions apply when defining trusted networks:

The following restrictions apply when defining trusted networks:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Configure trusted public IP ranges excluded from CNA internet exposure
-  evaluations.
+  Configure trusted public IP ranges in Cortex XSIAM to exclude approved
+  addresses from Cloud Network Analyzer internet exposure evaluations.
 ---
 
 # Configure trusted IPs
 
 You can define specific public IP ranges (CIDR blocks) that belong to your company, partners, or trusted services. By designating these networks as "trusted," the system will exclude them from Cloud Network Analyzer (CNA) internet exposure evaluations. This prevents assets from being flagged as "internet exposed" when they are only accessible to known and trusted external networks, reducing unnecessary security findings and noise.
 
 The following restrictions apply when defining trusted networks:
 
```
▸ ▾ East-west exposure detection modified +2 −2 xsiam/cloud-security/network-exposure-detection/east-west-exposure-detection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Learn about workloads with unrestricted lateral access and the controls

Learn how to identify cloud workloads with unrestricted lateral access in

causing that exposure.

Cortex XSIAM and the controls creating east-west exposure.

---

---

# East-west exposure detection

# East-west exposure detection

CNA supports east-west exposure detection. The east-west exposure detection capability allows CNA to detect VMs that have unrestricted access across their VPC in the same cloud account. This strengthens the visibility and security of your cloud environments by providing insights on which assets can access resources on different VPCs, namespaces, and cloud accounts. You can also find out details about an asset that is exposed to the internet, such as whether that asset can establish network sessions in violation of a compliance regulation.

CNA supports east-west exposure detection. The east-west exposure detection capability allows CNA to detect VMs that have unrestricted access across their VPC in the same cloud account. This strengthens the visibility and security of your cloud environments by providing insights on which assets can access resources on different VPCs, namespaces, and cloud accounts. You can also find out details about an asset that is exposed to the internet, such as whether that asset can establish network sessions in violation of a compliance regulation.

This helps you determine which assets have potentially unrestricted access to the other internal resources, taking into account the effect of cloud native security controls, network firewalls, VPC peerings, and Kubernetes network security policies and transit gateways. This allows you to:

This helps you determine which assets have potentially unrestricted access to the other internal resources, taking into account the effect of cloud native security controls, network firewalls, VPC peerings, and Kubernetes network security policies and transit gateways. This allows you to:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Learn about workloads with unrestricted lateral access and the controls
-  causing that exposure.
+  Learn how to identify cloud workloads with unrestricted lateral access in
+  Cortex XSIAM and the controls creating east-west exposure.
 ---
 
 # East-west exposure detection
 
 CNA supports east-west exposure detection. The east-west exposure detection capability allows CNA to detect VMs that have unrestricted access across their VPC in the same cloud account. This strengthens the visibility and security of your cloud environments by providing insights on which assets can access resources on different VPCs, namespaces, and cloud accounts. You can also find out details about an asset that is exposed to the internet, such as whether that asset can establish network sessions in violation of a compliance regulation.
 
 This helps you determine which assets have potentially unrestricted access to the other internal resources, taking into account the effect of cloud native security controls, network firewalls, VPC peerings, and Kubernetes network security policies and transit gateways. This allows you to:
 
```
▸ ▾ Internet exposure detection modified +2 −2 xsiam/cloud-security/network-exposure-detection/internet-exposure-detection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Learn how CNA detects publicly reachable cloud assets and validates exposure

Learn how to detect publicly exposed cloud assets in Cortex XSIAM and validate

through external network scanning.

internet exposure through external network scanning.

---

---

# Internet exposure detection

# Internet exposure detection

CNA detects assets that are exposed to unrestricted public network access. It uses three different methods to determine if an asset is exposed to the internet:

CNA detects assets that are exposed to unrestricted public network access. It uses three different methods to determine if an asset is exposed to the internet:

• Checks whether a routing path exists from source to destination.

• Checks whether a routing path exists from source to destination.

• Verifies the effectiveness of all cloud-native network security policies in the path.

• Verifies the effectiveness of all cloud-native network security policies in the path.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Learn how CNA detects publicly reachable cloud assets and validates exposure
-  through external network scanning.
+  Learn how to detect publicly exposed cloud assets in Cortex XSIAM and validate
+  internet exposure through external network scanning.
 ---
 
 # Internet exposure detection
 
 CNA detects assets that are exposed to unrestricted public network access. It uses three different methods to determine if an asset is exposed to the internet:
 
 * Checks whether a routing path exists from source to destination.
 * Verifies the effectiveness of all cloud-native network security policies in the path.
```
▸ ▾ Investigate an internet exposure modified +3 −1 xsiam/cloud-security/network-exposure-detection/investigate-an-internet-exposure

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,10 +1,12 @@

---

---

description: Investigate internet-exposed assets through Issues and Graph Search.

description: >-

Investigate internet-exposed cloud assets in Cortex XSIAM using Issues and

Graph Search to prioritize and remediate risk.

---

---

# Investigate an internet exposure

# Investigate an internet exposure

You can investigate assets exposed to the internet by reviewing issues detected by Cloud Network Analyzer or by using Graph Search.

You can investigate assets exposed to the internet by reviewing issues detected by Cloud Network Analyzer or by using Graph Search.

### Investigate internet exposure issues

### Investigate internet exposure issues
Show markdown source
```
@@ -1,10 +1,12 @@
 ---
-description: Investigate internet-exposed assets through Issues and Graph Search.
+description: >-
+  Investigate internet-exposed cloud assets in Cortex XSIAM using Issues and
+  Graph Search to prioritize and remediate risk.
 ---
 
 # Investigate an internet exposure
 
 You can investigate assets exposed to the internet by reviewing issues detected by Cloud Network Analyzer or by using Graph Search.
 
 ### **Investigate internet exposure issues**
 
```
▸ ▾ Outbound exposure detection modified +2 −2 xsiam/cloud-security/network-exposure-detection/outbound-exposure-detection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Learn about detecting workloads with unrestricted outbound internet access

Learn how to detect cloud workloads with unrestricted outbound internet access

based on security configurations.

in Cortex XSIAM and identify responsible security controls.

---

---

# Outbound exposure detection

# Outbound exposure detection

CNA supports outbound internet exposure detection. If CNA detects a workload that based on their security configurations has unrestricted internet access, CNA generates a finding.

CNA supports outbound internet exposure detection. If CNA detects a workload that based on their security configurations has unrestricted internet access, CNA generates a finding.

This helps you determine which assets have potentially unrestricted access to the internet, taking into account the effect of cloud native security controls, network firewalls and NAT gateways. It allows you to:

This helps you determine which assets have potentially unrestricted access to the internet, taking into account the effect of cloud native security controls, network firewalls and NAT gateways. It allows you to:
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Learn about detecting workloads with unrestricted outbound internet access
-  based on security configurations.
+  Learn how to detect cloud workloads with unrestricted outbound internet access
+  in Cortex XSIAM and identify responsible security controls.
 ---
 
 # Outbound exposure detection
 
 CNA supports outbound internet exposure detection. If CNA detects a workload that based on their security configurations has unrestricted internet access, CNA generates a finding.
 
 This helps you determine which assets have potentially unrestricted access to the internet, taking into account the effect of cloud native security controls, network firewalls and NAT gateways. It allows you to:
 
```
▸ ▾ What is Cloud Network Analyzer? modified +2 −2 xsiam/cloud-security/network-exposure-detection/what-is-cloud-network-analyzer

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Understand how CNA identifies internet, outbound, and lateral exposure across

Learn how Cloud Network Analyzer in Cortex XSIAM identifies internet,

cloud accounts.

outbound, and lateral exposure risks across cloud accounts.

---

---

# What is Cloud Network Analyzer?

# What is Cloud Network Analyzer?

Cloud Network Analyzer (CNA) in Cortex XSIAM determines which assets—such as virtual machines, databases, containers, and serverless functions—are exposed to the internet, have unrestricted access to the internet, or can laterally move within a cloud account.

Cloud Network Analyzer (CNA) in Cortex XSIAM determines which assets—such as virtual machines, databases, containers, and serverless functions—are exposed to the internet, have unrestricted access to the internet, or can laterally move within a cloud account.

CNA creates an internal network topology to map the path between the internet and the asset. This map provides insights about existing network security controls, including security groups and internet gateways.

CNA creates an internal network topology to map the path between the internet and the asset. This map provides insights about existing network security controls, including security groups and internet gateways.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Understand how CNA identifies internet, outbound, and lateral exposure across
-  cloud accounts.
+  Learn how Cloud Network Analyzer in Cortex XSIAM identifies internet,
+  outbound, and lateral exposure risks across cloud accounts.
 ---
 
 # What is Cloud Network Analyzer?
 
 Cloud Network Analyzer (CNA) in Cortex XSIAM determines which assets—such as virtual machines, databases, containers, and serverless functions—are exposed to the internet, have unrestricted access to the internet, or can laterally move within a cloud account.
 
 CNA creates an internal network topology to map the path between the internet and the asset. This map provides insights about existing network security controls, including security groups and internet gateways.
 
```
▸ ▾ Onboard cloud providers for serverless functions modified +8 −6 xsiam/cloud-security/serverless-function-posture-security/onboard-cloud-providers-for-serverless-functions

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,23 +1,25 @@

---

description: >-

Connect cloud provider accounts to scan serverless functions for security

vulnerabilities, malware, and exposed secrets in Cortex XSIAM.

---

# Onboard cloud providers for serverless functions

# Onboard cloud providers for serverless functions

Integrate Cortex XSIAM with your cloud provider accounts to enable security vulnerability, malware and exposed secret scans of your serverless functions. This enables you to efficiently analyze, prioritize, and resolve security findings specific to your serverless deployments.

Integrate Cortex XSIAM with your cloud provider accounts to enable security vulnerability, malware and exposed secret scans of your serverless functions. This enables you to efficiently analyze, prioritize, and resolve security findings specific to your serverless deployments.

hint info

hint info

### Note

When scanning serverless functions with layers, those layers need to be from the same cloud account.

When scanning serverless functions with layers, those layers need to be from the same cloud account.

endhint

endhint

Supported cloud providers include:

Supported cloud providers include:

• Amazon Web Services (AWS): Refer to Onboard Amazon Web Services for more information about integrating Cortex XSIAM with AWS Lambda functions.

• Amazon Web Services (AWS): Refer to Onboard Amazon Web Services for more information about integrating Cortex XSIAM with AWS Lambda functions.

• Google Cloud Platform (GCP): Refer to Onboard Google Cloud Platform for more information about integrating Cortex XSIAM with GCP functions.

• Google Cloud Platform (GCP): Refer to Onboard Google Cloud Platform for more information about integrating Cortex XSIAM with GCP functions.

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Important</h3><p>Cortex supports Google Cloud Functions: 1st gen and 2nd gen Cloud Functions API.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Cortex supports Google Cloud Functions: 1st gen and 2nd gen Cloud Functions API.</p></div>

• Microsoft Azure: Refer to Microsoft Azure cloud onboarding for more information about integrating Cortex Cloud with Azure functions.

• Microsoft Azure: Refer to Microsoft Azure cloud onboarding for more information about integrating Cortex XSIAM with Azure functions.

hint info

hint info

### Note

Only functions containing zip files are supported.

Only functions containing zip files are supported.

endhint

endhint
Show markdown source
```
@@ -1,23 +1,25 @@
+---
+description: >-
+  Connect cloud provider accounts to scan serverless functions for security
+  vulnerabilities, malware, and exposed secrets in Cortex XSIAM.
+---
+
 # Onboard cloud providers for serverless functions
 
 Integrate Cortex XSIAM with your cloud provider accounts to enable security vulnerability, malware and exposed secret scans of your serverless functions. This enables you to efficiently analyze, prioritize, and resolve security findings specific to your serverless deployments.
 
 {% hint style="info" %}
-### Note
-
 When scanning serverless functions with layers, those layers need to be from the same cloud account.
 {% endhint %}
 
 Supported cloud providers include:
 
 * Amazon Web Services (AWS): Refer to [Onboard Amazon Web Services](../../configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/amazon-web-services-cloud-onboarding/onboard-amazon-web-services) for more information about integrating Cortex XSIAM with AWS Lambda functions.
 *   Google Cloud Platform (GCP): Refer to [Onboard Google Cloud Platform](../../configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/google-cloud-platform-cloud-onboarding/onboard-google-cloud-platform) for more information about integrating Cortex XSIAM with GCP functions.
 
-    <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Important</h3><p>Cortex supports Google Cloud Functions: 1st gen and 2nd gen Cloud Functions API.</p></div>
-* Microsoft Azure: Refer to [Microsoft Azure cloud onboarding](../../configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/microsoft-azure-cloud-onboarding) for more information about integrating Cortex Cloud with Azure functions.
+    <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Cortex supports Google Cloud Functions: 1st gen and 2nd gen Cloud Functions API.</p></div>
+* Microsoft Azure: Refer to [Microsoft Azure cloud onboarding](../../configure-cortex-xsiam/cortex-xsiam-data-sources/cloud-service-provider-csp-onboarding/microsoft-azure-cloud-onboarding) for more information about integrating Cortex XSIAM with Azure functions.
 
 {% hint style="info" %}
-### Note
-
 Only functions containing zip files are supported.
 {% endhint %}
```
▸ ▾ Serverless function posture policies modified +2 −2 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-policies

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Create and manage serverless function policies to detect threats and drive

Create and manage serverless function posture policies to detect threats and

remediation.

drive remediation in Cortex XSIAM.

---

---

# Serverless function posture policies

# Serverless function posture policies

Create and manage serverless function policies to detect threats and drive remediation.

Create and manage serverless function policies to detect threats and drive remediation.

Policies combine rules, cloud-account scope, and response actions.\

Policies combine rules, cloud-account scope, and response actions.\

Create policies by selecting rules and target accounts.\

Create policies by selecting rules and target accounts.\
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
-  Create and manage serverless function policies to detect threats and drive
-  remediation.
+  Create and manage serverless function posture policies to detect threats and
+  drive remediation in Cortex XSIAM.
 ---
 
 # Serverless function posture policies
 
 Create and manage serverless function policies to detect threats and drive remediation.
 
 Policies combine rules, cloud-account scope, and response actions.\
 Create policies by selecting rules and target accounts.\
```
▸ ▾ Create serverless function policies modified +6 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-policies/create-serverless-function-policies

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Create serverless function policies with rules and cloud account scopes in

Cortex XSIAM.

---

# Create serverless function policies

# Create serverless function policies

The following procedure describes how to create policies for serverless functions.

The following procedure describes how to create policies for serverless functions.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Policies) → click Create Policy.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Policies) → click Create Policy.

2. On the Details step of the wizard:

2. On the Details step of the wizard:

1. Fill in these fields:

1. Fill in these fields:

• Policy Name (required): An alias you provide to identify the policy

• Policy Name (required): An alias you provide to identify the policy
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Create serverless function policies with rules and cloud account scopes in
+  Cortex XSIAM.
+---
+
 # Create serverless function policies
 
 The following procedure describes how to create policies for serverless functions.
 
 1. Under **Posture Management**, select **Rules & Policies** → **Cloud Security (under Policies)** → **click Create Policy**.
 2. On the **Details** step of the wizard:
    1. Fill in these fields:
       * **Policy Name** (required): An alias you provide to identify the policy
```
▸ ▾ Manage serverless function policies modified +6 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-policies/manage-serverless-function-policies

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Manage serverless function policies, scopes, and response actions in Cortex

XSIAM.

---

# Manage serverless function policies

# Manage serverless function policies

Serverless function policies define how a system should respond to serverless function threats. They include conditions that trigger the policy, the scope of its application, and the actions to be taken when these conditions are met. When policies detect a threat, they generate issues for remediation.

Serverless function policies define how a system should respond to serverless function threats. They include conditions that trigger the policy, the scope of its application, and the actions to be taken when these conditions are met. When policies detect a threat, they generate issues for remediation.

### How to access serverless function policies

### How to access serverless function policies

1. Under Posture Management, select Rules & Policies → Cloud Security (under Policies).

1. Under Posture Management, select Rules & Policies → Cloud Security (under Policies).

2. Select the Show filter panel icon.

2. Select the Show filter panel icon.
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Manage serverless function policies, scopes, and response actions in Cortex
+  XSIAM.
+---
+
 # Manage serverless function policies
 
 Serverless function policies define how a system should respond to serverless function threats. They include conditions that trigger the policy, the scope of its application, and the actions to be taken when these conditions are met. When policies detect a threat, they generate issues for remediation.
 
 ### How to access serverless function policies
 
 1. Under **Posture Management**, select **Rules & Policies** → **Cloud Security (under Policies)**.
 2. Select the **Show filter panel** icon.
```
▸ ▾ Serverless function posture rules modified +12 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-rules

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,3 +1,15 @@

---

description: >-

Create and manage custom posture rules to identify attack paths, configuration

issues, and network exposure in serverless functions in Cortex XSIAM.

---

# Serverless function posture rules

# Serverless function posture rules

Use serverless function posture rules to identify risks in your cloud functions. Create custom rules for attack paths, configuration issues, and network exposure. Review, edit, or clone rules as your environment changes.

Use serverless function posture rules to identify risks in your cloud functions. Create custom rules for attack paths, configuration issues, and network exposure. Review, edit, or clone rules as your environment changes.

• Manage serverless function rules

• Create serverless function rules

• Create an attack path rule for serverless functions

• Create a configuration rule for serverless functions

• Create a network exposure rule for serverless functions
Show markdown source
```
@@ -1,3 +1,15 @@
+---
+description: >-
+  Create and manage custom posture rules to identify attack paths, configuration
+  issues, and network exposure in serverless functions in Cortex XSIAM.
+---
+
 # Serverless function posture rules
 
 Use serverless function posture rules to identify risks in your cloud functions. Create custom rules for attack paths, configuration issues, and network exposure. Review, edit, or clone rules as your environment changes.
+
+* [Manage serverless function rules](serverless-function-posture-rules/manage-serverless-function-rules)
+* [Create serverless function rules](serverless-function-posture-rules/create-serverless-function-rules)
+* [Create an attack path rule for serverless functions](serverless-function-posture-rules/create-an-attack-path-rule-for-serverless-functions)
+* [Create a configuration rule for serverless functions](serverless-function-posture-rules/create-a-configuration-rule-for-serverless-functions)
+* [Create a network exposure rule for serverless functions](serverless-function-posture-rules/create-a-network-exposure-rule-for-serverless-functions)
```
▸ ▾ Create a configuration rule for serverless functions modified +6 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-rules/create-a-configuration-rule-for-serverless-functions

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Create serverless function configuration rules to detect misconfigurations in

Cortex XSIAM.

---

# Create a configuration rule for serverless functions

# Create a configuration rule for serverless functions

Config rules for serverless functions identify security misconfigurations within the settings and deployment infrastructure of your individual serverless resources.

Config rules for serverless functions identify security misconfigurations within the settings and deployment infrastructure of your individual serverless resources.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Rules) → click Create Rule.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Rules) → click Create Rule.

2. Select Config.

2. Select Config.

3. On the Overview step of the Create Config Rule wizard.

3. On the Overview step of the Create Config Rule wizard.

1. Fill in these fields:

1. Fill in these fields:
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Create serverless function configuration rules to detect misconfigurations in
+  Cortex XSIAM.
+---
+
 # Create a configuration rule for serverless functions
 
 Config rules for serverless functions identify security misconfigurations within the settings and deployment infrastructure of your individual serverless resources.
 
 1. Under **Posture Management**, select **Rules & Policies** → **Cloud Security (under Rules)** → **click Create Rule**.
 2. Select **Config**.
 3. On the **Overview** step of the **Create Config Rule** wizard.
    1. Fill in these fields:
```
▸ ▾ Create a network exposure rule for serverless functions modified +6 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-rules/create-a-network-exposure-rule-for-serverless-functions

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Create serverless function network exposure rules to find internet access in

Cortex XSIAM.

---

# Create a network exposure rule for serverless functions

# Create a network exposure rule for serverless functions

Network Exposure rules allow you to monitor and control the network accessibility of your serverless functions, identifying configurations that might expose them to unwanted external traffic.

Network Exposure rules allow you to monitor and control the network accessibility of your serverless functions, identifying configurations that might expose them to unwanted external traffic.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Rules) → click Create Rule.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Rules) → click Create Rule.

2. Select Network Exposure.

2. Select Network Exposure.

3. On the Overview step of the Create Network Exposure Rule wizard.

3. On the Overview step of the Create Network Exposure Rule wizard.

1. Fill in these fields:

1. Fill in these fields:
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Create serverless function network exposure rules to find internet access in
+  Cortex XSIAM.
+---
+
 # Create a network exposure rule for serverless functions
 
 Network Exposure rules allow you to monitor and control the network accessibility of your serverless functions, identifying configurations that might expose them to unwanted external traffic.
 
 1. Under **Posture Management**, select **Rules & Policies** → **Cloud Security (under Rules)** → **click Create Rule**.
 2. Select **Network Exposure**.
 3. On the **Overview** step of the **Create Network Exposure Rule** wizard.
    1. Fill in these fields:
```
▸ ▾ Create an attack path rule for serverless functions modified +6 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-rules/create-an-attack-path-rule-for-serverless-functions

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Create serverless function attack path rules to identify connected risks in

Cortex XSIAM.

---

# Create an attack path rule for serverless functions

# Create an attack path rule for serverless functions

Attack Path policies for serverless functions identify critical risks arising from interconnected weaknesses across your serverless architecture (such as correlating findings across functions, triggers, and permissions), to expose complex attack paths revealing complex attack paths beyond individual findings.

Attack Path policies for serverless functions identify critical risks arising from interconnected weaknesses across your serverless architecture (such as correlating findings across functions, triggers, and permissions), to expose complex attack paths revealing complex attack paths beyond individual findings.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Rules) → click Create Rule.

1. Under Posture Management, select Rules & Policies → Cloud Security (under Rules) → click Create Rule.

2. Select Attack Path.

2. Select Attack Path.

3. On the Overview step of the Create Attack Path Rule wizard.

3. On the Overview step of the Create Attack Path Rule wizard.

1. Fill in these fields.

1. Fill in these fields.
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Create serverless function attack path rules to identify connected risks in
+  Cortex XSIAM.
+---
+
 # Create an attack path rule for serverless functions
 
 Attack Path policies for serverless functions identify critical risks arising from interconnected weaknesses across your serverless architecture (such as correlating findings across functions, triggers, and permissions), to expose complex attack paths revealing complex attack paths beyond individual findings.
 
 1. Under **Posture Management**, select **Rules & Policies** → **Cloud Security (under Rules)** → **click Create Rule**.
 2. Select **Attack Path**.
 3. On the **Overview** step of the **Create Attack Path Rule** wizard.
    1. Fill in these fields.
```
▸ ▾ Create serverless function rules modified +4 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-rules/create-serverless-function-rules

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,7 +1,11 @@

---

description: Create attack path, configuration, and network exposure rules in Cortex XSIAM.

---

# Create serverless function rules

# Create serverless function rules

You can create custom rules for serverless functions to suit your requirements. The following types of rules are supported:

You can create custom rules for serverless functions to suit your requirements. The following types of rules are supported:

• Attack Path: These rules monitor the high risk attack paths for potential breaches. Refer to Create an attack path rule for serverless functions for more information

• Attack Path: These rules monitor the high risk attack paths for potential breaches. Refer to Create an attack path rule for serverless functions for more information

• Config: These rules monitor resource configurations for potential breaches. Refer to Create a configuration rule for serverless functions for more information

• Config: These rules monitor resource configurations for potential breaches. Refer to Create a configuration rule for serverless functions for more information

• Network Exposure: These rules detect assets exposed to the internet. Refer to Create a network exposure rule for serverless functions for more information

• Network Exposure: These rules detect assets exposed to the internet. Refer to Create a network exposure rule for serverless functions for more information
Show markdown source
```
@@ -1,7 +1,11 @@
+---
+description: Create attack path, configuration, and network exposure rules in Cortex XSIAM.
+---
+
 # Create serverless function rules
 
 You can create custom rules for serverless functions to suit your requirements. The following types of rules are supported:
 
 * **Attack Path**: These rules monitor the high risk attack paths for potential breaches. Refer to [Create an attack path rule for serverless functions](create-an-attack-path-rule-for-serverless-functions) for more information
 * **Config**: These rules monitor resource configurations for potential breaches. Refer to [Create a configuration rule for serverless functions](create-a-configuration-rule-for-serverless-functions) for more information
 * **Network Exposure**: These rules detect assets exposed to the internet. Refer to [Create a network exposure rule for serverless functions](create-a-network-exposure-rule-for-serverless-functions) for more information
```
▸ ▾ Manage serverless function rules modified +4 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-posture-rules/manage-serverless-function-rules

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,12 @@

---

description: Manage, edit, and clone serverless function security rules in Cortex XSIAM.

---

# Manage serverless function rules

# Manage serverless function rules

Serverless function rules are designed to detect security threats within your serverless function environment that can potentially introduce vulnerabilities to its security. Serverless function rules identify and flag issues based on predefined criteria, ensuring that potential threats are proactively detected and addressed to enhance the overall security posture of your serverless functions. There are three categories or types of serverless function rules:

Serverless function rules are designed to detect security threats within your serverless function environment that can potentially introduce vulnerabilities to its security. Serverless function rules identify and flag issues based on predefined criteria, ensuring that potential threats are proactively detected and addressed to enhance the overall security posture of your serverless functions. There are three categories or types of serverless function rules:

• Attack Path: These rules identify combined risks in your serverless function configurations, like overly permissive roles and network exposure, that could be exploited to breach your serverless applications

• Attack Path: These rules identify combined risks in your serverless function configurations, like overly permissive roles and network exposure, that could be exploited to breach your serverless applications

• Config: These rules detect security resource misconfigurations in your serverless function configurations and their related code and pipeline infrastructure

• Config: These rules detect security resource misconfigurations in your serverless function configurations and their related code and pipeline infrastructure

• Network Exposure: These rules detect internet-exposed serverless functions by leveraging network configurations monitored across your cloud environment

• Network Exposure: These rules detect internet-exposed serverless functions by leveraging network configurations monitored across your cloud environment
Show markdown source
```
@@ -1,8 +1,12 @@
+---
+description: Manage, edit, and clone serverless function security rules in Cortex XSIAM.
+---
+
 # Manage serverless function rules
 
 Serverless function rules are designed to detect security threats within your serverless function environment that can potentially introduce vulnerabilities to its security. Serverless function rules identify and flag issues based on predefined criteria, ensuring that potential threats are proactively detected and addressed to enhance the overall security posture of your serverless functions. There are three categories or types of serverless function rules:
 
 * **Attack Path**: These rules identify combined risks in your serverless function configurations, like overly permissive roles and network exposure, that could be exploited to breach your serverless applications
 * **Config**: These rules detect security resource misconfigurations in your serverless function configurations and their related code and pipeline infrastructure
 * **Network Exposure**: These rules detect internet-exposed serverless functions by leveraging network configurations monitored across your cloud environment
 
```
▸ ▾ Serverless function usage modified +6 −0 xsiam/cloud-security/serverless-function-posture-security/serverless-function-usage

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Manage serverless function assets, vulnerabilities, findings, and scan health

in Cortex XSIAM.

---

# Serverless function usage

# Serverless function usage

Serverless functions is integrated as a feature across various sections of your tenant. Refer to the following sections for specific usage instructions within each context:

Serverless functions is integrated as a feature across various sections of your tenant. Refer to the following sections for specific usage instructions within each context:

### Serverless function assets

### Serverless function assets

The Serverless Functions asset inventory provides a centralized view of all serverless functions in your environment.

The Serverless Functions asset inventory provides a centralized view of all serverless functions in your environment.
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Manage serverless function assets, vulnerabilities, findings, and scan health
+  in Cortex XSIAM.
+---
+
 # Serverless function usage
 
 Serverless functions is integrated as a feature across various sections of your tenant. Refer to the following sections for specific usage instructions within each context:
 
 ### Serverless function assets
 
 The **Serverless Functions** asset inventory provides a centralized view of all serverless functions in your environment.
 
```
▸ ▾ Create custom Cortex MCP server tools modified +2 −2 The OpenAPI and Python headings were expanded to name the task, as were the CLI and use case headings on the sibling MCP server pages. xsiam/configure-cortex-xsiam/cortex-mcp-server/create-custom-cortex-mcp-server-tools

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -7,25 +7,25 @@ description: >-

# Create custom Cortex MCP server tools

# Create custom Cortex MCP server tools

You can build your own tools using OpenAPI or Python to manage cases, handle issues, and conduct investigations. More detailed information can be found in the README file located in the src/usecase directory. Tools are based on Cortex API endpoints.

You can build your own tools using OpenAPI or Python to manage cases, handle issues, and conduct investigations. More detailed information can be found in the README file located in the src/usecase directory. Tools are based on Cortex API endpoints.

To view the Cortex XSIAM API documentation, see Cortex XSIAM APIs.

To view the Cortex XSIAM API documentation, see Cortex XSIAM APIs.

Any new or updated components provided by Cortex are automatically downloaded into the builtin_components folder. During each update, the folder is fully replaced and all existing contents are recreated. Do not add custom tools to this directory, as it is managed entirely by Cortex and is overwritten at every update.

Any new or updated components provided by Cortex are automatically downloaded into the builtin_components folder. During each update, the folder is fully replaced and all existing contents are recreated. Do not add custom tools to this directory, as it is managed entirely by Cortex and is overwritten at every update.

### OpenAPI

### Create custom Cortex MCP server tools with OpenAPI

You can create an OpenAPI specification for a specific API endpoint.

You can create an OpenAPI specification for a specific API endpoint.

1. Create a YAML file in the /custom_components/openapi directory with the name of the MCP component. For example: custom_cortex_component.yaml.

1. Create a YAML file in the /custom_components/openapi directory with the name of the MCP component. For example: custom_cortex_component.yaml.

2. Base your custom OpenAPI component on the Cortex API documentation structure for a specific endpoint. We recommend viewing the built-in tools, located at /builtin_components/openapi, as a reference.

2. Base your custom OpenAPI component on the Cortex API documentation structure for a specific endpoint. We recommend viewing the built-in tools, located at /builtin_components/openapi, as a reference.

3. After you define the OpenAPI specification, the Cortex MCP server collects it automatically, and it is ready for use.

3. After you define the OpenAPI specification, the Cortex MCP server collects it automatically, and it is ready for use.

4. Test your new MCP component by running the Cortex MCP server and writing a prompt that uses your new component.

4. Test your new MCP component by running the Cortex MCP server and writing a prompt that uses your new component.

### Python

### Create custom Cortex MCP server tools with Python

We recommend using Python for more complex MCP components that require custom logic. MCP components in Python are defined in a module.

We recommend using Python for more complex MCP components that require custom logic. MCP components in Python are defined in a module.

1. Create a new Python file in the /custom_components directory.

1. Create a new Python file in the /custom_components directory.

2. Define a class that inherits from the BaseModule class with the required methods. We recommend viewing the built-in modules, located at /builtin_components, as a reference.

2. Define a class that inherits from the BaseModule class with the required methods. We recommend viewing the built-in modules, located at /builtin_components, as a reference.

3. After you define a class, the Cortex MCP server collects it automatically and it is ready for use.

3. After you define a class, the Cortex MCP server collects it automatically and it is ready for use.

4. Test your new MCP component by adding an end-to-end test in the tests/e2e directory, or run the MCP server and write a prompt that uses your new component.

4. Test your new MCP component by adding an end-to-end test in the tests/e2e directory, or run the MCP server and write a prompt that uses your new component.
Show markdown source
```
@@ -7,25 +7,25 @@ description: >-
 # Create custom Cortex MCP server tools
 
 You can build your own tools using OpenAPI or Python to manage cases, handle issues, and conduct investigations. More detailed information can be found in the README file located in the `src/usecase` directory. Tools are based on Cortex API endpoints.
 
 To view the Cortex XSIAM API documentation, see [Cortex XSIAM APIs](https://app.gitbook.com/s/1ZrobAtcwfCDWAJAWeuj/).
 
 Any new or updated components provided by Cortex are automatically downloaded into the builtin\_components folder. During each update, the folder is fully replaced and all existing contents are recreated. Do not add custom tools to this directory, as it is managed entirely by Cortex and is overwritten at every update.
 
-### **OpenAPI**
+### **Create custom Cortex MCP server tools with OpenAPI**
 
 You can create an OpenAPI specification for a specific API endpoint.
 
 1. Create a YAML file in the `/custom_components/openapi` directory with the name of the MCP component. For example: `custom_cortex_component.yaml`.
 2. Base your custom OpenAPI component on the Cortex API documentation structure for a specific endpoint. We recommend viewing the built-in tools, located at `/builtin_components/openapi`, as a reference.
 3. After you define the OpenAPI specification, the Cortex MCP server collects it automatically, and it is ready for use.
 4. Test your new MCP component by running the Cortex MCP server and writing a prompt that uses your new component.
 
-### **Python**
+### **Create custom Cortex MCP server tools with Python**
 
 We recommend using Python for more complex MCP components that require custom logic. MCP components in Python are defined in a module.
 
 1. Create a new Python file in the `/custom_components` directory.
 2. Define a class that inherits from the `BaseModule` class with the required methods. We recommend viewing the built-in modules, located at `/builtin_components`, as a reference.
 3. After you define a class, the Cortex MCP server collects it automatically and it is ready for use.
 4. Test your new MCP component by adding an end-to-end test in the `tests/e2e` directory, or run the MCP server and write a prompt that uses your new component.
```
▸ ▾ Install the Cortex MCP server modified +1 −1 xsiam/configure-cortex-xsiam/cortex-mcp-server/install-the-cortex-mcp-server

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -79,17 +79,17 @@ Poetry

3. Install project dependencies.

3. Install project dependencies.

4. Provide the required variables in the Python runtime environment.

4. Provide the required variables in the Python runtime environment.

5. Start the server: python src/main.py.

5. Start the server: python src/main.py.

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>When using the Poetry virtual environment, you can also start the server using the CLI command <code>python src/cli.py start [OPTIONS</code>, where [OPTIONS] includes the API key id, API key, the Cortex PAPI server URL, and the log level.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>When using the Poetry virtual environment, you can also start the server using the CLI command <code>python src/cli.py start [OPTIONS</code>, where [OPTIONS] includes the API key id, API key, the Cortex PAPI server URL, and the log level.</p></div>

endstep

endstep

endstepper

endstepper

### Use the CLI

### Use Cortex MCP Server CLI commands

From the CLI, you can run three commands.

From the CLI, you can run three commands.

• start: Start the Cortex MCP server. Relevant only for the Poetry virtual environment.

• start: Start the Cortex MCP server. Relevant only for the Poetry virtual environment.

• update: Any new or updated components provided by Cortex are automatically downloaded into the builtin_components folder. During each update, the folder is fully replaced, and all existing contents are recreated. Do not add custom tools to this directory, as it is managed entirely by Cortex and is overwritten at every update.

• update: Any new or updated components provided by Cortex are automatically downloaded into the builtin_components folder. During each update, the folder is fully replaced, and all existing contents are recreated. Do not add custom tools to this directory, as it is managed entirely by Cortex and is overwritten at every update.

• version: Displays the current version of the Cortex MCP Server.

• version: Displays the current version of the Cortex MCP Server.

Additional information about the CLI is available in the README file located in the src directory.

Additional information about the CLI is available in the README file located in the src directory.
Show markdown source
```
@@ -79,17 +79,17 @@ Poetry
 3. Install project dependencies.
 4. Provide the required variables in the Python runtime environment.
 5.  Start the server: `python src/main.py`.
 
     <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>When using the Poetry virtual environment, you can also start the server using the CLI command <code>python src/cli.py start [OPTIONS</code>, where [OPTIONS] includes the API key id, API key, the Cortex PAPI server URL, and the log level.</p></div>
 {% endstep %}
 {% endstepper %}
 
-### **Use the CLI**
+### **Use Cortex MCP Server CLI commands**
 
 From the CLI, you can run three commands.
 
 * `start`: Start the Cortex MCP server. Relevant only for the Poetry virtual environment.
 * `update`: Any new or updated components provided by Cortex are automatically downloaded into the builtin\_components folder. During each update, the folder is fully replaced, and all existing contents are recreated. Do not add custom tools to this directory, as it is managed entirely by Cortex and is overwritten at every update.
 * `version`: Displays the current version of the Cortex MCP Server.
 
 Additional information about the CLI is available in the README file located in the `src` directory.
```
▸ ▾ Use the Cortex MCP server modified +1 −1 xsiam/configure-cortex-xsiam/cortex-mcp-server/use-the-cortex-mcp-server

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -16,17 +16,17 @@ Built-in tools include, but are not limited to:

• get_issues: Fetch all issues, or a filtered subset of issues matching specific criteria such as domain, severity, detection method, or specific issue ID.

• get_issues: Fetch all issues, or a filtered subset of issues matching specific criteria such as domain, severity, detection method, or specific issue ID.

• get_assessment_profile_results: Fetch the results of all or filtered compliance assessments from the Cortex platform.

• get_assessment_profile_results: Fetch the results of all or filtered compliance assessments from the Cortex platform.

• get_filtered_endpoints: Fetch a filtered list of endpoints managed by the XDR agents based on their status, XDR agent status, and other filters.

• get_filtered_endpoints: Fetch a filtered list of endpoints managed by the XDR agents based on their status, XDR agent status, and other filters.

When you run the update command in the Cortex MCP server, new or updated tools provided by Cortex are automatically downloaded.

When you run the update command in the Cortex MCP server, new or updated tools provided by Cortex are automatically downloaded.

You also have the flexibility to create and customize your own tools to fit specific use cases and workflows. For more information, see Create custom Cortex MCP server tools.

You also have the flexibility to create and customize your own tools to fit specific use cases and workflows. For more information, see Create custom Cortex MCP server tools.

Use case examples

### Cortex MCP Server use case examples

hint info

hint info

The built-in tools retrieve information, but do not write to the tenant. You can create your own tools that include write actions. The examples below include both.

The built-in tools retrieve information, but do not write to the tenant. You can create your own tools that include write actions. The examples below include both.

endhint

endhint

• Show me the top ten most critical cases and create a graphical representation for my manager to review.

• Show me the top ten most critical cases and create a graphical representation for my manager to review.

• Give me the details for case ID 12345 and create a visual timeline.

• Give me the details for case ID 12345 and create a visual timeline.

• Isolate endpoint WIN-123 because it may be compromised.

• Isolate endpoint WIN-123 because it may be compromised.
Show markdown source
```
@@ -16,17 +16,17 @@ Built-in tools include, but are not limited to:
 * **get\_issues**: Fetch all issues, or a filtered subset of issues matching specific criteria such as domain, severity, detection method, or specific issue ID.
 * **get\_assessment\_profile\_results**: Fetch the results of all or filtered compliance assessments from the Cortex platform.
 * **get\_filtered\_endpoints**: Fetch a filtered list of endpoints managed by the XDR agents based on their status, XDR agent status, and other filters.
 
 When you run the `update` command in the Cortex MCP server, new or updated tools provided by Cortex are automatically downloaded.
 
 You also have the flexibility to create and customize your own tools to fit specific use cases and workflows. For more information, see [Create custom Cortex MCP server tools](create-custom-cortex-mcp-server-tools).
 
-**Use case examples**
+### **Cortex MCP Server use case examples**
 
 {% hint style="info" %}
 The built-in tools retrieve information, but do not write to the tenant. You can create your own tools that include write actions. The examples below include both.
 {% endhint %}
 
 * Show me the top ten most critical cases and create a graphical representation for my manager to review.
 * Give me the details for case ID 12345 and create a visual timeline.
 * Isolate endpoint WIN-123 because it may be compromised.
```
▸ ▾ Attack surface management modified +1 −1 xsiam/detect-investigate-and-respond-to-threats/attack-surface-management

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,12 +1,12 @@

---

---

description: >-

description: >-

Learn how to discover, monitor, and remediate external asset exposures with

Learn how to discover, monitor, and remediate external asset exposures with

attack surface management.

Cortex XSIAM attack surface management.

---

---

# Attack surface management

# Attack surface management

hint info

hint info

### Notice

### Notice

Included in Cortex XSIAM Premium. For any other XSIAM license, the ASM add-on is required.

Included in Cortex XSIAM Premium. For any other XSIAM license, the ASM add-on is required.
Show markdown source
```
@@ -1,12 +1,12 @@
 ---
 description: >-
   Learn how to discover, monitor, and remediate external asset exposures with
-  attack surface management.
+  Cortex XSIAM attack surface management.
 ---
 
 # Attack surface management
 
 {% hint style="info" %}
 ### Notice
 
 Included in Cortex XSIAM Premium. For any other XSIAM license, the ASM add-on is required.
```
▸ ▾ Attack Surface Management detections modified +6 −0 xsiam/detect-investigate-and-respond-to-threats/attack-surface-management/attack-surface-management-detections

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Learn about Cortex XSIAM Attack Surface Management detections, findings, and

issues.

---

# Attack Surface Management detections

# Attack Surface Management detections

The Attack Surface Management module creates findings and issues based on the types of detections described in the following sections:

The Attack Surface Management module creates findings and issues based on the types of detections described in the following sections:

content attack-surface-management-detections/attack-surface-rules

content attack-surface-management-detections/attack-surface-rules

attack-surface-rules

attack-surface-rules

endcontent

endcontent
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Learn about Cortex XSIAM Attack Surface Management detections, findings, and
+  issues.
+---
+
 # Attack Surface Management detections
 
 The Attack Surface Management module creates findings and issues based on the types of detections described in the following sections:
 
 {% content-ref url="attack-surface-management-detections/attack-surface-rules" %}
 [attack-surface-rules](attack-surface-management-detections/attack-surface-rules)
 {% endcontent-ref %}
 
```
▸ ▾ Attack surface rules modified +6 −0 xsiam/detect-investigate-and-respond-to-threats/attack-surface-management/attack-surface-management-detections/attack-surface-rules

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,8 +1,14 @@

---

description: >-

Cortex XSIAM ASM uses attack surface rules to identify risks, generate

findings, and manage severity.

---

# Attack surface rules

# Attack surface rules

An attack surface rule is a definition managed by Cortex XSIAM that identifies risks on a customer's attack surface. Attack Surface Rules match on ASM global scan results to detect exposed or misconfigured customer-owned assets. When an attack surface rule is enabled, Cortex XSIAM will generate findings as well as issues for observations that match that rule.

An attack surface rule is a definition managed by Cortex XSIAM that identifies risks on a customer's attack surface. Attack Surface Rules match on ASM global scan results to detect exposed or misconfigured customer-owned assets. When an attack surface rule is enabled, Cortex XSIAM will generate findings as well as issues for observations that match that rule.

To view attack surface rules, navigate to Modules → Attack Surface → Policies → Attack Surface Rules.

To view attack surface rules, navigate to Modules → Attack Surface → Policies → Attack Surface Rules.

The following table describes each field in the Attack Surface Rules table.

The following table describes each field in the Attack Surface Rules table.
Show markdown source
```
@@ -1,8 +1,14 @@
+---
+description: >-
+  Cortex XSIAM ASM uses attack surface rules to identify risks, generate
+  findings, and manage severity.
+---
+
 # Attack surface rules
 
 An _attack surface rule_ is a definition managed by Cortex XSIAM that identifies risks on a customer's attack surface. Attack Surface Rules match on ASM global scan results to detect exposed or misconfigured customer-owned assets. When an attack surface rule is enabled, Cortex XSIAM will generate findings as well as issues for observations that match that rule.
 
 To view attack surface rules, navigate to **Modules** → **Attack Surface** → **Policies** → **Attack Surface Rules**.
 
 The following table describes each field in the Attack Surface Rules table.
 
```
▸ ▾ GeoIP data collection modified +2 −2 xsiam/detect-investigate-and-respond-to-threats/attack-surface-management/get-started-with-attack-surface-management/geoip-data-collection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,9 +1,9 @@

---

---

description: >-

description: >-

Use GeoIP data to validate network distribution, identify location-based

ASM in Cortex XSIAM uses GeoIP data to validate network distribution, identify

compliance risks, and route remediation efforts.

location-based compliance risks, and route remediation efforts.

---

---

# GeoIP data collection

# GeoIP data collection

Attack Surface Management (ASM) in Cortex XSIAM geoIP data collection enables you to confirm that your actual network distribution is consistent with what you believe your global footprint to be. GeoIP data is especially important for security organizations to identify compliance violations, such as data residing in restricted locations, and to drive efficient remediations where customers leverage geoIP data to determine infrastructure location, who owns the asset, and where to route notifications.

Attack Surface Management (ASM) in Cortex XSIAM geoIP data collection enables you to confirm that your actual network distribution is consistent with what you believe your global footprint to be. GeoIP data is especially important for security organizations to identify compliance violations, such as data residing in restricted locations, and to drive efficient remediations where customers leverage geoIP data to determine infrastructure location, who owns the asset, and where to route notifications.
Show markdown source
```
@@ -1,9 +1,9 @@
 ---
 description: >-
-  Use GeoIP data to validate network distribution, identify location-based
-  compliance risks, and route remediation efforts.
+  ASM in Cortex XSIAM uses GeoIP data to validate network distribution, identify
+  location-based compliance risks, and route remediation efforts.
 ---
 
 # GeoIP data collection
 
 Attack Surface Management (ASM) in Cortex XSIAM geoIP data collection enables you to confirm that your actual network distribution is consistent with what you believe your global footprint to be. GeoIP data is especially important for security organizations to identify compliance violations, such as data residing in restricted locations, and to drive efficient remediations where customers leverage geoIP data to determine infrastructure location, who owns the asset, and where to route notifications.
```
▸ ▾ Extended Threat Intelligence modified +2 −2 xsiam/detect-investigate-and-respond-to-threats/threat-management/extended-threat-intelligence

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -17,26 +17,26 @@ XTI offers the following core capabilities:

• TI context in case and issue investigations: Cases and issues are enriched with the XTI threat intelligence, providing SOC analysts with threat intel context during case and issue investigations.

• TI context in case and issue investigations: Cases and issues are enriched with the XTI threat intelligence, providing SOC analysts with threat intel context during case and issue investigations.

• AI-driven Behavioral Threat Analysis (BTA): XTI correlates observed behaviors and evidence from security cases and issues with known threat actor Tactics, Techniques, and Procedures (TTPs).

• AI-driven Behavioral Threat Analysis (BTA): XTI correlates observed behaviors and evidence from security cases and issues with known threat actor Tactics, Techniques, and Procedures (TTPs).

• TI investigations through XQL: Build investigations and hunt queries, and correlate threat intel data with issues data through Cortex Query Language (XQL) using the full depth of XTI intelligence library.

• TI investigations through XQL: Build investigations and hunt queries, and correlate threat intel data with issues data through Cortex Query Language (XQL) using the full depth of XTI intelligence library.

• Interactive TI dashboard: Leverage the built-in XQL dashboard summarizing threat intel relevant to your organization, and clone and modify it as needed.

• Interactive TI dashboard: Leverage the built-in XQL dashboard summarizing threat intel relevant to your organization, and clone and modify it as needed.

• Indicator/IOC detections: Continuously monitor your environment for known threat indicators with automated issue generation and dynamic targeting.

• Indicator/IOC detections: Continuously monitor your environment for known threat indicators with automated issue generation and dynamic targeting.

• Threat-aware automation and response: Utilize built-in commands in playbooks to automate TI triage, enrichment, and response.

• Threat-aware automation and response: Utilize built-in commands in playbooks to automate TI triage, enrichment, and response.

• Accessible TI with AgentiX: Natural language assistance for TI search and explanations powered by AgentiX.

• Accessible TI with AgentiX: Natural language assistance for TI search and explanations powered by AgentiX.

## What license do I need to use XTI?

## What Cortex XSIAM license do I need to use XTI?

To use XTI, you must have one of the following:

To use XTI, you must have one of the following:

• The Cortex XSIAM Premium license, or

• The Cortex XSIAM Premium license, or

• Another Cortex XSIAM license with the Extended Threat Intelligence (XTI) add-on or the Advanced SOC add-on.

• Another Cortex XSIAM license with the Extended Threat Intelligence (XTI) add-on or the Advanced SOC add-on.

If you have the correct license, you can access Cortex XTI by navigating to Threat Management → Threat Intelligence.

If you have the correct license, you can access Cortex XTI by navigating to Threat Management → Threat Intelligence.

## Permissions required for XTI

## Permissions required for XTI in Cortex XSIAM

XTI requires View or View/Edit RBAC permissions for Threat Intelligence in the Threat Management component tab.

XTI requires View or View/Edit RBAC permissions for Threat Intelligence in the Threat Management component tab.

Using indicator rules requires View or View/Edit RBAC permissions for both Threat Intelligence and Rules in the Threat Management component tab.

Using indicator rules requires View or View/Edit RBAC permissions for both Threat Intelligence and Rules in the Threat Management component tab.

Using XTI with platform features such as cases and issues or dashboards requires additional feature-specific permissions.

Using XTI with platform features such as cases and issues or dashboards requires additional feature-specific permissions.

## Accessing XTI when using TIM and XTI

## Accessing XTI when using TIM and XTI
Show markdown source
```
@@ -17,26 +17,26 @@ XTI offers the following core capabilities:
 * **TI context in case and issue investigations:** Cases and issues are enriched with the XTI threat intelligence, providing SOC analysts with threat intel context during case and issue investigations.
 * **AI-driven Behavioral Threat Analysis (BTA):** XTI correlates observed behaviors and evidence from security cases and issues with known threat actor Tactics, Techniques, and Procedures (TTPs).
 * **TI investigations through XQL:** Build investigations and hunt queries, and correlate threat intel data with issues data through Cortex Query Language (XQL) using the full depth of XTI intelligence library.
 * **Interactive TI dashboard:** Leverage the built-in XQL dashboard summarizing threat intel relevant to your organization, and clone and modify it as needed.
 * **Indicator/IOC detections:** Continuously monitor your environment for known threat indicators with automated issue generation and dynamic targeting.
 * **Threat-aware automation and response:** Utilize built-in commands in playbooks to automate TI triage, enrichment, and response.
 * **Accessible TI with AgentiX:** Natural language assistance for TI search and explanations powered by AgentiX.
 
-## What license do I need to use XTI?
+## What Cortex XSIAM license do I need to use XTI?
 
 To use XTI, you must have one of the following:
 
 * The Cortex XSIAM Premium license, or
 * Another Cortex XSIAM license with the Extended Threat Intelligence (XTI) add-on or the Advanced SOC add-on.
 
 If you have the correct license, you can access Cortex XTI by navigating to **Threat Management → Threat Intelligence**.
 
-## Permissions required for XTI
+## Permissions required for XTI in Cortex XSIAM
 
 XTI requires **View** or **View/Edit** RBAC permissions for **Threat Intelligence** in the **Threat Management** component tab.
 
 Using indicator rules requires **View** or **View/Edit** RBAC permissions for both **Threat Intelligence** and **Rules** in the **Threat Management** component tab.
 
 Using XTI with platform features such as cases and issues or dashboards requires additional feature-specific permissions.
 
 ## Accessing XTI when using TIM and XTI
```

▸ About Cortex CLI modified +4 −4 xsiam/reference-and-developer-docs/about-cortex-cli

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -28,12 +28,12 @@ The Cortex CLI consolidates multi-domain security scanning into a single executa

• Container security (CWP): Generates Software Bill of Materials (SBOMs) and detects vulnerabilities or malware in container images before registry push. Container scanning integrates directly into CI builds to prevent vulnerable images from reaching production registries

• API risk validation: Identifies vulnerabilities, sensitive data leaks, and configuration errors by analyzing OpenAPI and Swagger specifications. API testing validates application endpoints for high-risk vulnerabilities and specification leaks as a standard step prior to deployment

• Automated security guardrails: Enforces compliance directly within CI/CD pipelines by dynamically blocking deployments that violate organizational security policies

## Prerequisites

Before installing and running the Cortex CLI, verify that your environment and account meet the following system and access requirements:

Prerequisite│Description

| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

License│An active Cortex Cloud license with the Application Security add-on for Code Security if required

Permissions│The API key must be associated with a user or role that has CLI Tools permissions:

View: grants read-only access (sufficient for --upload-mode no-upload).This role is not supported for CWP, as the CWP system does not support offline mode.
View/Edit: grants full access including scan result upload (required for --upload-mode upload and --upload-mode no-code)

There are no preconfigured CLI-specific roles. Add the CLI Tools permission to an existing role or create a dedicated custom role.

Permissions│The API key must be associated with a user or role that has CLI Tools permissions:

View: grants read-only access (sufficient for --upload-mode no-upload).
This role is not supported for CWP, as the CWP system does not support offline mode.
View/Edit: grants full access including scan result upload (required for --upload-mode upload and --upload-mode no-code)

There are no preconfigured CLI-specific roles. Add the CLI Tools permission to an existing role or create a dedicated custom role.

Show markdown source

@@ -28,12 +28,12 @@ The Cortex CLI consolidates multi-domain security scanning into a single executa
 * **Container security (CWP)**: Generates Software Bill of Materials (SBOMs) and detects vulnerabilities or malware in container images before registry push. Container scanning integrates directly into CI builds to prevent vulnerable images from reaching production registries
 * **API risk validation**: Identifies vulnerabilities, sensitive data leaks, and configuration errors by analyzing OpenAPI and Swagger specifications. API testing validates application endpoints for high-risk vulnerabilities and specification leaks as a standard step prior to deployment
 * **Automated security guardrails**: Enforces compliance directly within CI/CD pipelines by dynamically blocking deployments that violate organizational security policies
 
 ## Prerequisites
 
 Before installing and running the Cortex CLI, verify that your environment and account meet the following system and access requirements:
 
-| Prerequisite | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
-| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| License      | An active Cortex Cloud license with the Application Security add-on for Code Security if required                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
-| Permissions  | <p>The API key must be associated with a user or role that has <strong>CLI Tools</strong> permissions:</p><ul><li><strong>View</strong>: grants read-only access (sufficient for <code>--upload-mode no-upload</code>).This role is not supported for CWP, as the CWP system does not support offline mode.</li><li><strong>View/Edit</strong>: grants full access including scan result upload (required for <code>--upload-mode upload</code> and --<code>upload-mode no-code</code>)</li></ul><p>There are no preconfigured CLI-specific roles. Add the CLI Tools permission to an existing role or create a dedicated custom role.</p> |
+| Prerequisite | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| License      | An active Cortex Cloud license with the Application Security add-on for Code Security if required                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| Permissions  | <p>The API key must be associated with a user or role that has <strong>CLI Tools</strong> permissions:</p><ul><li><p><strong>View</strong>: grants read-only access (sufficient for <code>--upload-mode no-upload</code>).</p><p>This role is not supported for CWP, as the CWP system does not support offline mode.</p></li><li><strong>View/Edit</strong>: grants full access including scan result upload (required for <code>--upload-mode upload</code> and --<code>upload-mode no-code</code>)</li></ul><p>There are no preconfigured CLI-specific roles. Add the CLI Tools permission to an existing role or create a dedicated custom role.</p> |

▸ ▾ Connect Cortex CLI modified +63 −254 Inline install, manage and download-script instructions were cut in favour of links to the existing subpages, and SCA runtime and suppression requirements were added. xsiam/reference-and-developer-docs/about-cortex-cli/connect-cortex-cli

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,81 +1,64 @@

# Connect Cortex CLI

# Connect Cortex CLI

Connect Cortex CLI to scan supported Cortex Cloud modules and gain insights into your security posture, enabling you to identify, analyze and address potential risks.

Connect Cortex CLI to scan supported Cortex Cloud modules and gain insights into your security posture, enabling you to identify, analyze and address potential risks.

## Installation workflows

## Prerequisites and requirements

You can choose from three main installation workflows:

• Package Manager: The most efficient developer workflow, utilizing Homebrew for macOS/Linux and Scoop for Windows

• Manual download: Directly download the binaries for any operating system

• UI-based installation: Onboard and download the CLI directly from your tenant

## Prerequisites

### System requirements

### System requirements

#### macOS

tabs

tab macOS

On Intel Core i7 Macs, such as Sequoia, install vectorscan:

On Intel Core i7 Macs, such as Sequoia, install vectorscan:

```bash

```bash

brew install vectorscan

brew install vectorscan

```

```

endtab

#### Linux

tab Linux

• RHEL 8.10 and Red Hat UBI 9: Install patchelf and zstd.

• RHEL 8.10 and Red Hat UBI 9: Install patchelf and zstd.

• Ubuntu 20: Install prefetch.

• Ubuntu 20: Install prefetch.

• Ubuntu linux-amd64: Install libhyperscan5.

• Ubuntu linux-amd64: Install libhyperscan5.

```bash

```bash

sudo apt install libhyperscan5

sudo apt install libhyperscan5

```

```

endtab

AppSec Module support

tab Windows

The AppSec Module supports these Linux environments:

• RHEL 10: Kernel 6.12, glibc 2.39

• Debian 12: Kernel 6.1.27, glibc 2.36

• Ubuntu 18.04: Kernel 4.15, glibc 2.27

• Ubuntu 20.04: Kernel 5.4, glibc 2.31

• Ubuntu 22.04: Kernel 5.15, glibc 2.35

• Ubuntu 24.04: Kernel 6.8, glibc 2.39

#### Windows

Windows supports AMD64 and ARM64 architectures.

Windows supports AMD64 and ARM64 architectures.

Cortex Cloud IDE extension

Cortex Cloud IDE extension

If you run terminal actions from a Cortex Cloud IDE extension, use Command Prompt. PowerShell is unsupported for these actions.

If you run terminal actions from a Cortex Cloud IDE extension, use Command Prompt. PowerShell is unsupported for these actions.

endtab

endtabs

### Utility requirements for cURL-based downloads

### Utility requirements for cURL-based downloads

Install both curl and jq. Install jq for your platform:

Install both curl and jq. Install jq for your platform:

tabs

tabs

tab Ubuntu or Debian

tab macOS

```bash

```bash

sudo apt-get install jq

brew install jq

```

```

endtab

endtab

tab Red Hat, CentOS, or Fedora

tab Ubuntu or Debian

```bash

```bash

sudo yum install jq

sudo apt-get install jq

```

```

endtab

endtab

tab macOS

tab Red Hat, CentOS, or Fedora

```bash

```bash

brew install jq

sudo yum install jq

```

```

endtab

endtab

tab Windows

tab Windows

Download jq from jq GitHub releases, or run:

Download jq from jq GitHub releases, or run:

```bash

```bash

choco install jq

choco install jq

@@ -87,261 +70,80 @@ choco install jq

* **API key:** The CLI authenticates with an API key. No CLI roles exist by default. Ensure the key's role has the required permissions

* **API key:** The CLI authenticates with an API key. No CLI roles exist by default. Ensure the key's role has the required permissions

* **API Security level:** Set the API key security level to `Standard`. Scans fail with the `Advanced` level

* **API Security level:** Set the API key security level to `Standard`. Scans fail with the `Advanced` level

* **Local scans only:** Use a role with `CLI Read Only` read-only permissions

* **Local scans only:** Use a role with `CLI Read Only` read-only permissions

* **Upload results:** Use a role with `CLI View/Edit` write permissions

* **Upload results:** Use a role with `CLI View/Edit` write permissions

For permission details, see [Cortex CLI]().

For permission details, see [Cortex CLI]().

### SCA suppression requirements

Configure how the CLI uses your API key in [Authenticate credentials](connect-cortex-cli/authenticate-credentials).

These practices are required for SCA vulnerability suppression:

* Run the CLI from the current working directory. Use its absolute path.

* Set `--repo-id` to `<repo_owner_name>/<repo_name>`.

* Exact match: The `<repo_name>` in your parameter **must** precisely match the exact name of your local directory.

For example, when the working directory is `Users/test/<repo_name>`, use:

```bash

--repo-id /

```

## Workflow 1: Install through a package manager

Using a package manager is the recommended method for installing the Cortex CLI. Use `Homebrew` (for macOS and Linux) or `Scoop` (for Windows).

### Homebrew for macOS and Linux

Supported on macOS (Apple Silicon & Intel) and Linux (x86\_64 & arm64).

Requires [Homebrew](https://brew.sh/).

#### Standard installation

```programlisting

brew tap paloaltonetworks/cortexcli

brew install cortexcli

cortexcli --version

```

#### Pin a specific version (optional)

If your workflow requires a specific version, use one of these methods.

**Pin a release line**

For example, stay on the `0.18.x` release line.

This locks the CLI to a minor version. Security patches continue automatically.

```programlisting

brew install cortexcli@0.18

# keg-only — add to PATH if needed:

echo 'export PATH="$(brew --prefix cortexcli@0.18)/bin:$PATH"' >> ~/.zprofile

```

**Pin an exact version**

For example, install exactly `0.18.0`.

This locks the CLI to one build. It prevents automatic updates.

### Scoop for Windows

Supported on Windows x64.

Requires [Scoop](https://scoop.sh/).

#### Standard installation

```programlisting

Generate API keys in the UI, or use the self-service workflow to create role-restricted CLI and IDE keys through the Public API. The self-service workflow uses a Primary API key. See [Self-service API keys for CLI scans](connect-cortex-cli/self-service-api-keys-for-cli-scans).

scoop bucket add cortexcli https://github.com/PaloAltoNetworks/homebrew-cortexcli

scoop install cortexcli

cortexcli --version

```

#### Install a specific version (optional)

If your workflow requires a specific version, use:

```programlisting

scoop install cortexcli@0.18.0

```

## Workflow 2: Manual download (any OS)

You can manually download the binaries for macOS, Linux, or Windows.

Download the archive from the [releases page](https://github.com/PaloAltoNetworks/homebrew-cortexcli/releases). Verify it against `SHA256SUMS`, then extract it.

| Step | macOS / Linux | Windows |

| ----------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------- |

| **Download** | Download the `.tar.gz` archive for your architecture | Download the `.zip` archive |

| **Extract** | The executable is named `cortexcli` | The executable is named `cortexcli.exe` |

| **Add to `PATH`** | Move `cortexcli` to a directory such as `/usr/local/bin/` | Move `cortexcli.exe` to a dedicated folder. Add that folder to **Environment Variables** |

## Workflow 3: UI-based installation

Install the CLI directly from your Cortex tenant. The UI generates a tenant-specific command that downloads and authenticates the binary.

{% stepper %}

{% step %}

### Generate the installation command

1. Navigate to **Settings** → **Data Sources** → **+ Data Source**.

2. Search for **Cortex CLI**.

3. Select **Connect** or **Connect Another Instance** on the Cortex CLI card.

4. In **Configure**, select your operating system. Then click **Next**.

5. In **Authenticate**, generate an API key.

* Select **With upload results permissions** to create a **CLI View/Edit** role.

* Otherwise, the key receives a **CLI Read Only** role with **CLI View** permissions.

{% hint style="info" %}

The Cortex CLI requires an API key with the `Standard` security level.

{% endhint %}

6. Save the generated **API Key ID** and **API key**.

7. Copy the command from **Retrieve your API key**.

{% hint style="info" %}

On macOS ARM64, unpack the download to access the executable.

{% endhint %}

8. Verify the key appears in the API Keys inventory.

## Installation workflows

{% endstep %}

{% step %}

### Download the CLI

Before you run the command, replace any placeholders with your credentials:

1. Replace `${API_KEY}` with the saved API key.

2. If needed, copy the API URL from **Settings** → **Configurations** → **API Keys**.

3. Paste the completed command into your terminal. Then press Enter.

The generated command follows this syntax:

```programlisting

curl -k -u $CORTEX_API_ID::$CORTEX_API_KEY --output ./cortexcli $CORTEX_FQDN/api/v2/remote-li/{version}/{platform}/artifacts

```

This securely connects to your specific Cortex tenant (`$CORTEX_FQDN`) and downloads the `cortexcli` application directly to your current folder.

{% endstep %}

{% step %}

### Make the CLI executable

On macOS and Linux, allow the downloaded binary to run:

```programlisting

chmod +x cortexcli

```

{% endstep %}

{% step %}

### Verify the installation

Run the command that matches the binary location:

{% tabs %}

{% tab title="On your PATH" %}

```programlisting

cortexcli -v

```

{% endtab %}

{% tab title="Current directory" %}

You can choose from three main installation workflows:

```programlisting

./cortexcli -v

```

{% endtab %}

{% endtabs %}

If the terminal displays a version, return to Cortex Cloud and click **Done**.

* [Package manager](installation-workflows#install-through-a-package-manager): The recommended developer workflow. Use Homebrew on macOS or Linux, or Scoop on Windows

{% endstep %}

* [Manual download](installation-workflows#manual-download): Download binaries directly for any operating system

{% endstepper %}

* [UI-based installation](installation-workflows#ui-based-installation): Download and authenticate the CLI from your tenant

## Manage the CLI after installation

## Post-installation configuration

After installation, manage the CLI with a package manager or download script. Use either method in CI/CD pipelines or local end-user environments.

After installation, you can upgrade, pin, uninstall, or update Cortex CLI through automated downloads. Refer to [manage the CLI](connect-cortex-cli/manage-the-cli-after-installation) for more information.

### Package managers

## Module-specific requirements

#### macOS and Linux

### AppSec module support

* **Upgrade to the latest version**

#### Supported Linux environments

```programlisting

The AppSec module supports these Linux environments:

brew upgrade cortexcli

```

* **Pin the installed version**

```programlisting

* **RHEL 10:** Kernel `6.12`, glibc `2.39`

brew pin cortexcli

* **Debian 12:** Kernel `6.1.27`, glibc `2.36`

```

* **Ubuntu 18.04:** Kernel `4.15`, glibc `2.27`

* **Uninstall the CLI**

* **Ubuntu 20.04:** Kernel `5.4`, glibc `2.31`

* **Ubuntu 22.04:** Kernel `5.15`, glibc `2.35`

* **Ubuntu 24.04:** Kernel `6.8`, glibc `2.39`

```programlisting

#### SCA requirements

brew uninstall cortexcli

```

#### Windows

**Runtime requirements**

* **Upgrade to the latest version**

Install these runtime layers on the host running Cortex Unified CLI:

```programlisting

* **Layer 1 (the baseline):** `Node.js v22+` is enforced. It is required to boot the SCA engine.

scoop update cortexcli

* **Layer 2 (per-ecosystem toolchain):** Install the native language runtime or package manager for the code being scanned. Without the matching toolchain, the SCA engine cannot resolve dependencies.

```

* **Prevent upgrades**

```programlisting

| Scanned project type | Additional toolchain needed locally, beyond Node v22 |

scoop hold cortexcli

| -------------------- | ---------------------------------------------------- |

```

| Java (Maven) | JDK and `mvn` |

* **Allow upgrades again**

| Java (Gradle) | JDK and `gradle` |

| .NET | .NET SDK (`dotnet`) |

| Python | Python and `pip` or `pipenv` |

| Ruby | Ruby and `bundler` |

| Go | Go toolchain |

| JavaScript/Node | `npm` or `yarn` (covered by Node v22) |

```programlisting

**Suppression requirements**

scoop unhold cortexcli

```

* **Uninstall the CLI**

```programlisting

These practices are required for SCA vulnerability suppression:

scoop uninstall cortexcli

```

### Automate binary downloads

* Run the CLI from the current working directory. Use its absolute path.

* Set `--repo-id` to `<repo_owner_name>/<repo_name>`.

* Exact match: The `<repo_name>` in your parameter **must** precisely match the exact name of your local directory.

Use this script for a manual installation. It downloads the latest release for your operating system and architecture. Replace your existing binary with the downloaded file. On macOS and Linux, make it executable with `chmod +x`.

For example, when the working directory is `Users/test/<repo_name>`, use:

```programlisting

```bash

crtx_resp=$(curl --fail "/public_api/v1/unified-cli/releases/download-link?os=&architecture=" \

--repo-id <repo_owner_name>/<repo_name>

-H "x-xdr-auth-id: " \

-H "Authorization: ${CORTEX_API_KEY}") \

&& crtx_url=$(echo $crtx_resp jq -r ".signed_url") \

&& crtx_file=$(echo $crtx_resp jq -r ".file_name") \

&& curl -o $crtx_file $crtx_url

```

```

#### Replace the placeholders

• CORTEX_API_KEY: Your API key

• <CORTEX_API_URL>: Your tenant API base URL

• <AUTH_ID>: Your API key ID value

• <OS>: Your operating system — linux, darwin, or windows

• <ARCH>: Your system architecture — such as amd64 or arm64

#### How the script works

The script:

1. Requests a signed download link from Cortex Cloud for the latest release matching your OS and architecture.

2. Uses jq to extract the signed URL and binary filename.

3. Downloads the binary from the signed URL.

## Troubleshooting

## Troubleshooting

### cortexcli --version shows an unexpected version

### cortexcli --version shows an unexpected version

An older cortexcli binary may appear earlier in your PATH. This can come from a .pkg installer, manual download, or tenant download.

An older cortexcli binary may appear earlier in your PATH. This can come from a .pkg installer, manual download, or tenant download.

#### Find every installed copy

#### Find every installed copy

@@ -369,8 +171,15 @@ The package-managed binary should be at one of these locations:

#### Remove the older copy

#### Remove the older copy

• macOS .pkg installer: Run sudo rm /usr/local/bin/cortexcli.

• macOS .pkg installer: Run sudo rm /usr/local/bin/cortexcli.

• Manual or tenant download: Delete the binary path returned by the command.

• Manual or tenant download: Delete the binary path returned by the command.

• Windows installer: Uninstall it in Settings → Apps → Installed apps.

• Windows installer: Uninstall it in Settings → Apps → Installed apps.

Open a new terminal. Then run cortexcli --version again.

Open a new terminal. Then run cortexcli --version again.

## Learn more

• Installation workflows

• Manage the CLI after installation

• Authenticate credentials

• Self-service API keys for CLI scans
Show markdown source
```
@@ -1,81 +1,64 @@
 # Connect Cortex CLI
 
 Connect Cortex CLI to scan supported Cortex Cloud modules and gain insights into your security posture, enabling you to identify, analyze and address potential risks.
 
-## Installation workflows
-
-You can choose from three main installation workflows:
-
-* [Package Manager](#workflow-1-install-through-a-package-manager): The most efficient developer workflow, utilizing Homebrew for macOS/Linux and Scoop for Windows
-* [Manual download](#workflow-2-manual-download-any-os): Directly download the binaries for any operating system
-* [UI-based installation](#workflow-3-ui-based-installation): Onboard and download the CLI directly from your tenant
-
-## Prerequisites
+## Prerequisites and requirements
 
 ### System requirements
 
-#### macOS
-
+{% tabs %}
+{% tab title="macOS" %}
 On Intel Core i7 Macs, such as Sequoia, install `vectorscan`:
 
 ```bash
 brew install vectorscan
 ```
+{% endtab %}
 
-#### Linux
-
+{% tab title="Linux" %}
 * **RHEL 8.10 and Red Hat UBI 9:** Install `patchelf` and `zstd`.
 * **Ubuntu 20:** Install `prefetch`.
 *   **Ubuntu linux-amd64:** Install `libhyperscan5`.
 
     ```bash
     sudo apt install libhyperscan5
     ```
+{% endtab %}
 
-**AppSec Module support**
-
-The AppSec Module supports these Linux environments:
-
-* **RHEL 10:** Kernel `6.12`, glibc `2.39`
-* **Debian 12:** Kernel `6.1.27`, glibc `2.36`
-* **Ubuntu 18.04:** Kernel `4.15`, glibc `2.27`
-* **Ubuntu 20.04:** Kernel `5.4`, glibc `2.31`
-* **Ubuntu 22.04:** Kernel `5.15`, glibc `2.35`
-* **Ubuntu 24.04:** Kernel `6.8`, glibc `2.39`
-
-#### Windows
-
+{% tab title="Windows" %}
 Windows supports AMD64 and ARM64 architectures.
 
 **Cortex Cloud IDE extension**
 
 If you run terminal actions from a Cortex Cloud IDE extension, use Command Prompt. PowerShell is unsupported for these actions.
+{% endtab %}
+{% endtabs %}
 
 ### Utility requirements for cURL-based downloads
 
 Install both `curl` and `jq`. Install `jq` for your platform:
 
 {% tabs %}
-{% tab title="Ubuntu or Debian" %}
+{% tab title="macOS" %}
 ```bash
-sudo apt-get install jq
+brew install jq
 ```
 {% endtab %}
 
-{% tab title="Red Hat, CentOS, or Fedora" %}
+{% tab title="Ubuntu or Debian" %}
 ```bash
-sudo yum install jq
+sudo apt-get install jq
 ```
 {% endtab %}
 
-{% tab title="macOS" %}
+{% tab title="Red Hat, CentOS, or Fedora" %}
 ```bash
-brew install jq
+sudo yum install jq
 ```
 {% endtab %}
 
 {% tab title="Windows" %}
 Download `jq` from [jq GitHub releases](https://github.com/stedolan/jq/releases), or run:
 
 ```bash
 choco install jq
@@ -87,261 +70,80 @@ choco install jq
 
 * **API key:** The CLI authenticates with an API key. No CLI roles exist by default. Ensure the key's role has the required permissions
 * **API Security level:** Set the API key security level to `Standard`. Scans fail with the `Advanced` level
 * **Local scans only:** Use a role with `CLI Read Only` read-only permissions
 * **Upload results:** Use a role with `CLI View/Edit` write permissions
 
 For permission details, see [Cortex CLI]().
 
-### SCA suppression requirements
-
-These practices are required for SCA vulnerability suppression:
-
-* Run the CLI from the current working directory. Use its absolute path.
-* Set `--repo-id` to `<repo_owner_name>/<repo_name>`.
-* Exact match: The `<repo_name>` in your parameter **must** precisely match the exact name of your local directory.
-
-For example, when the working directory is `Users/test/<repo_name>`, use:
-
-```bash
---repo-id <repo_owner_name>/<repo_name>
-```
-
-## Workflow 1: Install through a package manager
-
-Using a package manager is the recommended method for installing the Cortex CLI. Use `Homebrew` (for macOS and Linux) or `Scoop` (for Windows).
-
-### Homebrew for macOS and Linux
-
-Supported on macOS (Apple Silicon & Intel) and Linux (x86\_64 & arm64).
-
-Requires [Homebrew](https://brew.sh/).
-
-#### Standard installation
-
-```programlisting
-brew tap paloaltonetworks/cortexcli
-brew install cortexcli
-cortexcli --version
-```
-
-#### Pin a specific version (optional)
-
-If your workflow requires a specific version, use one of these methods.
-
-**Pin a release line**
-
-For example, stay on the `0.18.x` release line.
-
-This locks the CLI to a minor version. Security patches continue automatically.
-
-```programlisting
-brew install cortexcli@0.18
-# keg-only — add to PATH if needed:
-echo 'export PATH="$(brew --prefix cortexcli@0.18)/bin:$PATH"' >> ~/.zprofile
-```
-
-**Pin an exact version**
-
-For example, install exactly `0.18.0`.
-
-This locks the CLI to one build. It prevents automatic updates.
-
-### Scoop for Windows
-
-Supported on Windows x64.
-
-Requires [Scoop](https://scoop.sh/).
-
-#### Standard installation
+Configure how the CLI uses your API key in [Authenticate credentials](connect-cortex-cli/authenticate-credentials).
 
-```programlisting
-scoop bucket add cortexcli https://github.com/PaloAltoNetworks/homebrew-cortexcli
-scoop install cortexcli
-cortexcli --version
-```
-
-#### Install a specific version (optional)
-
-If your workflow requires a specific version, use:
-
-```programlisting
-scoop install cortexcli@0.18.0
-```
-
-## Workflow 2: Manual download (any OS)
-
-You can manually download the binaries for macOS, Linux, or Windows.
-
-Download the archive from the [releases page](https://github.com/PaloAltoNetworks/homebrew-cortexcli/releases). Verify it against `SHA256SUMS`, then extract it.
-
-| Step              | macOS / Linux                                             | Windows                                                                                  |
-| ----------------- | --------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
-| **Download**      | Download the `.tar.gz` archive for your architecture      | Download the `.zip` archive                                                              |
-| **Extract**       | The executable is named `cortexcli`                       | The executable is named `cortexcli.exe`                                                  |
-| **Add to `PATH`** | Move `cortexcli` to a directory such as `/usr/local/bin/` | Move `cortexcli.exe` to a dedicated folder. Add that folder to **Environment Variables** |
-
-## Workflow 3: UI-based installation
-
-Install the CLI directly from your Cortex tenant. The UI generates a tenant-specific command that downloads and authenticates the binary.
-
-{% stepper %}
-{% step %}
-### Generate the installation command
-
-1. Navigate to **Settings** → **Data Sources** → **+ Data Source**.
-2. Search for **Cortex CLI**.
-3. Select **Connect** or **Connect Another Instance** on the Cortex CLI card.
-4. In **Configure**, select your operating system. Then click **Next**.
-5. In **Authenticate**, generate an API key.
-   * Select **With upload results permissions** to create a **CLI View/Edit** role.
-   * Otherwise, the key receives a **CLI Read Only** role with **CLI View** permissions.
-
-{% hint style="info" %}
-The Cortex CLI requires an API key with the `Standard` security level.
-{% endhint %}
-
-6. Save the generated **API Key ID** and **API key**.
-7. Copy the command from **Retrieve your API key**.
-
-{% hint style="info" %}
-On macOS ARM64, unpack the download to access the executable.
-{% endhint %}
+Generate API keys in the UI, or use the self-service workflow to create role-restricted CLI and IDE keys through the Public API. The self-service workflow uses a Primary API key. See [Self-service API keys for CLI scans](connect-cortex-cli/self-service-api-keys-for-cli-scans).
 
-8. Verify the key appears in the API Keys inventory.
-{% endstep %}
-
-{% step %}
-### Download the CLI
-
-Before you run the command, replace any placeholders with your credentials:
-
-1. Replace `${API_KEY}` with the saved API key.
-2. If needed, copy the API URL from **Settings** → **Configurations** → **API Keys**.
-3. Paste the completed command into your terminal. Then press Enter.
-
-The generated command follows this syntax:
-
-```programlisting
-curl -k -u $CORTEX_API_ID::$CORTEX_API_KEY --output ./cortexcli $CORTEX_FQDN/api/v2/remote-li/{version}/{platform}/artifacts
-```
-
-This securely connects to your specific Cortex tenant (`$CORTEX_FQDN`) and downloads the `cortexcli` application directly to your current folder.
-{% endstep %}
-
-{% step %}
-### Make the CLI executable
-
-On macOS and Linux, allow the downloaded binary to run:
-
-```programlisting
-chmod +x cortexcli
-```
-{% endstep %}
-
-{% step %}
-### Verify the installation
-
-Run the command that matches the binary location:
-
-{% tabs %}
-{% tab title="On your PATH" %}
-```programlisting
-cortexcli -v
-```
-{% endtab %}
+## Installation workflows
 
-{% tab title="Current directory" %}
-```programlisting
-./cortexcli -v
-```
-{% endtab %}
-{% endtabs %}
+You can choose from three main installation workflows:
 
-If the terminal displays a version, return to Cortex Cloud and click **Done**.
-{% endstep %}
-{% endstepper %}
+* [Package manager](installation-workflows#install-through-a-package-manager): The recommended developer workflow. Use Homebrew on macOS or Linux, or Scoop on Windows
+* [Manual download](installation-workflows#manual-download): Download binaries directly for any operating system
+* [UI-based installation](installation-workflows#ui-based-installation): Download and authenticate the CLI from your tenant
 
-## Manage the CLI after installation
+## Post-installation configuration
 
-After installation, manage the CLI with a package manager or download script. Use either method in CI/CD pipelines or local end-user environments.
+After installation, you can upgrade, pin, uninstall, or update Cortex CLI through automated downloads. Refer to [manage the CLI](connect-cortex-cli/manage-the-cli-after-installation) for more information.
 
-### Package managers
+## Module-specific requirements
 
-#### macOS and Linux
+### AppSec module support
 
-*   **Upgrade to the latest version**
+#### Supported Linux environments
 
-    ```programlisting
-    brew upgrade cortexcli
-    ```
-*   **Pin the installed version**
+The AppSec module supports these Linux environments:
 
-    ```programlisting
-    brew pin cortexcli
-    ```
-*   **Uninstall the CLI**
+* **RHEL 10:** Kernel `6.12`, glibc `2.39`
+* **Debian 12:** Kernel `6.1.27`, glibc `2.36`
+* **Ubuntu 18.04:** Kernel `4.15`, glibc `2.27`
+* **Ubuntu 20.04:** Kernel `5.4`, glibc `2.31`
+* **Ubuntu 22.04:** Kernel `5.15`, glibc `2.35`
+* **Ubuntu 24.04:** Kernel `6.8`, glibc `2.39`
 
-    ```programlisting
-    brew uninstall cortexcli
-    ```
+#### SCA requirements
 
-#### Windows
+**Runtime requirements**
 
-*   **Upgrade to the latest version**
+Install these runtime layers on the host running Cortex Unified CLI:
 
-    ```programlisting
-    scoop update cortexcli
-    ```
-*   **Prevent upgrades**
+* **Layer 1 (the baseline):** `Node.js v22+` is enforced. It is required to boot the SCA engine.
+* **Layer 2 (per-ecosystem toolchain):** Install the native language runtime or package manager for the code being scanned. Without the matching toolchain, the SCA engine cannot resolve dependencies.
 
-    ```programlisting
-    scoop hold cortexcli  
-    ```
-*   **Allow upgrades again**
+| Scanned project type | Additional toolchain needed locally, beyond Node v22 |
+| -------------------- | ---------------------------------------------------- |
+| Java (Maven)         | JDK and `mvn`                                        |
+| Java (Gradle)        | JDK and `gradle`                                     |
+| .NET                 | .NET SDK (`dotnet`)                                  |
+| Python               | Python and `pip` or `pipenv`                         |
+| Ruby                 | Ruby and `bundler`                                   |
+| Go                   | Go toolchain                                         |
+| JavaScript/Node      | `npm` or `yarn` (covered by Node v22)                |
 
-    ```programlisting
-    scoop unhold cortexcli     
-    ```
-*   **Uninstall the CLI**
+**Suppression requirements**
 
-    ```programlisting
-    scoop uninstall cortexcli
-    ```
+These practices are required for SCA vulnerability suppression:
 
-### Automate binary downloads
+* Run the CLI from the current working directory. Use its absolute path.
+* Set `--repo-id` to `<repo_owner_name>/<repo_name>`.
+* Exact match: The `<repo_name>` in your parameter **must** precisely match the exact name of your local directory.
 
-Use this script for a manual installation. It downloads the latest release for your operating system and architecture. Replace your existing binary with the downloaded file. On macOS and Linux, make it executable with `chmod +x`.
+For example, when the working directory is `Users/test/<repo_name>`, use:
 
-```programlisting
-crtx_resp=$(curl --fail "<CORTEX_API_URL>/public_api/v1/unified-cli/releases/download-link?os=<OS>&architecture=<ARCH>" \
-  -H "x-xdr-auth-id: <AUTH_ID>" \
-  -H "Authorization: ${CORTEX_API_KEY}") \
-  && crtx_url=$(echo $crtx_resp | jq -r ".signed_url") \
-  && crtx_file=$(echo $crtx_resp | jq -r ".file_name") \
-  && curl -o $crtx_file $crtx_url
+```bash
+--repo-id <repo_owner_name>/<repo_name>
 ```
 
-#### Replace the placeholders
-
-* `CORTEX_API_KEY`: Your API key
-* `<CORTEX_API_URL>`: Your tenant API base URL
-* `<AUTH_ID>`: Your API key ID value
-* `<OS>`: Your operating system — `linux`, `darwin`, or `windows`
-* `<ARCH>`: Your system architecture — such as `amd64` or `arm64`
-
-#### How the script works
-
-The script:
-
-1. Requests a signed download link from Cortex Cloud for the latest release matching your OS and architecture.
-2. Uses `jq` to extract the signed URL and binary filename.
-3. Downloads the binary from the signed URL.
-
 ## Troubleshooting
 
 ### `cortexcli --version` shows an unexpected version
 
 An older `cortexcli` binary may appear earlier in your `PATH`. This can come from a `.pkg` installer, manual download, or tenant download.
 
 #### Find every installed copy
 
@@ -369,8 +171,15 @@ The package-managed binary should be at one of these locations:
 
 #### Remove the older copy
 
 * **macOS `.pkg` installer:** Run `sudo rm /usr/local/bin/cortexcli`.
 * **Manual or tenant download:** Delete the binary path returned by the command.
 * **Windows installer:** Uninstall it in **Settings** → **Apps** → **Installed apps**.
 
 Open a new terminal. Then run `cortexcli --version` again.
+
+## Learn more
+
+* [Installation workflows](connect-cortex-cli/installation-workflows)
+* [Manage the CLI after installation](connect-cortex-cli/manage-the-cli-after-installation)
+* [Authenticate credentials](connect-cortex-cli/authenticate-credentials)
+* [Self-service API keys for CLI scans](connect-cortex-cli/self-service-api-keys-for-cli-scans)
```
▸ ▾ Manage the CLI after installation modified +10 −0 xsiam/reference-and-developer-docs/about-cortex-cli/connect-cortex-cli/manage-the-cli-after-installation

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -33,16 +33,26 @@ Manage Cortex CLI with a package manager or download script. Use either method i

```programlisting

```programlisting

scoop update cortexcli

scoop update cortexcli

```

```

• Prevent upgrades

• Prevent upgrades

```programlisting

```programlisting

scoop hold cortexcli

scoop hold cortexcli

```

```

• Allow upgrades again

```programlisting

scoop unhold cortexcli

```

• Uninstall the CLI

```programlisting

scoop uninstall cortexcli

```

## Automate binary downloads

## Automate binary downloads

Use this script for a manual installation. It downloads the latest release for your operating system and architecture. Replace your existing binary with the downloaded file. On macOS and Linux, make it executable with chmod +x.

Use this script for a manual installation. It downloads the latest release for your operating system and architecture. Replace your existing binary with the downloaded file. On macOS and Linux, make it executable with chmod +x.

```programlisting

```programlisting

crtx_resp=$(curl --fail "<CORTEX_API_URL>/public_api/v1/unified-cli/releases/download-link?os=<OS>&architecture=<ARCH>" \

crtx_resp=$(curl --fail "<CORTEX_API_URL>/public_api/v1/unified-cli/releases/download-link?os=<OS>&architecture=<ARCH>" \

-H "x-xdr-auth-id: <AUTH_ID>" \

-H "x-xdr-auth-id: <AUTH_ID>" \
Show markdown source
```
@@ -33,16 +33,26 @@ Manage Cortex CLI with a package manager or download script. Use either method i
     ```programlisting
     scoop update cortexcli
     ```
 *   **Prevent upgrades**
 
     ```programlisting
     scoop hold cortexcli
     ```
+*   **Allow upgrades again**
+
+    ```programlisting
+    scoop unhold cortexcli
+    ```
+*   **Uninstall the CLI**
+
+    ```programlisting
+    scoop uninstall cortexcli
+    ```
 
 ## Automate binary downloads
 
 Use this script for a manual installation. It downloads the latest release for your operating system and architecture. Replace your existing binary with the downloaded file. On macOS and Linux, make it executable with `chmod +x`.
 
 ```programlisting
 crtx_resp=$(curl --fail "<CORTEX_API_URL>/public_api/v1/unified-cli/releases/download-link?os=<OS>&architecture=<ARCH>" \
   -H "x-xdr-auth-id: <AUTH_ID>" \
```
▸ ▾ Self-service API keys for CLI scans modified +1 −1 xsiam/reference-and-developer-docs/about-cortex-cli/connect-cortex-cli/self-service-api-keys-for-cli-scans

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,11 +1,11 @@

# Self-service API keys for CLI scans

# Self-service API keys for CLI scans

This self-service model allows developers to programmatically generate task-specific keys for CLI and IDE scans via the Public API. By using a Primary API key as a master credential, developers can provision restricted-access keys, such as read-only for local scans, without requiring administrative permissions in the UI. This approach maintains tenant security by ensuring all scans follow the principle of least privilege.

This self-service model uses a Primary API key as its master credential. It lets developers programmatically generate task-specific CLI and IDE keys through the Public API. Developers can provision restricted-access keys, such as read-only keys for local scans, without administrative UI permissions. This keeps each scan within the principle of least privilege.

## Prerequisite

## Prerequisite

You must have sufficient administrative permissions within your tenant to create new roles and manage API keys.

You must have sufficient administrative permissions within your tenant to create new roles and manage API keys.

IMPORTANT: When generating an API key, ensure you select the Standard security level. CLI scans will fail if the security level of the API key is set to Advanced.

IMPORTANT: When generating an API key, ensure you select the Standard security level. CLI scans will fail if the security level of the API key is set to Advanced.

## Create custom roles

## Create custom roles
Show markdown source
```
@@ -1,11 +1,11 @@
 # Self-service API keys for CLI scans
 
-This self-service model allows developers to programmatically generate task-specific keys for CLI and IDE scans via the Public API. By using a Primary API key as a master credential, developers can provision restricted-access keys, such as `read-only` for local scans, without requiring administrative permissions in the UI. This approach maintains tenant security by ensuring all scans follow the principle of least privilege.
+This self-service model uses a Primary API key as its master credential. It lets developers programmatically generate task-specific CLI and IDE keys through the Public API. Developers can provision restricted-access keys, such as `read-only` keys for local scans, without administrative UI permissions. This keeps each scan within the principle of least privilege.
 
 ## Prerequisite
 
 You must have sufficient administrative permissions within your tenant to create new roles and manage API keys.
 
 **IMPORTANT**: When generating an API key, ensure you select the Standard security level. CLI scans will fail if the security level of the API key is set to Advanced.
 
 ## Create custom roles
```

▸ Cortex CLI common command line reference guide modified +13 −9 --log-level, --version and --log gained environment variables ($MIN_LOG_LEVEL, $CORTEX_CLI_VERSION, $LOG_FILE), and the module references were listed in a callout. xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-common-command-line-reference-guide

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,41 +1,45 @@

# Cortex CLI common command line reference guide

This reference guide describes the command line flags used to manage the Cortex Cloud Application Security (AppSec), Cloud Workload Protection (CWP), and API Security modules through the Cortex CLI. It includes common flags, which apply to all supported modules, and global flags, which are shared specifically across AppSec and CWP and must be placed before the command. In instances where the same flag is available in both categories, its underlying functionality remains identical; however, its required placement within the command structure differs depending on how it is used.

Use these command-line flags to manage Cortex Cloud Application Security (AppSec), Cloud Workload Protection (CWP), and API Security through the Cortex CLI. Common flags apply to all supported modules. Global flags are shared across AppSec and CWP and must appear before the command. When a flag appears in both categories, it works the same way but requires different placement.

hint info

Module-specific flags are documented in their module references:

• cortex-cli-application-security-command-line-reference

• cloud-workload-protection-command-line-reference

• cortex-cli-api-security-command-line-reference-guide

endhint

## Common flags

The following table describes CLI commands common to all supported Cortex CLI modules.

hint warning

These flags are typically used after the module and command.

endhint

Command│Description

| ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

--api-base-url / $CORTEX_API_BASE_URL│Required: true. The public facing API URL. To retrieve the URL, under Settings, select Configurations → API Keys copy API URL

--api-key / $CORTEX_API_KEY│Required: true. The API key used for authorization

--api-key-id / $CORTEX_API_KEY_ID│Required: true.The API key ID

--support / $SUPPORT│Enable debug logs and upload the logs to the platform. Usage: Before the module name.EXAMPLE

cortexcli --api-base-url <URL> --api-key <KEY> --api-key-id <ID> --support code scan directory. --upload-mode no-upload --repo-id my/test --branch test

--support / $SUPPORT│Enable debug logs and upload the logs to the platform. Usage: Before the module name.
Example:

cortexcli --api-base-url <URL> --api-key <KEY> --api-key-id <ID> --support code scan directory. --upload-mode no-upload --repo-id my/test --branch test

--log-level│Set the logging level (INFO, WARNING, ERROR, DEBUG) for Stdout output

--log-level / $MIN_LOG_LEVEL│Set the logging level (INFO, WARNING, ERROR, DEBUG) for Stdout output

--http-proxy / $HTTP_PROXY│The HTTP proxy server URL to route traffic through

--https-proxy / $HTTPS_PROXY│The HTTPS proxy server URL to route traffic through

--ca-certificate / $CORTEX_CODE_CA_CERTIFICATE│Required: No

Path to a custom CA certificate (bundle) file, in PEM format, used for TLS certificate verification. It is intended for environments that use a corporate proxy or perform TLS interception, where the standard system CA bundle does not contain the intercepting proxy's certificate.
EXAMPLE: cortexcli --ca-certificate /path/to/ca-bundle.pem code scan --directory

--ca-certificate / $CORTEX_CODE_CA_CERTIFICATE│Required: No

--no-cert-verify / $CORTEX_CODE_NO_CERT_VERIFY / $NO_CERT_VERIFY│This flag disables TLS/SSL certificate verification (default: false). Skips TLS certificate verification when connecting to the API. Not recommended for production. Use only in test or development environments, as this reduces connection security

--help│Displays usage information, available subcommands, global flags, and flag descriptions for the Cortex CLI or any specific subcommand. Run --help at any level of the command hierarchy to discover available options:• cortexcli --help: Lists all available modules (AppSec, CWP, WAAS), global flags, and getting-started guidance.• Authentication: The --help flag works without API key authentication. No credentials, network connectivity, or platform access are required. This allows developers to explore the CLI interface before configuring authentication

--version│Retrieves the version of the Cortex CLI currently in use

--version / $CORTEX_CLI_VERSION│Retrieves the version of the Cortex CLI currently in use

## Global flags

The following table describes global CLI flags that are common specifically to the Application Security (AppSec) and Cloud Workload Protection (CWP) modules.

hint warning

These flags must be placed before the command.

endhint

Command│Description

| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

--upload-mode / $CORTEX_UPLOAD_MODE│Controls whether scan results are uploaded to the Cortex Cloud platform.

Accepts placement in both the global position (cortexcli --upload-mode no-upload code scan) and the command position (cortexcli code scan --upload-mode no-upload). The global position takes priority over the command position.

Accepted values:

• upload: Uploads results to the platform and triggers policy evaluation

• no-upload: Executes scanners locally without uploading results. Enables --severity filtering

• no-code: Uploads results without uploading source code

--upload-mode / $CORTEX_UPLOAD_MODE│Controls whether scan results are uploaded to the Cortex Cloud platform.

Accepted values:

• upload: Uploads results to the platform and triggers policy evaluation

• no-upload: Executes scanners locally without uploading results. Enables --severity filtering

• no-code: Uploads results without uploading source code

--soft-fail / $CORTEX_SOFT_FAIL│

Required: false.

Allows CI/CD pipelines to continue without disruption by returning a successful exit code (0) when scan errors are detected.

Visibility: Unlike skipped or suppressed checks, soft-fail errors remain fully reported in the output
Thresholds: Failed checks are evaluated against the defined severity threshold. If multiple severities are specified, the highest acts as the threshold
Exceptions: Fundamental execution errors (such as exit codes 126 or 127) are not suppressed and will still fail the build

--soft-fail / $CORTEX_SOFT_FAIL│

Required: false.

Allows CI/CD pipelines to continue without disruption by returning a successful exit code (0) when scan errors are detected.

Visibility: Unlike skipped or suppressed checks, soft-fail errors remain fully reported in the output
Thresholds: Failed checks are evaluated against the defined severity threshold. If multiple severities are specified, the highest acts as the threshold
Exceptions: Fundamental execution errors (such as exit codes 126 or 127) are not suppressed and will still fail the build

--no-fail-on-crash / $CORTEX_NO_FAIL_ON_CRASH│

Prevents the CLI from returning a non-zero exit code during internal errors (such as scanner crashes or network timeouts), ensuring CI/CD pipeline continuity even if a scan fails.

When to use: Enable in production pipelines where build availability takes priority over scan enforcement
EXAMPLE: Prevents a temporary Cortex Cloud platform outage from blocking all organizational builds
Best Practice: Combine with --log to ensure internal errors are still captured for post-incident review
Exceptions: Signal-based exit codes (126, 127, 128+) indicating the CLI itself failed to execute are never suppressed and require immediate investigation
IMPORTANT: The environment variable changed from $CORTEX_CODE_NO_FAIL_ON_CRASH to $CORTEX_NO_FAIL_ON_CRASH during the framework migration. Ensure CI/CD pipeline configurations referencing the previous variable name are updated

--no-fail-on-crash / $CORTEX_NO_FAIL_ON_CRASH│

Prevents the CLI from returning a non-zero exit code during internal errors (such as scanner crashes or network timeouts), ensuring CI/CD pipeline continuity even if a scan fails.

When to use: Enable in production pipelines where build availability takes priority over scan enforcement
EXAMPLE: Prevents a temporary Cortex Cloud platform outage from blocking all organizational builds
Best Practice: Combine with --log to ensure internal errors are still captured for post-incident review
Exceptions: Signal-based exit codes (126, 127, 128+) indicating the CLI itself failed to execute are never suppressed and require immediate investigation
IMPORTANT: The environment variable changed from $CORTEX_CODE_NO_FAIL_ON_CRASH to $CORTEX_NO_FAIL_ON_CRASH during the framework migration. Ensure CI/CD pipeline configurations referencing the previous variable name are updated

--log│Displays the path to the log file after command execution. Use this to troubleshoot CI/CD failures or provide details for support cases. By default, logs are stored at ~/.cortexcli/cortexcli-log/.

Log rotation: Includes automatic log rotation (10 MB per file, 3 backups, 24-hour retention)

--log / $LOG_FILE│Displays the path to the log file after command execution. Use this to troubleshoot CI/CD failures or provide details for support cases. By default, logs are stored at ~/.cortexcli/cortexcli-log/.

Log rotation: Includes automatic log rotation (10 MB per file, 3 backups, 24-hour retention)

--help│See --help flag under Common flags above

Show markdown source

@@ -1,41 +1,45 @@
 # Cortex CLI common command line reference guide
 
-This reference guide describes the command line flags used to manage the Cortex Cloud Application Security (AppSec), Cloud Workload Protection (CWP), and API Security modules through the Cortex CLI. It includes [common flags](#common-flags), which apply to all supported modules, and [global flags](#global-flags), which are shared specifically across AppSec and CWP and must be placed before the command. In instances where the same flag is available in both categories, its underlying functionality remains identical; however, its required placement within the command structure differs depending on how it is used.
+Use these command-line flags to manage Cortex Cloud Application Security (AppSec), Cloud Workload Protection (CWP), and API Security through the Cortex CLI. [Common flags](#common-flags) apply to all supported modules. [Global flags](#global-flags) are shared across AppSec and CWP and must appear before the command. When a flag appears in both categories, it works the same way but requires different placement.
+
+{% hint style="info" %}
+Module-specific flags are documented in their module references:
+
+* [cortex-cli-application-security-command-line-reference](cortex-cli-for-code-security/cortex-cli-application-security-command-line-reference "mention")
+* [cloud-workload-protection-command-line-reference](cortex-cli-for-cloud-workload-protection/cloud-workload-protection-command-line-reference "mention")
+* [cortex-cli-api-security-command-line-reference-guide](cortex-cli-for-api-security/cortex-cli-api-security-command-line-reference-guide "mention")
+{% endhint %}
 
 ## Common flags
 
 The following table describes CLI commands common to all supported Cortex CLI modules.
 
-{% hint style="warning" %}
-These flags are typically used **after** the module and command.
-{% endhint %}
-
 | Command                                                                | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `--api-base-url` / `$CORTEX_API_BASE_URL`                              | **Required: true**. The public facing API URL. To retrieve the URL, under Settings, select Configurations → API Keys copy API URL                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | `--api-key` / `$CORTEX_API_KEY`                                        | **Required: true**. The API key used for authorization                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | `--api-key-id` / `$CORTEX_API_KEY_ID`                                  | **Required: true**.The API key ID                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| `--support` / `$SUPPORT`                                               | Enable debug logs and upload the logs to the platform. Usage: Before the module name.**EXAMPLE**`cortexcli --api-base-url <URL> --api-key <KEY> --api-key-id <ID> --support code scan directory. --upload-mode no-upload --repo-id my/test --branch test`                                                                                                                                                                                                                                                                                                                         |
-| `--log-level`                                                          | Set the logging level (INFO, WARNING, ERROR, DEBUG) for Stdout output                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
+| `--support` / `$SUPPORT`                                               | <p>Enable debug logs and upload the logs to the platform. Usage: Before the module name.<br><strong>Example:</strong><br><code>cortexcli --api-base-url &#x3C;URL> --api-key &#x3C;KEY> --api-key-id &#x3C;ID> --support code scan directory. --upload-mode no-upload --repo-id my/test --branch test</code></p>                                                                                                                                                                                                                                                                  |
+| `--log-level` / `$MIN_LOG_LEVEL`                                       | Set the logging level (INFO, WARNING, ERROR, DEBUG) for Stdout output                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
 | `--http-proxy` / `$HTTP_PROXY`                                         | The HTTP proxy server URL to route traffic through                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | `--https-proxy` / `$HTTPS_PROXY`                                       | The HTTPS proxy server URL to route traffic through                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | `--ca-certificate` / `$CORTEX_CODE_CA_CERTIFICATE`                     | <p>Required: No</p><p>Path to a custom CA certificate (bundle) file, in PEM format, used for TLS certificate verification. It is intended for environments that use a corporate proxy or perform TLS interception, where the standard system CA bundle does not contain the intercepting proxy's certificate.<br>EXAMPLE: <code>cortexcli --ca-certificate /path/to/ca-bundle.pem code scan --directory</code></p>                                                                                                                                                                |
 | `--no-cert-verify` / `$CORTEX_CODE_NO_CERT_VERIFY` / `$NO_CERT_VERIFY` | This flag disables TLS/SSL certificate verification (default: false). Skips TLS certificate verification when connecting to the API. **Not recommended for production**. Use only in test or development environments, as this reduces connection security                                                                                                                                                                                                                                                                                                                        |
 | `--help`                                                               | Displays usage information, available subcommands, global flags, and flag descriptions for the Cortex CLI or any specific subcommand. Run `--help` at any level of the command hierarchy to discover available options:• `cortexcli --hel`p: Lists all available modules (AppSec, CWP, WAAS), global flags, and getting-started guidance.• **Authentication**: The --help flag works without API key authentication. No credentials, network connectivity, or platform access are required. This allows developers to explore the CLI interface before configuring authentication |
-| `--version`                                                            | Retrieves the version of the Cortex CLI currently in use                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| `--version` / `$CORTEX_CLI_VERSION`                                    | Retrieves the version of the Cortex CLI currently in use                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
 
 ## Global flags
 
 The following table describes global CLI flags that are common specifically to the Application Security (AppSec) and Cloud Workload Protection (CWP) modules.
 
 {% hint style="warning" %}
 These flags must be placed **before** the command.
 {% endhint %}
 
 | Command                                           | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
 | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `--upload-mode` / `$CORTEX_UPLOAD_MODE`           | <p>Controls whether scan results are uploaded to the Cortex Cloud platform.</p><p>Accepts placement in both the global position (<code>cortexcli --upload-mode no-upload code scan</code>) and the command position (<code>cortexcli code scan --upload-mode no-upload</code>). The global position takes priority over the command position.</p><p><strong>Accepted values</strong>:</p><p>• <code>upload</code>: Uploads results to the platform and triggers policy evaluation</p><p>• <code>no-upload</code>: Executes scanners locally without uploading results. Enables --severity filtering</p><p>• <code>no-code</code>: Uploads results without uploading source code</p>                                                                                                                                                                                                                                                                                                                                                                              |
 | `--soft-fail` / `$CORTEX_SOFT_FAIL`               | <p><strong>Required: false</strong>.</p><p>Allows CI/CD pipelines to continue without disruption by returning a successful exit code (<code>0</code>) when scan errors are detected.</p><ul><li><strong>Visibility</strong>: Unlike skipped or suppressed checks, soft-fail errors remain fully reported in the output</li><li><strong>Thresholds</strong>: Failed checks are evaluated against the defined severity threshold. If multiple severities are specified, the highest acts as the threshold</li><li><strong>Exceptions</strong>: Fundamental execution errors (such as exit codes 126 or 127) are not suppressed and will still fail the build</li></ul>                                                                                                                                                                                                                                                                                                                                                                                             |
 | `--no-fail-on-crash` / `$CORTEX_NO_FAIL_ON_CRASH` | <p>Prevents the CLI from returning a non-zero exit code during internal errors (such as scanner crashes or network timeouts), ensuring CI/CD pipeline continuity even if a scan fails.</p><ul><li><strong>When to use</strong>: Enable in production pipelines where build availability takes priority over scan enforcement</li><li>EXAMPLE: Prevents a temporary Cortex Cloud platform outage from blocking all organizational builds</li><li><strong>Best Practice</strong>: Combine with <code>--log</code> to ensure internal errors are still captured for post-incident review</li><li><strong>Exceptions</strong>: Signal-based exit codes (126, 127, 128+) indicating the CLI itself failed to execute are <em>never</em> suppressed and require immediate investigation</li><li>IMPORTANT: The environment variable changed from <code>$CORTEX_CODE_NO_FAIL_ON_CRASH</code> to <code>$CORTEX_NO_FAIL_ON_CRASH</code> during the framework migration. Ensure CI/CD pipeline configurations referencing the previous variable name are updated</li></ul> |
-| `--log`                                           | <p>Displays the path to the log file after command execution. Use this to troubleshoot CI/CD failures or provide details for support cases. By default, logs are stored at <code>~/.cortexcli/cortexcli-log/</code>.</p><p>Log rotation: Includes automatic log rotation (10 MB per file, 3 backups, 24-hour retention)</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `--log` / `$LOG_FILE`                             | <p>Displays the path to the log file after command execution. Use this to troubleshoot CI/CD failures or provide details for support cases. By default, logs are stored at <code>~/.cortexcli/cortexcli-log/</code>.</p><p>Log rotation: Includes automatic log rotation (10 MB per file, 3 backups, 24-hour retention)</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
 | `--help`                                          | See `--help` flag under Common flags above                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |

▸ ▾ Cortex CLI API Security command line reference guide modified +1 −1 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-api-security/cortex-cli-api-security-command-line-reference-guide

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,11 +1,11 @@

# Cortex CLI API Security command line reference guide

# Cortex CLI API Security command line reference guide

This reference guide describes the dedicated API Security commands and flags, including the structure of base commands and subcommands. Refer to Cortex CLI common command line reference guide for Cortex CLI commands common to all supported modules.

Use these API Security-specific commands and flags to run scans with the Cortex CLI. Refer to Cortex CLI common command line reference guide for common flags that apply across all supported modules.

Value│Description

Value│Description

| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |

| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |

--scanned-app-url (string)│Base URL of the app to scan (required)

--scanned-app-url (string)│Base URL of the app to scan (required)

--api-spec-file (string)│Path to the API specification file (required)

--api-spec-file (string)│Path to the API specification file (required)

--api-spec-type (string)│Type of the API specification ('openapi) (default "openapi")

--api-spec-type (string)│Type of the API specification ('openapi) (default "openapi")

--auth-file (string)│Path to the authentication file (optional). For more information on authentication, refer to Cortex CLI for API Security

--auth-file (string)│Path to the authentication file (optional). For more information on authentication, refer to Cortex CLI for API Security

--concurrency (int)│Concurrency limit for scan requests (default 5)

--concurrency (int)│Concurrency limit for scan requests (default 5)
Show markdown source
```
@@ -1,11 +1,11 @@
 # Cortex CLI API Security command line reference guide
 
-This reference guide describes the dedicated API Security commands and flags, including the structure of base commands and subcommands. Refer to [Cortex CLI common command line reference guide](../cortex-cli-common-command-line-reference-guide) for Cortex CLI commands common to all supported modules.
+Use these API Security-specific commands and flags to run scans with the Cortex CLI. Refer to [Cortex CLI common command line reference guide](../cortex-cli-common-command-line-reference-guide) for common flags that apply across all supported modules.
 
 | Value                        | Description                                                                                                                  |
 | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
 | `--scanned-app-url` (string) | Base URL of the app to scan (required)                                                                                       |
 | `--api-spec-file` (string)   | Path to the API specification file (required)                                                                                |
 | `--api-spec-type` (string)   | Type of the API specification ('openapi) (default "openapi")                                                                 |
 | `--auth-file` (string)       | Path to the authentication file (optional). For more information on authentication, refer to [Cortex CLI for API Security]() |
 | `--concurrency` (int)        | Concurrency limit for scan requests (default 5)                                                                              |
```
▸ ▾ Cortex CLI for Cloud Workload Protection modified +7 −29 A duplicated CWP command table was removed from the end of the page and the reference link now points at the CWP subpage rather than a same-page anchor. xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-cloud-workload-protection

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -9,17 +9,17 @@ Integrate Cloud Workload Protection (CWP) scans for secrets, vulnerabilities and

• Onboard and install the Cortex CLI. Refer to Connect Cortex CLI for more information

• Onboard and install the Cortex CLI. Refer to Connect Cortex CLI for more information

• Verify that Java version 11 and above is installed: Run java -version in your terminal. If not, refer to Java SE Development Kit 11.0.25 for information about installing Java

• Verify that Java version 11 and above is installed: Run java -version in your terminal. If not, refer to Java SE Development Kit 11.0.25 for information about installing Java

endhint

endhint

## Run CWP security scans

## Run CWP security scans

The cortexcli image scan command allows you to perform CWP scans on container images. By default, cortexcli scans images directly from your local Docker daemon's repository. You can also specify an image archive file to scan instead.

The cortexcli image scan command allows you to perform CWP scans on container images. By default, cortexcli scans images directly from your local Docker daemon's repository. You can also specify an image archive file to scan instead.

### Prerequisite

### Prerequisite

Before you begin, ensure you have sudo privileges to execute the image scan.

Before you begin, ensure you have sudo privileges to execute the image scan.

hint info

hint info

### Note

### Note

CWP does not support container image secret scanning for systems running on ARM architecture.

CWP does not support container image secret scanning for systems running on ARM architecture.

endhint

endhint

@@ -39,39 +39,39 @@ The image scan accepts the following arguments:

• --api-base-url: Required - true. The public facing API URL. Refer to Connect Cortex CLI for more information

• --api-base-url: Required - true. The public facing API URL. Refer to Connect Cortex CLI for more information

• --api-key: Required - true. Your Cortex Cloud API key. Refer to Connect Cortex CLI for more information

• --api-key: Required - true. Your Cortex Cloud API key. Refer to Connect Cortex CLI for more information

• --api-key-id: Required - true. Your Cortex Cloud API key ID

• --api-key-id: Required - true. Your Cortex Cloud API key ID

• image scan: Required - true. Refers to CWP as the type of scan

• image scan: Required - true. Refers to CWP as the type of scan

hint info

hint info

### Note

### Note

For available CWP commands, refer to Cloud Workload Protection command line reference.

For available CWP commands, refer to Cloud Workload Protection command line reference.

endhint

endhint

EXAMPLE

EXAMPLE

```programlisting

```programlisting

./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image scan docker.io/library/nginx:latest

./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image scan docker.io/library/nginx:latest

```

```

EXAMPLE with custom Docker socket path

EXAMPLE

```programlisting

```programlisting

./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image scan --docker-host unix:///var/snap/docker/common/run/docker.sock my-custom-image:latest

./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image scan --docker-host unix:///var/snap/docker/common/run/docker.sock my-custom-image:latest

```

```

By default, Cortex XSIAM looks for the Docker socket at unix:///var/run/docker.sock.

By default, Cortex Cloud looks for the Docker socket at unix:///var/run/docker.sock.

--docker-host <path> specifies the path to the Docker socket. Use this flag if your Docker socket is located elsewhere, for example unix:///var/snap/docker/common/run/docker.sock.

--docker-host <path> specifies the path to the Docker socket. Use this flag if your Docker socket is located elsewhere, for example unix:///var/snap/docker/common/run/docker.sock.

### Scan from an image archive file

### Scan from an image archive file

hint warning

hint warning

### Preerquisite

### Danger

Before you begin, ensure you have sudo privileges to execute the image scan.

Before you begin, ensure you have sudo privileges to execute the image scan.

endhint

endhint

To scan an image from a previously saved archive file (such as a .tar file), use the --archive flag:

To scan an image from a previously saved archive file (such as a .tar file), use the --archive flag:

```programlisting

```programlisting

./cortexcli --api-base-url <API URL> --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image scan --archive <archive file of container image>

./cortexcli --api-base-url <API URL> --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image scan --archive <archive file of container image>

@@ -91,19 +91,17 @@ This example demonstrates how to create an image archive from your Docker or Pod

* With Docker: `docker save -o ubuntu.tar ubuntu`

* With Docker: `docker save -o ubuntu.tar ubuntu`

* With Podman: `podman save --format oci-archive -o /tmp/alpine-oci.tar alpine:latest`

* With Podman: `podman save --format oci-archive -o /tmp/alpine-oci.tar alpine:latest`

## Export SBOM

## Export SBOM

You can generate a Software Bill of Materials (SBOM) for your container images using the Cortex CLI and and save the output to a specified file. This functionality enables you to store the SBOM for further analysis, auditing, and compliance.

You can generate a Software Bill of Materials (SBOM) for your container images using the Cortex CLI and and save the output to a specified file. This functionality enables you to store the SBOM for further analysis, auditing, and compliance.

By default, this will retrieve the SBOM for an image from your local Docker daemon.

### Export SBOM from local Docker daemon

### Export from local Docker daemon

To export an SBOM for an image from your local Docker daemon:

To export an SBOM for an image from your local Docker daemon:

```programlisting

```programlisting

./cortexcli --api-base-url --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image sbom [command options]

./cortexcli --api-base-url --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image sbom [command options]

```

```

**Command**: `cortexcli image sbom`: Exports a Software Bill of Materials (SBOM) document for a container image archive.

**Command**: `cortexcli image sbom`: Exports a Software Bill of Materials (SBOM) document for a container image archive.

@@ -119,44 +117,24 @@ To export an SBOM for an image from your local Docker daemon:

* -`-help`, `-h`: Displays help information for the command

* -`-help`, `-h`: Displays help information for the command

EXAMPLE

EXAMPLE

```programlisting

```programlisting

./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image sbom docker.io/library/alpine:latest

./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image sbom docker.io/library/alpine:latest

```

```

### Export from an image archive file

### Export from an image archive

To export an SBOM from an image archive file, use the `--archive` flag:

To export an SBOM from an image archive file, use the `--archive` flag:

```programlisting

```programlisting

./cortexcli --api-base-url --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image sbom --archive

./cortexcli --api-base-url --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image sbom --archive

```

```

**NAME**: `cortexcli image sbom` - Exports an SBOM document for an image from the local Docker daemon or an image archive.

**NAME**: `cortexcli image sbom` - Exports an SBOM document for an image from the local Docker daemon or an image archive.

**USAGE**: `cortexcli image sbom` \[command options] \[image name or archive file].

**USAGE**: `cortexcli image sbom` \[command options] \[image name or archive file].

## Troubleshooting

## Troubleshooting

* **Docker socket not reachable**: If you encounter errors indicating the Docker socket cannot be reached, ensure the Docker daemon is running and verify the path to your Docker socket. If it's not in the default location (`unix:///var/run/docker.sock`), use the `--docker-host` flag to specify the correct path

* **Docker socket not reachable**: If you encounter errors indicating the Docker socket cannot be reached, ensure the Docker daemon is running and verify the path to your Docker socket. If it's not in the default location (`unix:///var/run/docker.sock`), use the `--docker-host` flag to specify the correct path

* **Image not found**: If you attempt to scan an image directly from the Docker daemon and receive an error that the image does not exist, confirm that the image is indeed present in your local Docker repository by running `docker images`. The CLI will not pull images

* **Image not found**: If you attempt to scan an image directly from the Docker daemon and receive an error that the image does not exist, confirm that the image is indeed present in your local Docker repository by running `docker images`. The CLI will not pull images

This reference guide documents the Cloud Workload Protection commands and flags for the Cortex CLI, including the structure of base commands and subcommands. Refer to [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide) for Cortex CLI commands common to all supported modules.

<details>

<summary>Read more...</summary>

| Command | Description |

| ---------------------- | -------------------------------------------------------------------------------------------------- |

| --image scan | Scans a container image archive |

| --ci-pipeline-id value | The CI pipeline identifier |

| --ci-build-id value | The CI build identifier |

| --timeout value | Timeout (in seconds) after which the scan will be terminated if it has not completed (default: 60) |

| --output-format value | Output format options: `human-readable`, `json` (default: human-readable) |

| --archive-format value | The image archive format options: `docker-archive`, `oci-archive` (default: docker-archive) |

| --name value | The name assigned to the image |

| --docker-host \<path> | Specifies the path to the Docker socket |

| --archive | Specifies that the image scan should use an archive file |

</details>
Show markdown source
```
@@ -9,17 +9,17 @@ Integrate Cloud Workload Protection (CWP) scans for secrets, vulnerabilities and
 * Onboard and install the Cortex CLI. Refer to [Connect Cortex CLI](connect-cortex-cli) for more information
 * Verify that `Java` version 11 and above is installed: Run `java -version` in your terminal. If not, refer to [Java SE Development Kit 11.0.25](https://www.oracle.com/java/technologies/downloads/#java11?er=221886) for information about installing Java
 {% endhint %}
 
 ## Run CWP security scans
 
 The `cortexcli image scan` command allows you to perform CWP scans on container images. By default, `cortexcli` scans images directly from your local Docker daemon's repository. You can also specify an image archive file to scan instead.
 
-### **Prerequisite**
+### Prerequisite
 
 Before you begin, ensure you have `sudo` privileges to execute the image scan.
 
 {% hint style="info" %}
 ### Note
 
 CWP does not support container image secret scanning for systems running on ARM architecture.
 {% endhint %}
@@ -39,39 +39,39 @@ The image scan accepts the following arguments:
 * `--api-base-url`: Required - true. The public facing API URL. Refer to [Connect Cortex CLI](connect-cortex-cli) for more information
 * `--api-key`: Required - true. Your Cortex Cloud API key. Refer to [Connect Cortex CLI](connect-cortex-cli) for more information
 * `--api-key-id`: Required - true. Your Cortex Cloud API key ID
 * `image scan`: Required - true. Refers to CWP as the type of scan
 
 {% hint style="info" %}
 ### Note
 
-For available CWP commands, refer to [Cloud Workload Protection command line reference](#cloud-workload-protection-command-line-reference).
+For available CWP commands, refer to [Cloud Workload Protection command line reference](cortex-cli-for-cloud-workload-protection/cloud-workload-protection-command-line-reference).
 {% endhint %}
 
 EXAMPLE
 
 ```programlisting
 ./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image scan docker.io/library/nginx:latest
 ```
 
-EXAMPLE with custom Docker socket path
+EXAMPLE
 
 ```programlisting
 ./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image scan --docker-host unix:///var/snap/docker/common/run/docker.sock my-custom-image:latest
 ```
 
-By default, Cortex XSIAM looks for the Docker socket at `unix:///var/run/docker.sock`.
+By default, Cortex Cloud looks for the Docker socket at `unix:///var/run/docker.sock`.
 
 `--docker-host <path>` specifies the path to the Docker socket. Use this flag if your Docker socket is located elsewhere, for example `unix:///var/snap/docker/common/run/docker.sock`.
 
 ### Scan from an image archive file
 
 {% hint style="warning" %}
-### Preerquisite
+### Danger
 
 Before you begin, ensure you have sudo privileges to execute the image scan.
 {% endhint %}
 
 To scan an image from a previously saved archive file (such as a .tar file), use the `--archive` flag:
 
 ```programlisting
 ./cortexcli --api-base-url <API URL> --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image scan --archive <archive file of container image>
@@ -91,19 +91,17 @@ This example demonstrates how to create an image archive from your Docker or Pod
 
 * With Docker: `docker save -o ubuntu.tar ubuntu`
 * With Podman: `podman save --format oci-archive -o /tmp/alpine-oci.tar alpine:latest`
 
 ## Export SBOM
 
 You can generate a Software Bill of Materials (SBOM) for your container images using the Cortex CLI and and save the output to a specified file. This functionality enables you to store the SBOM for further analysis, auditing, and compliance.
 
-By default, this will retrieve the SBOM for an image from your local Docker daemon.
-
-### Export from local Docker daemon
+### Export SBOM from local Docker daemon
 
 To export an SBOM for an image from your local Docker daemon:
 
 ```programlisting
 ./cortexcli --api-base-url <API URL> --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image sbom <image name> [command options]
 ```
 
 **Command**: `cortexcli image sbom`: Exports a Software Bill of Materials (SBOM) document for a container image archive.
@@ -119,44 +117,24 @@ To export an SBOM for an image from your local Docker daemon:
 * -`-help`, `-h`: Displays help information for the command
 
 EXAMPLE
 
 ```programlisting
 ./cortexcli --api-base-url https://api.cortex.example.com --api-key your-api-key --api-key-id 1 image sbom docker.io/library/alpine:latest
 ```
 
-### Export from an image archive file
+### Export from an image archive
 
 To export an SBOM from an image archive file, use the `--archive` flag:
 
 ```programlisting
 ./cortexcli --api-base-url <API URL> --api-key <API key from the "Authenticate" step in the CLI connector screen> --api-key-id <API key ID from the "Authenticate" step in the CLI connector screen> image sbom --archive <archive file of container image>
 ```
 
 **NAME**: `cortexcli image sbom` - Exports an SBOM document for an image from the local Docker daemon or an image archive.
 
 **USAGE**: `cortexcli image sbom` \[command options] \[image name or archive file].
 
 ## Troubleshooting
 
 * **Docker socket not reachable**: If you encounter errors indicating the Docker socket cannot be reached, ensure the Docker daemon is running and verify the path to your Docker socket. If it's not in the default location (`unix:///var/run/docker.sock`), use the `--docker-host` flag to specify the correct path
 * **Image not found**: If you attempt to scan an image directly from the Docker daemon and receive an error that the image does not exist, confirm that the image is indeed present in your local Docker repository by running `docker images`. The CLI will not pull images
-
-This reference guide documents the Cloud Workload Protection commands and flags for the Cortex CLI, including the structure of base commands and subcommands. Refer to [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide) for Cortex CLI commands common to all supported modules.
-
-<details>
-
-<summary>Read more...</summary>
-
-| Command                | Description                                                                                        |
-| ---------------------- | -------------------------------------------------------------------------------------------------- |
-| --image scan           | Scans a container image archive                                                                    |
-| --ci-pipeline-id value | The CI pipeline identifier                                                                         |
-| --ci-build-id value    | The CI build identifier                                                                            |
-| --timeout value        | Timeout (in seconds) after which the scan will be terminated if it has not completed (default: 60) |
-| --output-format value  | Output format options: `human-readable`, `json` (default: human-readable)                          |
-| --archive-format value | The image archive format options: `docker-archive`, `oci-archive` (default: docker-archive)        |
-| --name value           | The name assigned to the image                                                                     |
-| --docker-host \<path>  | Specifies the path to the Docker socket                                                            |
-| --archive              | Specifies that the image scan should use an archive file                                           |
-
-</details>
```
▸ ▾ Cloud Workload Protection command line reference modified +1 −1 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-cloud-workload-protection/cloud-workload-protection-command-line-reference

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,11 +1,11 @@

# Cloud Workload Protection command line reference

# Cloud Workload Protection command line reference

This reference guide documents the Cloud Workload Protection commands and flags for the Cortex CLI, including the structure of base commands and subcommands. Refer to Cortex CLI common command line reference guide for Cortex CLI commands common to all supported modules.

Use these Cloud Workload Protection-specific commands and flags to run scans with the Cortex CLI. Refer to Cortex CLI common command line reference guide for common flags that apply across all supported modules and global flags shared with Application Security.

Command│Description

Command│Description

| ------------------------ | -------------------------------------------------------------------------------------------------- |

| ------------------------ | -------------------------------------------------------------------------------------------------- |

--image scan│Scans a container image archive

--image scan│Scans a container image archive

--ci-pipeline-id value│The CI pipeline identifier

--ci-pipeline-id value│The CI pipeline identifier

--ci-build-id value│The CI build identifier

--ci-build-id value│The CI build identifier

--timeout value│Timeout (in seconds) after which the scan will be terminated if it has not completed (default: 60)

--timeout value│Timeout (in seconds) after which the scan will be terminated if it has not completed (default: 60)

--output-format value│Output format options: human-readable, json (default: human-readable)

--output-format value│Output format options: human-readable, json (default: human-readable)
Show markdown source
```
@@ -1,11 +1,11 @@
 # Cloud Workload Protection command line reference
 
-This reference guide documents the Cloud Workload Protection commands and flags for the Cortex CLI, including the structure of base commands and subcommands. Refer to [Cortex CLI common command line reference guide](../cortex-cli-common-command-line-reference-guide) for Cortex CLI commands common to all supported modules.
+Use these Cloud Workload Protection-specific commands and flags to run scans with the Cortex CLI. Refer to [Cortex CLI common command line reference guide](../cortex-cli-common-command-line-reference-guide) for common flags that apply across all supported modules and global flags shared with Application Security.
 
 | Command                  | Description                                                                                        |
 | ------------------------ | -------------------------------------------------------------------------------------------------- |
 | `--image scan`           | Scans a container image archive                                                                    |
 | `--ci-pipeline-id value` | The CI pipeline identifier                                                                         |
 | `--ci-build-id value`    | The CI build identifier                                                                            |
 | `--timeout value`        | Timeout (in seconds) after which the scan will be terminated if it has not completed (default: 60) |
 | `--output-format value`  | Output format options: `human-readable`, `json` (default: human-readable)                          |
```
▸ ▾ Cortex CLI for Code Security modified +6 −6 The authentication flag list now names --api-key-id / $CORTEX_API_KEY_ID instead of --auth-id, and SCA is described as also detecting malicious packages. xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,23 +1,23 @@

# Cortex CLI for Code Security

# Cortex CLI for Code Security

Cortex CLI for Code Security scans allow developers and security teams to integrate security checks directly into their application development workflows.

Cortex CLI for Code Security scans allow developers and security teams to integrate security checks directly into their application development workflows.

The Code Security CLI supports the following scan types:

The Code Security CLI supports the following scan types:

• Secrets: Identifies exposed sensitive secrets within your codebase

• Secrets: Identifies exposed sensitive secrets within your codebase

• Infrastructure-as-Code (IaC): Analyzes infrastructure configuration files to detect potential security misconfigurations

• Infrastructure-as-Code (IaC): Analyzes infrastructure configuration files to detect potential security misconfigurations

• Software Composition Analysis (SCA): Performs vulnerability detection in third-party dependencies, assesses their license compliance and their package operational risk

• Software Composition Analysis (SCA): Performs vulnerability detection in third-party dependencies, detects malicious packages, assesses their license compliance and their package operational risk

In addition, the Code Security CLI serves as the integration mechanism for security scanning within supported CI tools such as Jenkins, GitHub Actions, and others. This is achieved by adding a code snippet containing the CLI command into the configuration files of your CI tool when integrating the CI tool with Cortex Cloud. It acts as a wrapper, enabling security scanning within your pipelines, and direct upload of results to the platform.

In addition, the Code Security CLI serves as the integration mechanism for security scanning within supported CI tools such as Jenkins, GitHub Actions, and others. This is achieved by adding a code snippet containing the CLI command into the configuration files of your CI tool when integrating the CI tool with Cortex Cloud. It acts as a wrapper, enabling security scanning within your pipelines, and direct upload of results to the platform.

## Code Security CLI scan behavior and output

## Code Security CLI scan behavior and output

• Scans generate assets (see Code Security assets, issues, and findings

• Scans generate assets (see Code and CI/CD assets, issues, and findings

• If one scanner (such as Secrets) fails, the other scanners will continue to run and produce results

• If one scanner (such as Secrets) fails, the other scanners will continue to run and produce results

• Scan failures trigger an error message indicating the scanner that failed

• Scan failures trigger an error message indicating the scanner that failed

• The Code Security CLI provides these output modes for management and viewing of scan results:

• The Code Security CLI provides these output modes for management and viewing of scan results:

• Upload to platform: --upload-mode = upload (default). Uploads scan results directly to the platform for centralized analysis and management

• Upload to platform: --upload-mode = upload (default). Uploads scan results directly to the platform for centralized analysis and management

• Upload findings only. --upload-mode = no-code. Upload findings, but without including the actual source code content. This prevents raw source code from leaving your local environment or being stored on the platform

• Upload findings only. --upload-mode = no-code. Upload findings, but without including the actual source code content. This prevents raw source code from leaving your local environment or being stored on the platform

• CLI output only: --upload-mode=no-upload. View scan results directly in your command-line interface without being uploaded to the platform

• CLI output only: --upload-mode=no-upload. View scan results directly in your command-line interface without being uploaded to the platform

@@ -38,32 +38,32 @@ The CLI supports the following outputs:

## Authentication

## Authentication

To authenticate the Code Security CLI, choose one of the following methods:

To authenticate the Code Security CLI, choose one of the following methods:

• Local developer workflows: Run manual, ad-hoc scans on your local machine to catch vulnerabilities and misconfigurations before committing code to your version control system

• Local developer workflows: Run manual, ad-hoc scans on your local machine to catch vulnerabilities and misconfigurations before committing code to your version control system

The following flags are required to authenticate the Code Security CLI:

The following flags are required to authenticate the Code Security CLI:

• --api-base-url: [$CORTEX_API_BASE_URL]

• --api-base-url [$CORTEX_API_BASE_URL]

• --api-key: [$CORTEX_API_KEY]

• --api-key [$CORTEX_API_KEY]

• --auth-id. [$CORTEX_AUTH_ID]

• --api-key-id [$CORTEX_API_KEY_ID]

For more information about these flags, refer to [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide).

For more information about these flags, refer to [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide).

• Using a cortex.env file: Place your authentication details in a cortex.env file. You can download this file from the UI

• Using a cortex.env file: Place your authentication details in a cortex.env file. You can download this file from the UI

• CI/CD pipeline automation: The Application Security CLI serves as the core integration mechanism for security scanning within your automated pipelines. By inserting simple code snippets into CI tools like Jenkins, GitHub Actions, CircleCI, or GitLab Runner, the CLI acts as a wrapper to enforce security guardrails dynamically and block risky deployments

• CI/CD pipeline automation: The Application Security CLI serves as the core integration mechanism for security scanning within your automated pipelines. By inserting simple code snippets into CI tools like Jenkins, GitHub Actions, CircleCI, or GitLab Runner, the CLI acts as a wrapper to enforce security guardrails dynamically and block risky deployments

## Requirements

## Requirements

• For the Cortex CLI binary:

• For the Cortex CLI binary:

• Install Node.js v22 on the host machine before running scans. The Cortex CLI requires Node.js for JavaScript analysis

• Install Node.js v22 on the host machine before running scans. The Cortex CLI requires Node.js for JavaScript analysis

• Check the installed version with node -v

• Check the installed version with node -v

• Download Node.js from the official Node.js site.

• Download Node.js from the official Node.js site.

• On Linux systems, install GLIBC (GNU C Library) version 2.35 or later. This does not apply when using the CLI container image

• On Linux systems, install GLIBC (GNU C Library) version 2.35 or later. This does not apply when using the CLI container image

• Permissions: Ensure you have the required user permissions. Refer to Cortex CLI

• Permissions: Ensure you have the required user permissions. Refer to About Cortex CLI

• Onboard and install the Cortex CLI: Refer to Connect Cortex CLI

• Onboard and install the Cortex CLI: Refer to Connect Cortex CLI

## Configure proxy for the Code Security CLI

## Configure proxy for the Code Security CLI

When operating the Code Security CLI within environments requiring internet access via a proxy server, you can configure the tool to route its traffic through your proxy using standard environment variables. For proxies that perform TLS inspection, you must also specify a CA certificate

When operating the Code Security CLI within environments requiring internet access via a proxy server, you can configure the tool to route its traffic through your proxy using standard environment variables. For proxies that perform TLS inspection, you must also specify a CA certificate

• Environment variables: Set HTTP_PROXY and HTTPS_PROXY (or http_proxy and https_proxy) to your proxy address

• Environment variables: Set HTTP_PROXY and HTTPS_PROXY (or http_proxy and https_proxy) to your proxy address

• CA Certificate: Use the --ca-certificate flag or the $CORTEX_CA_CERTIFICATE environment variable to provide your CA certificate for proxies that perform TLS inspection. The flag is now global and must appear before code scan. It is currently limited to the Application Security CLI. You can either:

• CA Certificate: Use the --ca-certificate flag or the $CORTEX_CA_CERTIFICATE environment variable to provide your CA certificate for proxies that perform TLS inspection. The flag is now global and must appear before code scan. It is currently limited to the Application Security CLI. You can either:
Show markdown source
```
@@ -1,23 +1,23 @@
 # Cortex CLI for Code Security
 
 Cortex CLI for Code Security scans allow developers and security teams to integrate security checks directly into their application development workflows.
 
 The Code Security CLI supports the following scan types:
 
 * **Secrets**: Identifies exposed sensitive secrets within your codebase
 * **Infrastructure-as-Code** (IaC): Analyzes infrastructure configuration files to detect potential security misconfigurations
-* **Software Composition Analysis** (SCA): Performs vulnerability detection in third-party dependencies, assesses their license compliance and their package operational risk
+* **Software Composition Analysis** (SCA): Performs vulnerability detection in third-party dependencies, detects malicious packages, assesses their license compliance and their package operational risk
 
 In addition, the Code Security CLI serves as the integration mechanism for security scanning within supported CI tools such as Jenkins, GitHub Actions, and others. This is achieved by adding a code snippet containing the CLI command into the configuration files of your CI tool when integrating the CI tool with Cortex Cloud. It acts as a wrapper, enabling security scanning within your pipelines, and direct upload of results to the platform.
 
 ## Code Security CLI scan behavior and output
 
-* Scans generate assets (see [Code Security assets](../../detect-investigate-and-respond-to-threats/asset-management/asset-classes/code-and-ci-cd-assets), [issues](../../detect-investigate-and-respond-to-threats/asset-management/asset-classes/code-and-ci-cd-assets), and [findings](../../detect-investigate-and-respond-to-threats/asset-management/asset-classes/code-and-ci-cd-assets)
+* Scans generate assets (see [Code and CI/CD assets](../../detect-investigate-and-respond-to-threats/asset-management/asset-classes/code-and-ci-cd-assets), [issues](../../detect-investigate-and-respond-to-threats/asset-management/asset-classes/code-and-ci-cd-assets), and [findings](../../detect-investigate-and-respond-to-threats/asset-management/asset-classes/code-and-ci-cd-assets)
 * If one scanner (such as Secrets) fails, the other scanners will continue to run and produce results
 * Scan failures trigger an error message indicating the scanner that failed
 *   The Code Security CLI provides these output modes for management and viewing of scan results:
 
     * **Upload to platform**: `--upload-mode = upload` (default). Uploads scan results directly to the platform for centralized analysis and management
     * **Upload findings only**. `--upload-mode = no-code`. Upload findings, but without including the actual source code content. This prevents raw source code from leaving your local environment or being stored on the platform
     * **CLI output only**: `--upload-mode=no-upload`. View scan results directly in your command-line interface without being uploaded to the platform
 
@@ -38,32 +38,32 @@ The CLI supports the following outputs:
 ## Authentication
 
 To authenticate the Code Security CLI, choose one of the following methods:
 
 *   **Local developer workflows**: Run manual, ad-hoc scans on your local machine to catch vulnerabilities and misconfigurations before committing code to your version control system
 
     The following flags are required to authenticate the Code Security CLI:
 
-    * `--api-base-url`: \[$CORTEX\_API\_BASE\_URL]
-    * `--api-key`: \[$CORTEX\_API\_KEY]
-    * `--auth-id`. \[$CORTEX\_AUTH\_ID]
+    * `--api-base-url` \[`$CORTEX_API_BASE_URL`]
+    * `--api-key` \[`$CORTEX_API_KEY`]
+    * `--api-key-id` \[`$CORTEX_API_KEY_ID`]
 
     For more information about these flags, refer to [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide).
 * **Using a `cortex.env` file**: Place your authentication details in a `cortex.env` file. You can download this file from the UI
 * **CI/CD pipeline automation**: The Application Security CLI serves as the core integration mechanism for security scanning within your automated pipelines. By inserting simple code snippets into CI tools like Jenkins, GitHub Actions, CircleCI, or GitLab Runner, the CLI acts as a wrapper to enforce security guardrails dynamically and block risky deployments
 
 ## Requirements
 
 * **For the Cortex CLI binary**:
   * Install `Node.js v22` on the host machine before running scans. The Cortex CLI requires Node.js for JavaScript analysis
     * Check the installed version with `node -v`
     * Download Node.js from the official [Node.js](https://nodejs.org/) site.
   * On Linux systems, install **GLIBC** (GNU C Library) version 2.35 or later. This does not apply when using the CLI container image
-* **Permissions**: Ensure you have the required user permissions. Refer to [Cortex CLI]()
+* **Permissions**: Ensure you have the required user permissions. Refer to [About Cortex CLI]()
 * **Onboard and install the Cortex CLI**: Refer to [Connect Cortex CLI](connect-cortex-cli)
 
 ## Configure proxy for the Code Security CLI
 
 When operating the Code Security CLI within environments requiring internet access via a proxy server, you can configure the tool to route its traffic through your proxy using standard environment variables. For proxies that perform TLS inspection, you must also specify a CA certificate
 
 * **Environment variables**: Set `HTTP_PROXY` and `HTTPS_PROXY` (or `http_proxy` and `https_proxy`) to your proxy address
 * **CA Certificate**: Use the `--ca-certificate` flag or the `$CORTEX_CA_CERTIFICATE` environment variable to provide your CA certificate for proxies that perform TLS inspection. The flag is now global and must appear before `code scan`. It is currently limited to the Application Security CLI. You can either:
```

▸ Cortex CLI Cortex Cloud Application Security command line reference modified +103 −6 Gained --ignore-existing-secrets, a How to retrieve the repository ID section, and worked --repo-id examples for GitHub Actions and GitLab CI.

xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security/cortex-cli-application-security-command-line-reference

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,35 +1,40 @@

# Cortex CLI Cortex Cloud Application Security command line reference

This reference guide documents the commands and flags unique to the Cortex Cloud Application Security CLI. For CLI commands common to all supported modules refer to Cortex CLI common command line reference guide.

Use these command-line flags to configure Cortex Cloud Application Security scans. They are scoped to the code scan command and define what to scan and how results are reported. Their environment variables use the CORTEX_CODE_ prefix. The Application Security CLI also accepts flags that apply across modules, including authentication, TLS, proxy, logging, upload behavior, and exit-code policy.

--upload-mode and --no-fail-on-crash are the only flags supported in both global and command positions. They use the global variables $CORTEX_UPLOAD_MODE and $CORTEX_NO_FAIL_ON_CRASH, not CORTEX_CODE_ variables. Command-position support is retained for backward compatibility.

For global and common CLI commands, refer to Cortex CLI common command line reference guide.

hint info

### Important

The Cortex CLI Cortex Cloud Application Security only supports single occurrences of each flag. If the same flag is passed multiple times, only the last provided value will be used. For example, in the following command, only TF CloudFormation will be the scanned framework.

EXAMPLE

cortexcli --api-base-url <YOUR_API_URL> --api-key <YOUR_API_KEY> --api-key-id <YOUR_API_KEY_ID> code scan --framework terraform --framework "terraform cloudformation

cortexcli --api-base-url <YOUR_API_URL> --api-key <YOUR_API_KEY> --api-key-id <YOUR_API_KEY_ID> code scan --framework terraform --framework "terraform cloudformation

endhint

Command/Variable│Description

| ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

| ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

--source

$CORTEX_CODE_SOURCE

│(Optional, default CORTEX_CLI)

The execution environment that launched the scan.

Use one of the following values: CORTEX_CLI, IDE_VSCODE, JENKINS, GITHUB_ACTIONS, CIRCLE_CI, AWS_CODE_BUILD, GIT_HOOK, GIT_HOOK_COMMITS.

EXAMPLE: In a GitHub Actions pipeline, pass --source GITHUB_ACTIONS

--source

$CORTEX_CODE_SOURCE

│(Optional, default CORTEX_CLI)

The execution environment that launched the scan.

Use one of the following values: CORTEX_CLI, IDE_VSCODE, JENKINS, GITHUB_ACTIONS, CIRCLE_CI, AWS_CODE_BUILD, GIT_HOOK, GIT_HOOK_COMMITS.

EXAMPLE: In a GitHub Actions pipeline, pass --source GITHUB_ACTIONS

--repo-id

$CORTEX_CODE_REPO_ID

│

The unique identifier used to associate scan results with the correct repository in Cortex.

Value: owner/repo (for example, my-org/my-repo). Value must contain a forward slash /
Requirement: Required for upload mode; otherwise, optional
Auto-detection: If omitted, the CLI automatically extracts this value from your Git remote URL using the last two segments of the path

--repo-id

$CORTEX_CODE_REPO_ID

│

The unique identifier used to associate scan results with the correct repository in Cortex.

Value: owner/repo (for example, my-org/my-repo). Value must contain a forward slash /
Requirement: Required for upload mode; otherwise, optional
Auto-detection: If omitted, the CLI automatically extracts this value from your Git remote URL using the last two segments of the path
Do not use the tenant Asset ID hash, as it will fail validation.
For more information on how to retrieve the repository ID, refer to #how-to-retrieve-the-repository-id

--repo-url
$CORTEX_CODE_REPO_URL│Optional: URL of the repository being scanned (for example, https://github.com/org/repo). If omitted, the CLI attempts to auto-detect the URL from the local Git remote of the scanned directory

--branch

$CORTEX_CODE_BRANCH

│The branch name associated with the scan.

Default: The branch detected from your local Git checkout in upload mode when upload permissions are valid

--branch

$CORTEX_CODE_BRANCH

│The branch name associated with the scan.

Default: The branch detected from your local Git checkout in upload mode when upload permissions are valid

--directory

$CORTEX_CODE_DIRECTORY

│Required.

The directory path to scan. Cannot be used together with --file

--directory

$CORTEX_CODE_DIRECTORY

│Required.

The directory path to scan. Cannot be used together with --file

--file

$CORTEX_CODE_FILE

│The file path to scan. Cannot be used together with --directory. When using this option, the Cortex CLI will filter runners based on the file type provided. For example, if you specify a .tf file, only the Terraform and secrets frameworks will be included. You can further limit this (for example; skip secrets) by using the --skip-framework argument

--file

$CORTEX_CODE_FILE

--var-file

$CORTEX_CODE_VAR_FILE

│Variable files to load in addition to the default files. This feature is currently supported for both source Terraform (.tfvars files) and Helm chart scans (for providing custom values or variable overrides). Refer to https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files) for more information

--var-file

$CORTEX_CODE_VAR_FILE

--framework

$CORTEX_CODE_FRAMEWORK

│Filter to scan specific frameworks. Example: --framework arm.

Syntax: Use a single flag with comma-separated values for multiple frameworks. Both quoted ("arm,ansible") and unquoted (arm,ansible) formats are supported. Example: --framework arm,ansible.

Constraint: Do not use multiple --framework flags: --framework terraform --framework sca_package.

Environment variables: export CORTEX_CODE_FRAMEWORK=arm,ansible.

Supported frameworks: ARM, ANSIBLE, BICEP, CLOUDFORMATION, DOCKER, DOCKERFILE, HELM, KUBERNETES, KUSTOMIZE, OPENAPI, SCA, SECRETS, SERVERLESS, TERRAFORM, TERRAFORMJSON, TERRAFORMPLAN

--framework

$CORTEX_CODE_FRAMEWORK

│Filter to scan specific frameworks. Example: --framework arm.

Syntax: Use a single flag with comma-separated values for multiple frameworks. Both quoted ("arm,ansible") and unquoted (arm,ansible) formats are supported. Example: --framework arm,ansible.

Constraint: Do not use multiple --framework flags: --framework terraform --framework sca_package.

Environment variables: export CORTEX_CODE_FRAMEWORK=arm,ansible.

--skip-framework

$CORTEX_CODE_SKIP_FRAMEWORK

│Skip specific frameworks. Example: --skip-framework terraform.

Syntax: Use a single flag with comma-separated values for multiple frameworks. Both quoted ("arm,ansible") and unquoted (arm,ansible) formats are supported. Example: --skip-framework terraform, sca_package.

Constraint: Do not use multiple skip --framework flags: --skip-framework terraform --skip-framework sca_package.

Environment variables: export CORTEX_CODE_SKIP_FRAMEWORK="tf,sca"

--skip-framework

$CORTEX_CODE_SKIP_FRAMEWORK

│Skip specific frameworks. Example: --skip-framework terraform.

Constraint: Do not use multiple skip --framework flags: --skip-framework terraform --skip-framework sca_package.

Environment variables: export CORTEX_CODE_SKIP_FRAMEWORK="tf,sca"

--rule

$CORTEX_CODE_RULE

│Restrict the scan to specific check IDs; all other checks are skipped. Enter one or more comma-separated check IDs, for example --rule APPSEC_AWS_79,APPSEC_SECRET_80

--rule

$CORTEX_CODE_RULE

│Restrict the scan to specific check IDs; all other checks are skipped. Enter one or more comma-separated check IDs, for example --rule APPSEC_AWS_79,APPSEC_SECRET_80

--severity
$CORTEX_CODE_SEVERITY│Filters scan results by severity level. Accepts one or more comma-separated values: unknown, low, medium, high, critical. Repeat the flag or use comma separation to specify multiple levels (for example, --severity high,critical).

Constraint: Only effective when --upload-mode is set to no-upload. When upload mode is active, the flag is ignored and an informational message is displayed

--ignore-existing-secrets

$CORTEX_CODE_IGNORE_EXISTING_SECRETS

│In CI/CD scans, report only newly introduced secrets. This flag filters out secret findings whose fingerprints already exist in the Cortex Cloud findings backlog, which a periodic baseline scan populates. This flag is ignored during pull request scans

--blocked-only

$CORTEX_CODE_BLOCKED_ONLY

│Boolean flag. When set, shows only blocked findings in the output. Available only in upload mode

--blocked-only

$CORTEX_CODE_BLOCKED_ONLY

│Boolean flag. When set, shows only blocked findings in the output. Available only in upload mode

--summary-position

$CORTEX_CODE_SUMMARY_POSITION

│Sets the position for displaying the summary information relative to the findings. Values: top, bottom

--summary-position

$CORTEX_CODE_SUMMARY_POSITION

│Sets the position for displaying the summary information relative to the findings. Values: top, bottom

--upload-mode

$CORTEX_UPLOAD_MODE

│Upload mode determines the method or mode used to upload data. See common flags for more information

--upload-mode

$CORTEX_UPLOAD_MODE

│Upload mode determines the method or mode used to upload data. See common flags for more information

--download-external-modules
$CORTEX_CODE_DOWNLOAD_EXTERNAL_MODULES│(Optional, default False)
Download external Terraform modules from public Git repositories and the Terraform Registry so they are included in the IaC scan. . Use --external-modules-download-path to control the download location (defaults to .external_modules). Requires outbound network access

--external-modules-download-path

$CORTEX_CODE_EXTERNAL_MODULES_DOWNLOAD_PATH

│Specifies the directory to download external modules to. Defaults to .external_modules

--external-modules-download-path

$CORTEX_CODE_EXTERNAL_MODULES_DOWNLOAD_PATH

│Specifies the directory to download external modules to. Defaults to .external_modules

--external-checks-dir

$CORTEX_CODE_EXTERNAL_CHECKS_DIR

│Local directory containing custom Cortex Python (.py) checks. The directory must be a Python package. This flag is repeatable and cannot be used with --external-checks-git.

--external-checks-dir

$CORTEX_CODE_EXTERNAL_CHECKS_DIR

│Local directory containing custom Cortex Python (.py) checks. The directory must be a Python package. This flag is repeatable and cannot be used with --external-checks-git.

--external-checks-git

$CORTEX_CODE_EXTERNAL_CHECKS_GIT

│Git URL containing custom Cortex Python (.py) checks. Supports //subdir and ?ref=.... This flag cannot be used with --external-checks-dir.

--external-checks-git

$CORTEX_CODE_EXTERNAL_CHECKS_GIT

│Git URL containing custom Cortex Python (.py) checks. Supports //subdir and ?ref=.... This flag cannot be used with --external-checks-dir.

--external-checks-public-key

$CORTEX_CODE_EXTERNAL_CHECKS_PUBLIC_KEY

│Path to a PEM-encoded ECDSA P-256 public key used to verify signatures for custom Cortex Python (.py) checks.

When set, any tampered or unsigned file aborts the scan with exit code 2 before any check runs. When unset, verification is disabled for backward compatibility.

See Workflow: Sign and verify custom checks.

--external-checks-public-key

$CORTEX_CODE_EXTERNAL_CHECKS_PUBLIC_KEY

│Path to a PEM-encoded ECDSA P-256 public key used to verify signatures for custom Cortex Python (.py) checks.

When set, any tampered or unsigned file aborts the scan with exit code 2 before any check runs. When unset, verification is disabled for backward compatibility.

See Workflow: Sign and verify custom checks.

@@ -37,12 +42,104 @@ EXAMPLE

--output-file-path

$CORTEX_CODE_OUTPUT_FILE_PATH

│Specifies the output path for the scan result file

--output-file-path

$CORTEX_CODE_OUTPUT_FILE_PATH

│Specifies the output path for the scan result file

--deep-analysis

$CORTEX_CODE_DEEP_ANALYSIS

│Enables or disables deep analysis of the Terraform plan and related files

--deep-analysis

$CORTEX_CODE_DEEP_ANALYSIS

│Enables or disables deep analysis of the Terraform plan and related files

--repo-root-for-plan-enrichment

$CORTEX_CODE_REPO_ROOT_FOR_PLAN_ENRICHMENT

│Enriches Terraform plan findings by mapping them to their original .tf files

--repo-root-for-plan-enrichment

$CORTEX_CODE_REPO_ROOT_FOR_PLAN_ENRICHMENT

│Enriches Terraform plan findings by mapping them to their original .tf files

--skip-path

$CORTEX_CODE_SKIP_PATH

│Specifies a path (file or directory) that should be skipped during the scanning process. This option is useful for excluding specific files or directories that are not relevant to the scanning analysis, increasing the efficiency and accuracy of scan results

--skip-path

$CORTEX_CODE_SKIP_PATH

--compact

$CORTEX_CODE_COMPACT

│Do not display code blocks in the output

--compact

$CORTEX_CODE_COMPACT

│Do not display code blocks in the output

--no-fail-on-crash

$CORTEX_NO_FAIL_ON_CRASH

│See common flags for a description

--no-fail-on-crash

$CORTEX_NO_FAIL_ON_CRASH

│See common flags for a description

--validate-secrets

CORTEX_APPSEC_VALIDATE_SECRETS

│Validate detected secrets against their respective services to confirm they are active. By default, this feature is disabled. Set CORTEX_APPSEC_VALIDATE_SECRETS = true to enable it

--validate-secrets

CORTEX_APPSEC_VALIDATE_SECRETS

│Validate detected secrets against their respective services to confirm they are active. By default, this feature is disabled. Set CORTEX_APPSEC_VALIDATE_SECRETS = true to enable it

--timeout
$CORTEX_CODE_TIMEOUT│

Sets the maximum time the Cortex CLI will wait for triggered local scan processes to complete. Default value: 15 minutes.

Syntax:

To specify a duration: Use a numeric value followed by a unit (for example --timeout 10m)
Default unit: Numeric values entered without a unit are interpreted as seconds. For example, 30 is equal to 30 seconds.
Supported units: Milliseconds, seconds, minutes and hours

--timeout
$CORTEX_CODE_TIMEOUT│

Sets the maximum time the Cortex CLI will wait for triggered local scan processes to complete. Default value: 15 minutes.

Syntax:

To specify a duration: Use a numeric value followed by a unit (for example --timeout 10m)
Default unit: Numeric values entered without a unit are interpreted as seconds. For example, 30 is equal to 30 seconds.
Supported units: Milliseconds, seconds, minutes and hours

--start-commit│Starting commit hash for git history scanning (Git Hook flag)

--start-commit│Starting commit hash for git history scanning (Git Hook flag). No environment-variable equivalent is available.

--commit-list│Comma-separated list of commit hashes to scan (Git Hook flag)

--commit-list│Comma-separated list of commit hashes to scan (Git Hook flag). No environment-variable equivalent is available.

--hook-event│Git hook event type - pre-commit (Git Hook flag)

--hook-event│Git hook event type, such as pre-commit (Git Hook flag). No environment-variable equivalent is available.

--help│See common flags for a description

## How to retrieve the repository ID

### Option 1: From the local repository checkout (Recommended)

git config --get remote.origin.url

Remove any trailing .git and take the final two path segments. For example, https://github.com/my-org/my-repo.git yields my-org/my-repo. This matches the exact logic the CLI uses to auto-derive the value.

### Option 2: From the Cortex Cloud console

1. Navigate to Inventory → All Assets → Repositories.

2. Select the repository row to open the side card.

3. Copy the title displayed at the top of the side card (in owner/repo format).

Note: Two console fields are commonly mistaken for this value and neither is valid:

Asset ID (in the side card Properties section) is an internal platform hash, not a repository path. Passing it will fail validation

Repository Name (in the table column) is only the repository name without the owner

### Option 3: From the Public API

GET /public_api/appsec/v1/repositories

In the response, locate your repository and join the owner and name fields with a forward slash (owner/name).

#### EXAMPLES

#### Explicitly defining the repository path and branch

Use this pattern for local scans or custom builds. It sets the repository and branch manually.

```bash

cortexcli code scan \

--directory . \

--branch main \

--repo-id my-org/my-repo \

--upload-mode upload

```

hint info

Providing --repo-id and --branch explicitly associates results with the correct platform asset. This works regardless of local Git status or API key permission levels.

endhint

#### Auto-deriving values from the local Git checkout

Use this minimal syntax from a developer workstation inside an active Git working tree.

```bash

# Auto-derive the repository path and branch from the local Git remote

cortexcli code scan \

--directory . \

--upload-mode upload

```

hint info

When omitted, the CLI derives --repo-id from the origin remote URL. It derives --branch from the local HEAD checkout. Auto-derivation requires an API key with write or upload permissions. With a read-only API key, pass both values explicitly.

endhint

#### Running in GitHub Actions workflows

Use native GitHub Actions context variables to set the repository and branch dynamically.

```bash

# In GitHub Actions workflows

cortexcli code scan \

--directory . \

--branch ${{ github.ref_name }} \

--repo-id ${{ github.repository }} \

--upload-mode upload

```

hint info

Always pass --repo-id and --branch explicitly in CI. GitHub Actions checkouts often use a detached HEAD. Auto-derivation can resolve the branch as HEAD, rather than the target branch.

endhint

#### Running in GitLab CI pipelines

Use predefined GitLab CI variables to populate the repository path and branch.

```bash

# In GitLab CI pipelines

cortexcli code scan \

--directory . \

--branch $CI_COMMIT_BRANCH \

--repo-id $CI_PROJECT_PATH \

--upload-mode upload

```

hint info

GitLab CI supports multi-segment subgroup paths, such as my-group/my-subgroup/my-repo. $CI_PROJECT_PATH provides the complete forward-slash-delimited path required by --repo-id.

endhint

Show markdown source

@@ -1,35 +1,40 @@
 # Cortex CLI Cortex Cloud Application Security command line reference
 
-This reference guide documents the commands and flags unique to the Cortex Cloud Application Security CLI. For CLI commands common to all supported modules refer to [Cortex CLI common command line reference guide](../cortex-cli-common-command-line-reference-guide).
+Use these command-line flags to configure Cortex Cloud Application Security scans. They are scoped to the `code scan` command and define what to scan and how results are reported. Their environment variables use the `CORTEX_CODE_` prefix. The Application Security CLI also accepts flags that apply across modules, including authentication, TLS, proxy, logging, upload behavior, and exit-code policy.
+
+`--upload-mode` and `--no-fail-on-crash` are the only flags supported in both global and command positions. They use the global variables `$CORTEX_UPLOAD_MODE` and `$CORTEX_NO_FAIL_ON_CRASH`, not `CORTEX_CODE_` variables. Command-position support is retained for backward compatibility.
+
+For global and common CLI commands, refer to [Cortex CLI common command line reference guide](../cortex-cli-common-command-line-reference-guide).
 
 {% hint style="info" %}
 ### Important
 
 The Cortex CLI Cortex Cloud Application Security only supports single occurrences of each flag. If the same flag is passed multiple times, only the last provided value will be used. For example, in the following command, only TF CloudFormation will be the scanned framework.
 
 EXAMPLE
 
 `cortexcli --api-base-url <YOUR_API_URL> --api-key <YOUR_API_KEY> --api-key-id <YOUR_API_KEY_ID> code scan --framework terraform --framework "terraform cloudformation`
 {% endhint %}
 
 | Command/Variable                                                                                                             | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
 | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | <p><code>--source</code></p><p><code>$CORTEX_CODE_SOURCE</code></p>                                                          | <p>(Optional, default <code>CORTEX_CLI</code>)</p><p>The execution environment that launched the scan.</p><p>Use one of the following values: <code>CORTEX_CLI</code>, <code>IDE_VSCODE</code>, <code>JENKINS</code>, <code>GITHUB_ACTIONS</code>, <code>CIRCLE_CI</code>, <code>AWS_CODE_BUILD</code>, <code>GIT_HOOK</code>, <code>GIT_HOOK_COMMITS</code>.</p><p>EXAMPLE: In a GitHub Actions pipeline, pass <code>--source GITHUB_ACTIONS</code></p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| <p><code>--repo-id</code></p><p><code>$CORTEX_CODE_REPO_ID</code></p>                                                        | <p>The unique identifier used to associate scan results with the correct repository in Cortex.</p><ul><li><strong>Value:</strong> <code>owner/repo</code> (for example, <code>my-org/my-repo</code>). Value must contain a forward slash <code>/</code></li><li><strong>Requirement:</strong> Required for upload mode; otherwise, optional</li><li><strong>Auto-detection:</strong> If omitted, the CLI automatically extracts this value from your Git remote URL using the last two segments of the path</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| <p><code>--repo-id</code></p><p><code>$CORTEX_CODE_REPO_ID</code></p>                                                        | <p>The unique identifier used to associate scan results with the correct repository in Cortex.</p><ul><li><strong>Value:</strong> <code>owner/repo</code> (for example, <code>my-org/my-repo</code>). Value must contain a forward slash <code>/</code></li><li><strong>Requirement:</strong> Required for upload mode; otherwise, optional</li><li><strong>Auto-detection</strong>: If omitted, the CLI automatically extracts this value from your Git remote URL using the last two segments of the path</li><li><strong>Do not</strong> use the tenant Asset ID hash, as it will fail validation.<br>For more information on how to retrieve the repository ID, refer to <a data-mention href="#how-to-retrieve-the-repository-id">#how-to-retrieve-the-repository-id</a></li></ul>                                                                                                                                                                              |
 | <p><code>--repo-url</code><br><code>$CORTEX_CODE_REPO_URL</code></p>                                                         | Optional: URL of the repository being scanned (for example, `https://github.com/org/repo`). If omitted, the CLI attempts to auto-detect the URL from the local Git remote of the scanned directory                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | <p><code>--branch</code></p><p><code>$CORTEX_CODE_BRANCH</code></p>                                                          | <p>The branch name associated with the scan.</p><p>Default: The branch detected from your local Git checkout in <code>upload</code> mode when upload permissions are valid</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | <p><code>--directory</code></p><p><code>$CORTEX_CODE_DIRECTORY</code></p>                                                    | <p>Required.</p><p>The directory path to scan. Cannot be used together with <code>--file</code></p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | <p><code>--file</code></p><p><code>$CORTEX_CODE_FILE</code></p>                                                              | The file path to scan. Cannot be used together with `--directory`. When using this option, the Cortex CLI will filter runners based on the file type provided. For example, if you specify a `.tf` file, only the Terraform and secrets frameworks will be included. You can further limit this (for example; skip secrets) by using the `--skip-framework` argument                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| <p><code>--var-file</code></p><p><code>$CORTEX_CODE_VAR_FILE</code></p>                                                      | Variable files to load in addition to the default files. This feature is currently supported for both source Terraform (.tfvars files) and Helm chart scans (for providing custom values or variable overrides). Refer to [https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files](https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files)) for more information                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| <p><code>--var-file</code></p><p><code>$CORTEX_CODE_VAR_FILE</code></p>                                                      | Variable files to load in addition to the default files. This feature is currently supported for both source Terraform (.tfvars files) and Helm chart scans (for providing custom values or variable overrides). Refer to [https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files](https://www.terraform.io/docs/language/values/variables.html#variable-definitions-tfvars-files)) below for more information                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | <p><code>--framework</code></p><p><code>$CORTEX_CODE_FRAMEWORK</code></p>                                                    | <p>Filter to scan specific frameworks. Example: <code>--framework arm</code>.</p><p>Syntax: Use a single flag with comma-separated values for multiple frameworks. Both quoted (<code>"arm,ansible"</code>) and unquoted (<code>arm,ansible</code>) formats are supported. Example: <code>--framework arm,ansible</code>.</p><p>Constraint: <strong>Do not</strong> use multiple --framework flags: <code>--framework terraform --framework sca_package</code>.</p><p>Environment variables: <code>export CORTEX_CODE_FRAMEWORK=arm,ansible</code>.</p><p>Supported frameworks: <code>ARM</code>, <code>ANSIBLE</code>, <code>BICEP</code>, <code>CLOUDFORMATION</code>, <code>DOCKER</code>, <code>DOCKERFILE</code>, <code>HELM</code>, <code>KUBERNETES</code>, <code>KUSTOMIZE</code>, <code>OPENAPI</code>, <code>SCA</code>, <code>SECRETS</code>, <code>SERVERLESS</code>, <code>TERRAFORM</code>, <code>TERRAFORMJSON</code>, <code>TERRAFORMPLAN</code></p> |
 | <p><code>--skip-framework</code></p><p><code>$CORTEX_CODE_SKIP_FRAMEWORK</code></p>                                          | <p>Skip specific frameworks. Example: <code>--skip-framework terraform</code>.</p><p>Syntax: Use a single flag with comma-separated values for multiple frameworks. Both quoted (<code>"arm,ansible"</code>) and unquoted (<code>arm,ansible</code>) formats are supported. Example: <code>--skip-framework terraform, sca_package</code>.</p><p>Constraint: <strong>Do not</strong> use multiple skip --framework flags: <code>--skip-framework terraform --skip-framework sca_package</code>.</p><p>Environment variables: <code>export CORTEX_CODE_SKIP_FRAMEWORK="tf,sca"</code></p>                                                                                                                                                                                                                                                                                                                                                                             |
 | <p><code>--rule</code></p><p><code>$CORTEX_CODE_RULE</code></p>                                                              | Restrict the scan to specific check IDs; all other checks are skipped. Enter one or more comma-separated check IDs, for example `--rule APPSEC_AWS_79,APPSEC_SECRET_80`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
 | <p><code>--severity</code><br><code>$CORTEX_CODE_SEVERITY</code></p>                                                         | <p>Filters scan results by severity level. Accepts one or more comma-separated values: unknown, low, medium, high, critical. Repeat the flag or use comma separation to specify multiple levels (for example, <code>--severity high,critical</code>).</p><p><strong>Constraint</strong>: Only effective when <code>--upload-mode</code> is set to <code>no-upload</code>. When upload mode is active, the flag is ignored and an informational message is displayed</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
+| <p><code>--ignore-existing-secrets</code></p><p><code>$CORTEX_CODE_IGNORE_EXISTING_SECRETS</code></p>                        | In CI/CD scans, report only newly introduced secrets. This flag filters out secret findings whose fingerprints already exist in the Cortex Cloud findings backlog, which a periodic baseline scan populates. This flag is ignored during pull request scans                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
 | <p><code>--blocked-only</code></p><p><code>$CORTEX_CODE_BLOCKED_ONLY</code></p>                                              | Boolean flag. When set, shows only blocked findings in the output. Available only in `upload` mode                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | <p><code>--summary-position</code></p><p><code>$CORTEX_CODE_SUMMARY_POSITION</code></p>                                      | Sets the position for displaying the summary information relative to the findings. Values: `top`, `bottom`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | <p><code>--upload-mode</code></p><p><code>$CORTEX_UPLOAD_MODE</code></p>                                                     | Upload mode determines the method or mode used to upload data. See common flags for more information                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | <p><code>--download-external-modules</code><br><em><code>$</code></em><code>CORTEX_CODE_DOWNLOAD_EXTERNAL_MODULES</code></p> | <p>(Optional, default <code>False</code>)<br>Download external Terraform modules from public Git repositories and the Terraform Registry so they are included in the IaC scan. . Use <code>--external-modules-download-path</code> to control the download location (defaults to <code>.external_modules</code>). Requires outbound network access</p>                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | <p><code>--external-modules-download-path</code></p><p><code>$CORTEX_CODE_EXTERNAL_MODULES_DOWNLOAD_PATH</code></p>          | Specifies the directory to download external modules to. Defaults to `.external_modules`                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
 | <p><code>--external-checks-dir</code></p><p><code>$CORTEX_CODE_EXTERNAL_CHECKS_DIR</code></p>                                | Local directory containing [custom Cortex Python (`.py`) checks](cortex-cli-application-security-command-line-reference/custom-cortex-checks-and-signature-verification). The directory must be a Python package. This flag is repeatable and cannot be used with `--external-checks-git`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | <p><code>--external-checks-git</code></p><p><code>$CORTEX_CODE_EXTERNAL_CHECKS_GIT</code></p>                                | Git URL containing [custom Cortex Python (`.py`) checks](cortex-cli-application-security-command-line-reference/custom-cortex-checks-and-signature-verification). Supports `//subdir` and `?ref=...`. This flag cannot be used with `--external-checks-dir`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
 | <p><code>--external-checks-public-key</code></p><p><code>$CORTEX_CODE_EXTERNAL_CHECKS_PUBLIC_KEY</code></p>                  | <p>Path to a PEM-encoded ECDSA P-256 public key used to verify signatures for <a href="cortex-cli-application-security-command-line-reference/custom-cortex-checks-and-signature-verification">custom Cortex Python (<code>.py</code>) checks</a>.</p><p>When set, any tampered or unsigned file <strong>aborts the scan with exit code 2</strong> before any check runs. When unset, verification is disabled for backward compatibility.</p><p>See <a href="custom-cortex-checks-and-signature-verification#workflow-sign-and-verify-custom-checks">Workflow: Sign and verify custom checks</a>.</p>                                                                                                                                                                                                                                                                                                                                                               |
@@ -37,12 +42,104 @@ EXAMPLE
 | <p><code>--output-file-path</code></p><p><code>$CORTEX_CODE_OUTPUT_FILE_PATH</code></p>                                      | Specifies the output path for the scan result file                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | <p><code>--deep-analysis</code></p><p><code>$CORTEX_CODE_DEEP_ANALYSIS</code></p>                                            | Enables or disables deep analysis of the Terraform plan and related files                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | <p><code>--repo-root-for-plan-enrichment</code></p><p><code>$CORTEX_CODE_REPO_ROOT_FOR_PLAN_ENRICHMENT</code></p>            | Enriches Terraform plan findings by mapping them to their original `.tf` files                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | <p><code>--skip-path</code></p><p><code>$CORTEX_CODE_SKIP_PATH</code></p>                                                    | Specifies a path (file or directory) that should be skipped during the scanning process. This option is useful for excluding specific files or directories that are not relevant to the scanning analysis, increasing the efficiency and accuracy of scan results                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | <p><code>--compact</code></p><p><code>$CORTEX_CODE_COMPACT</code></p>                                                        | Do not display code blocks in the output                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
 | <p><code>--no-fail-on-crash</code></p><p><code>$CORTEX_NO_FAIL_ON_CRASH</code></p>                                           | See common flags for a description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
 | <p><code>--validate-secrets</code></p><p><code>CORTEX_APPSEC_VALIDATE_SECRETS</code></p>                                     | Validate detected secrets against their respective services to confirm they are active. By default, this feature is disabled. Set `CORTEX_APPSEC_VALIDATE_SECRETS = true` to enable it                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
 | <p><code>--timeout</code><br><code>$CORTEX_CODE_TIMEOUT</code></p>                                                           | <p>Sets the maximum time the Cortex CLI will wait for triggered local scan processes to complete. Default value: 15 minutes.</p><p>Syntax:</p><ul><li><strong>To specify a duration</strong>: Use a numeric value followed by a unit (for example <code>--timeout 10m</code>)</li><li><strong>Default unit</strong>: Numeric values entered without a unit are interpreted as seconds. For example, <code>30</code> is equal to 30 seconds.</li><li><strong>Supported units</strong>: Milliseconds, seconds, minutes and hours</li></ul>                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| `--start-commit`                                                                                                             | Starting commit hash for git history scanning (Git Hook flag)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `--commit-list`                                                                                                              | Comma-separated list of commit hashes to scan (Git Hook flag)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `--hook-event`                                                                                                               | Git hook event type - pre-commit (Git Hook flag)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `--start-commit`                                                                                                             | Starting commit hash for git history scanning (Git Hook flag). No environment-variable equivalent is available.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `--commit-list`                                                                                                              | Comma-separated list of commit hashes to scan (Git Hook flag). No environment-variable equivalent is available.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `--hook-event`                                                                                                               | Git hook event type, such as `pre-commit` (Git Hook flag). No environment-variable equivalent is available.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
 | `--help`                                                                                                                     | See common flags for a description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+
+## How to retrieve the repository ID
+
+### Option 1: From the local repository checkout (Recommended)
+
+`git config --get remote.origin.url`
+
+Remove any trailing `.git` and take the final two path segments. For example, [https://github.com/my-org/my-repo.git](https://github.com/my-org/my-repo.git) yields `my-org/my-repo`. This matches the exact logic the CLI uses to auto-derive the value.
+
+### Option 2: From the Cortex Cloud console
+
+1. Navigate to **Inventory → All Assets → Repositories**.
+2. Select the repository row to open the side card.
+3. Copy the title displayed at the top of the side card (in `owner/repo` format).
+
+> Note: Two console fields are commonly mistaken for this value and neither is valid:
+>
+> * Asset ID (in the side card _Properties_ section) is an internal platform hash, not a repository path. Passing it will fail validation
+> * Repository Name (in the table column) is only the repository name without the owner
+
+### Option 3: From the Public API
+
+`GET /public_api/appsec/v1/repositories`
+
+In the response, locate your repository and join the `owner` and `name` fields with a forward slash (`owner/name`).
+
+#### **EXAMPLES**
+
+#### Explicitly defining the repository path and branch
+
+Use this pattern for local scans or custom builds. It sets the repository and branch manually.
+
+```bash
+cortexcli code scan \
+  --directory . \
+  --branch main \
+  --repo-id my-org/my-repo \
+  --upload-mode upload
+```
+
+{% hint style="info" %}
+Providing `--repo-id` and `--branch` explicitly associates results with the correct platform asset. This works regardless of local Git status or API key permission levels.
+{% endhint %}
+
+#### Auto-deriving values from the local Git checkout
+
+Use this minimal syntax from a developer workstation inside an active Git working tree.
+
+```bash
+# Auto-derive the repository path and branch from the local Git remote
+cortexcli code scan \
+  --directory . \
+  --upload-mode upload
+```
+
+{% hint style="info" %}
+When omitted, the CLI derives `--repo-id` from the origin remote URL. It derives `--branch` from the local `HEAD` checkout. Auto-derivation requires an API key with write or upload permissions. With a read-only API key, pass both values explicitly.
+{% endhint %}
+
+#### Running in GitHub Actions workflows
+
+Use native GitHub Actions context variables to set the repository and branch dynamically.
+
+```bash
+# In GitHub Actions workflows
+cortexcli code scan \
+  --directory . \
+  --branch ${{ github.ref_name }} \
+  --repo-id ${{ github.repository }} \
+  --upload-mode upload
+```
+
+{% hint style="info" %}
+Always pass `--repo-id` and `--branch` explicitly in CI. GitHub Actions checkouts often use a detached `HEAD`. Auto-derivation can resolve the branch as `HEAD`, rather than the target branch.
+{% endhint %}
+
+#### Running in GitLab CI pipelines
+
+Use predefined GitLab CI variables to populate the repository path and branch.
+
+```bash
+# In GitLab CI pipelines
+cortexcli code scan \
+  --directory . \
+  --branch $CI_COMMIT_BRANCH \
+  --repo-id $CI_PROJECT_PATH \
+  --upload-mode upload
+```
+
+{% hint style="info" %}
+GitLab CI supports multi-segment subgroup paths, such as `my-group/my-subgroup/my-repo`. `$CI_PROJECT_PATH` provides the complete forward-slash-delimited path required by `--repo-id`.
+{% endhint %}

▸ ▾ Cortex CLI pre-commit hooks modified +15 −9 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security/cortex-cli-pre-commit-hooks

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,43 +1,49 @@

---

description: >-

Integrate Application Security secrets scanner as pre-commit hooks into your

workflows to scan for errors on your machine before local commits.

---

# Cortex CLI pre-commit hooks

# Cortex CLI pre-commit hooks

Integrate the Application Security secrets scanner as a pre-commit hook by installing the Cortex CLI. The scanner executes the hook locally before a commit. This setup ensures that secrets checks are enforced before any changes are committed.

Integrate the Cortex Cloud Application Security secrets scanner as a pre-commit hook by installing the Cortex CLI. The scanner executes the hook locally before a commit. This setup ensures that secrets checks are enforced before any changes are committed.

When setting up pre-commit hooks, you can choose between local hooks and global hooks.

When setting up pre-commit hooks, you can choose between local hooks and global hooks.

• Local: Installs the hook in the .git/hooks directory of the current repository, ensuring that Cortex XSIAM secrets scans automatically run on your code before every commit

• Local: Installs the hook in the .git/hooks directory of the current repository, ensuring that Cortex Cloud secrets scans automatically run on your code before every commit

• Global: Installs the hook for all Git repositories on your machine, so Cortex XSIAM secrets scans will automatically run on your code before every commit, regardless of the project

• Global: Installs the hook for all Git repositories on your machine, so Cortex Cloud secrets scans will automatically run on your code before every commit, regardless of the project

## How to configure pre-commit hooks

## How to configure pre-commit hooks

hint warning

hint warning

### Danger

### Prerequisite

These common prerequisites are required for all types of installation (both local and global) of the Cortex CLI pre-commit hook.

These common prerequisites are required for all types of installation (both local and global) of the Cortex CLI pre-commit hook.

• Ensure you have a license for Application Security

• Ensure you have a license for Cortex Cloud Application Security

• Install the Cortex XSIAM CLI binary locally. Refer to Connect Cortex CLI for information about onboarding the CLI

• Install the Cortex Cloud CLI binary locally. Refer to Connect Cortex CLI for information about onboarding the CLI

• Obtain Cortex XSIAM API credentials (API Key ID and API Key) available from the CLI onboarding process (see above), and your API base URL. For more information on creating API keys, refer to Create a new API key

• Obtain Cortex Cloud API credentials (API Key ID and API Key) available from the CLI onboarding process (see above), and your API base URL. For more information on creating API keys, refer to Create a new API key

• Git: You must have Git installed on your machine. For installation instructions, refer to the official Git website

• Git: You must have Git installed on your machine. For installation instructions, refer to the official Git website

endhint

endhint

1. Create a directory:

1. Create a directory:

```programlisting

```programlisting

mkdir -p ~/.cortexcli

mkdir -p ~/.cortexcli

```

```

2. Create a .cortex.yaml file in the ~/.cortexcli/ directory.

2. Create a .cortex.yaml file in the ~/.cortexcli/ directory.

3. Open the .cortex.yaml file and add your Cortex XSIAM API credentials and API base URL to the yaml file:

3. Open the .cortex.yaml file and add your Cortex Cloud API credentials and API base URL to the yaml file:

• CORTEX_API_BASE_URL: <replace with the base API URL>

• CORTEX_API_BASE_URL: <replace with the base API URL>

• CORTEX_API_KEY_ID: <replace with API Key ID>

• CORTEX_API_KEY_ID: <replace with API Key ID>

• CORTEX_API_KEY: <replace with API Key>

• CORTEX_API_KEY: <replace with API Key>

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>It is recommended that you configure credentials for the Cortex CLI using a configuration file.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>It is recommended you configure credentials for the Cortex CLI using a configuration file.</p></div>

4. For local hooks: Install the Cortex CLI pre-commit hook package to set up a local hook for the current Git repository:

4. For local hooks: Install the Cortex CLI pre-commit hook package to set up a local hook for the current Git repository:

<div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><h3>Prerequisite</h3><p>For local installation: Install the <strong>pre-commit</strong> framework version 3.2.0 or greater. Refer to <a href="https://pre-commit.com/">https://pre-commit.com/</a> for installation instructions.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><h3>Prerequisite</h3><p>For local installation: Install the <strong>pre-commit</strong> framework version 3.2.0 or greater. Refer to <a href="https://pre-commit.com/">https://pre-commit.com/</a> for installation instructions.</p></div>

1.

1.

• For macOS, you can use Homebrew:

• For macOS, you can use Homebrew:

```programlisting

```programlisting
Show markdown source
```
@@ -1,43 +1,49 @@
+---
+description: >-
+  Integrate Application Security secrets scanner as pre-commit hooks into your
+  workflows to scan for errors on your machine before local commits.
+---
+
 # Cortex CLI pre-commit hooks
 
-Integrate the Application Security secrets scanner as a pre-commit hook by installing the Cortex CLI. The scanner executes the hook locally before a commit. This setup ensures that secrets checks are enforced before any changes are committed.
+Integrate the Cortex Cloud Application Security secrets scanner as a pre-commit hook by installing the Cortex CLI. The scanner executes the hook locally before a commit. This setup ensures that secrets checks are enforced before any changes are committed.
 
 When setting up pre-commit hooks, you can choose between local hooks and global hooks.
 
-* **Local**: Installs the hook in the `.git/hooks` directory of the **current** repository, ensuring that Cortex XSIAM secrets scans automatically run on your code before every commit
-* **Global**: Installs the hook for **all** Git repositories on your machine, so Cortex XSIAM secrets scans will automatically run on your code before every commit, regardless of the project
+* **Local**: Installs the hook in the `.git/hooks` directory of the **current** repository, ensuring that Cortex Cloud secrets scans automatically run on your code before every commit
+* **Global**: Installs the hook for **all** Git repositories on your machine, so Cortex Cloud secrets scans will automatically run on your code before every commit, regardless of the project
 
 ## How to configure pre-commit hooks
 
 {% hint style="warning" %}
-### Danger
+### Prerequisite
 
 These common prerequisites are required for all types of installation (both local and global) of the Cortex CLI pre-commit hook.
 
-* Ensure you have a license for Application Security
-* Install the Cortex XSIAM CLI binary locally. Refer to [Connect Cortex CLI](../connect-cortex-cli) for information about onboarding the CLI
-* Obtain Cortex XSIAM API credentials (API Key ID and API Key) available from the CLI onboarding process (see above), and your API base URL. For more information on creating API keys, refer to [Create a new API key](https://app.gitbook.com/s/1ZrobAtcwfCDWAJAWeuj/create-a-new-api-key)
+* Ensure you have a license for Cortex Cloud Application Security
+* Install the Cortex Cloud CLI binary locally. Refer to [Connect Cortex CLI](../connect-cortex-cli) for information about onboarding the CLI
+* Obtain Cortex Cloud API credentials (API Key ID and API Key) available from the CLI onboarding process (see above), and your API base URL. For more information on creating API keys, refer to [Create a new API key](https://app.gitbook.com/s/1ZrobAtcwfCDWAJAWeuj/create-a-new-api-key)
 * **Git**: You must have Git installed on your machine. For installation instructions, refer to the [official Git website](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
 {% endhint %}
 
 1.  Create a directory:
 
     ```programlisting
      mkdir -p ~/.cortexcli
     ```
 2. Create a `.cortex.yaml` file in the `~/.cortexcli/` directory.
-3.  Open the `.cortex.yaml` file and add your Cortex XSIAM API credentials and API base URL to the `yaml` file:
+3.  Open the `.cortex.yaml` file and add your Cortex Cloud API credentials and API base URL to the `yaml` file:
 
     * `CORTEX_API_BASE_URL`: \<replace with the base API URL>
     * `CORTEX_API_KEY_ID`: \<replace with API Key ID>
     * `CORTEX_API_KEY`: \<replace with API Key>
 
-    <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>It is recommended that you configure credentials for the Cortex CLI using a configuration file.</p></div>
+    <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>It is recommended you configure credentials for the Cortex CLI using a configuration file.</p></div>
 4.  **For local hooks**: Install the Cortex CLI pre-commit hook package to set up a local hook for the current Git repository:
 
     <div data-gb-custom-block data-tag="hint" data-style="warning" class="hint hint-warning"><h3>Prerequisite</h3><p>For local installation: Install the <strong>pre-commit</strong> framework version 3.2.0 or greater. Refer to <a href="https://pre-commit.com/">https://pre-commit.com/</a> for installation instructions.</p></div>
 
     1.
        *   For **macOS**, you can use **Homebrew**:
 
            ```programlisting
```
▸ ▾ Pre-commit hook usage modified +1 −1 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security/cortex-cli-pre-commit-hooks/pre-commit-hook-usage

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,17 +1,17 @@

# Pre-commit hook usage

# Pre-commit hook usage

You can run secrets checks on your code, customize its behavior using supported flags, and suppress detected secrets when required.

You can run secrets checks on your code, customize its behavior using supported flags, and suppress detected secrets when required.

By default, Cortex CLI pre-commit hooks:

By default, Cortex CLI pre-commit hooks:

• Scan staged files only: The scan performs a quick and efficient check by only analyzing the changes you are about to commit, rather than the entire codebase

• Scan staged files only: The scan performs a quick and efficient check by only analyzing the changes you are about to commit, rather than the entire codebase

• Scan for secrets only: Pre-commit hooks support secrets scans only

• Scan for secrets only: Pre-commit hooks support secrets scans only

• Do not upload results to the platform: All scan results are kept local to your machine, ensuring your data remains private.

• Do not upload results to the platform: All scan results are kept local to your machine, ensuring your data remains private

## Command flag reference

## Command flag reference

Use the following flags with the cortexcli code pre-commit command to customize scanner behavior.

Use the following flags with the cortexcli code pre-commit command to customize scanner behavior.

• --ignore-existing-secrets: Ignores secrets that already exist from a periodic scan (default: false) [$CORTEX_CODE_IGNORE_EXISTING_SECRETS]

• --ignore-existing-secrets: Ignores secrets that already exist from a periodic scan (default: false) [$CORTEX_CODE_IGNORE_EXISTING_SECRETS]

• --validate-secrets: Checks if the secrets are valid (default: false) [$CORTEX_CODE_VALIDATE_SECRETS]

• --validate-secrets: Checks if the secrets are valid (default: false) [$CORTEX_CODE_VALIDATE_SECRETS]

• --skip-path: Specifies a file or directory path to skip during the scan [$CORTEX_CODE_SKIP_PATH]

• --skip-path: Specifies a file or directory path to skip during the scan [$CORTEX_CODE_SKIP_PATH]
Show markdown source
```
@@ -1,17 +1,17 @@
 # Pre-commit hook usage
 
 You can run secrets checks on your code, customize its behavior using supported flags, and suppress detected secrets when required.
 
 By default, Cortex CLI pre-commit hooks:
 
 * **Scan staged files only**: The scan performs a quick and efficient check by only analyzing the changes you are about to commit, rather than the entire codebase
 * **Scan for secrets only**: Pre-commit hooks support secrets scans only
-* **Do not upload results to the platform**: All scan results are kept local to your machine, ensuring your data remains private.
+* **Do not upload results to the platform**: All scan results are kept local to your machine, ensuring your data remains private
 
 ## Command flag reference
 
 Use the following flags with the `cortexcli code pre-commit` command to customize scanner behavior.
 
 * `--ignore-existing-secrets`: Ignores secrets that already exist from a periodic scan (default: false) `[$CORTEX_CODE_IGNORE_EXISTING_SECRETS]`
 * `--validate-secrets`: Checks if the secrets are valid (default: false) `[$CORTEX_CODE_VALIDATE_SECRETS]`
 * `--skip-path`: Specifies a file or directory path to skip during the scan `[$CORTEX_CODE_SKIP_PATH]`
```
▸ ▾ Cortex CLI pre-receive hooks modified +17 −8 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security/cortex-cli-pre-receive-hooks

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,38 +1,47 @@

---

description: >-

Integrate the Application Security secrets scanner as a pre-receive hook into

your workflows to scan for errors before code is accepted into your

repository.

---

# Cortex CLI pre-receive hooks

# Cortex CLI pre-receive hooks

Integrate the Application Security secrets scanner as pre-receive hook into your workflows installing the Cortex CLI. The hook runs on the remote server before changes are pushed, allowing you to enforce checks before code is accepted into version control.

Integrate the Cortex Cloud Application Security secrets scanner as pre-receive hook into your workflows installing the Cortex CLI. The hook runs on the remote server before changes are pushed, allowing you to enforce checks before code is accepted into version control.

## Supported version control systems

Supported version control systems: Pre-receive hooks are supported for GitHub Enterprise, GitLab self-managed, and Bitbucket Data Center. To setup pre-receive hook on these platforms refer to Setup on third-party platforms below.

Pre-receive hooks are supported for GitHub Enterprise, GitLab self-managed, and Bitbucket Data Center. To setup pre-receive hook on these platforms refer to Setup on third-party platforms below.

## Pre-receive hook workflow setup

## Pre-receive hook workflow setup

1. Fulfill prerequisites.

1. Fulfill prerequisites.

2. Configure API credentials.

2. Configure API credentials.

3. Install the pre-receive hook.

3. Install the pre-receive hook.

4. Setup the pre-receive hook on third party platforms.

4. Setup the pre-receive hook on third party platforms.

### Setup requirements

### Setup requirements

hint warning

hint warning

### Prerequisites

### Prerequisites

Before you begin, ensure you have:

Before you begin, ensure you have:

• Administrator access to the VCS server and console

• Administrator access to the VCS server and console

• A valid license for Application Security

• A valid license for Cortex Cloud Application Security

• The Cortex XSIAM CLI binary or Docker image installed on the server (requires GLIBC (GNU C library) version 2.35 or greater). Refer to Connect Cortex CLI for information about onboarding the CLI

• The Cortex Cloud CLI binary or Docker image installed on the server (requires GLIBC (GNU C library) version 2.35 or greater). Refer to Connect Cortex CLI for information about onboarding the CLI

• Cortex XSIAM API credentials (API Key ID and API Key) and your API base URL. For more information on creating API keys, refer to Create a new API key

• Cortex Cloud API credentials (API Key ID and API Key) and your API base URL. For more information on creating API keys, refer to Create a new API key

• Git is installed on your machine. For installation instructions, refer to the official Git website

• Git installed on your machine. For installation instructions, refer to the official Git website

endhint

endhint

### Configure credentials

### Configure credentials

It is recommended to configure credentials for the Application Security Cortex CLI using a configuration file, instead of embedding them directly in the hook script.

It is recommended to configure credentials for the Cortex Cloud Application Security Cortex CLI using a configuration file, instead of embedding them directly in the hook script.

1. Create a directory:

1. Create a directory:

```programlisting

```programlisting

mkdir -p ~/.cortexcli/.cortex.yaml

mkdir -p ~/.cortexcli/.cortex.yaml

```

```

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>Make sure to create the directory under the home directory of the Linux user that runs the Git hooks. This user is typically not the root user.</p></div>

<div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>Make sure to create the directory under the home directory of the Linux user that runs the Git hooks. This user is typically not the root user.</p></div>

@@ -46,17 +55,17 @@ It is recommended to configure credentials for the Application Security Cortex C

To set up the Cortex CLI as a pre-receive hook on supported third-party platforms, refer to the official vendor documentation:

To set up the Cortex CLI as a pre-receive hook on supported third-party platforms, refer to the official vendor documentation:

• GitHub Enterprise: About pre-receive hooks

• GitHub Enterprise: About pre-receive hooks

• GitLab self-managed: Git server hooks

• GitLab self-managed: Git server hooks

• Bitbucket Enterprise: Using repository hooks

• Bitbucket Enterprise: Using repository hooks

#### Reference script

#### Reference script

Use the script below as a reference to extend or modify your existing pre-receive hooks in your VCS provider.

Use the script below as reference to extend or modify your existing pre-receive hooks in your VCS provider.

```programlisting

```programlisting

#!/usr/bin/env bash

#!/usr/bin/env bash

# This script is used to run Cortex CLI in a pre-receive hook.

# This script is used to run Cortex CLI in a pre-receive hook.

# Hide the update notice.

# Hide the update notice.

export CORTEX_HIDE_UPDATE_NOTICE=1

export CORTEX_HIDE_UPDATE_NOTICE=1
Show markdown source
```
@@ -1,38 +1,47 @@
+---
+description: >-
+  Integrate the Application Security secrets scanner as a pre-receive hook into
+  your workflows to scan for errors before code is accepted into your
+  repository.
+---
+
 # Cortex CLI pre-receive hooks
 
-Integrate the Application Security secrets scanner as pre-receive hook into your workflows installing the Cortex CLI. The hook runs on the remote server before changes are pushed, allowing you to enforce checks before code is accepted into version control.
+Integrate the Cortex Cloud Application Security secrets scanner as pre-receive hook into your workflows installing the Cortex CLI. The hook runs on the remote server before changes are pushed, allowing you to enforce checks before code is accepted into version control.
+
+## Supported version control systems
 
-**Supported version control systems**: Pre-receive hooks are supported for GitHub Enterprise, GitLab self-managed, and Bitbucket Data Center. To setup pre-receive hook on these platforms refer to [Setup on third-party platforms](#setup-on-third-party-platforms) below.
+Pre-receive hooks are supported for GitHub Enterprise, GitLab self-managed, and Bitbucket Data Center. To setup pre-receive hook on these platforms refer to [Setup on third-party platforms](#setup-on-third-party-platforms) below.
 
 ## Pre-receive hook workflow setup
 
 1. [Fulfill prerequisites](#prerequisites).
 2. [Configure API credentials](#configure-credentials).
 3. Install the pre-receive hook.
 4. [Setup the pre-receive hook on third party platforms](#setup-on-third-party-platforms).
 
 ### Setup requirements
 
 {% hint style="warning" %}
 ### Prerequisites
 
 Before you begin, ensure you have:
 
 * **Administrator** access to the VCS server and console
-* A valid license for Application Security
-* The **Cortex XSIAM CLI binary** or Docker image installed on the server (requires `GLIBC (GNU C library) version 2.35` or greater). Refer to [Connect Cortex CLI](../connect-cortex-cli) for information about onboarding the CLI
-* **Cortex XSIAM API credentials** (API Key ID and API Key) and your API base URL. For more information on creating API keys, refer to [Create a new API key](https://app.gitbook.com/s/1ZrobAtcwfCDWAJAWeuj/create-a-new-api-key)
-* **Git** is installed on your machine. For installation instructions, refer to the [official Git website](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+* A valid license for Cortex Cloud Application Security
+* The **Cortex Cloud CLI binary** or Docker image installed on the server (requires `GLIBC (GNU C library) version 2.35` or greater). Refer to [Connect Cortex CLI](../connect-cortex-cli) for information about onboarding the CLI
+* **Cortex Cloud API credentials** (API Key ID and API Key) and your API base URL. For more information on creating API keys, refer to [Create a new API key](https://app.gitbook.com/s/1ZrobAtcwfCDWAJAWeuj/create-a-new-api-key)
+* **Git** installed on your machine. For installation instructions, refer to the [official Git website](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
 {% endhint %}
 
 ### Configure credentials
 
-It is recommended to configure credentials for the Application Security Cortex CLI using a configuration file, instead of embedding them directly in the hook script.
+It is recommended to configure credentials for the Cortex Cloud Application Security Cortex CLI using a configuration file, instead of embedding them directly in the hook script.
 
 1.  Create a directory:
 
     ```programlisting
     mkdir -p ~/.cortexcli/.cortex.yaml
     ```
 
     <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><h3>Note</h3><p>Make sure to create the directory under the home directory of the Linux user that runs the Git hooks. This user is typically not the root user.</p></div>
@@ -46,17 +55,17 @@ It is recommended to configure credentials for the Application Security Cortex C
 To set up the Cortex CLI as a pre-receive hook on supported third-party platforms, refer to the official vendor documentation:
 
 * **GitHub Enterprise**: [About pre-receive hooks](https://docs.github.com/en/enterprise-server@3.16/admin/enforcing-policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks)
 * **GitLab self-managed**: [Git server hooks](https://docs.gitlab.com/ee/administration/server_hooks.html)
 * **Bitbucket Enterprise**: [Using repository hooks](https://confluence.atlassian.com/bitbucketserver/using-repository-hooks-776639836.html)
 
 #### Reference script
 
-Use the script below as a reference to extend or modify your existing pre-receive hooks in your VCS provider.
+Use the script below as reference to extend or modify your existing pre-receive hooks in your VCS provider.
 
 ```programlisting
 #!/usr/bin/env bash
 
 # This script is used to run Cortex CLI in a pre-receive hook.
 
 # Hide the update notice.
 export CORTEX_HIDE_UPDATE_NOTICE=1
```

▸ Pre-receive hook usage modified +10 −10 The pre-receive flag table was reflowed so environment variables sit inside the description column rather than beside the flag.

xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security/cortex-cli-pre-receive-hooks/pre-receive-hook-usage

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -1,17 +1,17 @@

# Pre-receive hook usage

The hook executes a script on every git push.

By default, Cortex CLI pre-receive hooks:

• Only scans code changes: It analyzes the code difference included in the pushed commits, not the entire repository

• Scans for secrets only: The analysis is focused on detecting sensitive information

• Does not upload results to Cortex XSIAM: All scan results are kept local to your machine (on the server)

• Does not upload results to Cortex Cloud: All scan results are kept local to your machine (on the server)

## Understanding the script variables

• CORTEX_CLI: Defines the executable path, pointing to the absolute location of the cortexcli binary

• BASE_COMMAND: Assembles the core command string, including authentication flags (--api-base-url, --api-key-id, --api-key) and the primary command: code pre-receive. The use of ${...} ensures authentication variables are injected as flag values

• OPTIONAL_FLAGS: An empty variable placeholder for adding optional runtime arguments

## Command flag reference

@@ -19,25 +19,25 @@ By default, Cortex CLI pre-receive hooks:

Use the following flags with the pre-receive command to customize scanner behavior.

Example command structure:

```programlisting

$ cortexcli code pre-receive [options]

```

Command / Variable│Description

Command│Description

| ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |

| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |

--ignore-existing-secrets

[$CORTEX_CODE_IGNORE_EXISTING_SECRETS]

│Ignores secrets that already exist in the periodic scan (default: false)

--ignore-existing-secrets│Ignores secrets that already exist in the periodic scan (default: false) [$CORTEX_CODE_IGNORE_EXISTING_SECRETS]

--validate-secrets

[$CORTEX_CODE_VALIDATE_SECRETS]

│Checks if the secrets are valid (default: false)

--validate-secrets│Checks if the secrets are valid (default: false) [$CORTEX_CODE_VALIDATE_SECRETS]

--skip-path

[$CORTEX_CODE_SKIP_PATH]

│Specifies a file or directory path to skip during the scan

--skip-path│Specifies a file or directory path to skip during the scan [$CORTEX_CODE_SKIP_PATH]

--compact

[$CORTEX_CODE_COMPACT]

│Prevents the display of code blocks in the output (default: false)

--compact│Prevents the display of code blocks in the output (default: false) [$CORTEX_CODE_COMPACT]

--summary-position

[$CORTEX_CODE_SUMMARY_POSITION]

│Determines whether the summary appears on top (before the check results) or on bottom (after the check results). (default: top)

--summary-position│Determines whether the summary appears on top (before the check results) or on bottom (after the check results). (default: top) [$CORTEX_CODE_SUMMARY_POSITION]

--no-fail-on-crash

[$CORTEX_CODE_NO_FAIL_ON_CRASH]

│Returns exit code 0 instead of 2 in case of a failure in the integration with the platform (default: false)

--no-fail-on-crash│Returns exit code 0 instead of 2 in case of a failure in the integration with the platform (default: false) [$CORTEX_CODE_NO_FAIL_ON_CRASH]

--help, -h│Displays a help message with available options

## Breakglass: Bypassing the hook

The breakglass feature allows you to intentionally bypass the pre-receive hook security scan. This is useful in urgent situations where a push must go through immediately, but it should be used with caution as it overrides your security policies.

1. Configure your server to accept custom push options:

````programlisting

Show markdown source

@@ -1,17 +1,17 @@
 # Pre-receive hook usage
 
 The hook executes a script on every git push.
 
 By default, Cortex CLI pre-receive hooks:
 
 * **Only scans code changes**: It analyzes the code difference included in the pushed commits, not the entire repository
 * **Scans for secrets only**: The analysis is focused on detecting sensitive information
-* **Does not upload results to Cortex XSIAM**: All scan results are kept local to your machine (on the server)
+* **Does not upload results to Cortex Cloud**: All scan results are kept local to your machine (on the server)
 
 ## Understanding the script variables
 
 * `CORTEX_CLI`: Defines the executable path, pointing to the absolute location of the `cortexcli` binary
 * `BASE_COMMAND`: Assembles the core command string, including authentication flags (`--api-base-url`, `--api-key-id`, `--api-key`) and the primary command: `code pre-receive`. The use of `${...}` ensures authentication variables are injected as flag values
 * `OPTIONAL_FLAGS`: An empty variable placeholder for adding optional runtime arguments
 
 ## Command flag reference
@@ -19,25 +19,25 @@ By default, Cortex CLI pre-receive hooks:
 Use the following flags with the pre-receive command to customize scanner behavior.
 
 **Example command structure:**
 
 ```programlisting
 $ cortexcli code pre-receive [options]
 ```
 
-| Command / Variable                                                                                      | Description                                                                                                                     |
-| ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
-| <p><code>--ignore-existing-secrets</code></p><p><code>[$CORTEX_CODE_IGNORE_EXISTING_SECRETS]</code></p> | Ignores secrets that already exist in the periodic scan (default: false)                                                        |
-| <p><code>--validate-secrets</code></p><p><code>[$CORTEX_CODE_VALIDATE_SECRETS]</code></p>               | Checks if the secrets are valid (default: false)                                                                                |
-| <p><code>--skip-path</code></p><p><code>[$CORTEX_CODE_SKIP_PATH]</code></p>                             | Specifies a file or directory path to skip during the scan                                                                      |
-| <p><code>--compact</code></p><p><code>[$CORTEX_CODE_COMPACT]</code></p>                                 | Prevents the display of code blocks in the output (default: false)                                                              |
-| <p><code>--summary-position</code></p><p><code>[$CORTEX_CODE_SUMMARY_POSITION]</code></p>               | Determines whether the summary appears on top (before the check results) or on bottom (after the check results). (default: top) |
-| <p><code>--no-fail-on-crash</code></p><p><code>[$CORTEX_CODE_NO_FAIL_ON_CRASH]</code></p>               | Returns exit code `0` instead of `2` in case of a failure in the integration with the platform (default: false)                 |
-| `--help, -h`                                                                                            | Displays a help message with available options                                                                                  |
+| Command                     | Description                                                                                                                                                       |
+| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `--ignore-existing-secrets` | Ignores secrets that already exist in the periodic scan (default: false) `[$CORTEX_CODE_IGNORE_EXISTING_SECRETS]`                                                 |
+| `--validate-secrets`        | Checks if the secrets are valid (default: false) `[$CORTEX_CODE_VALIDATE_SECRETS]`                                                                                |
+| `--skip-path`               | Specifies a file or directory path to skip during the scan `[$CORTEX_CODE_SKIP_PATH]`                                                                             |
+| `--compact`                 | Prevents the display of code blocks in the output (default: false) `[$CORTEX_CODE_COMPACT]`                                                                       |
+| `--summary-position`        | Determines whether the summary appears on top (before the check results) or on bottom (after the check results). (default: top) `[$CORTEX_CODE_SUMMARY_POSITION]` |
+| `--no-fail-on-crash`        | Returns exit code `0` instead of `2` in case of a failure in the integration with the platform (default: false) `[$CORTEX_CODE_NO_FAIL_ON_CRASH]`                 |
+| `--help, -h`                | Displays a help message with available options                                                                                                                    |
 
 ## Breakglass: Bypassing the hook
 
 The breakglass feature allows you to intentionally bypass the pre-receive hook security scan. This is useful in urgent situations where a push must go through immediately, but it should be used with caution as it overrides your security policies.
 
 1.  Configure your server to accept custom push options:
 
     ````programlisting

▸ ▾ Cortex CLI usage for Cortex Cloud Application Security modified +1 −1 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-for-code-security/cortex-cli-usage-for-application-security

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -9,17 +9,17 @@ cortexcli –-api-base-url <API URL> --api-key <API key from the "Authenticate"

```

```

## Command line structure

## Command line structure

The command structure includes global flags which are used for authentication, and then specifies the module name and command specific to Cortex Cloud Application Security which are followed by dedicated flags unique to this module as well as flags common to all modules.

The command structure includes global flags which are used for authentication, and then specifies the module name and command specific to Cortex Cloud Application Security which are followed by dedicated flags unique to this module as well as flags common to all modules.

* **Global flags**: These flags are part of the initial `cortexcli` command and are necessary to authenticate and connect to Cortex Cloud

* **Global flags**: These flags are part of the initial `cortexcli` command and are necessary to authenticate and connect to Cortex Cloud

* `--api-base-url`: (Required = true). The public facing API URL. Refer to [Connect Cortex CLI](../connect-cortex-cli) for more information

* `--api-base-url`: (Required = true). The public facing API URL. Refer to [Connect Cortex CLI](../connect-cortex-cli) and the [Cortex Cloud API reference](https://cortex-docs.paloaltonetworks.com/cortex-cloud-api) for more information

* `--api-key`: (Required = true). The Cortex Cloud API key generated when onboarding the CLI as a data source. Refer to [Connect Cortex CLI](../connect-cortex-cli) for more information

* `--api-key`: (Required = true). The Cortex Cloud API key generated when onboarding the CLI as a data source. Refer to [Connect Cortex CLI](../connect-cortex-cli) for more information

* `--api-key-id`: (Required = true). The Cortex Cloud API key ID generated when onboarding the CLI as a data source

* `--api-key-id`: (Required = true). The Cortex Cloud API key ID generated when onboarding the CLI as a data source

For a comprehensive list of Cortex Cloud Application Security global flags, refer to [Cortex CLI Cortex Cloud Application Security command line reference](cortex-cli-application-security-command-line-reference)

For a comprehensive list of Cortex Cloud Application Security global flags, refer to [Cortex CLI Cortex Cloud Application Security command line reference](cortex-cli-application-security-command-line-reference)

* **Cortex Cloud Application Security specifics**: Following the global flags, the command specifies the module and the commands required for initiating a scan using the Cortex Cloud Application Security module:

* **Cortex Cloud Application Security specifics**: Following the global flags, the command specifies the module and the commands required for initiating a scan using the Cortex Cloud Application Security module:

* `code scan`: Required - true. This command instructs the CLI to perform an Cortex Cloud Application Security scan.

* `code scan`: Required - true. This command instructs the CLI to perform an Cortex Cloud Application Security scan.

* For the optional flags, refer to the dedicated Cortex Cloud Application Security [command line reference](cortex-cli-application-security-command-line-reference)

* For the optional flags, refer to the dedicated Cortex Cloud Application Security [command line reference](cortex-cli-application-security-command-line-reference)
Show markdown source
```
@@ -9,17 +9,17 @@ cortexcli –-api-base-url <API URL> --api-key <API key from the "Authenticate"
 ```
 
 ## Command line structure
 
 The command structure includes global flags which are used for authentication, and then specifies the module name and command specific to Cortex Cloud Application Security which are followed by dedicated flags unique to this module as well as flags common to all modules.
 
 *   **Global flags**: These flags are part of the initial `cortexcli` command and are necessary to authenticate and connect to Cortex Cloud
 
-    * `--api-base-url`: (Required = true). The public facing API URL. Refer to [Connect Cortex CLI](../connect-cortex-cli) for more information
+    * `--api-base-url`: (Required = true). The public facing API URL. Refer to [Connect Cortex CLI](../connect-cortex-cli) and the [Cortex Cloud API reference](https://cortex-docs.paloaltonetworks.com/cortex-cloud-api) for more information
     * `--api-key`: (Required = true). The Cortex Cloud API key generated when onboarding the CLI as a data source. Refer to [Connect Cortex CLI](../connect-cortex-cli) for more information
     * `--api-key-id`: (Required = true). The Cortex Cloud API key ID generated when onboarding the CLI as a data source
 
     For a comprehensive list of Cortex Cloud Application Security global flags, refer to [Cortex CLI Cortex Cloud Application Security command line reference](cortex-cli-application-security-command-line-reference)
 * **Cortex Cloud Application Security specifics**: Following the global flags, the command specifies the module and the commands required for initiating a scan using the Cortex Cloud Application Security module:
   * `code scan`: Required - true. This command instructs the CLI to perform an Cortex Cloud Application Security scan.
   * For the optional flags, refer to the dedicated Cortex Cloud Application Security [command line reference](cortex-cli-application-security-command-line-reference)
 
```
▸ ▾ Cortex CLI usage modified +4 −4 xsiam/reference-and-developer-docs/about-cortex-cli/cortex-cli-usage

Read it on the Cortex docs portal ↗ Read it here → This file's diff on GitHub ↗

Before After

@@ -20,20 +20,20 @@ Place global flags before the module name. Place module flags after `scan`.

• --api-key-id <value>

• --api-key-id <value>

AppSec and CWP support additional global flags. WAAS does not. See the [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide).

AppSec and CWP support additional global flags. WAAS does not. See the [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide).

• Module name — Select the environment to scan.

• Module name — Select the environment to scan.

• api — API Security. See Cortex CLI for API Security.

• api — API Security. See Cortex CLI for API Security.

• image — Cloud Workload Protection (CWP). See Cortex CLI for Cloud Workload Protection.

• image — Cloud Workload Protection (CWP). See Cortex CLI for Cloud Workload Protection.

• code — Cortex Cloud Application Security. See Cortex CLI for Code Security.

• code — Cortex Cloud Application Security. See Cortex CLI for Code Security.

• Module flags — Apply to the selected command.

• Module flags — Apply to the selected command.

• Common command-line flags

• Cortex CLI common command line reference guide

• CWP command-line flags

• Cloud Workload Protection command line reference

• API Security command-line flags

• Cortex CLI API Security command line reference guide

• Cortex Cloud Application Security command-line flags

• Cortex CLI Cortex Cloud Application Security command line reference

### Examples

### Examples

#### Global flags

#### Global flags

Global flags apply to all modules. Place them between cortexcli and the module name.

Global flags apply to all modules. Place them between cortexcli and the module name.

```shell

```shell
Show markdown source
```
@@ -20,20 +20,20 @@ Place global flags before the module name. Place module flags after `scan`.
     * `--api-key-id <value>`
 
     AppSec and CWP support additional global flags. WAAS does not. See the [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide).
 * **Module name** — Select the environment to scan.
   * `api` — API Security. See [Cortex CLI for API Security](cortex-cli-for-api-security).
   * `image` — Cloud Workload Protection (CWP). See [Cortex CLI for Cloud Workload Protection](cortex-cli-for-cloud-workload-protection).
   * `code` — Cortex Cloud Application Security. See [Cortex CLI for Code Security](cortex-cli-for-code-security).
 * **Module flags** — Apply to the selected command.
-  * [Common command-line flags](cortex-cli-common-command-line-reference-guide)
-  * [CWP command-line flags](cortex-cli-for-cloud-workload-protection/cloud-workload-protection-command-line-reference)
-  * [API Security command-line flags](cortex-cli-for-api-security/cortex-cli-api-security-command-line-reference-guide)
-  * [Cortex Cloud Application Security command-line flags](cortex-cli-for-code-security/cortex-cli-application-security-command-line-reference)
+  * [Cortex CLI common command line reference guide](cortex-cli-common-command-line-reference-guide)
+  * [Cloud Workload Protection command line reference](cortex-cli-for-cloud-workload-protection/cloud-workload-protection-command-line-reference)
+  * [Cortex CLI API Security command line reference guide](cortex-cli-for-api-security/cortex-cli-api-security-command-line-reference-guide)
+  * [Cortex CLI Cortex Cloud Application Security command line reference](cortex-cli-for-code-security/cortex-cli-application-security-command-line-reference)
 
 ### Examples
 
 #### Global flags
 
 Global flags apply to all modules. Place them between `cortexcli` and the module name.
 
 ```shell
```