Agents need credentials to do anything useful. A trading agent needs API keys for Alpaca or Interactive Brokers. A support agent needs database credentials to look up customer records. A deployment agent needs cloud provider tokens to spin up infrastructure.
The standard approach is to inject these secrets as environment variables or pass them in tool definitions. This works until the agent reads a malicious file, gets prompt-injected through a web search result, or hallucinates a tool call that exfiltrates the credentials it was given.
Credential brokering flips the model. Instead of giving the agent secrets, you give it a way to request them at runtime. The broker issues short-lived, scoped tokens on demand, logs every access, and can revoke them mid-execution if the agent’s behavior looks suspicious.
Why This Pattern Matters Now
Infisical’s recent technical explainer on credential brokering addresses a gap that’s become urgent as agents move from demos to production. The core problem: agents are non-deterministic, so traditional secret injection patterns break down. You can’t audit a fixed code path when the LLM decides which tool to call and what parameters to pass.
According to Infisical, the most important credential (the LLM provider key) authenticates the agent’s harness, the inference loop used for decision-making. But agents also need credentials to reach external systems. The question everyone hits: what if the agent gets prompt-injected or reads a malicious script that fools it into leaking the credentials it needs to access different systems?
Credential brokering is positioned as a runtime security layer, not just a secrets management convenience. The agent uses credentials without seeing them. This is critical for production workflows involving financial APIs, customer data access, and infrastructure automation where credential leakage can mean immediate financial loss or compliance violations.
The Problem: Agents Are Non-Deterministic Credential Holders
Traditional applications follow fixed execution paths. You can audit the code, trace the flow, and know exactly when and how a secret gets used. Agents are probabilistic. The LLM decides which tool to call, what parameters to pass, and what to do with the response. This makes static secret injection risky.
Attack surfaces:
- Direct prompt injection: A user tricks the agent into leaking credentials through chat input.
- Indirect injection: The agent reads a malicious README, web page, or API response that contains hidden instructions to exfiltrate secrets.
- Tool misuse: The agent hallucinates a tool call that sends credentials to an unintended endpoint.
If the agent has direct access to a long-lived API key, any of these attacks can succeed. The agent doesn’t need to be compromised in the traditional sense. It just needs to be confused.
How Credential Brokering Works
A credential broker sits between the agent and the secrets store. The agent never sees the actual credentials. Instead, it requests access to a resource, the broker validates the request, and issues a short-lived token scoped to that specific operation.
Basic flow:
- Agent decides it needs to call a payment API.
- Agent sends a request to the broker: “I need credentials for Stripe API, scope: read invoices.”
- Broker checks the agent’s identity, task context, and policy rules.
- Broker issues a token valid for 5 minutes, scoped to read-only invoice access.
- Agent uses the token to call the Stripe API.
- Token expires. If the agent needs another call, it requests a new token.
The broker logs every request, token issuance, and expiration event. If the agent starts requesting credentials for tools it shouldn’t touch, the broker can deny the request or flag it for review.
Architecture: Where the Broker Sits
The broker is a runtime service, not a build-time secret injector. It needs to be reachable from the agent’s execution environment and must have access to the underlying secrets store (Vault, AWS Secrets Manager, Infisical, etc.).
Typical deployment:
┌─────────────┐
│ Agent │
│ Runtime │
└──────┬──────┘
│ 1. Request token for "stripe:read_invoices"
▼
┌─────────────────┐
│ Credential │
│ Broker Service │
└──────┬──────────┘
│ 2. Validate agent identity + policy
▼
┌─────────────────┐
│ Secrets Store │
│ (Vault, etc.) │
└─────────────────┘
│ 3. Fetch master secret, mint short-lived token
▼
┌─────────────────┐
│ External API │
│ (Stripe, etc.) │
└─────────────────┘Figure 1: Credential broker sits between agent runtime and secrets store, issuing short-lived tokens on demand.
The broker can run as a sidecar container, a dedicated microservice, or a serverless function. The key requirement is low latency. If the agent has to wait 500ms every time it needs a credential, orchestration loops slow down.
Dynamic Scope Negotiation
The hard part is handling tools the agent hasn’t seen before. If the agent is designed to work with a fixed set of APIs, you can pre-define scopes. But if the agent is supposed to adapt to new tools dynamically (e.g., a user adds a new integration), the broker needs a way to negotiate scope on the fly.
Two approaches:
- Pre-registered tool catalog: The broker maintains a registry of tools and their required scopes. When the agent requests access, the broker looks up the tool and issues the appropriate token.
- Agent-declared scope: The agent tells the broker what it needs (“I need write access to this S3 bucket”). The broker validates the request against a policy engine (OPA, Cedar, etc.) and decides whether to grant it.
The second approach is more flexible but riskier. If the agent is compromised, it can request overly broad scopes. The policy engine becomes critical.
Audit Trail: Who Accessed What
Every credential request generates an audit event. The broker logs:
- Agent identity (session ID, task ID, user context)
- Requested resource and scope
- Whether the request was granted or denied
- Token lifetime and expiration timestamp
- Actual API calls made with the token (if the broker proxies requests)
This is useful for post-incident analysis. If an agent leaks data, you can trace which credentials it requested, when, and what it did with them.
Multi-agent systems add complexity. If multiple agents share a tool registry, you need to distinguish which agent made which request. This requires agent identity to be part of the orchestration framework, not just a runtime afterthought.
Failure Modes: When Credentials Expire Mid-Task
Short-lived tokens expire. If an agent is in the middle of a multi-step task and the token expires, what happens?
Three strategies:
| Strategy | Behavior | Operational Impact |
|---|---|---|
| Fail fast | Agent throws an error, task halts | Simple, but breaks long-running workflows |
| Auto-refresh | Broker issues a new token automatically | Requires the broker to track agent state, adds complexity |
| Retry with re-auth | Agent detects 401/403, requests a new token, retries the call | Agent needs retry logic, but keeps the broker stateless |
Most production systems use retry with re-auth. The agent’s tool-calling layer wraps every API call in a retry loop that checks for auth failures and re-requests credentials if needed.
The risk is that a compromised agent can keep requesting new tokens indefinitely. Rate limiting and anomaly detection become important.
Code Snippet: Broker Request Flow
Here’s a simplified example of how an agent requests a credential from a broker service.
import requests
from datetime import datetime, timedelta
import time
class CredentialBroker:
"""Manages credential requests to a broker service with local token caching."""
def __init__(self, broker_url, agent_id):
self.broker_url = broker_url
self.agent_id = agent_id
self.token_cache = {}
def get_credential(self, resource, scope, max_retries=3):
cache_key = f"{resource}:{scope}"
# Check if we have a valid cached token
if cache_key in self.token_cache:
token, expiry = self.token_cache[cache_key]
if datetime.now() < expiry:
return token
# Request new token from broker with exponential backoff
for attempt in range(max_retries):
try:
response = requests.post(
f"{self.broker_url}/token",
json={
"agent_id": self.agent_id,
"resource": resource,
"scope": scope,
"ttl": 300 # 5 minutes
},
timeout=5
)
if response.status_code != 200:
raise Exception(f"Broker denied request: {response.text}")
data = response.json()
token = data["token"]
expiry = datetime.now() + timedelta(seconds=data["ttl"])
# Cache the token
self.token_cache[cache_key] = (token, expiry)
return token
except requests.exceptions.RequestException as e:
if attempt == max_retries - 1:
raise Exception(f"Broker unavailable after {max_retries} attempts: {e}")
# Exponential backoff: 1s, 2s, 4s
time.sleep(2 ** attempt)
# Agent tool wrapper with retry logic
def call_stripe_api(broker, endpoint, params):
"""
Production-ready wrapper should include:
- Circuit breaker to stop requests if broker is consistently failing
- Rate limiting to prevent credential request storms
- Metrics/logging for observability
"""
token = broker.get_credential("stripe", "read_invoices")
headers = {"Authorization": f"Bearer {token}"}
response = requests.get(f"https://api.stripe.com/v1/{endpoint}",
headers=headers, params=params)
if response.status_code == 401:
# Token expired, clear cache and retry
cache_key = "stripe:read_invoices"
if cache_key in broker.token_cache:
del broker.token_cache[cache_key]
token = broker.get_credential("stripe", "read_invoices")
headers = {"Authorization": f"Bearer {token}"}
response = requests.get(f"https://api.stripe.com/v1/{endpoint}",
headers=headers, params=params)
response.raise_for_status()
return response.json()The broker service itself would validate the agent ID, check policies, fetch the master secret from Vault, and mint a short-lived token using the target API’s OAuth or token generation mechanism.
When to Proxy vs. When to Issue Tokens
Some brokers don’t just issue tokens. They proxy the actual API calls. The agent sends requests to the broker, and the broker forwards them to the target API using the master credential.
Proxy model benefits:
- Agent never touches credentials at all
- Broker can inspect and filter requests in real time
- Easier to enforce rate limits and block suspicious calls
Proxy model costs:
- Broker becomes a bottleneck
- Adds latency to every API call
- Broker needs to understand every API’s request/response format
For high-throughput agents (e.g., trading bots making hundreds of API calls per second), proxying is too slow. Token issuance is faster but requires the agent to handle credentials correctly.
Rotation and Revocation
The broker can rotate master credentials without the agent knowing. If the Stripe API key changes, the broker updates its secrets store and starts issuing tokens derived from the new key. The agent doesn’t need to be redeployed.
Revocation is trickier. If you detect that an agent is compromised, you can stop issuing new tokens. But tokens already issued remain valid until they expire. If you need instant revocation, you need one of these:
- Short TTLs: 1-minute tokens mean compromise window is small, but agent requests credentials constantly.
- Token introspection: The target API checks with the broker on every request to see if the token is still valid (adds latency).
- Proxy model: Broker can block requests immediately, even with valid tokens.
Technical Verdict
Use credential brokering when:
- Agents access financial APIs, customer databases, or other high-value resources.
- You need an audit trail of which agent accessed which credential and when.
- You’re running multi-agent systems where different agents need different scopes.
- You want to rotate credentials without redeploying agents.
Skip it when:
- The agent only accesses low-risk, read-only data.
- You’re prototyping and need fast iteration (brokering adds operational overhead).
- Your orchestration framework already has built-in credential management (some do).
- Latency is critical and you can’t afford the broker round-trip on every tool call.
The pattern is most valuable when agents move from demos to production workflows involving sensitive resources. If your agent can move money, read PII, or modify production infrastructure, the broker is worth the complexity.
Source Links
- Credential Brokering for AI Agents, Explained (Infisical)
- HashiCorp Vault Documentation (Secrets storage and dynamic credential generation)
- AWS Secrets Manager (Managed secrets service with rotation)
- Open Policy Agent (OPA) (Policy engine for scope validation)
- Cedar Policy Language (AWS-backed authorization policy framework)