Prisma package v1.0.0

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.

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 minimum R2 tier for update: 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.