Only a scoped token
The agent presents a signed capability token. Scope and expiry come from the verified payload, never from an untrusted header.
Agents never hold upstream service credentials—the gateway brokers them. The agent presents a signed, scoped, short-lived capability token, and the gateway attaches the real service credential on the upstream call from its own secret store. The agent receives none of it.
The agent’s claim is a scoped token. The real secret is added only at the boundary, on the outbound call, and never travels back to the agent.
The real credential stays in a gateway-side secret store. The trust boundary between the agent and the tool server is exactly this swap.
The agent presents a signed capability token. Scope and expiry come from the verified payload, never from an untrusted header.
The real service credential is read from Kubernetes Secrets, HashiCorp Vault, or AWS Secrets Manager, held on the gateway side.
The real credential is attached on the outbound call and forwarded to the tool server. It is never returned to the agent.
Brokering moves the secret to the boundary; it does not hand the agent a longer leash.
A compromised or hijacked agent has a scoped token, not the upstream secret. It cannot exfiltrate a credential it never held.
The real credential lives in the gateway-side secret store and is used only on the upstream call. It does not flow back across the boundary.
Brokering reads from Kubernetes Secrets, HashiCorp Vault, and AWS Secrets Manager. We do not claim integrations beyond those.
Your secret store remains the source of truth. IntentGate attaches the credential at the boundary after the token verifies; it does not replace secrets management.
Each control sits on the same MCP firewall decision path. Explore the neighbouring runtime capabilities.