Release identity
SHA-256 of the pack file bytes: 610abf7adecdf3216150a7d3ac067c49ef8be4d90f2e9f8b726ad20ae9dc4db4
Not in the distributable release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.
Capabilities (8)
prisma.alerts.read v1.0.0R0
- Action
- read
- Endpoint
GET https://prisma-cloud-api.invalid/alert- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
List alerts matching query-parameter constraints (status, policy, time range): the tenant's open and historical security alerts. Registered as the collection read; the vendor caps this variant's response at 10k results — the paginated V2 list, single-alert detail (GET /alert/{id}) and alert counts are not registered. The host is a reserved placeholder: substitute the tenant's stack-specific API host before enabling.
prisma.policies.read v1.0.0R0
- Action
- read
- Endpoint
GET https://prisma-cloud-api.invalid/policy- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
List the tenant's policies from the collection endpoint: the misconfiguration, network, identity and anomaly policies (including custom policies) whose violations generate alerts. Registered as the collection read; policy create, update and delete are deliberately not registered. The host is a reserved placeholder: substitute before enabling.
prisma.compliance_posture.read v1.0.0R0
- Action
- read
- Endpoint
GET https://prisma-cloud-api.invalid/compliance/posture- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
Read the tenant's compliance posture: pass/fail posture against compliance standards across the connected cloud accounts. Registered as the posture read; compliance standard management is deliberately not registered. The host is a reserved placeholder: substitute before enabling.
prisma.cloud_accounts.read v1.0.0R0
- Action
- read
- Endpoint
GET https://prisma-cloud-api.invalid/cloud- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
List the cloud accounts onboarded to the tenant from the collection endpoint: account ids, names and onboarding status across AWS, Azure, GCP, OCI and Alibaba. Registered as the collection read; onboarding, update and offboarding of cloud accounts are deliberately not registered. The host is a reserved placeholder: substitute before enabling.
prisma.alert_rule.create v1.0.0R3
- Actions
- create, send, deploy
- Endpoint
POST https://prisma-cloud-api.invalid/alert/rule- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
Create one alert rule: which policies on which account groups generate alerts, and which notification integrations receive them. The retrieved operation reference (POST /alert/rule, retrieved 2026-09-21) shows the request body carries the required allowAutoRemediate parameter (default false) and an AlertRuleNotificationConfig object routing triggered alerts to third-party integrations or email — so an unrestricted rule create can cause external notification delivery (send: alert data leaves the tenant and cannot be un-sent) and can enable automatic remediation of matching alerts against the customer's cloud resources (deploy: live configuration change without any further call). The capability declares create, send and deploy at the R3 floor because the registration does not restrict the request body; send and deploy are IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) that cannot be taken without a person. Alert rule deletion is deliberately not registered. The host is a reserved placeholder: substitute before enabling.
prisma.alerts.dismiss v1.0.0R2
- Action
- update
- Endpoint
POST https://prisma-cloud-api.invalid/alert/dismiss- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
Dismiss one or more alerts (alert ids in the request body); if the caller specifies a dismissal time range the alerts snooze for that period rather than being dismissed outright. Dismissing or snoozing an alert suppresses a security finding from the active queue; the change is reversible (dismissed alerts can be reopened), so the capability sits at the R2 update floor with the suppression risk stated here and bounded by policy. The tenant can require a dismissal note; whether a note is required is tenant configuration, and this registration does not guarantee one was given. The host is a reserved placeholder: substitute before enabling.
prisma.alerts.reopen v1.0.0R2
- Action
- update
- Endpoint
POST https://prisma-cloud-api.invalid/alert/reopen- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
Set one or more dismissed or snoozed alerts back to open (alert ids in the request body); registered as a reversible update at R2 — it restores visibility rather than removing it. The host is a reserved placeholder: substitute before enabling.
prisma.alerts.remediate v1.0.0R3
- Action
- deploy
- Endpoint
POST https://prisma-cloud-api.invalid/alert/remediation- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-prisma-jwt- Data class
- internal
Remediate the alert with the specified id if it is associated with a remediable policy. Remediation is not a label change: the platform executes the policy's remediation (via the cloud provider CLI commands surfaced by the remediation-commands endpoint) against the customer's cloud resources, so a single call can change live cloud configuration. Registered with the deploy verb at the R3 floor: executing remediation against live cloud configuration is deploy-equivalent under the library convention (compare crowdstrike host containment and dbt run triggers). The host is a reserved placeholder: substitute before enabling.
Credential reference
The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.
- Reference
secret-ref-prisma-jwt- Custody
- customer_vault
- Injection
- header (x-redlock-auth)
A Prisma Cloud JWT access token, held in the client's own secret manager. The stored material must be the complete x-redlock-auth header value, which per the vendor's Headers documentation is the JWT itself (no scheme prefix) as returned in the response object of a successful login request. Issuance is a two-step external flow: an admin creates an access key in the Prisma Cloud console (an access key id plus a secret key — two secret values, themselves stored under their own vault references), and an external deployment process exchanges them at POST /login for the JWT, storing and renewing it under this reference; the injector injects the stored value verbatim and performs no token lifecycle itself, so refresh ownership sits entirely with that external process. JWTs are short-lived and expire; an expired value fails closed. Stated honestly for revocation: the retrieved login and access-keys documentation do not state whether disabling or deleting an access key invalidates already-issued JWTs — the JWT's format alone does not establish that its authorization remains usable until expiry. Deleting the key stops NEW JWT issuance; until the console's invalidation behavior is verified, the deployment must treat any captured JWT as live until expiry and rotate the key on suspicion. Per the vendor's login documentation, access keys maintain the same level of permissions as the permission group of the account that created them — least privilege therefore means creating the key from a dedicated service account assigned to a minimum permission group (read-only for the read capabilities; a group with alert-dismiss and remediation rights only where those capabilities are enabled), and never from a System Admin's personal account. The vendor allows a limited number of access keys per user and supports key expiry dates: use a short key expiry and rotate regularly; an expired access key cannot be reactivated. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.
Resources
prisma-cloud-tenant(api, internal):https://prisma-cloud-api.invalid
Pack notes and exclusions
The endpoint host 'prisma-cloud-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the tenant's Prisma Cloud API host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. The API host VARIES by the console stack the tenant is provisioned on (the vendor documents api.prismacloud.io, api2/api3/api4, api.eu, api.gov, api.anz, api.ca, api.sg, api.uk, api.jp and others, each matching a distinct admin console URL); the tenant's order fulfillment email and console URL determine the correct API host, so do not guess it. The pack does not create access keys or mint JWTs: an external deployment process creates an access key in the Prisma Cloud console, exchanges the access key id and secret key for a JWT at POST /login, and stores and renews the value described in the credential note. Alert dismissal sits at the R2 update floor: dismissing or snoozing an alert suppresses a posture or runtime finding, but the change is reversible (dismissed alerts can be reopened), so it is registered as update at R2 with the suppression risk stated in its description and bounded by policy. Alert remediation sits at R3: for alerts on remediable policies the platform executes a remediation that changes the customer's cloud resources, which is a privileged response action on a third-party estate. Alert rule creation declares create, send and deploy at R3: the retrieved operation reference shows the rule schema admits external notification routing (AlertRuleNotificationConfig to third-party tools or email) and automatic remediation (the required allowAutoRemediate parameter), so an unrestricted rule create is notification-capable and remediation-capable, not a reversible metadata edit. List-alerts responses cap at 10k results per the vendor documentation; use the V2 paginated variant if the deployment needs more coverage. Documented exclusions — this pack does not register: cloud account onboarding, update and offboarding (/cloud writes — offboarding a cloud account removes its monitoring and is not part of this pack), policy create/update/delete, compliance standard and requirement management, alert rule deletion, user, role and permission-group management, access key management APIs, SSO configuration, IP allow list changes, integration create/update (which sends alert data to third parties), and the alert evidence/report download jobs. The access-keys API itself (List/Add/Delete/Update Access Key) is deliberately not registered: credential management must stay a human console operation. Vendor deprecation flag: the retrieved compliance-posture operation page (2026-09-21) marks GET /compliance/posture deprecated ('may be replaced or removed in future versions') and limits its data to the past 1 year — the capability is registered against the current contract and must be re-reviewed when the vendor replaces it.
Review record
Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://pan.dev/prisma-cloud/api/cspm/api-urls/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/api-headers/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/app-login/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/alerts/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/access-keys/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/add-alert-rule/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/get-policies/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/get-compliance-posture/ (retrieved 2026-09-21)
- https://pan.dev/prisma-cloud/api/cspm/get-cloud-accounts/ (retrieved 2026-09-21)
A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.