Palo Alto Prisma Cloud Cloud Security Integration Guide

Overview

The Palo Alto Prisma Cloud integration connects NINA workflows to the Prisma Cloud Cloud Security REST API. It supports cloud security posture, alerts, policies, compliance, asset and application inventory, IAM findings, Data Security, cloud-account administration, reports, searches, audit logs, and tenant administration.

This guide covers only the Cloud Security API (/api/cspm in Palo Alto's documentation). It does not cover Prisma Cloud Runtime Security/Compute, Application Security, DSPM APIs, MSSP APIs, or Cortex products. Those products can use different hosts, credentials, permissions, and request headers.

The integration identifier used in workflow configurations is paloalto-prisma-cloud.

Before You Begin

You need:

• A Prisma Cloud tenant with the Cloud Security capabilities required by your workflows.
• A dedicated Prisma Cloud user for NINA. Do not use an employee's normal administrator account.
• API access enabled for that user.
• A Prisma Cloud role that combines the required permission group with only the required account groups.
• An Access Key ID and Secret Key owned by that user.
• The API URL for the stack hosting your tenant.
• HTTPS connectivity from the integration service to the tenant API URL on TCP 443.
• If login IP allow-list enforcement is enabled, the connector's public egress/NAT addresses in an allowed CIDR.

Licensing and enabled features affect which endpoints are available. For example, Data Security, IAM, Code to Cloud, application inventory, and vulnerability capabilities may not be enabled in every tenant.

Understand the Credentials and Keys

Several unrelated values are called a key, token, or credential in Prisma Cloud. Only the first two rows participate in connector authentication.

Value	Purpose	Store in the NINA credential?
Prisma Cloud Access Key ID	Long-lived identifier sent to POST /login as username	Yes, in Username
Prisma Cloud Secret Key	Secret paired with the Access Key ID and sent as password	Yes, in Password
Prisma Cloud JWT	Short-lived token returned by /login and sent in x-redlock-auth	No. The connector obtains and caches it automatically.
Tenant API URL	Selects the Prisma Cloud stack hosting the tenant	Yes, in Base URL; it is routing information, not a secret.
Interactive Prisma Cloud username/password	Human console sign-in, including local or SSO-backed access	No. Do not enter a human password in place of the Secret Key.
Palo Alto Customer Support Portal, platform, application, or other product API key	Authenticates other Palo Alto services	No. It cannot replace a Prisma Cloud Cloud Security access key.
Cloud-provider onboarding credential	Allows Prisma Cloud to access AWS, Azure, GCP, OCI, or Alibaba Cloud	No. It is used only in cloud-account onboarding operations.
External-integration credential	Allows Prisma Cloud to communicate with systems such as ServiceNow, Splunk, Qualys, Tenable, Okta, or webhooks	No. It belongs in the relevant Prisma integration configuration.

The connector performs this authentication sequence:

1. Sends the Access Key ID and Secret Key to POST {baseUrl}/login as the JSON fields username and password.
2. Receives a JWT that is valid for approximately 10 minutes.
3. Caches the JWT for 9 minutes and keeps a 30-second expiration buffer.
4. Sends the JWT in the x-redlock-auth header for Cloud Security API calls.
5. Logs in again automatically after the cached token expires. Users do not need to create, paste, or refresh JWTs.

This is not OAuth2. No authorization URL, callback URL, client ID, or client secret is used.

Find the Correct Base URL

The default is https://api.prismacloud.io, but it is correct only for tenants whose console is https://app.prismacloud.io. Use the API URL from the Prisma Cloud order fulfillment email or match the hostname shown in the browser after signing in.

Admin console URL	API Base URL
https://app.prismacloud.io	https://api.prismacloud.io
https://app2.prismacloud.io	https://api2.prismacloud.io
https://app3.prismacloud.io	https://api3.prismacloud.io
https://app4.prismacloud.io	https://api4.prismacloud.io
https://app.anz.prismacloud.io	https://api.anz.prismacloud.io
https://app.eu.prismacloud.io	https://api.eu.prismacloud.io
https://app2.eu.prismacloud.io	https://api2.eu.prismacloud.io
https://app.gov.prismacloud.io	https://api.gov.prismacloud.io
https://app.prismacloud.cn	https://api.prismacloud.cn
https://app.ca.prismacloud.io	https://api.ca.prismacloud.io
https://app.sg.prismacloud.io	https://api.sg.prismacloud.io
https://app.uk.prismacloud.io	https://api.uk.prismacloud.io
https://app.ind.prismacloud.io	https://api.ind.prismacloud.io
https://app.jp.prismacloud.io	https://api.jp.prismacloud.io
https://app.fr.prismacloud.io	https://api.fr.prismacloud.io
https://app.id.prismacloud.io	https://api.id.prismacloud.io

Enter only the origin, with no /login, API path, or query string. A trailing slash is accepted and removed by the connector. Palo Alto can add stacks, so verify the current Prisma Cloud API URL table rather than inferring a host from geography.

Using the wrong stack normally causes login failure even when the access key is valid.

Create a Least-Privilege API Identity

Prisma Cloud authorization has four separate controls:

1. User: Owns the access keys and must be active and allowed to use the API.
2. API access: Allows the user to create and use access keys. By default, System Admin has API access and can enable it for other administrators.
3. Permission group: Determines the Cloud Security features and functions the user can access.
4. Role and account groups: A role associates a permission group with account groups and is assigned to the user. Account groups limit the cloud accounts and related data visible to the role.

Access keys do not have independent permissions. Every key inherits the permissions and scope of its owner. Changing the user's role, account groups, API access, or active status changes what the key can do.

Recommended Identity Models

Workflow need	Recommended identity
Read alerts, posture, compliance, inventory, searches, and reports	Dedicated user with a read-only custom permission group and only required account groups
Dismiss/reopen alerts or run remediations	Separate dedicated user with alert read and only the required alert action permissions
Manage policies, standards, users, SSO, IP allow lists, integrations, or cloud accounts	Separate administrative identity for each required administrative domain
Full connector API coverage in a controlled test tenant	System Admin can simplify validation, but is not recommended for routine production workflows

System-defined role and permission-group names vary with the tenant generation, licensing, and enabled modules. Common options include System Admin, System Admin Read Only, Account Group Admin, Account Group Read Only, and Cloud Provisioning Admin. Do not select a role by name alone; inspect its effective features and account-group scope.

Create and Assign the User

The exact navigation differs between Classic and Darwin tenants, but the required result is the same:

1. Sign in as a Prisma Cloud System Admin.
2. Open the tenant's Settings or Access Control area and find Permission Groups.
3. Create a custom permission group for the connector, or select an existing read-only group.
4. Enable only the feature/function permissions listed in the permission matrix below.
5. Create a role that uses that permission group.
6. Assign only the account groups containing cloud accounts the workflow must access.
7. Create a dedicated nonhuman user, for example [email protected].
8. Assign the role to the user and enable API access.
9. Confirm the user is active and can see the required account groups.
10. Test the required API operations with this identity before production use.

Do not enable SSO bypass merely to support the connector. Access-key authentication is independent of the interactive SSO flow. A dedicated API identity also avoids disruption when an employee leaves or their SSO session, password, or MFA configuration changes.

Required Permissions

Prisma Cloud does not publish one stable permission string for each REST endpoint. Available feature/function identifiers are tenant- and release-dependent. Therefore, copying a fixed list of internal permission IDs from another tenant can create either authorization failures or excessive access.

Use this reliable procedure:

1. As an authorized administrator, list the tenant's active features with permission_groups.listFeatures (GET /authz/v1/feature).
2. Inspect existing permission groups with permission_groups.list (GET /authz/v1/permission_group).
3. Create or update a custom permission group with the read or mutation functions needed for the resource families below.
4. Attach the permission group to a role and restrict the role to required account groups.
5. Assign the role to the dedicated user and enable API access.
6. Test every operation the workflow will execute. A successful login proves the key is valid; it does not prove authorization to all endpoints.

Capability-to-Permission Matrix

Connector capability	Minimum read access	Add only when the workflow mutates data	Scope or risk
Alerts and alert rules	Alerts view/list/detail, alert evidence/remediation guidance, alert-rule view	Dismiss/reopen/remediate/send notification; alert-rule create/update/delete	Alerts are account-group scoped. Rules can change alerting and notifications.
Policies and anomalies	Policy and anomaly settings/trusted-list view	Policy create/update/delete/enable; anomaly settings and trusted-list administration	Policy changes alter detection behavior.
Compliance	Compliance posture and standards view	Custom standard, requirement, and section administration	Definition administration is different from reading posture results.
Assets, resources, applications, exposure, and search	Asset Inventory, Asset Explorer, Resource Explorer, application/exposure views, RQL search	Saved filter, saved search, collection, application-discovery criteria, resource-list, or widget administration	Limit role account groups to required cloud accounts.
IAM security findings	IAM findings, identities, effective permissions, and access graph view	IAM IdP configuration only if explicitly required	Cloud IAM findings are distinct from Prisma administrator permissions.
Data Security	Data Security dashboard, inventory, settings, and onboarding-status view	Start onboarding; update settings or data patterns	Requires the relevant license and provider setup.
Vulnerabilities and Code to Cloud	Vulnerability dashboard and Code to Cloud views	Create vulnerability remediation/suppression actions	Remediation can create external tickets or merge requests.
Cloud accounts	Cloud-account inventory, status, hierarchy, owner, and feature view	Cloud Provisioning permissions to add/update/disable/delete accounts or change feature state	Also requires provider-side roles/credentials. Deleting an account is destructive.
Reports, audit, jobs, licensing, and dashboards	Report/adoption/audit/background-job/licensing/Command Center view	Report and widget create/update/delete	Downloads may require a distinct function in some tenants.
External integrations and notification templates	Integration metadata/type and template view	Add/test/update/enable/disable/delete integrations and templates	Integration configurations can contain sensitive destinations or credentials.
Tenant users, roles, permission groups, and account groups	Administration view only if workflows collect these objects	User, role, permission-group, and account-group administration	High privilege; often tenant-global. Keep out of ordinary telemetry identities.
SSO, login IP allow list, and IAM IdP settings	Configuration view only if required	Settings administration	Highest-risk tenant-global controls. Incorrect changes can lock out administrators.
Access keys	Own-key view; API access must be enabled	Create, disable, or delete keys	System Admin sees all tenant keys; other users see only their own.

Some tenant-global administration endpoints are not constrained by account-group membership. Account-group scoping must not be treated as protection for SSO, users, permission groups, integrations, or other global settings. Use a separate identity or omit those permissions.

Read-Only Baseline

For normal security-data ingestion, start with a custom read-only permission group for:

• Alerts and alert rules
• Policies and anomaly information
• Compliance posture and standards
• Asset Inventory, Asset Explorer, Resource Explorer, and RQL search
• Applications, exposure, vulnerabilities, and Code to Cloud only when licensed and used
• IAM findings and Data Security only when licensed and used
• Cloud-account names/status and account groups
• Reports, audit logs, dashboards, background jobs, and licensing only when used

Do not grant user administration, SSO, IP allow-list, permission-group, cloud provisioning, integration administration, policy write, or remediation functions to a read-only collector.

Create the Prisma Cloud Access Key

1. Sign in as the dedicated connector user. If policy requires a System Admin to create or manage the key, preserve ownership by the dedicated user according to your tenant's supported workflow.
2. Open the access-key management page in Prisma Cloud.
3. Select Add Access Key.
4. Enter a descriptive name, such as NINA Cloud Security Production.
5. Select the shortest practical expiration period supported by the tenant.
6. Create the key.
7. Copy both the Access Key ID and Secret Key immediately into an approved secrets manager. The secret is not retained for later retrieval.
8. Record the owner, role, account-group scope, purpose, creation date, expiration date, and rotation owner without recording the Secret Key in tickets or documentation.

Important lifecycle behavior:

• An API-enabled user can have at most two access keys.
• System Admin can list all tenant access keys; other users see only their own.
• Keys can be enabled, disabled, or deleted.
• An expired key cannot be re-enabled.
• The key keeps the permissions of its owner; it is not a separate service principal.
• Rotate keys periodically and before expiry. A two-key limit supports overlap: create the replacement, update and test NINA, and then disable/delete the old key.

For details, see Palo Alto's Access Keys API documentation.

Configure the NINA Credential

NINA field	Required	Value
Name	Yes	Descriptive name, for example Prisma Cloud Production - Read Only
Description	No	Tenant, stack, owner, role, account groups, purpose, and rotation reference; never include the Secret Key
Integration Service	Yes	Palo Alto Prisma Cloud
Auth Type	Yes	Access Key / Secret Key or Credentials, depending on the UI label
Username	Yes	Prisma Cloud Access Key ID, not a username or email address
Password	Yes	Prisma Cloud Secret Key, not the user's console password
Base URL	No, but strongly recommended	Exact API stack URL, for example https://api2.eu.prismacloud.io

To create it:

1. Navigate to Credentials in NINA.
2. Select Add New Credential.
3. Select Palo Alto Prisma Cloud.
4. Enter the Access Key ID in Username.
5. Enter the Secret Key in Password.
6. Enter the exact API stack in Base URL. Leaving it blank uses https://api.prismacloud.io.
7. Select Test Connection. The test calls /login; it validates the key pair and stack, but not permission to every resource.
8. Save the credential.
9. Run one representative read call from every API family the workflow needs.
10. If the workflow performs writes, test those in a non-production scope before enabling production automation.

IP Allow Lists and Network Access

If the tenant enforces a login IP allow list:

1. Determine all public source addresses used by the integration service, including NAT gateways, failover regions, and disaster-recovery paths.
2. Add those addresses as CIDRs to the tenant's login IP allow list before enforcement.
3. Permit outbound HTTPS/TCP 443 to the exact API hostname.
4. Ensure TLS inspection preserves a valid trusted certificate chain and does not block x-redlock-auth.
5. Test /login and at least one authenticated API operation from the deployed connector path.

Do not update or enable the login allow list through the connector without an out-of-band recovery path. A bad CIDR or status change can lock administrators and API clients out of the tenant.

Supported Cloud Security Resources

The connector exposes the following implemented resource keys. Operation names are case-sensitive.

Authentication and Tenant Administration

Resource	Operations	Purpose
login	login, extendSession, logout, ssoInit	Manage JWT sessions or initiate SSO. Normal workflows do not need explicit login operations.
access_keys	list, create, get, delete, updateStatus	Manage Prisma access keys.
user_profile	getMe, updateMe, list, create, get, update, delete, getRoles	Manage the current profile and tenant users.
user_roles	list, create, listNames, listTypes, get, update, delete	Manage user roles and assignments.
permission_groups	list, add, get, update, delete, listFeatures	Manage feature/function permission groups.
sso	getConfig, updateConfig, getBypassUsers, updateBypassUsers	Manage tenant SSO and bypass users.
ip_allow_list	getLoginIPAllowList, updateLoginIPAllowList, updateLoginIPAllowListStatus	Manage login CIDR allow lists.
iam_idp	getIdpConfig, updateIdpConfig, testIdpConnection	Manage the IAM identity-provider configuration.

Cloud Accounts and Organization

Resource	Operations	Purpose
account_groups	list, create, listNames, listNamesByCloudType, get, update, delete	Group cloud accounts for access and alerting.
cloud_accounts_all	getAccountStatus, listCloudAccounts, listCloudAccountNames, listCloudAccountNamesFiltered, listCloudTypes, getCloudAccountDetails, getCloudOrgAccounts, listCloudAccountOwners, listSupportedFeatures, deleteCloudAccount, updateCloudAccountDetails, updateCloudAccountStatus, updateFeatureStateForMembers, saveAccountConfig	Provider-neutral inventory and administration.
cloud_accounts_aws	addCloudAccount, updateCloudAccount, addDataSecurityConfig, updateDataSecurityConfig, listAncestors, listChildren, getAccountStatus, checkDataSecurityPreconditions, getDataSecurityConfig, generateCFTLink, generateCFTTemplate, getMasterAccountConfig, getPCDSStatus	AWS onboarding, hierarchy, and Data Security configuration.
cloud_accounts_azure	addCloudAccount, updateCloudAccount, getAccountStatus, listAncestors, listChildren, generateTerraformTemplate	Azure onboarding and hierarchy.
cloud_accounts_gcp	addCloudAccount, updateCloudAccount, getAccountStatus, listChildren, listAncestors, getHierarchy, listFolders, listProjects, generateTerraformTemplate	GCP onboarding and hierarchy.
cloud_accounts_oci	addCloudAccount, updateCloudAccount, getAccountStatus	OCI onboarding and status.
cloud_accounts_alibaba	addCloudAccount, updateCloudAccount	Alibaba Cloud onboarding.
aws_logging_accounts	getStatus, getStatusFiltered	Inspect AWS log-puller status.
cloud_ingested_logs	getStatus, listConfigs	Inspect cloud log ingestion.
collections	listCollections, getCollection, addCollection, updateCollection, deleteCollection	Manage cloud-resource collections.
resource_lists	list, create, listTypes, get, update, delete	Manage tagged or labeled resource lists.

Cloud-account onboarding requires two permission planes. The connector identity needs Prisma Cloud provisioning permission, and Prisma Cloud needs provider-side authorization such as an AWS IAM role, Azure application/service principal values, GCP service account/configuration, OCI credentials, or Alibaba RAM role. Provider credentials passed to onboarding operations are not connector credentials. Generate and review the current Palo Alto CFT/Terraform templates to obtain the exact provider permissions for the enabled features.

Alerts, Policies, and Anomalies

Resource	Operations	Purpose
alert_rules	list, create, get, update, delete	Manage policy-to-notification rules.
alerts	getFilterSuggestions, getFilterAutoComplete, listV2, listV2Post, getCount, get, getGraph, getAIRemediation, getDismissalNoteConfig, setDismissalNoteConfig, listByPolicyV2, listByPolicyAggregateV2, dismiss, reopen, sendNotification, getRemediation, remediate, submitExportJob, getExportJobStatus, downloadExportJob, submitCSVExportJob, getCSVExportJobStatus, downloadCSVExport, submitPolicyExportJob, getPolicyExportJobStatus, downloadPolicyExportJob	Query, act on, remediate, and export alerts.
anomalies	getTrustedList, addTrustedListEntries, getTrustedListEntry, updateTrustedListEntry, deleteTrustedListEntry, listTrustedListTypes, listPoliciesForType, getAllSettings, getSettings, updateSettings	Manage anomaly settings and trusted lists.
policy	listFilters, listFilterSuggestions, list, listV2, add, get, update, delete, updateStatus, listComplianceStandards, preValidateRule	Query and manage policies.
notification_templates	list, add, get, update, delete	Manage alert-notification templates.

Inventory, Exposure, and Vulnerabilities

Resource	Operations	Purpose
applications	downloadInventory, getDiscoveryCriteria, createDiscoveryCriteria, getAppDiscoveryCriteria, deleteDiscoveryCriteria, updateDiscoveryCriteria, downloadAppDetails, downloadAppABOM, list, get, getAssets, getVulnerabilities, getAlerts, getSummary, getRiskCounts, listTags, searchByRQL, getVulnsAndAlerts, getServiceVulnsAndAlerts, getAssetsAndServices	Query applications, assets, risks, vulnerabilities, and discovery criteria.
asset_inventory	listFiltersV2, listFilterSuggestionsV2, listSavedFilters, saveFilter, getSavedFilter, updateSavedFilter, deleteSavedFilter, getInventoryV2, getInventoryV2Post, getInventoryTrendV2, getInventoryTrendV2Post, getInventoryV3, getInventoryV3Post, getInventoryTrendV3, getInventoryTrendV3Post	Query inventory/trends and manage saved filters.
asset_explorer	listFilters, listFilterSuggestions, getScanInfo, getScanInfoPost, getScanInfoV2, getScanInfoV2Post, getAsset	Query scan and asset details.
asset_relationship_definitions	list	List supported asset relationships.
resource_explorer	getTimeline, getNetworkTopology, getAlerts	Investigate a resource's history, topology, and alerts.
archived_assets	bulkExport	Request archived deleted-asset data.
discovery_exposure_management	listFilters, getAssets, getAsset, getSummary	Query discovered/exposed assets.
code_to_cloud	listAssets, getPipeline, getRuntimeTrend	Correlate development and runtime assets.
vulnerabilities_dashboard	c2cTraceAssetGraph, cveOverviewPost, burndown, vulnerableAssetsByCve, prioritisedVulnerabilitiesPost, topImpactingVulnerabilitiesPost, vulnerabilityOverviewPost, impactByStagePost, vulnerableAssetsStats, remediationStatus, createRemediation, downloadVulnerabilitiesByRql, cveDetailsV3, vulnerableAssetsByRql, vulnerabilitiesByRql	Prioritize vulnerabilities and create remediation actions.

Compliance and Data Security

Resource	Operations	Purpose
compliance_posture	getPostureStats, getPostureStatsPost, getPostureStatsByStandard, getPostureStatsByStandardPost, getPostureStatsByRequirement, getPostureStatsByRequirementPost, getPostureTrend, getPostureTrendPost, getPostureTrendByStandard, getPostureTrendByStandardPost, getPostureTrendByRequirement, getPostureTrendByRequirementPost, getFilterOptions, getFilterAutoComplete, getPostureStatsV2, getPostureStatsV2Post, getPostureStatsByStandardV2, getPostureStatsByStandardV2Post, getPostureStatsByRequirementV2, getPostureStatsByRequirementV2Post, getPostureTrendV2, getPostureTrendV2Post, getPostureTrendByStandardV2, getPostureTrendByStandardV2Post, getPostureTrendByRequirementV2, getPostureTrendByRequirementV2Post	Query compliance statistics and trends.
compliance_standards	list, create, get, update, delete, clone, listRequirements, createRequirement, getRequirement, updateRequirement, deleteRequirement, listSections, createSection, updateSection, deleteSection	Manage custom standards, requirements, and sections.
data_security_dashboard	getSummary, getObjectCategories, getTopExposedObjects, getTopDataPatterns, getTopRisks	Query Data Security posture.
data_security_inventory	listResources, getResource, listObjects	Query protected data resources and objects.
data_security_onboarding	getStatus, start	Inspect or start Data Security onboarding.
data_security_settings	getSettings, updateSettings, addDataPattern, updateDataPattern, deleteDataPattern	Manage Data Security settings and patterns.

Search, Reporting, and Dashboards

Resource	Operations	Purpose
search_manager	list, save, get, update, delete	Manage saved and recent RQL searches.
search	networkSearch, searchAlerts, configSearchByQuery, configSearchAsync, configSearchDownload, configSearchV2, configSearchByIdV2, configSearchById, configSearch, submitConfigCsvJob, downloadConfigCsv, configSearchPage, eventSearch, eventSearchAggregated, eventSearchFiltered, eventSearchDownload, eventSearchPage, eventSearchRaw, suggest	Run network, configuration, alert, and event RQL searches.
audit_logs	getAuditLogs, getFilterSuggestions	Query tenant audit activity.
reports	list, add, get, update, delete, download	Manage and retrieve reports.
adoption_advisor	listReports, getReport, downloadReport	Retrieve Adoption Advisor reports.
command_center	getSummary, getTopAttackPaths, getTopIncidents, getTopVulnerabilities, getTopPolicyViolations	Query Command Center summaries.
widgets	getWidgets, addWidget, getWidget, updateWidget, deleteWidget, getDiscoveredSecuredResources	Manage dashboards and widgets.
background_jobs	list	Inspect asynchronous jobs.

Integrations, IAM, and Licensing

Resource	Operations	Purpose
integrations	getSupportedTypes, list, add, get, updateStatus, update, delete, test, getSecurityHubRegions, getSecurityHubAccounts	Manage external integrations.
integrations_pull	getQualysConfig, updateQualysConfig, getTenableConfig, updateTenableConfig, getOktaConfig, updateOktaConfig	Manage pull-integration settings.
iam	getNetEffectivePermissions, getAccessGraph, getPermissionDetails	Investigate cloud IAM access.
licensing	getSummary, getUsage, getUsageHistory	Query license and usage information.

Parameter and Response Behavior

Parameter Routing

• Path parameters such as id, policyId, appId, or cloudType replace {...} placeholders and must be non-empty strings.
• For GET and DELETE, remaining scalar parameters are URL query parameters. Arrays become repeated query keys.
• For POST, PUT, and PATCH, remaining parameters become one JSON object body.
• Operation and parameter names are case-sensitive.
• The schema describes required parameters and enums, but the remote Prisma Cloud API remains the final validator. Follow the node's operation schema and Palo Alto API reference.
• Input fields from upstream nodes are passed through as extracted parameters. Node-level parameter merging and {{variable_name}} interpolation are provided by the NINA workflow runtime.

Pagination

The connector does not automatically fetch all pages. For token-based endpoints:

1. Call the list/search operation with an optional limit.
2. Process the returned records.
3. Read the returned nextPageToken or pageToken field, depending on the API.
4. Call the same operation again with that token.
5. Stop when no next token is returned.

alerts.listV2 also exposes zero-based offset; prefer the API's token model when a next-page token is returned. Large application and vulnerability searches have endpoint-specific limits, so use RQL filters and pagination rather than assuming one response is complete.

Response Normalization

• JSON objects are returned unchanged.
• A top-level JSON array is returned as {"value": [...]}.
• A successful empty response is returned as {"success": true}.
• HTTP errors include the Prisma message when present.
• The default request timeout is 90 seconds.
• Normal operations retry timeouts and HTTP 429 responses up to three times after the initial attempt, using 1-, 2-, and 4-second exponential delays. A numeric Retry-After header is honored.
• Other HTTP failures are not automatically retried. A 401/403 does not trigger immediate refresh-and-replay.

Download Limitation

The current connector expects JSON responses and always requests application/json. Operations that return raw CSV, GZIP, template, or other binary/text files may fail response parsing even though their submit/status operations work. This affects operations whose names include download, bulkExport, or template generation when the endpoint returns non-JSON content. Validate each download operation before building a production workflow around it.

Workflow Examples

List Open Alerts

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "alerts",
  "operation": "listV2",
  "parameters": {
    "status": "open",
    "timeType": "relative",
    "timeUnit": "day",
    "timeAmount": 7,
    "limit": 100
  }
}

