Quick answer: Azure Key Vault is the right place to store credentials for Azure-hosted services and infrastructure. When autonomous AI agents start consuming those credentials, a per-agent identity and policy layer on top gives each agent exactly the access its task requires — without migrating anything out of Key Vault.
Quick answer
Azure Key Vault handles secret storage well. Managed identities, Azure AD RBAC, HSM-backed keys, automatic rotation — it's a mature, well-operated secrets store. What it wasn't designed for is distinguishing between one autonomous AI agent and another, or enforcing per-agent operation scope before a credential is retrieved.
When agents share a managed identity, they share its access profile. A Cursor agent and a Claude Code agent running in the same Azure environment get identical permissions. One runaway task or prompt injection has the same blast radius as the other. Layering Gazebo in front of Key Vault adds per-agent identity, policy enforcement, and an action-level audit trail — without touching the Key Vault setup, the managed identities, or the CI/CD pipelines that already use them.
How Azure Key Vault handles credentials
Key Vault is designed around a vault-and-secret model. You create a vault, store secrets (and certificates and keys) in it, and control access through Azure AD. Three things it does well:
Managed identity integration. Azure resources — VMs, App Service, Container Apps, Functions — can authenticate to Key Vault via managed identity without storing a credential anywhere. The Azure platform handles the token exchange. For Azure-native service auth, this is the right approach: no secrets in environment variables, no rotation burden on the developer.
Azure AD RBAC. Access policies can be as granular as a specific secret within a vault, scoped to a specific identity. Key Vault RBAC roles (Key Vault Secrets User, Key Vault Reader) let you control read vs. read-write access at the resource level.
Audit logging via Azure Monitor. Key Vault diagnostic logs sent to a Log Analytics workspace record every secret access: which identity retrieved which secret, at what time, from what IP. For compliance requirements around secret access, this covers the storage layer.
Automatic rotation for supported services. Key Vault integrates with a short list of Azure services — Azure SQL, Azure Cache for Redis, and others — to rotate credentials automatically without downtime. For those services, rotation is handled by the platform.
Verify Key Vault's current feature set against Azure Key Vault documentation — capabilities evolve and specifics may have shifted since this was written.
How agents consume Key Vault credentials by default
The standard pattern for an AI agent on Azure: the agent runs in an environment with a managed identity (a VM, a Container App, an Azure Function). That managed identity has been granted Key Vault Secrets User on the relevant vault. At runtime, the agent fetches the secret it needs using the Azure SDK and calls the target service.
This is correct infrastructure practice. The problem is that managed identity is a coarse-grained identity — it identifies the compute resource, not the specific agent process running on it. Two agents running in the same Container App share the same managed identity and therefore the same Key Vault access profile.
Three things this model doesn't provide for autonomous agents:
Per-agent scoping below the managed identity level. All processes that share a managed identity have identical Key Vault permissions. If your managed identity has Key Vault Secrets User on a vault that contains Stripe, GitHub, and OpenAI secrets, every agent process in that environment can retrieve all three — regardless of whether a given agent's task requires more than one.
Approval gates before credential retrieval. Key Vault is a secrets store. It evaluates "is this identity allowed to read this secret?" — not "is this agent allowed to perform this operation right now, given what I know about the task it's executing?" There's no workflow-level approval step in the retrieval path.
Per-agent-call audit records. Azure Monitor logs that the managed identity retrieved a secret. It doesn't log what the agent subsequently did with that credential — which endpoint it called, what parameters it passed, what the response was. When a production incident involves an AI agent, the Key Vault log tells you a credential was accessed; it doesn't tell you what the agent did next.
Why this creates exposure for autonomous agents
The gap between "identity allowed to read this secret" and "agent allowed to do this specific thing" is where most AI agent security incidents happen.
Blast radius from over-permissioned retrieval. If an agent can retrieve the full Stripe secret key, it has every Stripe operation that key permits — reading customer payment methods, issuing refunds, modifying subscription plans, updating webhook endpoints. The workflow may have been designed to create payment intents only. The credential doesn't know that.
Prompt injection. Autonomous agents often read external content as part of their task — fetching a document, reading a GitHub issue, processing an email, parsing an API response. If that content contains a malicious instruction, it can redirect what the agent does next. An agent with broad credential access when that happens has broad access during the attack. Narrowing the credential scope at the agent level limits the damage to what the task legitimately needed. See what happens when you paste an API key into an AI agent's prompt for how this plays out in practice.
No per-agent revocation path. If one agent behaves unexpectedly, the revocation option within Key Vault's model is removing the managed identity's access to the vault — which revokes access for every agent process sharing that identity. Targeted revocation of one agent's access without affecting the others requires either separate managed identities per agent (significant infrastructure overhead) or a credential broker that handles per-agent identity independently.
How Key Vault and Gazebo compose
Gazebo sits in front of Key Vault as the agent-facing policy layer. Key Vault continues doing what it does well — storing and rotating the underlying credentials. Gazebo adds what Key Vault wasn't designed to provide — per-agent identity, operation-level scope enforcement, and action-level audit logging.
The flow:
-
Key Vault stores the real credentials. Stripe keys, GitHub tokens, OpenAI keys, database URLs — all remain in Key Vault. No migration. Existing managed identities, RBAC policies, rotation schedules, and CI/CD pipelines that pull from Key Vault are untouched.
-
Gazebo holds a read-scoped service credential for the vault. A single managed identity with Key Vault Secrets User is granted to Gazebo's service. Gazebo uses it to fetch credentials at policy resolution time — not the agents.
-
Agents authenticate to Gazebo, not Key Vault directly. Each agent gets a Gazebo access profile with an MCP endpoint URL and an agent token. The profile defines which services the agent can access and which operations are permitted. The agent never sees the Key Vault secret directly.
-
Gazebo enforces scope at resolution time. When an agent calls a tool through the MCP endpoint, Gazebo checks the policy, fetches the credential from Key Vault, and returns a scoped credential valid for the permitted operations only. An agent scoped to "Stripe payment intent creation" can't retrieve or use the parts of the Stripe key that allow refunds or customer reads.
-
Per-agent revocation is a single token revoke. If a Cursor agent behaves unexpectedly, you revoke its Gazebo token. The Stripe key in Key Vault is untouched. Claude Code, the CI pipeline, and the n8n workflow that use the same underlying credential keep running.
For teams already running Key Vault in production, this is an additive layer — not a migration. The existing vault structure, managed identities, and rotation setup stay exactly as-is.
Connecting an Azure AI agent to Gazebo's MCP endpoint
1. Create an access profile in Gazebo.
Log in to Gazebo and create a new access profile for the agent. Add the services it needs — Stripe, GitHub, OpenAI, or whichever services your Key Vault holds — and set the operation scope for each. For a billing agent, that might be Stripe payment intent creation only. For a DevOps agent, GitHub PR reads and Vercel deployment triggers.
2. Copy the MCP endpoint URL and agent token.
Gazebo generates a unique MCP endpoint URL and agent token per access profile. Copy both from the profile page.
3. Configure the agent to call the MCP endpoint.
Replace the agent's direct Key Vault credential retrieval with an MCP tool connection. In the agent's MCP config, add the Gazebo endpoint:
{
"mcpServers": {
"gazebo": {
"url": "https://mcp.gazebohq.com/YOUR_PROFILE_ID",
"headers": {
"Authorization": "Bearer YOUR_AGENT_TOKEN"
}
}
}
}
The agent token goes here — not your Key Vault credentials or your Azure AD service principal. The underlying Key Vault secrets remain in Gazebo's configuration, never in the agent's context.
4. Verify the connection.
Run the agent on a low-stakes task. In the Gazebo dashboard, confirm the execution appears in the access log with the correct agent identity and the expected operations. If the agent attempts an operation outside the profile's scope, Gazebo returns a permission denied — log it, adjust the policy if the operation is legitimate, or investigate if it isn't.
5. Optionally tighten the managed identity scope.
Once agents route through Gazebo rather than directly to Key Vault, the managed identity you granted Gazebo needs Key Vault Secrets User access to the vault — but the per-agent managed identities that previously held direct vault access may no longer need it. Review and narrow those permissions. The principle of least privilege applies to the infrastructure layer too.
What changes, what doesn't
The Key Vault setup doesn't change. Managed identities, RBAC policies, diagnostic logging, rotation schedules — all continue as-is. What changes is how agents authenticate to use those credentials: through a policy-aware broker rather than directly against the vault.
Each agent gets its own identity in Gazebo — a narrower surface than a shared managed identity, with operation scope defined per task rather than per compute resource. The Key Vault audit log still records the Gazebo service identity retrieving secrets. The Gazebo access log records which agent used which operation and when. Together they give you a complete chain from credential storage through agent action.
For teams managing multiple agents across Azure-hosted services, see AI agent credential management: a complete guide for how to think through access profile design across agent types and risk levels. For the broader IAM model, IAM for AI agents covers how per-agent identity differs from per-user and per-service identity patterns.
Gazebo gives every Azure AI agent its own scoped identity — credentials limited to what the task requires, logged per action, revocable without touching your Key Vault setup. See how it works or get started free.
Last reviewed: August 2026. This post is not affiliated with or endorsed by Microsoft. Verify against current Azure Key Vault documentation for the latest feature set and configuration options.