This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern
Before you enable this package
The endpoint host 'cyberark-privilege-cloud.invalid' is a reserved .invalid placeholder that fails closed until you substitute the real host in both the endpoint URLs and the egress allowlist.
Read each action's effects and exclusions below. Before installation, also read the complete package requirements, including credential issuance, scope, expiry, and provider permissions. These are deployment prerequisites, not capabilities this package supplies.
Capabilities (5)
Each capability below is one registered operation. The complete package JSON includes its exact network destination allowlist. The repository stores it at packs/cyberark.json and embeds a copy in the release binary.
Risk tiers. R0 is the minimum for reads. R2 is the minimum for write, create, update, execute, and invoke. R3 is the minimum for delete, send, pay, deploy, approve, share, and transfer. Operators can raise these levels. A minimum tier does not measure the operation's business or confidentiality risk.
On supported execution paths routed through AAES Govern, the R3 actions listed below require approval by an authorized person. Bypass paths and observation-only registrations are outside that guarantee. A provider's restoration feature does not remove this approval requirement. A provider-side approval, such as approving a GitLab merge request, is also separate from AAES Govern human approval. The capability matrix shows which execution paths are implemented, restricted to lab use, or refused at startup. Live compatibility must be tested in your environment.
Field guide. Endpoint is the service address and request method. Connector is the adapter that makes the call. Custody describes how the credential is held; the credential reference identifies the value to resolve. Data class sets handling requirements: pii means personal data, financial means financial records, and internal means internal organizational data.
cyberark.accounts.read v1.0.0R0
- Kind
- tool
- 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
Read accounts.
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 classified as pii (personal data). 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
- Kind
- tool
- 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 account details.
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, classified as pii (personal data). 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
- Kind
- tool
- 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
Read safe members.
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 classified as pii (personal data). 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
- Kind
- tool
- 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
Create account.
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 according to the reviewed 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 minimum R3 tier: deploy is one of the designated actions requiring human approval.
On supported execution paths mediated by AAES Govern, irreversible actions require approval by an authorized person; this does not prevent calls through bypass or observation-only paths. Request-body secret handling 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
- Kind
- tool
- 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 account.
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 minimum R3 tier: delete is one of the designated actions requiring human approval.
On supported execution paths mediated by AAES Govern, irreversible actions require approval by an authorized person; this does not prevent calls through bypass or observation-only paths.
ACCOUNT_ID is a placeholder the deployment binds to a concrete account before enabling.
Credential reference
The credential field names a reference rather than containing credential material. Packs are designed not to contain secrets; the format checks cover only known credential formats and cannot prove that arbitrary text contains no secrets. Installing a package registers its capabilities. Configure the provider credentials, endpoints, and network access, then test the integration in your environment before enabling it.
- Reference
secret-ref-cyberark-session-token- Custody
- customer_vault
- Injection
- header (Authorization)
Configure the value and injection format specified in the package. Assign responsibility for credential rotation and revocation, restrict provider permissions, and keep credential material out of logs and responses.
Complete credential requirements
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 reviewed 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: 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
Technical package and review record
Complete provider requirements 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.
Excluded operations: 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 reviewed 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.
Download the complete package JSON for exact network allowlists, credential requirements, exclusions, and setup notes. Read these requirements before installation.
The full documentation review record is supplied in the evaluation package. The evaluation package runs in your environment and comes only with the paid design partnership. This page reproduces the source links and review block; the full record is available for evaluation. Discuss a design partnership to inspect it before installation.
Review block
This section reproduces the review block recorded in the pack file. The evidence and approval record is separate: for a reviewed pack, it is in the evaluation materials and in the release binary's embedded assets.
Review completed: 2026-09-22
8 sources, retrieved 2026-09-21
- Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/sdk/cyberark%20authentication%20-%20logon_v10.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/implementing%20privileged%20account%20security%20web%20services%20.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/sdk/getaccounts.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/get%20account%20details.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/add%20account%20v10.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/delete%20account.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/sdk/safe%20members%20ws%20-%20list%20safe%20members.htm(retrieved 2026-09-21) - Current API documentation portal; navigation only, not the historical reference (link checked 2026-10-19)
Historical review URL, now unavailable:https://docs.cyberark.com/privilege-cloud-standard/latest/en/content/webservices/api-logoff-lp.htm(retrieved 2026-09-21)
Current documentation links are navigation aids. They do not change the package, its historical sources or its review date. Review dates describe a documentation review, not a live integration test. No package is provider-endorsed or yet tested against a live provider tenant.
Release identity
SHA-256 of the pack file bytes: 445e165bda563c47069d4af939b48593309ae19c9646f06640a25b73c2d248f8
Distributable: yes, digest matches the release manifest. Editing a package changes its release identity. A deployment plan checks its own file digests; it does not restore reviewed status or authenticate approval.