Use a returned page token in a subsequent call:

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "alerts",
  "operation": "listV2",
  "parameters": {
    "status": "open",
    "limit": 100,
    "pageToken": "{{nextPageToken}}"
  }
}

Get an Alert and Remediation Guidance

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "alerts",
  "operation": "get",
  "parameters": {
    "id": "{{alert_id}}"
  }
}

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "alerts",
  "operation": "getRemediation",
  "parameters": {
    "alerts": ["{{alert_id}}"]
  }
}

List Cloud Accounts and Account Groups

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "cloud_accounts_all",
  "operation": "listCloudAccounts",
  "parameters": {}
}

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "account_groups",
  "operation": "listNamesByCloudType",
  "parameters": {
    "cloudType": "aws"
  }
}

Valid cloudType values for account_groups.listNamesByCloudType are aws, azure, gcp, alibaba_cloud, and oci.

Run a Configuration RQL Search

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "search",
  "operation": "configSearchByQuery",
  "parameters": {
    "query": "config from cloud.resource where cloud.type = 'aws' AND api.name = 'aws-ec2-describe-instances'"
  }
}

Use the exact RQL supported by your tenant. Available fields and APIs vary by provider and enabled features.

Read Compliance Posture

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "compliance_posture",
  "operation": "getPostureStatsV2",
  "parameters": {
    "timeType": "relative",
    "timeUnit": "day",
    "timeAmount": 30
  }
}

