--- title: "What Is a Secrets Broker for AI Agents?" description: "A secrets manager stores your credentials. A secrets broker controls which AI agent can retrieve them, under what conditions, and what it can do with them. Here's why the distinction matters." publishedAt: "2026-07-28" readingTime: "6 min" url: "https://gazebohq.com/writing/secrets-broker" --- **Quick answer:** A secrets broker is the layer that sits between an AI agent and the API credentials it needs. The agent authenticates to the broker with its own scoped token. The broker checks whether that agent may retrieve a service credential, returns it only when policy allows, and logs the retrieval. A broker that proxies provider calls can also enforce operations without releasing the credential; a credential-release broker must rely on provider-side scopes after release. ## Secrets manager vs. secrets broker The distinction matters and it's easy to conflate the two. A **secrets manager** (HashiCorp Vault, AWS Secrets Manager, 1Password Secrets Automation) solves the storage problem: your API keys live in an encrypted vault rather than in `.env` files or hardcoded in source. That's necessary but not sufficient for AI agents. A **secrets broker** solves the retrieval-control problem: which agent can retrieve which credential and under what conditions. A proxying broker can additionally control provider operations because the credential never leaves the proxy. For humans, these functions often collapse — a developer fetches a secret from the vault and uses it directly. The audit trail and approval workflow are relatively lightweight because there are limited humans and they act predictably. For AI agents, the separation becomes critical. An agent might call a credential endpoint hundreds of times a day, from multiple tasks, across many services. Without a broker enforcing per-agent, per-service policies, the vault becomes a self-service key dispenser — secure at rest, uncontrolled in motion. ## What a broker actually does The broker pattern has four steps, every time an agent requests a credential: 1. **Identify the caller.** The agent presents a token representing its access profile — not a raw API key. The broker verifies which agent this is. 2. **Check the policy.** The broker looks up which services the agent may access and which declared methods permit credential release. If the request falls outside the policy, the broker denies it. 3. **Issue a response.** If permitted, the broker either returns the credential to the authorized agent process or proxies the provider call. Only the proxy model keeps the provider credential hidden from the agent process. 4. **Log the transaction.** Every request — allowed or denied — is recorded: which agent, which service, which operation, what time, what result. The key property is that credential retrieval is bounded by agent policy. In a credential-release model, the underlying provider key still bounds what can happen after release. Hard operation-level enforcement requires provider-scoped credentials or a proxy that performs the provider call. ## Why AI agents specifically need this Secrets managers were designed for a world where the consumers of secrets are services or humans with stable, well-understood access patterns. You configure the service once, it retrieves the secret at startup, and that's largely the end of the story. AI agents break every assumption in that model: - **Variable tasks.** The same agent might be asked to do different things in different sessions. Static access grants don't match dynamic task requirements. - **No authentication ceremony.** Agents don't log in — they hold a credential and call APIs. There's no login event to audit, no MFA to require, no session to review. - **Shared keys by default.** Without a broker, the natural pattern is to give every agent the same API key your team uses. One compromised agent exposes everything that key can touch. - **No instinct for scope.** An agent given a full-access key will use it. It has no concept of "I probably shouldn't do this." The broker injects the enforcement that agents lack natively: a policy check before every credential access, with logging and revocation built in. ## Approval gates Some operations shouldn't be automated regardless of whether the agent is authorized — a POST to a production database, a DELETE on a live resource, a high-value Stripe charge. The broker pattern makes approval gates a first-class feature rather than an afterthought. When an agent requests a credential for an operation that requires approval, the broker pauses execution and sends a notification to a designated reviewer (Slack, email, dashboard). The agent waits. If the reviewer approves, the broker issues the credential and the operation proceeds. If the reviewer denies or the timeout expires, the broker rejects the request and logs the outcome. This means the human-in-the-loop isn't an architectural add-on — it's enforced at the access control layer. The agent can't skip it, even if its prompt instructs it to. Approval gates are configured per-profile, per-service, and per-operation type. A write-access Stripe profile might require approval for any `POST /charges` request above $100, while allowing `GET` requests to proceed automatically. The granularity is at the HTTP method and endpoint level. ## Revocation without rotation One of the most practical consequences of the broker pattern is what it does to revocation. In a direct-key model, revoking one agent's access means rotating the key — which means updating every other service and agent that uses the same key. This is painful enough that teams defer it, which means compromised agents stay active far longer than they should. With a broker, each agent holds a profile token, not the underlying credential. Revoking an agent means invalidating its token. The underlying Stripe key, Vercel token, or Cloudflare API key is untouched. Every other agent that was using those credentials through their own profiles keeps working. Revocation goes from a multi-system key rotation exercise to a single-click action. ## Performance considerations Adding a broker to the credential request path introduces latency. In practice, this is rarely the bottleneck — a broker check and credential issue adds 10-50ms to a credential retrieval, and agent tasks typically involve seconds to minutes of processing time. The latency is negligible relative to the task duration. Where it does matter: agents that retrieve credentials on every API call rather than caching them for the session duration. If your agent calls `get_credential` for every Stripe request, and makes dozens of Stripe requests per session, the cumulative broker latency adds up. The mitigation is simple: retrieve credentials once at session start, cache them for the session duration, and call the broker again only if the cached credential is rejected (which signals it was revoked or expired). Brokers can also be deployed regionally to reduce latency for globally distributed agent workloads. A broker instance in us-east-1 serving agents in us-east-1, and one in eu-west-1 serving agents in Europe, keeps the credential retrieval round-trip under 20ms even at geographic scale. ## Self-hosted vs. managed broker Teams evaluating the broker pattern often consider building their own. The core logic isn't complicated: an API that accepts agent tokens, looks up policies, checks requested operations against those policies, retrieves credentials from the vault, and returns results. A weekend project can produce a working version. The complexity is in everything else: secure token issuance and revocation, policy management UI, audit log storage and querying, approval gate notification routing, key derivation for scoped credentials, and ongoing maintenance as service APIs change. Most teams that start down this path spend more time maintaining their broker than using it — and end up with fewer features than a purpose-built solution. The decision point: if your team has dedicated platform engineering capacity and strong internal security requirements (data residency, custom integration needs, internal compliance), self-hosted is viable. If your team is primarily building products rather than infrastructure, a managed broker is almost always the right tradeoff. ## Integration with existing secrets managers A broker doesn't require migrating away from your existing secrets manager. The broker sits in front of it: - **HashiCorp Vault:** The broker authenticates to Vault using AppRole or Kubernetes auth, retrieves the underlying credential, applies its own policy layer, and issues a scoped response to the agent. Vault stores the raw credentials; the broker controls agent access. - **AWS Secrets Manager:** The broker uses an IAM role to call `GetSecretValue`, then issues per-agent credentials from the retrieved value. Your existing Secrets Manager setup is unchanged. - **1Password:** The broker uses the Secrets Automation API to retrieve credentials on demand. 1Password remains the vault; the broker adds the per-agent enforcement layer. This layered architecture means you can adopt broker-based access control incrementally — without migrating credentials, without changing your vault setup, and without disrupting existing non-agent systems that access the same credentials directly. ## Compliance benefits For SOC 2 Type II, the broker pattern directly addresses several common control requirements: - **CC6.1 (Logical Access Controls):** Per-agent access profiles are documented, scoped, and enforced — not implicit. - **CC6.2 (New Access / Modifications):** Profile creation and modification is logged with a timestamp and actor. - **CC6.3 (Access Removal):** Revocation is a single action with an immediate, logged effect. - **CC7.2 (Monitoring of System Components):** Every credential access is logged with enough detail to reconstruct what happened. Auditors reviewing AI agent access controls typically look for the same evidence they'd look for with human access: documented policies, access reviews, audit trails, and revocation procedures. A broker provides all of these automatically rather than requiring manual documentation processes. ## What this looks like with Gazebo Gazebo is a secrets broker built specifically for AI agents. You connect your services once — Stripe, Vercel, Cloudflare, GitHub, and more. Each agent gets an access profile: a named policy defining exactly which services it can reach and which operations it can perform (GET, POST, PUT, DELETE, per service). When an agent needs a credential, it calls Gazebo's [MCP endpoint](/agents) or API with its profile token. Gazebo checks the policy, either returns the scoped credential or proxies the call, and writes a log entry. If the action requires human review — a POST to a production endpoint, a DELETE operation — it goes through an approval gate before execution. The result: your underlying credentials stay in one place, protected, and each agent's access is bounded to exactly what you've defined for it. For how this fits into the broader identity model, see [IAM for AI agents](/writing/iam-for-ai-agents). For how scoped credentials compare to environment variables in practice, see [environment variables and AI agent security](/writing/environment-variables-ai-agents-security). For the audit side of the broker pattern, see [secrets management for AI agents](/writing/secrets-management-best-practices-ai-agents). ## Frequently asked questions **Q: What is a secrets broker?** A secrets broker is the access-control layer between an AI agent and your credentials. The agent presents a profile token, the broker checks whether it can access the requested service and operation, and returns a scoped credential or denies the request. **Q: How is a secrets broker different from a secrets manager?** A secrets manager (Vault, AWS Secrets Manager) solves storage — credentials encrypted at rest. A secrets broker solves access control — enforcing which agent can retrieve which credential, under what conditions, and logging every retrieval. **Q: Why do AI agents specifically need a secrets broker?** AI agents don't log in — they hold a credential and call APIs continuously. Without a broker, the natural pattern is a shared full-access key that every agent uses. If one agent is compromised, everything that key can touch is exposed. **Q: Does the agent ever see the raw API key?** No. The agent calls the broker's endpoint with its profile token. The broker checks the policy and either proxies the request or returns a scoped credential. The plaintext API key never enters the agent's context window, logs, or conversation history. **Q: How does revocation work with a secrets broker?** Each agent holds a profile token, not the underlying credential. Revoking an agent means invalidating its token — the underlying API key is untouched and every other agent continues working.