Palo Alto Prisma Access (SASE) Integration Guide

Overview

The Palo Alto Prisma Access integration connects NINA workflows to Palo Alto Networks' cloud-delivered SASE platform via the Strata Cloud Manager (SCM) Configuration API. The integration covers 77 resources and 344 operations, generated directly from Palo Alto's official OpenAPI specifications, allowing your workflows to manage policy, objects, profiles, network services, identity providers, certificates, and configuration deployment for cloud-delivered Prisma Access tenants.

Prisma Access is Palo Alto's flagship SASE product — cloud-delivered firewall-as-a-service, ZTNA, and GlobalProtect-as-a-service. It is managed through the Strata Cloud Manager rather than an on-premises firewall, so it uses a different API surface than the on-premises Palo Alto integration (which targets PAN-OS firewalls and Panorama).

Status

The integration covers the entirety of the Prisma Access Configuration API (/sse/config/v1/...):

Supported Resource Categories

• Policy Objects (15 resources): Addresses, Address Groups, Applications, Application Filters, Application Groups, Schedules, Services, Service Groups, Tags, External Dynamic Lists, Dynamic User Groups, HIP Objects, HIP Profiles, Regions, URL Categories, URL Filtering Categories
• Policy Rules (5 resources): Security Rules, Decryption Rules, Authentication Rules, Application Override Rules, Traffic Steering Rules, QoS Policy Rules
• Security Profiles (8 resources): Anti-Spyware, Vulnerability Protection, File Blocking, WildFire Antivirus, DNS Security, URL Access, Decryption, Decryption Exclusions, HTTP Header, Profile Groups
• Identity & Authentication (10 resources): Authentication Profiles, Authentication Portals, Authentication Sequences, LDAP/RADIUS/TACACS/Kerberos/MFA Server Profiles, SAML Server Profiles, Local Users, Local User Groups
• Certificates & Trust (6 resources): Certificates, Certificate Profiles, OCSP Responder, SCEP Profiles, TLS Service Profiles, Trusted Certificate Authorities
• Network Setup (8 resources): Remote Networks, Service Connections, Service Connection Groups, Bandwidth Allocations, IKE/IPSec Crypto Profiles, IKE Gateways, IPSec Tunnels, Internal DNS Servers, Infrastructure Settings
• Mobile Agent / GlobalProtect (9 resources): Agent Profiles, Authentication Settings, Infrastructure Settings, Tunnel Profiles, Global Settings, Locations, Agent Versions, Enable, User Authentication
• Configuration Management (2 resources): Config Versions (push, load, rollback, view running), Jobs (monitor async operations)
• Tenant Catalogues (3 resources, read-only): Locations, License Types, Quarantined Devices
• Threat Signatures (2 resources, read-only): Anti-Spyware Signatures, Vulnerability Protection Signatures

Key Capabilities

• Schema-driven dispatch: every operation is declaratively described — adding a new resource is a schema-only change as Palo Alto evolves the API
• Authoritative field documentation: parameter descriptions, enums, and constraints (max length, regex patterns, value formats) are pulled directly from Palo Alto's OpenAPI specs and surface in the workflow editor as tooltips
• Live folder discovery: the folder parameter is a resource locator with a dropdown that calls the SCM Setup API to enumerate your tenant's folders — including any custom folders or snippets — with manual entry as a fallback
• OAuth2 client-credentials authentication: stateless, token-cached, mutex-protected for concurrent workers, and refreshed automatically before expiry
• Configuration deployment: trigger candidate-config push (:push) and saved-version load (:load), then poll for completion via the Jobs resource
• Action endpoints: rule re-ordering (securityRule:move), config rollback (configVersion.rollbackCandidate), and other non-CRUD verbs are first-class operations

Important Notes