Dismiss an Alert

This is a write operation. Use an identity with alert dismissal permission, and consider an approval step.

{
  "integration_service": "paloalto-prisma-cloud",
  "resource": "alerts",
  "operation": "dismiss",
  "parameters": {
    "alerts": ["{{alert_id}}"],
    "dismissalNote": "Reviewed and resolved under incident {{incident_id}}"
  }
}

To snooze instead of permanently dismissing, add snoozeTime as a Unix epoch timestamp in milliseconds. The API also supports a filter object for bulk dismissal. Confirm body fields in the current tenant/API schema before production use because Prisma Cloud can evolve these values.

High-Risk Operations

Use separate credentials, approval gates, and audit logging for operations that can change security coverage or tenant access:

• Deleting, disabling, or changing cloud accounts and their enabled features
• Starting Data Security onboarding or changing data patterns/settings
• Creating remediation or suppression actions
• Dismissing, reopening, or remediating alerts
• Creating, changing, disabling, or deleting policies and anomaly settings
• Changing alert rules, notification templates, or external integrations
• Creating, changing, or deleting users, roles, permission groups, or account groups
• Changing SSO, SSO bypass users, IAM IdP, or login IP allow lists
• Creating, disabling, or deleting access keys

Troubleshooting

Symptom	Cause and resolution
username is required or password is required	Enter the Access Key ID as Username and Secret Key as Password. Both are required.
Login fails with valid-looking keys	Verify the Base URL matches the tenant stack, the key is enabled and unexpired, its owner is active, and API access is enabled.
Password/SSO login error	Do not use an interactive username/password. Create a Prisma Cloud Access Key ID and Secret Key.
HTTP 401	The JWT or key may be invalid/expired, the owner may be disabled, or the wrong stack may be configured. Re-test the credential. The connector does not replay a failed request automatically after a 401.
HTTP 403	Login succeeded but the owner's permission group or account-group scope does not authorize the endpoint. Add only the missing feature/function and retest.
One account or alert is missing	Verify the role includes the account group containing that cloud account. Also inspect API filters and pagination tokens.
HTTP 404	Check the stack URL, resource ID, feature/license availability, and whether the endpoint is available in the tenant generation.
HTTP 429	The tenant rate limit was reached. The connector retries up to three times; reduce concurrency, narrow searches, paginate, or delay polling.
Login blocked by network policy	Add every connector public egress CIDR to the login IP allow list and permit HTTPS to the API host.
Empty list despite visible console data	Check account-group scope, time range, filters, pagination, and whether the console view uses a separately licensed API family.
id is required, policyId is required, or similar	Path identifiers must be present, non-empty strings. Pass the exact identifier from the preceding response.
Download operation reports JSON parse failure	The endpoint returned CSV, GZIP, or another non-JSON artifact. The current connector does not support raw artifact responses.
Mutation returns an API validation error	Body fields are passed to Prisma as provided. Review the operation schema and current Palo Alto API documentation for required nested objects and allowed values.
Test Connection succeeds but workflow fails	Test Connection validates only /login. Test each required API family because permissions and licenses are enforced per endpoint.

