Palo Alto Prisma Cloud Integration via API

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.

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

This is not the same address as your main Prisma Cloud login URL (app.prismacloud.io, app2.prismacloud.io, etc.). 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.

Step 2: Create an Access Key in the Compute Console

1. In the Prisma Cloud console, go to Settings > Access Keys under the Compute module.
2. Click Add New.
3. Enter a Name (for example, "logsign-uso-integration") and optionally set an expiration date.
4. Make sure the role assigned to the key includes the monitorRuntimeIncidents permission.
5. Click Create.
6. 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:

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.

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.
• This integration only covers Compute module runtime incident audit events (the audits/incidents endpoint). 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/incidents has 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.io or 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.