Quick answer: A secrets broker is the layer that sits between an AI agent and the raw API credentials it needs. The agent never gets the real key — it gets a scoped token. The broker checks whether that agent is permitted to access that service, returns a time-limited or revocable credential, and logs everything. A secrets manager stores credentials securely; a secrets broker controls who can retrieve them, under what conditions, and what they can do with them.
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 access-control problem: which agent can retrieve which credential, under what conditions, and what exactly can it do with it once it has it. The broker adds an enforcement layer in front of storage.
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:
- Identify the caller. The agent presents a token representing its access profile — not a raw API key. The broker verifies which agent this is.
- Check the policy. The broker looks up what this agent is allowed to reach: which services, which HTTP methods, which specific endpoints. If the requested action falls outside the policy, the broker denies it — the underlying credential is never touched.
- Issue a scoped response. If the request is permitted, the broker returns either a scoped credential or proxies the call directly. The agent never sees the underlying API key.
- Log the transaction. Every request — allowed or denied — is recorded: which agent, which service, which operation, what time, what result.
The key property: the agent's access is bounded by its policy, not by what the underlying API key allows. A full-access Stripe key in the vault doesn't give every agent full Stripe access — only the operations each agent's profile explicitly permits.
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 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. For how scoped credentials compare to environment variables in practice, see environment variables and AI agent security. For the audit side of the broker pattern, see secrets management for AI agents.