canonical: https://jentic.com/apis/akeyless.io/akeyless # Akeyless API Jentic publishes the only available OpenAPI specification for Akeyless API, keeping it validated and agent-ready. Akeyless is a vaultless secrets-management platform - the v2 API exposes 17 endpoints covering authentication, static and dynamic secrets, encryption and decryption, auth methods, roles and rules, and gateway access listing. Calls are POST-driven with bearer-token authentication after an initial /auth call returns a session token. ## For AI agents Authenticate, fetch and create secrets (static and dynamic), encrypt and decrypt payloads, and manage auth methods and role rules in the Akeyless vaultless platform. ## Scope Does not run application servers, host CI pipelines, or scan for vulnerabilities - use for secrets management, encryption, and RBAC only. ## Capabilities - Authenticate via /auth and obtain a session token - Fetch and create static secrets and update their values - List, describe, and delete vault items - Generate and create dynamic secrets for short-lived database or cloud credentials - Encrypt and decrypt payloads using Akeyless-managed keys - Create auth methods and list configured methods on the account - Define roles and attach rules that govern access ## Use cases ### Just-in-time credential delivery An automation pipeline calls Akeyless to fetch secrets at runtime instead of storing them on disk. The agent authenticates via POST /auth, then calls POST /get-secret-value for static secrets or POST /get-dynamic-secret-value to mint short-lived credentials. Example prompt: POST /auth, then POST /get-secret-value with name=/prod/db/password to read the value at deploy time ### Encryption and decryption workflow Use Akeyless as a managed key service - call POST /encrypt to wrap a payload with a named Akeyless key, store the ciphertext, and POST /decrypt to recover it later. This keeps key material out of application code. Example prompt: POST /encrypt with key-name=app-key and plaintext, store the returned ciphertext, then POST /decrypt to recover the original plaintext ### Role and access policy automation Manage RBAC programmatically - create a role via POST /create-role and attach access rules via POST /set-role-rule to control which paths a service can read, write, or list. Useful when an admin agent provisions new services and must grant scoped access. Example prompt: POST /create-role with role-name=svc-billing, then POST /set-role-rule to grant read access to /prod/billing/* ### AI agent integration via Jentic An agent that needs runtime secrets uses Jentic to discover Akeyless operations by intent. The Akeyless access credential is stored in your Jentic One instance, the agent loads the operation schema at runtime, and the response payload (e.g., a database password) is consumed by the next step without ever appearing in agent memory beyond the immediate call. Example prompt: Search Jentic for 'fetch a secret value at runtime', load the Akeyless POST /get-secret-value operation, and execute with the secret name ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | /auth | Authenticate and get a session token | | POST | /get-secret-value | Get a static secret value | | POST | /create-secret | Create a static secret | | POST | /get-dynamic-secret-value | Get a dynamic short-lived secret | | POST | /encrypt | Encrypt a payload | | POST | /decrypt | Decrypt a payload | | POST | /create-role | Create an RBAC role | | POST | /set-role-rule | Attach an access rule to a role | ## Key resources - **Auth** — Authenticate and obtain a session token - **Secrets** — Get, create, update, describe, list, and delete static and dynamic secrets - **Encryption** — Encrypt and decrypt payloads with Akeyless-managed keys - **Auth Methods** — Create and list auth methods on the account - **Roles** — Create roles, list roles, and set role rules for RBAC - **Gateways** — List allowed access entries for a gateway ## Why Jentic - **Setup:** Wiring Akeyless by hand means calling /auth for a session token, passing it to secret, encryption, and role operations, and writing your own retry logic. Through Jentic you install once, import Akeyless from the API Directory, store the access credentials once, and your agent calls it while Jentic performs the /auth step. - **Permission scoping:** Akeyless names its secrets, roles, and keys in the request body, so scope your agent by operation: limit it to the operations it needs, such as /get-secret-value, and leave out /create-secret, /decrypt, or role management it does not use. - **Credential handling:** Your Akeyless access id and key are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'fetch a database secret at runtime', and Jentic returns the Akeyless /get-secret-value operation with its schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **1Password Events** — Password manager with audit-event API rather than full secrets-as-a-service. - **HashiCorp** — HashiCorp ecosystem (Vault, Nomad) is the closest peer to Akeyless's vaultless model. - **OpenAI API** — OpenAI calls themselves consume Akeyless-stored API keys at runtime. ## FAQ ### Why is there no official OpenAPI spec for Akeyless API? Akeyless does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Akeyless API 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 Akeyless API use? Authenticate first via POST /auth to receive a session token, then pass it as a bearer token on subsequent calls. Through Jentic, both the access credential used for /auth and the resulting session token are managed in the encrypted Jentic One instance. ### How do dynamic secrets differ from static secrets in Akeyless? Static secrets are stored values you create via POST /create-secret and read via POST /get-secret-value. Dynamic secrets are minted on demand via POST /get-dynamic-secret-value - they are short-lived credentials (e.g., database users) that Akeyless creates against a configured producer and revokes when the lease expires. ### Can I encrypt payloads through Akeyless without managing keys? Yes. POST /encrypt wraps your payload with a named Akeyless key and returns ciphertext; POST /decrypt reverses the operation. The key material never leaves Akeyless, so application code only handles ciphertext. ### How do I fetch a secret through Jentic? Use the Jentic search query 'fetch a secret value'. Jentic returns the POST /get-secret-value operation; supply the secret name, and Jentic injects the bearer token at execution time. ### Are there rate limits on the Akeyless API? The OpenAPI spec does not declare explicit rate limits; Akeyless applies plan-based quotas. Watch for 429 responses on burst traffic and implement exponential backoff for fetch loops. ### Can I limit what my agent is allowed to do with the Akeyless API? Yes. Because Akeyless names its secrets, roles, and keys in the request body, you scope the agent by operation, and since Jentic One is self-hosted your own rules decide which operations and credentials it may use. For a read-only agent you can allow POST /get-secret-value or POST /get-dynamic-secret-value while leaving out POST /create-secret, POST /encrypt, POST /decrypt, and role management like POST /create-role and POST /set-role-rule. That way the agent authenticates through /auth and retrieves only the secrets it needs, with no ability to write secrets, decrypt payloads, or change access policy.