KeyVaultClient

Name: KeyVaultClient API
Brand: KeyVaultClient
Availability: InStock

★ Only Publicly Available OpenAPI DocumentSecuritySecrets Managementoauth278 EndpointsREST

For Agents

Manage and use Azure Key Vault keys, secrets, and certificates including sign, encrypt, wrap, backup, restore, and soft-delete recovery against a specific vault host.

Connect the KeyVaultClient to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the KeyVaultClient, 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 KeyVaultClient API.

Create, import, and rotate cryptographic keys with sign, verify, encrypt, decrypt, wrap, and unwrap operations

Set, get, and version secrets stored in a vault

Issue, import, merge, and renew X.509 certificates with policy-driven lifecycles

Configure certificate issuers and contact addresses for renewal notifications

GET STARTED

Start building with KeyVaultClient API

Explore with Jentic

View OpenAPI Document

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

Jentic publishes the only available OpenAPI specification for the Azure Key Vault data plane (7.0-preview), keeping it validated and agent-ready. The KeyVaultClient performs cryptographic key operations and secret, certificate, and storage account credential operations against a vault host such as https://myvault.vault.azure.net. It exposes 78 endpoints to manage keys, secrets, certificates and their policies, soft-deleted resources and recovery, certificate issuers and contacts, and storage account access definitions.

Use Cases

Patterns agents use KeyVaultClient API for, with concrete tasks.

★ Workload Secret Retrieval at Runtime

Application workloads fetch database connection strings and third-party API keys from Key Vault at runtime via /secrets/{secret-name} rather than baking them into config files. The vault returns the value over TLS scoped to the AAD identity making the call. This is the standard pattern for credential-free Azure deployments and integrates naturally with managed identity tokens from IMDS.

GET https://acme-vault.vault.azure.net/secrets/db-connection-string?api-version=7.0 and return the value field.

HSM-Backed Cryptographic Operations

Security-sensitive workloads keep private keys in Key Vault and call /keys/{key-name}/sign and /keys/{key-name}/wrapkey to sign payloads or wrap data encryption keys without exporting the private material. The vault performs the operation server-side, so the key never leaves the HSM boundary. This is the foundation for envelope encryption and signed-token issuance from server workloads.

POST to /keys/signing-key/sign with alg=RS256 and the SHA-256 hash of the payload, then return the resulting signature.

Certificate Issuance and Renewal

Platform teams issue X.509 certificates from Key Vault by configuring an issuer (e.g. DigiCert), defining a certificate policy, and POSTing /certificates/{certificate-name}/create. Key Vault tracks pending operations and merges the signed certificate back when the issuer responds. The same flow drives automatic renewal as policies hit their renewal window.

POST a certificate creation with issuerName 'DigiCert' and subject 'CN=api.acme.com' to /certificates/api-acme-com/create.

Soft-Delete Recovery and Backup Hygiene

Operators recover accidentally deleted keys, secrets, or certificates by walking /deletedkeys, /deletedsecrets, and /deletedcertificates and POSTing the recover endpoint on the affected resource. For compliant backup hygiene the same teams call backup endpoints to export blobs that can be restored into a paired vault. This is essential for production vaults that hold critical credentials.

List all deletedsecrets in the vault and POST recover on any whose name starts with 'prod-'.

Agent-Driven Secret Access via Jentic

An AI agent can fetch secrets, sign payloads, and rotate certificates in Key Vault through Jentic without holding raw AAD credentials or vault access tokens. The agent searches Jentic for 'get a secret from azure key vault', loads the operation schema, and executes against the target vault host. Jentic's MAXsystem injects a scoped bearer token for the vault audience.

Use the Jentic MCP tool azure_keyvault_get_secret to fetch the value of secret 'stripe-key' from vault https://acme-vault.vault.azure.net.

Key Endpoints

