Purpose
This guide explains how to generate an Access Key in the Prisma Cloud console and how to use it in Logsign USO to ingest Prisma Cloud Compute runtime incident audit events for security analytics and forensic purposes.
Prisma Cloud is a cloud-hosted platform and exposes its Compute module's incident data through a REST API rather than syslog. This API poller is the supported way to bring that data into Logsign USO. Note that this integration covers the Compute (workload protection) module's runtime incidents only. It does not pull Prisma Cloud CSPM posture alerts or compliance findings, which live under a separate API family and are out of scope here.
Prerequisites
The account you use to generate the Access Key must have administrative access to the Compute module in the Prisma Cloud console, specifically the Settings > Access Keys screen. This is separate from the main CSPM console's own Access Keys screen. Make sure you are creating the key under the Compute module.
The role tied to the key must include the monitorRuntimeIncidents permission. Without it, the key will authenticate successfully but every call to the incidents endpoint will fail authorization.
Use least privilege. Do not tie the key to a full System Admin role. Prisma Cloud lets you create a scoped custom role first (Compute or CSPM > Settings > Roles > Add New) and log in as that role before generating the key, so the key inherits only the permissions the role has. In this case, only monitorRuntimeIncidents is required for this integration. Whether the Compute role editor exposes monitorRuntimeIncidents as an individually toggleable checkbox or only as part of a bundled permission set has not been verified against a live console. Confirm the exact toggle in your own tenant before assuming it is a single checkbox.
Step 1: Find Your Compute Console Path
In the Prisma Cloud console, go to Compute > Manage > System > Downloads (labeled Utilities in some console versions). Copy the value shown as Path to Console. It looks like https://<region>.cloud.twistlock.com/<tenant-id> (for example https://us-east1.cloud.twistlock.com/us-1-123456789).
Important: do not confuse this with your main Prisma Cloud login URL. Prisma Cloud's main console (the CSPM/posture side) is hosted on one of a fixed set of regional addresses, shown below. Your order fulfillment email tells you which one is yours; you log into that URL first, then navigate into the Compute module to get the Path to Console above.
| Region / stack | Console login URL |
|---|---|
| US (default) | app.prismacloud.io |
| US (stack 2) | app2.prismacloud.io |
| US (stack 3) | app3.prismacloud.io |
| US (stack 4) | app4.prismacloud.io |
| Europe | app.eu.prismacloud.io |
| Europe (stack 2) | app2.eu.prismacloud.io |
| United Kingdom | app.uk.prismacloud.io |
| France | app.fr.prismacloud.io |
| Canada | app.ca.prismacloud.io |
| Australia / New Zealand | app.anz.prismacloud.io |
| Singapore | app.sg.prismacloud.io |
| India | app.ind.prismacloud.io |
| Indonesia | app.id.prismacloud.io |
| Japan | app.jp.prismacloud.io |
| China | app.prismacloud.cn |
| Government | app.gov.prismacloud.io |
This regional list only identifies which Prisma Cloud stack your organization is on. It is not what you enter in Logsign's Host field. Unlike the main console, the Compute module has no fixed regional address: every tenant gets its own Path to Console value (shown above), and it must be copied from your own console each time. There is no published list to look it up from.
The Compute console path is tenant-specific and is the value Logsign needs. Enter it without the https:// prefix in the Host field in Step 3. If you paste it with the https:// prefix included, the connection will fail (the same restriction applies to Logsign's other host-type fields, such as Cortex XDR).
Step 2: Create an Access Key in the Compute Console
- In the Prisma Cloud console, go to Settings > Access Keys under the Compute module.
- Click Add New.
- Enter a Name (for example, "logsign-uso-integration") and optionally set an expiration date.
- Make sure the role assigned to the key includes the monitorRuntimeIncidents permission.
- Click Create.
- Copy the Access Key ID and Secret Key immediately and store them somewhere safe. The Secret Key is not shown again once you leave the screen; if you lose it, you must generate a new key.
Step 3: Configure the Integration in Logsign USO
After obtaining the console path and Access Key, log in to Logsign USO and add a new Prisma Cloud data source. You will be asked for:
| Field | Value |
|---|---|
| Protocol | https (recommended) |
| Host | Your Compute console path from Step 1, without the https:// prefix, for example us-east1.cloud.twistlock.com/us-1-123456789 |
| Access Key | The Access Key ID from Step 2 |
| Secret Key | The Secret Key from Step 2 |
| Verify SSL | Checked (default) unless your console uses a self-signed certificate |
Logsign exchanges the Access Key and Secret Key for a JWT Bearer token automatically on the first poll by calling the console's /authenticate endpoint, and re-exchanges it as needed. You do not need to generate or refresh a token yourself. Logsign then periodically queries the Compute audits/incidents endpoint for new runtime incidents, using the time field of each incident as the sync cursor so no incident is skipped or duplicated.
Troubleshooting
| Error | Likely cause | What to check |
|---|---|---|
| 401 Unauthorized | Access Key ID / Secret Key pair is wrong, was regenerated, or was deleted; or the initial /authenticate call itself is failing (for example because Host still has the https:// prefix or points at the wrong console). | Re-check the Host value against Step 1 (no https://, no trailing slash), and confirm the Access Key/Secret Key were copied from the Compute module's Access Keys screen, not the CSPM one. |
| 403 Forbidden | The key authenticates but its role does not include monitorRuntimeIncidents. | In the Compute console, open the role tied to this key and confirm it grants monitorRuntimeIncidents (or the permission set that includes it). |
| 429 Too Many Requests | The polling interval or number of concurrent integrations against the same tenant is exceeding Prisma Cloud's rate limit for this endpoint. The exact limit for audits/incidents is not published; Prisma Cloud's documented general guidance for HTTP errors is to back off and retry, but this poller does not currently implement automatic backoff for 429 (see Notes below). | If 429s are frequent, increase the polling interval in the Logsign data source configuration, or contact Logsign support if the failure persists across cycles. |
| 500 / 502 / 503 / 504 | Server-side issue on Prisma Cloud's side (per Palo Alto Networks' published API error documentation, these indicate an unexpected server error, bad gateway, service unavailable, or gateway timeout). | Usually transient; the poller retries on its next scheduled cycle. If it persists for an extended period, check the Prisma Cloud status page or contact Palo Alto Networks support. |
Notes and Limits
- The JWT Bearer token is valid for about 10 minutes per Palo Alto Networks' published documentation. Logsign is expected to request a new one automatically on expiry; whether the token-refresh response Prisma Cloud returns includes an explicit expiry field has not been verified against a live tenant, so this behavior is inferred from the integration's code, not confirmed by a live test.
- This integration only covers Compute module runtime incident audit events (the
audits/incidentsendpoint). It does not cover Prisma Cloud CSPM posture/compliance alerts or Prisma Cloud DSPM findings. Those use separate API families and are out of scope. If you need those log types, a separate integration would be required. - No per-endpoint rate limit figure for
audits/incidentshas been confirmed publicly; Prisma Cloud APIs generally return HTTP 429 when a client is rate-limited. The current integration does not implement special retry/backoff handling for 429 responses. A failed poll simply retries on the next scheduled cycle. - Make sure the Host value you enter is your tenant-specific Compute console path (from Step 1), not your main Prisma Cloud login URL (
app.prismacloud.ioor similar). Those are different addresses, and the login URL will not work for this integration. - Field-level mapping of the incident data to Logsign's normalized event schema (user, asset, severity, etc.) has not yet been fully built out on the Logsign side; raw incident fields are currently retained but not all are mapped to normalized fields. This does not block ingestion, but customers relying on specific normalized fields for correlation rules should confirm field availability with Logsign support first.