canonical: https://jentic.com/apis/cyberark.com/cyberark # CyberArk Conjur API Jentic publishes the only available OpenAPI specification for CyberArk Conjur API, keeping it validated and agent-ready. This bundle is a curated CyberArk Conjur secrets-management surface for privileged access security with four core REST endpoints covering secret storage and retrieval, policy creation, and role enumeration. It is a leaner alternative to the full Conjur API spec and is well-suited to integrations that only need the basics: store a secret, fetch it back, create a policy, and list roles. ## For AI agents Store and retrieve secrets, create access policies, and list roles in CyberArk Conjur via four core REST endpoints. ## Scope Does not handle human password vaulting, MFA enrolment, or endpoint protection - use for workload secret storage, retrieval, and basic Conjur policy/role operations only. ## Capabilities - Store a secret value in Conjur via POST /secrets - Retrieve a stored secret by id via GET `/secrets/{id}` - Create an access policy in Conjur via POST /policies - List the roles that exist in the Conjur policy graph via GET /roles - Drive a secret-rotation pipeline that writes new values to Conjur after rotation - Bootstrap a minimal Conjur access model with a single policy load on first deployment ## Use cases ### Centralised secret storage for applications Replace hard-coded credentials with Conjur lookups. Application bootstrap calls GET `/secrets/{id}` with an authenticated token to fetch the secret it needs at runtime, so secrets never live in source code or config files. POST /secrets handles the initial seeding and any in-place rotations. Example prompt: Store the value 'rotated-pw' under id 'prod/db/password' via POST /secrets, then retrieve it back via GET `/secrets/{id}` and confirm a 200 response. ### Bootstrap RBAC for a new service Stand up access control for a new service in one step. POST /policies loads a YAML policy describing the service's hosts, the variables it needs, and the role-permission grants. Subsequent GET /roles calls confirm the expected roles exist before downstream automation continues. Example prompt: Load a policy creating role 'host/service-x' with read access to 'service-x/db/*' and confirm the role appears in GET /roles. ### Rotation and audit pipeline After a downstream system rotates a credential (database, third-party API key), the rotation job stores the new value in Conjur via POST /secrets. Applications that later call GET `/secrets/{id}` pick up the new value on their next refresh cycle, with no redeploy required. Example prompt: After rotating the prod database password, store the new value in Conjur at id 'prod/db/password' and verify GET `/secrets/{id}` returns the new value. ### AI agent secret fetcher via Jentic Give an autonomous agent a tool to read a specific named secret without holding any long-lived credentials in its prompt. The agent searches Jentic for 'retrieve a secret from Conjur', loads the GET `/secrets/{id}` schema, and executes - Jentic handles the Conjur API key. Example prompt: Through Jentic, retrieve the value at id 'prod/db/password' and pass only a redacted reference back to the user. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/secrets` | Store a secret value | | GET | `/secrets/{id}` | Retrieve a stored secret by id | | POST | `/policies` | Create an access policy | | GET | `/roles` | List roles defined in Conjur | ## Key resources - **Secrets** — Store and retrieve secret values by id - **Policies** — Create access policies that define resources and grants - **Roles** — Enumerate the roles defined in the Conjur policy graph ## Why Jentic - **Setup:** Wiring the CyberArk Conjur API by hand means provisioning an API key, passing it in the Authorization header, and mapping its secret, policy, and role routes yourself. Through Jentic you install once, import the CyberArk Conjur API from the API Directory, store the key once, and your agent calls it. - **Permission scoping:** CyberArk Conjur puts the secret id in the URL path (`/secrets/{id}`), so a rule can pin your agent to reading a specific secret and nothing else. You choose the operations it may call, so writing secrets or applying policies is not included unless you add them. - **Credential handling:** Your CyberArk Conjur API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'retrieve a secret from Conjur', and Jentic returns the matching CyberArk Conjur operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Conjur (full spec)** — Larger Conjur surface covering authentication, host factory, certificate authority, and more - **1Password Events API** — Audit-event stream for the 1Password secrets manager - **CyberGordon** — Cyber-reputation lookup across multiple intelligence engines ## FAQ ### Why is there no official OpenAPI spec for CyberArk Conjur? CyberArk does not publish a clean OpenAPI specification for the Conjur REST surface on its docs site. Jentic generates and maintains this curated 4-endpoint spec so that AI agents and developers can call Conjur via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the CyberArk Conjur API use? An API-key style Authorization header (the ApiKeyAuth scheme). Through Jentic, the key is stored in the encrypted vault and injected at execution time so it never appears in agent prompts or logs. ### Can I store and retrieve a secret with this API? Yes. POST /secrets stores a value and GET `/secrets/{id}` reads it back. This pair is the minimum surface for replacing hard-coded credentials with a Conjur lookup. ### Can I create access policies through the API? Yes. POST /policies accepts a Conjur policy definition and creates the corresponding resources, roles, and grants. GET /roles confirms the resulting roles exist. ### What are the rate limits for the CyberArk Conjur API? Conjur is typically self-hosted, so rate limits depend on the operator's deployment sizing rather than a vendor-imposed quota. Capacity-plan around concurrent workloads and back off on 5xx responses that signal overload. ### How do I retrieve a Conjur secret through Jentic? Run pip install jentic, search for 'retrieve a secret from Conjur', load the GET `/secrets/{id}` schema, and execute with the secret id. Jentic handles the API key so your code never holds it directly. ### Can I limit what my agent is allowed to do with the CyberArk Conjur API? Yes. Because you run Jentic One yourself, your own rules decide which Conjur operations the agent may call and which credential it uses. Since the secret id sits in the URL path (GET `/secrets/{id}`), you can pin the agent to reading one specific secret and exclude everything else, so writing values through POST /secrets or loading policies through POST /policies is not available unless you grant it. The Conjur API key is held by your instance and injected at execution time, so the agent never sees it.