Security and Operational Best Practices

1. Use a dedicated nonhuman Prisma Cloud user and document its operational owner.
2. Separate read-only collection credentials from remediation, provisioning, and tenant-administration credentials.
3. Restrict the role to required account groups and verify effective access with representative API calls.
4. Store only the Access Key ID and Secret Key in the credential manager. Never place them in workflow parameters, logs, screenshots, tickets, or source control.
5. Select limited key validity, record expiry, and rotate before expiration using the second access-key slot.
6. Disable and delete the old key after replacement validation. Disable the user and keys when decommissioning the connector.
7. Use stable outbound addresses and narrowly scoped CIDRs if login IP allow lists are enabled.
8. Require approvals for destructive or security-control changes and preserve Prisma audit logs.
9. Paginate all list/search workflows and rate-limit polling of export, remediation, and background jobs.
10. Validate licensed feature availability and operation permissions in a non-production account group before deployment.
11. Review custom permission groups after Prisma Cloud releases because active features and function identifiers can change.
12. Do not confuse connector authentication with provider onboarding credentials or external-integration secrets.

Authoritative References

• Cloud Security API reference
• Prisma Cloud API URLs
• Cloud Security API headers
• Access Keys
• Login API
• JWT authentication workflow
• Permission Groups
• User Roles
• Account Groups
• IP Allow List
• Rate Limits

Updated: 2026-07-22