canonical: https://jentic.com/apis/cyberark.com/conjur-api # Cyberark Conjur Jentic publishes the only available OpenAPI specification for Conjur, keeping it validated and agent-ready. Conjur is CyberArk's open-source secrets-management platform for storing, retrieving, and rotating secrets used by applications, containers, and CI/CD pipelines. The published spec is structured around authentication, secrets, policies, roles, host factories, public keys, resources, status, and certificate authority surfaces. Conjur supports basic authentication, an API-key/token-based Authorization scheme, and Kubernetes mutual TLS for workloads running in clusters. License: Apache-2.0. ## For AI agents Programmatically authenticate to Conjur, retrieve and store secrets, manage policies and roles, and authorise workloads via API key or Kubernetes mutual TLS. ## Scope Does not handle human password management, MFA enrollment, or endpoint protection - use for workload secrets management, policy-as-code, and machine identity through Conjur only. ## Capabilities - Authenticate to Conjur using user login plus API key, or via Kubernetes mutual TLS for in-cluster workloads - Retrieve secrets that an application needs at runtime without embedding them in source code - Load and update policies that define resources, roles, and permissions in Conjur - Manage roles and grant or revoke role memberships across the policy graph - Issue host-factory tokens so newly provisioned hosts can self-enrol with Conjur - Inspect Conjur server health and version through the status surface ## Use cases ### Workload secrets retrieval at runtime Replace hard-coded secrets in application config with Conjur lookups. The application authenticates to Conjur (API key or Kubernetes mutual TLS), exchanges credentials for a short-lived token, and retrieves the secret it needs each time the process starts. Conjur's policy graph governs which workloads can read which secrets. Example prompt: Authenticate as host/myapp using its API key, then fetch the secret at variable id 'prod/db/password'. ### Policy-as-code for access control Manage Conjur access control as version-controlled YAML policies. CI/CD loads or updates policies through the API, which keeps roles, resources, and permissions reproducible and reviewable. Combined with the host-factory surface, new workloads can self-enrol on bootstrap. Example prompt: Load the new policy file at root, scoped to branch 'staging', and verify the resulting role and resource counts match expectations. ### Kubernetes secrets for cluster workloads Use Conjur's Kubernetes mutual-TLS authenticator so pods authenticate by their service account and short-lived certificate rather than long-lived tokens. The application then retrieves only the secrets its policy permits, keeping cluster-level secrets out of Kubernetes Secret objects. Example prompt: Authenticate the pod via authn-k8s and retrieve the API token bound to its service account. ### AI agent secrets fetcher via Jentic Allow an autonomous agent to fetch a specific Conjur secret as part of a workflow without ever holding the API key in prompt context. The agent searches Jentic for 'retrieve a secret from Conjur', loads the schema, and executes the call - Jentic mediates the Conjur authentication flow. Example prompt: Through Jentic, retrieve the secret at variable id 'prod/db/password' on Conjur account 'myorg' and surface only a redacted reference to the user. ## Key resources - **Authentication** — Login flows, API-key authentication, and Kubernetes mutual-TLS authenticator - **Secrets** — Store and retrieve secret values bound to variables in the Conjur policy graph - **Policies** — Load and update YAML policies that define resources, roles, and permissions - **Roles** — Inspect and manage role membership and grants - **Host Factory** — Issue tokens for ephemeral hosts to self-enrol with Conjur - **Public Keys** — Manage public keys associated with Conjur identities - **Resources** — Inspect resources and the role-permission relationships on them - **Status** — Server health and version information - **Certificate Authority** — Issue and manage certificates for workloads ## Why Jentic - **Setup:** Wiring Conjur by hand means handling its basic-auth and API-key authentication steps, targeting the right Conjur appliance host, and mapping its secret and policy surfaces yourself. Through Jentic you install once, import Conjur from the API Directory, store the credentials once, and your agent calls it. - **Permission scoping:** You choose which Conjur operations the agent may call and scope it to the ones it needs, such as retrieving a secret. If you grant only secret reads, policy or role changes are not included unless you add them. - **Credential handling:** Your Conjur basic-auth credentials and API keys 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 Jentic 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 APIs - **CyberArk Conjur API (sibling spec)** — Smaller curated Conjur surface focused on the core secrets, policies, and roles endpoints - **1Password Events API** — Audit-event stream for the 1Password secrets manager - **CyberGordon** — Cyber threat reputation lookup across multiple intelligence engines ## FAQ ### Why is there no official OpenAPI spec for Conjur? CyberArk's Conjur project ships an internal OpenAPI definition, but it is not maintained as a clean, validated, agent-ready spec on the vendor's docs site. Jentic generates and maintains this 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 Conjur API use? Conjur supports HTTP basic auth, an API-key/token Authorization header (the conjurAuth scheme), and Kubernetes mutual TLS for workloads running in a cluster. Through Jentic, credentials are stored in the encrypted vault rather than embedded in code or agent prompts. ### Can I retrieve a secret from Conjur with this API? Yes. The Secrets surface lets an authenticated workload fetch secret values bound to variables in the Conjur policy graph, which is the standard pattern for replacing hard-coded secrets in application config. ### Does Conjur work with Kubernetes workloads? Yes. The conjurKubernetesMutualTls scheme implements the authn-k8s authenticator, so pods authenticate using their service account and a short-lived certificate rather than a long-lived token. ### What are the rate limits for the Conjur API? Conjur is a self-hosted open-source platform, so rate limits depend on the operator's deployment sizing rather than a vendor-imposed quota. Capacity-plan around concurrent workloads and watch for 5xx responses indicating overload. ### How do I retrieve a Conjur secret through Jentic? Run pip install jentic, search for 'retrieve a secret from Conjur', load the schema, and execute with the account and variable id. Jentic handles the Conjur authentication step so your code never holds the user API key directly. ### Can I limit what my agent is allowed to do with the Conjur API? Yes. Because you run Jentic One yourself, your own rules decide which Conjur operations and credentials the agent may use, so you can scope it to just the calls it needs, such as retrieving a secret from the Secrets surface. If you grant only secret reads, the agent cannot load or update policies, manage role memberships, or issue host-factory tokens unless you explicitly add those operations. This lets you keep an autonomous agent tightly bound to the exact Conjur actions its task requires.