78 endpoints — jentic publishes the only available openapi specification for the azure key vault data plane (7.

METHOD

PATH

DESCRIPTION

GET

/secrets/{secret-name}

Get the latest version of a secret

PUT

/secrets/{secret-name}

Set or update a secret value

POST

/keys/{key-name}/sign

Sign a payload with a key

POST

/keys/{key-name}/wrapkey

Wrap a symmetric key with a vault key

POST

/certificates/{certificate-name}/create

Create a new certificate via the configured issuer policy

POST

/keys/{key-name}/backup

Back up a key as a portable blob

POST

/deletedsecrets/{secret-name}/recover

Recover a soft-deleted secret

GET

/secrets/{secret-name}

Get the latest version of a secret

PUT

/secrets/{secret-name}

Set or update a secret value

POST

/keys/{key-name}/sign

Sign a payload with a key

POST

/keys/{key-name}/wrapkey

Wrap a symmetric key with a vault key

POST

/certificates/{certificate-name}/create

Create a new certificate via the configured issuer policy

Why though Jentic?

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

Credential isolation

Azure AD OAuth 2.0 client secrets and refresh tokens for the vault.azure.net audience are stored encrypted in the Jentic vault (MAXsystem). Agents receive scoped bearer tokens — raw client secrets and the secret values returned from the vault never persist in the agent's context beyond the tool invocation.

Intent-based discovery

Agents search Jentic by intent (e.g. 'get a secret from azure key vault' or 'sign a payload with a key vault key') and Jentic returns the matching Key Vault operation with its parameter schema, so the agent calls the right endpoint without parsing the data-plane reference.

Time to first call

Direct Key Vault data-plane integration: 1-2 days to wire AAD against the vault audience, handle 429 retries, and implement soft-delete recovery flows. Through Jentic: under 1 hour — search, load schema, execute.

Related APIs

Alternatives and complements available in the Jentic catalogue.

Complementary

Azure Instance Metadata Service

IMDS issues the managed identity token used to authenticate against Key Vault from inside an Azure VM.

Use IMDS first to obtain a vault-scoped bearer token, then call Key Vault with it.

Complementary

Azure IoT Hub

IoT Hub workloads commonly fetch device-side credentials and CA private keys from Key Vault.

Use Key Vault to back the secrets that IoT Hub services depend on.

Complementary

Azure IoT Device Provisioning Service

DPS verification flows benefit from CA private keys held in Key Vault rather than on disk.

Use Key Vault to source the CA signing material consumed during DPS proof-of-possession.

FAQs

Specific to using KeyVaultClient API through Jentic.

Why is there no official OpenAPI spec for KeyVaultClient?

Microsoft documents the Key Vault data plane as a REST API but does not publish a maintained OpenAPI 3 specification for it. Jentic generates and maintains this spec so that AI agents and developers can call KeyVaultClient 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 KeyVaultClient use?

The data plane requires an Azure Active Directory OAuth 2.0 bearer token whose audience is https://vault.azure.net. Through Jentic the AAD client secret or refresh token is held in the Jentic vault (MAXsystem) and a vault-scoped bearer token is injected per call so the agent never sees raw secrets.

Can I sign a payload without exporting the key?

Yes. POST to /keys/{key-name}/sign with the algorithm (e.g. RS256) and the digest in the request body. The vault performs the signing inside its HSM boundary and returns only the signature, so the private key never leaves the vault.

What are the rate limits for KeyVaultClient?

Key Vault enforces per-vault transaction quotas — typically 2,000 transactions every 10 seconds for HSM keys and higher for software-protected keys, with limits surfaced via 429 responses including a Retry-After header. Cryptographic operations and key management operations have separate buckets, so balance batch-signing carefully.

How do I fetch a secret through Jentic?

Run pip install jentic, then search Jentic with 'get a secret from azure key vault', load the get-secret operation, and execute with the vault host and secret-name. Jentic returns the secret bundle including value, contentType, and tags.

Can I recover a deleted secret with this API?

Yes — when soft delete is enabled on the vault. List candidates via GET /deletedsecrets, then POST /deletedsecrets/{secret-name}/recover to restore the secret to its prior version. Without soft delete the secret is permanently gone, so verify the vault property before relying on this flow.