• Distinct from on-premises Palo Alto integration: this integration targets cloud-delivered Prisma Access via SCM, not on-premises firewalls. Operations created here will not appear on your PAN-OS firewall and vice versa.
• Folder selection drives multi-tenancy: nearly every operation requires a folder parameter (e.g. Shared, Mobile Users, Remote Networks). The folder determines where the object lives in your SCM hierarchy.
• Candidate vs running configuration: changes (create, update, delete) modify the candidate configuration. They do not take effect until you push them via configVersion.push.
• Push is asynchronous: the push operation returns a job ID. Monitor completion via job.get.
• TSG-ID scope: every API call is scoped to a single Tenant Service Group (TSG). If your organisation has multiple TSGs, configure separate credentials.
• Read-only catalogues: location, licenseType, and a handful of signature resources are tenant catalogues exposed as read-only.

Not Currently Supported

The following Palo Alto SASE surfaces are not part of this integration:

• Prisma SaaS (CASB): SaaS application security and DLP for cloud apps — separate product, separate API
• Prisma Cloud (CSPM/CWPP): cloud workload protection, container, and IaC scanning — separate product
• Prisma SD-WAN (CloudGenix): software-defined WAN — separate product, separate SDK
• Prisma Access Browser: enterprise browser product (formerly Talon)
• Autonomous DEM (ADEM): digital experience monitoring — separate API
• Strata Logging Service: log retrieval and query — separate API
• SCM Setup CRUD: folder/snippet/device management — exposed read-only via the folder resource locator only; full CRUD lives on a different host (api.strata.paloaltonetworks.com/config/setup/v1/...) and would require a separate integration

For comprehensive information about Prisma Access capabilities, refer to the official documentation at https://docs.paloaltonetworks.com/prisma-access and the developer docs at https://pan.dev/access/docs/.

---

Credential Configuration

Before using the Palo Alto Prisma Access integration, configure OAuth2 client-credentials authentication.

Authentication Method

Prisma Access uses OAuth2 client credentials flow scoped to your Tenant Service Group (TSG):

Field	Description	Example / Default
Client ID	OAuth2 client ID provisioned in the Palo Alto Networks Identity Provider	abc12345
Client Secret	OAuth2 client secret paired with the Client ID	xxxxxxxx... (treat as a password)
TSG ID	Tenant Service Group ID — the OAuth2 scope (tsg_id:<TSG_ID>)	1234567890
Base URL	Strata Cloud Manager API base URL	https://api.sase.paloaltonetworks.com
Auth Base URL	Identity Provider URL for token requests	https://auth.apps.paloaltonetworks.com

The integration handles token acquisition, caching (5-minute refresh buffer), and concurrent-worker safety automatically. You never need to manage tokens directly.

Generating Client Credentials

Client credentials are provisioned through the Strata Cloud Manager UI:

1. Sign in to the Strata Cloud Manager.
2. Navigate to Settings → Identity & Access → Service Accounts.
3. Click Add Service Account.
4. Provide a descriptive name (e.g. "NINA Automation").
5. Assign one or more roles. Recommended:
   • Prisma Access Admin — read/write access to /sse/config/v1/... (this integration's full surface)
   • SCM Admin — additional read access to folders/snippets via the SCM Setup API (used by the folder dropdown; without it, the dropdown silently falls back to the system folders)
6. Click Save. The Client ID and Client Secret are displayed once — copy and store them securely.

Where to find your TSG ID:

• The TSG ID appears in the SCM URL when you're signed in: https://stratacloudmanager.paloaltonetworks.com/.../tsg/<TSG_ID>/...
• Alternatively, navigate to Settings → Tenant Information

Important Security Notes:

• Client Secrets are credentials — never commit them to version control or share them in workflow configuration
• Use dedicated service accounts with the minimum required role assignments
• Tokens issued by this flow are short-lived (15 minutes) — the integration refreshes them automatically
• Rotate Client Secrets periodically per your organisation's security policy

Required Permissions

The minimum permissions depend on which operations your workflows perform:

• Read operations (list, get) on /sse/config/v1/...: Prisma Access read-only role
• Write operations (create, update, delete): Prisma Access Admin role
• Configuration deployment (configVersion.push, configVersion.load): Prisma Access Admin role
• Folder enumeration (the folder dropdown's live lookup): SCM Admin role on api.strata.paloaltonetworks.com/config/setup/v1/folders. If your service account lacks this role, the dropdown still works — it falls back to the six predefined system folders.

Creating a Palo Alto Prisma Access Credential in NINA

1. Navigate to the Credentials section in NINA
2. Click Add New Credential
3. Fill in the credential details:
   • Name: A descriptive name (e.g. "Prisma Access Production")
   • Description: Optional details about the credential's purpose
   • Integration Service: Select "Palo Alto Prisma Access"
   • Auth Type: "OAuth2 Client Credentials" (only option available)
   • Client ID: Paste your Client ID
   • Client Secret: Paste your Client Secret
   • TSG ID: Paste your Tenant Service Group ID
   • Base URL and Auth Base URL: leave as default unless your tenant runs in a regional cloud
4. Click Test Connection to verify credentials
5. Click Save to store the credential

---

Supported Resources and Operations

The full operation matrix is generated from the Palo Alto OpenAPI specs and includes 77 resources × 344 operations. The most-used resources are summarised below. Every resource exposes a consistent CRUD shape (list, create, get, update, delete) unless otherwise noted; some resources additionally expose action endpoints (:push, :load, :move).

Policy Rules

The rule-based resources expose CRUD plus a move action for re-ordering:

Resource	Operations	Path stem
securityRule	list, create, get, update, delete, move	/sse/config/v1/security-rules
decryptionRule	list, create, get, update, delete, move	/sse/config/v1/decryption-rules
authenticationRule	list, create, get, update, delete	/sse/config/v1/authentication-rules
applicationOverrideRule	list, create, get, update, delete, move	/sse/config/v1/application-override-rules
qosPolicyRule	list, create, get, update, delete, move	/sse/config/v1/qos-policy-rules
trafficSteeringRule	list, create, get, update, delete	/sse/config/v1/traffic-steering-rules

Key parameters across rule resources:

• folder — required; the folder containing the rule (resource locator with live dropdown)
• position — required for security rules; pre (evaluated before service-managed rules) or post
• name — rule name (alphanumeric plus ._-, max 63 chars)
• action — allow, deny, drop, reset-client, reset-server, reset-both
• Source/destination zones, addresses, applications, services, users, categories
• Profile group references (profile_group, individual security profile fields)

Policy Objects

Resource	Operations	Path stem
address	list, create, get, update, delete	/sse/config/v1/addresses
addressGroup	list, create, get, update, delete	/sse/config/v1/address-groups
application	list, create, get, update, delete	/sse/config/v1/applications
applicationGroup	list, create, get, update, delete	/sse/config/v1/application-groups
applicationFilter	list, create, get, update, delete	/sse/config/v1/application-filters
service	list, create, get, update, delete	/sse/config/v1/services
serviceGroup	list, create, get, update, delete	/sse/config/v1/service-groups
tag	list, create, get, update, delete	/sse/config/v1/tags
schedule	list, create, get, update, delete	/sse/config/v1/schedules
region	list, create, get, update, delete	/sse/config/v1/regions
externalDynamicList	list, create, get, update, delete	/sse/config/v1/external-dynamic-lists
dynamicUserGroup	list, create, get, update, delete	/sse/config/v1/dynamic-user-groups
hipObject	list, create, get, update, delete	/sse/config/v1/hip-objects
hipProfile	list, create, get, update, delete	/sse/config/v1/hip-profiles
urlCategory	list, create, get, update, delete	/sse/config/v1/url-categories
urlFilteringCategory	list, get	/sse/config/v1/url-filtering-categories

Address-object discriminator: when creating an address, provide exactly one of ip_netmask, ip_range, ip_wildcard, or fqdn.

Security Profiles

Resource	Path stem
antiSpywareProfile	/sse/config/v1/anti-spyware-profiles
vulnerabilityProtectionProfile	/sse/config/v1/vulnerability-protection-profiles
fileBlockingProfile	/sse/config/v1/file-blocking-profiles
wildfireAntivirusProfile	/sse/config/v1/wildfire-antivirus-profiles
dnsSecurityProfile	/sse/config/v1/dns-security-profiles
urlAccessProfile	/sse/config/v1/url-access-profiles
decryptionProfile	/sse/config/v1/decryption-profiles
decryptionExclusion	/sse/config/v1/decryption-exclusions
httpHeaderProfile	/sse/config/v1/http-header-profiles
profileGroup	/sse/config/v1/profile-groups

All security profile resources expose CRUD. Profile groups bundle profiles for attachment to security rules.

Identity & Authentication

Resource	Path stem
authenticationProfile	/sse/config/v1/authentication-profiles
authenticationPortal	/sse/config/v1/authentication-portals
authenticationSequence	/sse/config/v1/authentication-sequences
samlServerProfile	/sse/config/v1/saml-server-profiles
ldapServerProfile	/sse/config/v1/ldap-server-profiles
radiusServerProfile	/sse/config/v1/radius-server-profiles
tacacsServerProfile	/sse/config/v1/tacacs-server-profiles
kerberosServerProfile	/sse/config/v1/kerberos-server-profiles
mfaServer	/sse/config/v1/mfa-servers
localUser	/sse/config/v1/local-users
localUserGroup	/sse/config/v1/local-user-groups

Certificates

Resource	Path stem
certificate	/sse/config/v1/certificates
certificateProfile	/sse/config/v1/certificate-profiles
ocspResponder	/sse/config/v1/ocsp-responder
scepProfile	/sse/config/v1/scep-profiles
tlsServiceProfile	/sse/config/v1/tls-service-profiles
trustedCertificateAuthority	/sse/config/v1/trusted-certificate-authorities

Network Setup

Resource	Path stem
remoteNetwork	/sse/config/v1/remote-networks
serviceConnection	/sse/config/v1/service-connections
serviceConnectionGroup	/sse/config/v1/service-connection-groups
bandwidthAllocation	/sse/config/v1/bandwidth-allocations
internalDnsServer	/sse/config/v1/internal-dns-servers
infrastructureSetting	/sse/config/v1/shared-infrastructure-settings
ikeCryptoProfile	/sse/config/v1/ike-crypto-profiles
ikeGateway	/sse/config/v1/ike-gateways
ipsecCryptoProfile	/sse/config/v1/ipsec-crypto-profiles
ipsecTunnel	/sse/config/v1/ipsec-tunnels

Mobile Agent / GlobalProtect

The MobileAgent surface is split into nine sub-resources reflecting the API path segments:

Resource	Path stem
mobileAgentAgentProfile	/sse/config/v1/mobile-agent/agent-profiles
mobileAgentAuthenticationSetting	/sse/config/v1/mobile-agent/authentication-settings
mobileAgentInfrastructureSetting	/sse/config/v1/mobile-agent/infrastructure-settings
mobileAgentTunnelProfile	/sse/config/v1/mobile-agent/tunnel-profiles
mobileAgentGlobalSetting	/sse/config/v1/mobile-agent/global-settings
mobileAgentLocation	/sse/config/v1/mobile-agent/locations
mobileAgentAgentVersion	/sse/config/v1/mobile-agent/agent-versions
mobileAgentEnable	/sse/config/v1/mobile-agent/enable
mobileAgentUserAuthentication	/sse/config/v1/mobile-agent/user-authentication

Configuration Management

Resource	Operations	Description
configVersion	list, push, load, getRunning, rollbackCandidate	Manage candidate configuration deployment
job	list, get	Monitor asynchronous configuration jobs

Action endpoints:

• configVersion.push — POST /sse/config/v1/config-versions/candidate:push — pushes the current candidate configuration to the Prisma Access dataplane. Returns a job ID.
• configVersion.load — POST /sse/config/v1/config-versions:load — loads a previously-saved configuration version as the new candidate.
• configVersion.getRunning — GET /sse/config/v1/config-versions/running — returns the current running configuration.
• configVersion.rollbackCandidate — DELETE /sse/config/v1/config-versions/candidate — discards the candidate configuration and reverts to the running configuration.

---

The Folder Parameter

Most operations require a folder parameter — Prisma Access's multi-tenancy unit. NINA renders this as a resource locator with two modes:

• Folder dropdown: live-populated from the SCM Setup API. Includes both the predefined system folders and any custom folders/snippets your tenant has created. Searchable by name.
• Manual entry: free-text field for explicit folder names. Useful when chaining workflows or when the dropdown is unavailable due to permissions.

Predefined System Folders

These folders are guaranteed available on every tenant:

Folder	Use
Shared	Objects available to all configurations
Mobile Users	GlobalProtect / Prisma Access for Users configuration
Remote Networks	Branch / IPSec-tunnel-attached site configuration
Service Connections	Backbone connections to data centres / SaaS
Mobile Users Container	Container for the Mobile Users hierarchy
Mobile Users Explicit Proxy	Explicit proxy mode for Mobile Users

If your service account lacks the SCM Admin role, the live folder dropdown silently falls back to these six folders. The integration never errors on missing folder permissions — the user simply doesn't see custom folders.

---

Examples

Example: List Addresses in the Shared Folder

{
  "resource": "address",
  "operation": "list",
  "parameters": {
    "folder": "Shared",
    "limit": 200
  }
}

Example: Create an Address Object

{
  "resource": "address",
  "operation": "create",
  "parameters": {
    "folder": "Shared",
    "name": "Malicious_IP_203_0_113_42",
    "ip_netmask": "203.0.113.42/32",
    "description": "IP flagged by threat intel feed on 2026-05-04",
    "tag": ["Blocked", "ThreatIntel"]
  }
}

Example: Create a Security Rule

{
  "resource": "securityRule",
  "operation": "create",
  "parameters": {
    "folder": "Shared",
    "position": "pre",
    "name": "Block_Malicious_IP_203_0_113_42",
    "action": "deny",
    "from": ["any"],
    "to": ["any"],
    "source": ["Malicious_IP_203_0_113_42"],
    "destination": ["any"],
    "application": ["any"],
    "service": ["any"],
    "description": "Auto-block from threat intel workflow"
  }
}

Example: Push the Candidate Configuration

After making changes, deploy them via push and capture the job ID:

{
  "resource": "configVersion",
  "operation": "push",
  "parameters": {
    "folders": ["Shared"],
    "description": "Deploy malicious IP block from incident #2026-001"
  }
}

Example: Monitor a Push Job

{
  "resource": "job",
  "operation": "get",
  "parameters": {
    "id": "12345"
  }
}

Example: List Running Configuration

{
  "resource": "configVersion",
  "operation": "getRunning",
  "parameters": {}
}

Example: Re-order a Security Rule

{
  "resource": "securityRule",
  "operation": "move",
  "parameters": {
    "id": "abc-123-def-456",
    "destination": "before",
    "destination_rule": "xyz-789-pqr-012",
    "rulebase": "pre"
  }
}

Example: Create a URL Category for Domain Blocking

{
  "resource": "urlCategory",
  "operation": "create",
  "parameters": {
    "folder": "Shared",
    "name": "Phishing_Domains_2026_05",
    "type": "URL List",
    "list": ["phishing-site-a.com", "*.phishing-site-b.net"],
    "description": "Phishing domains identified by inbound email analysis"
  }
}

---

Integration in Workflow Context

Prisma Access shines when chained into multi-step automation:

Common Workflow Patterns

1. Automated IOC Blocking:

   • Threat Intel Feed → Script Node (parse IOCs) → Prisma Access (create address) → Prisma Access (create security rule) → Prisma Access (push) → Prisma Access (poll job) → Slack (notify)

2. Phishing Domain Response:

   • Email Analysis Node → Script Node (extract domains) → Prisma Access (create URL category) → Prisma Access (push) → Email Node (notify SOC)

3. Compromised Account Containment:

   • Identity Provider Alert → Prisma Access (create dynamic user group rule) → Prisma Access (push) → Identity Provider (disable account) → Ticket Node

4. Bulk IOC Import:

   • Schedule Node → File Node (read IOC CSV) → Loop → Prisma Access (create address) → End Loop → Prisma Access (push) → Job poll → Notification

5. Remote Network Provisioning:

   • Provisioning Trigger → Prisma Access (create remote network) → Prisma Access (create IKE/IPSec config) → Prisma Access (push) → Job poll → Document Node (provisioning record)

6. Compliance Reporting:

   • Schedule Node → Prisma Access (list security rules) → Prisma Access (list URL categories) → Script Node (format report) → SharePoint Node (upload)

---

Best Practices

1. Stage changes before pushing: create/update/delete operations modify the candidate configuration only. Batch related changes and push once at the end of a workflow.
2. Always poll push jobs: configVersion.push is asynchronous. Capture the returned job ID and poll job.get until completion before treating the change as deployed.
3. Use folders for blast radius control: prefer creating objects in the most specific folder (e.g. a custom snippet) rather than Shared to limit the impact of mistakes.
4. Tag everything: tags make later cleanup, audit, and selective rollback dramatically easier. Use consistent prefixes (auto-, incident-, tier-1-).
5. Use dedicated service accounts: create a service account per major automation surface, with the minimum role assignments. Easier to revoke and audit.
6. Rotate Client Secrets: align rotation with your organisation's password policy. The integration's token cache means rotation is safe at any time — workflows pick up the new secret on next token refresh.
7. Reserve position: pre for high-priority workflow rules: place automated SOC rules in pre so they evaluate before service-managed rules.
8. Reference existing objects, don't inline values: create address/service objects once and reference them by name in rules. This keeps rules concise and lets you update the IP set without touching every rule.
9. Use descriptive names: rule and object names appear in audit logs and reports. Encode the source/incident in the name (e.g. Block_C2_APT29_2026_05_04).
10. Handle 4xx errors gracefully: SCM returns detailed error messages in the response body. Capture and log them — they typically explain exactly which validation failed.
11. Test in a non-production folder first: Prisma Access supports custom folders/snippets. Use them as staging grounds before promoting to Shared.
12. Monitor token refresh: tokens are 15 minutes long. Workflows running for hours rely on the integration's automatic refresh. If you see "token fetch failed" errors, verify the Client Secret hasn't been rotated upstream.

---

Troubleshooting

Issue	Resolution
token fetch failed: status=401	Client ID or Client Secret is incorrect, or the secret has been rotated. Regenerate the credential in SCM and update the NINA credential.
token fetch failed: status=403	The service account lacks an active role assignment on the TSG. Check Settings → Identity & Access in SCM.
API error [403] on /sse/config/v1/...	The service account is authenticated but lacks the role required for this resource. Most resources require Prisma Access Admin.
Folder dropdown only shows the 6 system folders	The service account lacks SCM Admin role. The dropdown falls back gracefully — either assign the role for live tenant folders or select system folders / use manual entry.
API error [400] on create/update	The body has invalid or missing fields. Check the response body — SCM returns precise validation errors. Common causes: missing required field, value violates regex pattern, FQDN longer than 255 chars, name longer than 63 chars.
Changes don't appear on Prisma Access	Changes only modify the candidate configuration. Run configVersion.push and wait for the job to complete.
Push job stuck in Pending for a long time	Large pushes can take several minutes. Continue polling. If a push exceeds 30 minutes, check Configuration → Push Status in SCM.
Push fails with validation errors	The candidate configuration has issues. Check the SCM UI for "Configuration Issues" — typical causes: orphaned references, invalid object combinations, license capacity exceeded. Use configVersion.rollbackCandidate to discard.
unsupported resource: <name>	The resource key in your node configuration doesn't match any registered resource. Check the resource list in this guide; resource keys are camelCase singulars (address, not addresses).
unsupported operation: <res>.<op>	The operation isn't defined for this resource. Most resources expose list/create/get/update/delete; some have additional action verbs (push, load, move, getRunning, rollbackCandidate).
Folder enum says Mobile Users but I configured a custom name	Custom folder names are case-sensitive and must match exactly. Use the live dropdown to confirm spelling.

Common Error Messages

Error Message	Meaning	Solution
clientId is required	Validation failed before any HTTP call	Provide all three required credential fields (clientId, clientSecret, tsgId)
token fetch failed: status=401 body=invalid_client	Client ID/Secret pair is rejected by the IdP	Verify the credentials in SCM, regenerate the secret if unsure
failed to obtain access token	Token endpoint not reachable	Check network connectivity to auth.apps.paloaltonetworks.com. Verify any corporate proxy settings.
received empty response from API	A non-DELETE call returned 200 with no body	Usually a Prisma Access service issue — retry. If persistent, contact Palo Alto support.
API error [404] on get/update/delete	The object ID doesn't exist or is in a different folder	Use list to confirm the object's ID and folder before targeting it.
API error [409] on create	Object with this name already exists in the folder	Use update or delete-then-create instead.
unsupported resource locator method	An invalid method was passed to GetResources	Only getFolders is currently supported for this integration.

---

Advanced Configuration

Regional Tenants

If your Prisma Access tenant runs in a regional cloud (e.g. EU, UK), override Base URL and optionally Auth Base URL on the credential. Common regional hosts:

• US (default): https://api.sase.paloaltonetworks.com
• New SCM hostname (US): https://api.strata.paloaltonetworks.com
• Other regions: consult your tenant administrator

The integration is fully URL-agnostic — only the base URLs change.

Pagination on List Operations

Most list operations accept limit (default 200, max varies per resource) and offset. For large tenants, page through results in workflow loops:

{
  "resource": "address",
  "operation": "list",
  "parameters": {
    "folder": "Shared",
    "limit": 200,
    "offset": 0
  }
}

Continue with offset: 200, offset: 400, etc., until the response contains fewer items than limit.

Filtering List Operations

Many list operations support a name query parameter for substring filtering:

{
  "resource": "address",
  "operation": "list",
  "parameters": {
    "folder": "Shared",
    "name": "Malicious"
  }
}

Action Endpoint Path Suffixes

Action endpoints use Google-style colon suffixes:

• :push — push the candidate configuration
• :load — load a saved configuration version as the new candidate
• :move — re-order a rule within the rulebase

These are passed through the dispatcher unchanged; the colon is a literal part of the URL path, not a placeholder.

Working with HIP-Based Policies

Host Information Profile (HIP) policies tie security rules to endpoint posture. Typical chain:

1. Create or update hipObject (matches endpoint conditions like OS, patch level, AV signature)
2. Create or update hipProfile (combines multiple HIP objects with logical match expressions)
3. Reference the HIP profile in a securityRule via hip_profiles

Bulk Operations

For bulk creates (e.g. importing a long IOC list), use a workflow loop. Each iteration does one create. Keep individual operations small — Prisma Access enforces per-call rate limits, and a workflow loop is easier to retry on partial failure than a single bulk request.

---

Authentication & Token Lifecycle

The integration handles the OAuth2 client-credentials lifecycle transparently:

1. On the first API call, the integration calls POST {authBaseUrl}/oauth2/access_token with HTTP Basic auth (clientId:clientSecret) and form body grant_type=client_credentials&scope=tsg_id:<TSG>.
2. The IdP returns an access_token (JWT, 15-minute lifetime) and expires_in.
3. The token is cached on the integration instance, protected by a mutex for concurrent worker safety.
4. Subsequent API calls reuse the cached token until 5 minutes before expiry, at which point it's automatically refreshed.
5. The token is sent as Authorization: Bearer <token> on every Prisma Access API request.

You don't need to do anything to manage tokens. If a workflow runs for hours, the integration will silently refresh tokens as needed.

---

Additional Resources

• Strata Cloud Manager Configuration API docs: https://pan.dev/access/api/prisma-access-config/
• Prisma Access overview: https://docs.paloaltonetworks.com/prisma-access
• OAuth2 Access Tokens: https://pan.dev/sase/docs/access-tokens/
• Strata Cloud Manager UI: https://stratacloudmanager.paloaltonetworks.com/
• OpenAPI specs (source of this integration's schema): https://github.com/PaloAltoNetworks/pan.dev/tree/master/openapi-specs/access/prisma-access-config

---

Support

If you encounter issues with the Palo Alto Prisma Access integration, please contact our support team with:

• The operation you were attempting (resource and operation key)
• The folder you were targeting
• Any error messages received from the API (full response body)
• The TSG ID (do not share Client ID or Client Secret)
• Whether the issue reproduces on every call or intermittently
• The workflow context where the issue occurred

This information will help us provide faster and more accurate assistance.

Updated: 2026-05-05