Credential brokering
Updated 2026-07-11
Questions this answers
- How do I let an AI agent use my real accounts without it seeing my secrets?
- I'm nervous about an agent that could just print my API key.
- How do I limit what an agent can do with the access I give it?
- What's the safe way to give an agent live credentials?
The Fix
If you're giving an agent access to real systems, the scary part is that it can see, and potentially leak, your secrets. Anything it can read, it can print, log, or send somewhere. The pattern that solves this is credential brokering: the agent never actually holds the real key.
Here's the shape of it. The agent runs with only a short-lived token and the address of a proxy. The real API keys live in that proxy, not in the agent's environment. When the agent wants to make a call, it goes through the proxy, which checks whether this action is allowed (often with simple scope patterns like crm.* to mean "anything in the CRM"), and only then adds the real key and forwards the request. The secret gets attached out at the edge, so the agent physically can't read it.
So instead of trusting the agent not to misuse a key it can see, you make sure it never sees the key at all, and you decide up front exactly what it's allowed to touch.
When to Use It
Reach for this when an agent needs to act in real systems that matter: your CRM, billing, production data, anything you'd be unhappy to see leaked or misused. For a local experiment against test data it's overkill. The moment real credentials and real consequences are involved, brokering plus scoped permissions is the safer default.
In the Wild
Breaks down brokering credentials through a scoped proxy so the sandbox never sees the real secret.