canonical: https://jentic.com/apis/cyberark.com

# CyberArk APIs

CyberArk's Conjur secrets management platform, exposed to AI agents through two Jentic-published OpenAPI specifications. Conjur stores, retrieves, and rotates secrets for applications, containers, and CI/CD pipelines, with access governed by version-controlled policies and role-based permissions. Agents can authenticate workloads, fetch secrets at runtime, load policy-as-code, and enumerate roles without embedding long-lived credentials in source code or prompts. The portfolio offers a curated four-endpoint surface for basic store, retrieve, policy, and role operations, plus a fuller spec covering authentication, host factory, and certificate authority flows.

## For AI agents

An agent can authenticate workloads to CyberArk Conjur, retrieve and store secrets at runtime, load policy-as-code definitions, and list roles across the policy graph, using either a compact four-endpoint surface or the fuller Conjur spec with host factory and certificate authority coverage.

## Scope

Use for: Workload and machine-identity secrets management with Conjur: authenticating applications, retrieving and storing secrets at runtime, loading policy-as-code, and managing roles.

Not supported:
- human password vaulting
- MFA enrollment
- endpoint protection
- real-time secret streaming

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| CyberArk Conjur API | security | 4 | Store and retrieve secrets, create access policies, and list roles in CyberArk Conjur via four core REST endpoints. |
| Conjur | security | 0 | Programmatically authenticate to Conjur, retrieve and store secrets, manage policies and roles, and authorise workloads via API key or Kubernetes mutual TLS. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Store, retrieve, create a policy, and list roles with the minimum surface | cyberark | The curated four-endpoint spec covers POST /secrets, GET /secrets/{id}, POST /policies, and GET /roles and nothing else, which keeps integrations simple. |
| Authentication flows, host factory enrolment, or certificate authority operations | conjur-api | The fuller Conjur spec adds login and API-key authentication, Kubernetes mutual TLS, host factory tokens, public keys, resources, status, and certificate authority surfaces. |

## Cross-API use cases

### Retrieve a secret with the compact spec, escalate to the full spec when needed

An agent handles routine secret reads through the four-endpoint spec, calling GET /secrets/{id}, and switches to the fuller Conjur spec when a workflow needs a Kubernetes mutual-TLS authentication step or a host factory token that the compact surface does not expose.

Example prompt: Fetch the secret at id 'prod/db/password' via the compact spec, and if the workload runs in Kubernetes, authenticate it via the fuller spec's mutual-TLS authenticator first.

### Bootstrap access control then confirm it end to end

An agent loads a new access policy through one spec and verifies the resulting roles through the other, standing up role-based access for a new service and confirming the expected roles exist before downstream automation continues.

Example prompt: Load a policy granting 'host/service-x' read access to 'service-x/db/*', then list roles and confirm the new role appears.

### Rotate credentials and manage the policy that governs them

A rotation job writes new secret values through the compact store operation while the fuller spec manages the policies and roles that decide which workloads may read those secrets, keeping rotation and access control in one flow.

Example prompt: Store a rotated database password at id 'prod/db/password', then load an updated policy scoping read access to the intended host role.

## Why Jentic

- **Setup:** Wiring the Conjur specs by hand means handling API-key, basic-auth, or Kubernetes mutual-TLS authentication, targeting the right Conjur appliance, and mapping the secret, policy, and role routes yourself. Through Jentic you install Jentic One once, add either Conjur API from the Jentic directory, store the credentials once, and your agent calls both.
- **Permission scoping:** Your own rules decide which Conjur operations the agent may call across both specs. Because the compact spec puts the secret id in the URL path, a rule can pin an agent to reading one specific secret, and writing secrets or applying policies stays out unless you add them.
- **Credential handling:** Your Conjur API keys and basic-auth credentials are stored once, encrypted, by your own Jentic One instance, which performs the Conjur authentication step at execution time. The long-lived secret never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search the Jentic directory by intent such as 'retrieve a secret from Conjur', and Jentic returns the matching Conjur operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related vendors

- **1Password** — Pairs with Conjur when people use 1Password for human credentials and workloads use Conjur, giving a unified audit pipeline.
- **HashiCorp** — HashiCorp Vault is a direct alternative secrets manager for workloads, policies, and dynamic credentials.
- **Azure Key Vault** — A managed secrets and key store often chosen for cloud-native workloads instead of a self-hosted Conjur deployment.

## FAQ

### What can an AI agent do across the CyberArk Conjur APIs?

An agent can authenticate a workload, retrieve and store secrets at runtime, load and update policy-as-code definitions, and enumerate roles in the policy graph. The compact spec covers the four core secret, policy, and role operations, while the fuller spec adds authentication flows, host factory enrolment, and certificate authority surfaces.

### Why does Jentic publish two Conjur specifications?

The two specs serve different needs against the same platform. The four-endpoint spec is a leaner surface for integrations that only need to store a secret, fetch it back, create a policy, and list roles. The fuller spec covers login and API-key authentication, Kubernetes mutual TLS, host factory tokens, public keys, resources, status, and certificate authority operations.

### Which Conjur spec should an agent choose?

Use the compact spec when storing and retrieving secrets plus basic policy and role work is enough, because its small surface keeps calls simple. Use the fuller spec when a workflow needs Kubernetes workload authentication, host factory self-enrolment, or certificate authority operations that the compact spec does not expose.

### Is CyberArk Conjur for human passwords or machine secrets?

Conjur is built for workloads and machine identities rather than human password vaulting. Its policy graph governs which applications, containers, and CI/CD pipelines can read which secrets, which is why it pairs well with a separate human-credential manager for people.

### Do these APIs handle secret rotation?

Yes. A rotation job can write new secret values through the store operation, and applications pick up the new value on their next refresh without a redeploy. The policy and role surfaces let an agent manage which workloads are allowed to read the rotated secret.

### Are these official CyberArk specifications?

CyberArk does not maintain a clean, validated, agent-ready OpenAPI specification for the Conjur REST surface on its docs site. Jentic generates and maintains both of these specs, validates them against the live API, and keeps them up to date so agents and developers can call Conjur through structured tooling.