Secrets Broker

The secrets broker manages credentials so that agents never handle raw API keys, tokens, or passwords. It intercepts outbound requests at the sandbox boundary and injects credentials on the agent’s behalf.

How it works

1. An agent makes an outbound HTTP request via the http_fetch capability.
2. The broker checks the request URL against the configured endpoint allowlist.
3. If the endpoint is allowed and has a secret_env_var configured, the broker reads the credential from the environment variable and injects it into the request headers.
4. If the endpoint is not on the allowlist, the request is denied and the agent receives a deny receipt explaining why.

The agent never sees the credential value. It only knows whether the request succeeded or was denied.

Endpoint allowlist

Each allowed endpoint is defined by:

• Domain: the exact hostname (e.g., api.anthropic.com).
• Path prefix: optional path binding (e.g., /v1/messages).
• secret_env_var: the environment variable holding the credential.

Requests to endpoints not on the allowlist are blocked by default.

Security protections

The broker includes defenses against common credential-exfiltration attacks:

• DNS rebinding protection: the broker resolves DNS and verifies the IP has not changed between resolution and connection.
• IPv4-mapped IPv6 normalization: prevents bypassing allowlist checks via ::ffff: mapped addresses.
• Deny receipts: every blocked request generates a structured deny receipt with the reason, so agents and operators can debug allowlist issues.

Why not just pass keys to agents?

Giving agents raw credentials creates a data exfiltration risk — a compromised or misbehaving agent could send credentials to an unauthorized endpoint. The broker eliminates this by keeping credentials outside the sandbox and only injecting them into requests that match the allowlist.