Credential Brokering
The gateway holds each tool's credential and attaches it to the outbound call, so an AI agent never possesses a production secret. By default an agent must carry a tool's API key or token in order to call it, which turns every agent into a copy of a live secret. Credential brokering reverses that: the credential lives only on the gateway, is stored encrypted, and is injected at the moment the call is forwarded. A complementary capability alongside the seven-check IntentGate authorization pipeline.
Every agent, sub-agent, prompt, and log holds a copy of the tool's real credential. A single compromised agent leaks a live production secret.
The credential lives only on the gateway. Agents carry a short-lived capability token, never a tool secret, so there is nothing to leak.
The problem with agents holding secrets
To call a tool, an agent normally needs that tool's credential. In an agentic deployment that credential is copied into every agent, every sub-agent, and often into prompts, memory, and logs along the way. Each copy is a place the secret can leak. A single compromised or prompt-injected agent hands an attacker a valid production credential, and from that point the attacker authenticates as the agent to the real tool with nothing standing in the way.
The blast radius is rarely reviewed. A typical agent service identity holds credentials roughly equivalent to a senior engineer with cross-system access, distributed across processes that were never designed to be secret stores.
How IntentGate brokers credentials
With brokering enabled, the agent authenticates only to the gateway, using a short-lived capability token. It never receives the tool's real credential. When a call passes the authorization checks, the gateway attaches the tool's secret to the outbound request and forwards it. The tool sees a correctly authenticated call; the agent never saw the key.
There are two ways to supply the credentials, and they can be combined:
Console-managed, per tool
Each tool's credential is entered once in the console and stored encrypted with AES-256-GCM in PostgreSQL. The key is derived from the gateway master key, or set explicitly as a dedicated 64-hex-character key. Add, replace, or remove credentials live; the gateway picks up changes with no restart, so rotation is an operator action, not a redeployment. Every replica in a highly available deployment reads the same store.
Static, by environment variable
When no database is present, a fixed set of credentials is provided to the gateway by environment variable: a single upstream header for a one-credential deployment, or a per-tool JSON map. Not editable from the console, but it covers the simplest single-node case and the local lab.
Defence in depth against bypass
Routing agents through the gateway is the primary control that makes IntentGate the only approved path to the tools. Credential brokering is a second, independent layer. Because the tool secret exists only on the gateway, an agent that somehow reaches a tool directly, a misconfigured network path, a forgotten egress route, still cannot authenticate to it. Bypass has to defeat both the network segmentation and the absence of a credential, not just one of them.
Central rotation
When a tool credential must be rotated, it is changed in one place. Operators replace the value in the console; the gateway begins injecting the new secret on the next call, across all replicas, with no change to any agent. Agents hold capability tokens, not tool secrets, so the two lifecycles are decoupled: rotate the tool credential without touching the fleet, revoke an agent's capability without touching the tool.
What credential brokering does and does not do
Brokering removes the tool secret from agents; it only delivers that benefit if the credential is genuinely removed from the agent side. Leaving the same secret in both the agent and the gateway provides no security gain. Brokering also does not replace a secrets manager: the gateway can source a brokered credential from Vault or a cloud secrets store, and brokering governs the last step, where the secret meets the outbound call, so the agent is never in possession of it.
Related capabilities
Credential brokering pairs naturally with capability tokens (agents authenticate with these instead of tool secrets) and with the bypass-prevention guidance on the Agent Runtime Authorization page. See the Standards Alignment page for how least-privilege secret handling maps to common compliance frameworks.
Frequently asked questions
How is this different from a secrets manager?
A secrets manager stores secrets and hands them to a caller, which then makes the request, so the agent still holds the secret at call time. Credential brokering keeps the secret on the gateway and injects it onto the outbound call itself, so the agent never receives it. They are complementary: the gateway can retrieve a brokered credential from your secrets manager, but the agent is never in possession of it.
Where are the credentials stored?
Per-tool credentials managed from the console are encrypted with AES-256-GCM and stored in PostgreSQL. The encryption key is derived from the gateway master key by default, or set explicitly as a dedicated 64-hex-character key. A static set can also be supplied by environment variable when no database is present.
Does it work in a highly available deployment?
Yes. Console-managed credentials live in the shared database, so every gateway replica reads the same values and a rotation applies fleet-wide on the next call.
See it in the live demo → Try the interactive scenarios on the demo page, including how a brokered call reaches a tool without the agent ever holding the secret.