CyberArk Conjur API

Name: CyberArk Conjur API API
Brand: CyberArk Conjur API
Availability: InStock

★ Only Publicly Available OpenAPI DocumentSecuritySecrets ManagementapiKey4 EndpointsREST

For Agents

Store and retrieve secrets, create access policies, and list roles in CyberArk Conjur via four core REST endpoints.

Connect the CyberArk Conjur API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the CyberArk Conjur API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Install Jentic One Beta (Self-Hosted)

Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh

Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with CyberArk Conjur API API.

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

GET STARTED

Start building with CyberArk Conjur API API

Explore with Jentic

View OpenAPI Document

Jentic publishes the only available OpenAPI document for CyberArk Conjur API, keeping it validated and agent-ready.

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.

Use Cases

Patterns agents use CyberArk Conjur API API for, with concrete tasks.

★ 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.

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.

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.

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.

Through Jentic, retrieve the value at id 'prod/db/password' and pass only a redacted reference back to the user.

Key Endpoints

4 endpoints — jentic publishes the only available openapi specification for cyberark conjur api, keeping it validated and agent-ready.

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

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

Why though Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

The CyberArk Conjur API key is stored encrypted in the Jentic vault. Agents receive a scoped execution token - the long-lived key never reaches the agent's prompt or logs.

Intent-based discovery

Agents search by intent (e.g. 'retrieve a secret from Conjur') and Jentic returns the GET /secrets/{id} operation with its parameter schema, so the agent goes from intent to call in one step.

Time to first call

Direct Conjur integration: 1-2 days for auth, retry handling, and policy bootstrap. Through Jentic: under 1 hour - search, load, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Alternative

Conjur (full spec)

Larger Conjur surface covering authentication, host factory, certificate authority, and more

Use the conjur-api spec when you need authn flows, host-factory enrolment, or certificate-authority operations; use this 4-endpoint spec when storing and retrieving secrets is enough.

Complementary

1Password Events API

Audit-event stream for the 1Password secrets manager

Pair 1Password Events with Conjur when humans use 1Password and workloads use Conjur, and you want a unified audit pipeline.

Complementary

CyberGordon

Cyber-reputation lookup across multiple intelligence engines

Use CyberGordon alongside Conjur during incident response, when secret rotation and observable reputation lookups happen in the same workflow.

FAQs

Specific to using CyberArk Conjur API API through Jentic.

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 at https://app.jentic.com/sign-up.

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.