Release identity
SHA-256 of the pack file bytes: be8def09256475d1eb54d93a5e42a2c7f60fb0abf1882bf46db685a3dbb12ae8
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 (5)
cyberark.accounts.read v1.0.0R0
- Action
- read
- Endpoint
GET https://cyberark-privilege-cloud.invalid/PasswordVault/API/Accounts- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-cyberark-session-token- Data class
- pii
List the accounts visible to the service user, with the documented search, filter, sort, offset and limit query parameters; this pack registers the collection read only — single-account reads are the separate cyberark.account.details.read capability. Account records carry the account user name, address and platform properties of privileged logins, so the read is registered at the pii class. The response is metadata only: the account's secret value is never returned by this endpoint. The host is a reserved placeholder: substitute the customer's Privilege Cloud tenant host before enabling.
cyberark.account.details.read v1.0.0R0
- Action
- read
- Endpoint
GET https://cyberark-privilege-cloud.invalid/PasswordVault/API/Accounts/ACCOUNT_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-cyberark-session-token- Data class
- pii
Read one account's details by its account ID: name, user name, address, platform, safe, secret-management status and remote-machine restrictions — metadata identifying a privileged login, registered at the pii class. The secret value is not returned by this endpoint; secret retrieval is deliberately not registered by this pack (see the pack notes). ACCOUNT_ID is a placeholder the deployment binds to a concrete account before enabling.
cyberark.safe_members.read v1.0.0R0
- Action
- read
- Endpoint
GET https://cyberark-privilege-cloud.invalid/PasswordVault/API/Safes/SAFE_URL_ID/Members- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-cyberark-session-token- Data class
- pii
List the members of one Safe with their full permission sets, using the Gen 2 endpoint; the caller requires View Safe Members permission in the Safe. The response names the users and groups who can reach stored credentials and exactly what each may do — an access-map of the vault's most sensitive boundary — so the read is registered at the pii class. SAFE_URL_ID is a placeholder the deployment binds to a concrete Safe (URL-encoded Safe name) before enabling. The Gen 1 variant under PIMServices.svc is not registered.
cyberark.account.create v1.0.0R3
- Actions
- create, deploy
- Endpoint
POST https://cyberark-privilege-cloud.invalid/PasswordVault/API/Accounts- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-cyberark-session-token- Data class
- pii
Onboard one account into a Safe; the caller requires the Add account and Update password or Update password properties permissions. The request body carries the account's name, address, user name, platform, Safe and the secret value itself, and the platform account properties are validated against the platform definition. The body is unrestricted: this registration does not restrict which Safe or platform a request may name, and per the retrieved Add Account documentation automaticManagementEnabled defaults to true, so unrestricted onboarding can bring a live credential under automatic CPM management — the CPM will then change, verify and reconcile that production credential on the target system on its own schedule without any further AAES call, a deploy-equivalent effect on live infrastructure. The capability is therefore registered as create and deploy at the R3 floor: deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer), and an irreversible action cannot be taken without a person. SECRET-BODY HYGIENE IS REQUIRED: the body carries the onboarded password or private key in plaintext, so the request body itself must meet the same bar as the injected token — exist only in executor memory for the lifetime of the call, never be written to logs, traces, diagnostics or crash dumps; a deployment that cannot meet that bar must not enable this capability. The service user's own Safe permissions are the real boundary. Registered at the pii class because the body contains credential material and account-holder identifiers.
cyberark.account.delete v1.0.0R3
- Action
- delete
- Endpoint
DELETE https://cyberark-privilege-cloud.invalid/PasswordVault/API/Accounts/ACCOUNT_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-cyberark-session-token- Data class
- pii
Delete one account from the Vault by its account ID; the caller requires Delete Accounts permission, and the endpoint applies to both password and SSH key accounts. Deleting an account removes the vaulted credential record — re-onboarding later is a new account, not an undo, and anything depending on the stored secret or its CPM management loses it. Registered as delete at the R3 floor: delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer), and an irreversible action cannot be taken without a person. ACCOUNT_ID is a placeholder the deployment binds to a concrete account 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-cyberark-session-token- Custody
- customer_vault
- Injection
- header (Authorization)
A CyberArk Privilege Cloud session token for a dedicated least-privilege service user, held in the client's own secret manager. Authentication is the documented two-step flow: an external process calls POST /PasswordVault/API/auth/Cyberark/Logon (or the LDAP or RADIUS variant) with the service user's username and password and receives a short-lived session token; every other REST call then carries that token verbatim in the Authorization header. The stored material must be the session token exactly as returned by Logon — Privilege Cloud's Authorization header takes the token value with no Bearer scheme. The HTTP injector injects the stored value verbatim and performs no logon itself: an external custody job must run the logon, store the resulting token, and re-run it before the token expires. Session tokens are short-lived and are invalidated by the documented Logoff call and by session timeout; the retrieved documentation does not establish that changing or disabling the service user's password invalidates already-issued session tokens, so treat every issued token as live until expiry or explicit logoff and rotate promptly on any suspicion of exposure. Least privilege: create the service user with membership only in the Safes these capabilities touch and only the permissions the registered endpoints document (List Accounts for the account reads, View Safe Members for the Safe member listing, Add account and Update password or Update password properties for onboarding, Delete Accounts for deletion — grant Delete Accounts only if the delete capability is enabled), and never a user with Manage Safe or administrative rights. Deployment-model honesty: the reviewed logon flow is the one documented for the Privilege Cloud Standard deployment model named in the review sources; other Privilege Cloud variants may authenticate differently, so do not generalize this flow — re-verify the variant's own authentication documentation before enabling. Executor hygiene: the token 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
cyberark-privilege-cloud(api, pii):https://cyberark-privilege-cloud.invalid/PasswordVault/API
Pack notes and exclusions
The endpoint host 'cyberark-privilege-cloud.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Privilege Cloud tenant host (<subdomain>.privilegecloud.cyberark.com) before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable. This pack registers only Gen 2 endpoints under /PasswordVault/API/ that the retrieved Privilege Cloud documentation establishes: listing accounts, reading one account's details, listing a Safe's members, adding an account, and deleting an account. The Gen 1 endpoints under /PasswordVault/WebServices/PIMServices.svc/ exist in the same documentation and are deliberately not registered — CyberArk recommends the Gen 2 API. The Privilege Cloud API enforces the logging-in user's own Safe permissions, so a capability works only if the service user holds the documented permission (List Accounts for the account reads, View Safe Members for the Safe member listing, Add account plus Update password or Update password properties for onboarding, Delete Accounts for deletion); the registration records the endpoint, not the tenant's authorization decision. ACCOUNT_ID and SAFE_URL_ID in the endpoint paths are placeholders the deployment binds before enabling. Documented exclusions — this pack does not register: account secret retrieval (POST /PasswordVault/API/Accounts/{id}/Secret/Retrieve returns the actual stored password or key material; exposing credential bytes to an agent is a different risk decision and requires its own review); CPM secret-management actions (Change, Verify and Reconcile credentials immediately — each rotates or tests a live production credential on the target system, not just a vault record); account property update (PATCH /PasswordVault/API/Accounts/{id}); Safe creation, update and deletion, and Safe member add/update/remove (each changes who can reach stored credentials — an access-granting surface requiring its own review); discovered-account onboarding, sessions (PSM) and recording access, platform management, and user/group administration. Documented limitation: a Safe list read (GET /PasswordVault/API/Safes) is referenced in the retrieved documentation but its dedicated reference page was not reachable at review time, so this pack registers Safe member listing only and no Safe collection read.
Review record
Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/sdk/cyberark%20authentication%20-%20logon_v10.htm (retrieved 2026-09-21)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/implementing%20privileged%20account%20security%20web%20services%20.htm (retrieved 2026-09-21)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/sdk/getaccounts.htm (retrieved 2026-09-21)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/get%20account%20details.htm (retrieved 2026-09-21)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/add%20account%20v10.htm (retrieved 2026-09-21)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/delete%20account.htm (retrieved 2026-09-21)
- https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/sdk/safe%20members%20ws%20-%20list%20safe%20members.htm (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.