AgySecretVault
Agents never hold the real API key. Each agent gets a short-lived session handle that only works through the fleet's reverse proxy, only for the services it is allowed to call, and only until it expires. The proxy checks the handle and adds the real key on the way out. If an agent leaks its handle into a log or a prompt, the handle is useless to anyone else.
Claimed by the proposal, not verified
- "Zero-leakage". A proxy removes keys from agents, but the proxy itself now holds every key, so it becomes the thing to protect. Leakage is reduced, not zero.
- "Multi-tenant". The brief gives no detail on tenant isolation. The demo uses one scope list per agent.
Issue a handle
Active handles
| Handle | Agent | Scope | Expires |
|---|
Make a call through the proxy
How this maps onto the fleet
Today a key in an agent's environment file can end up in a log, a transcript, or a model's context. With this pattern the keys live only on the proxy (e.g. Caddy or nginx with a small auth hook, or an off-the-shelf broker such as HashiCorp Vault, Infisical or a cloud secrets manager). A first version is a day or two of work: one proxy on one VPS, one key per upstream, handles stored in Redis with a TTL, and an audit log of every call.
The demo's handles are random strings. Real handles should be signed (HMAC or JWT) and bound to the calling agent's network identity so a copied handle can't be used from another machine.
What to try
- Issue a handle for Claude with only gmail allowed, then call api.openai.com. The proxy refuses: out of scope.
- Call an allowed service and look at the log: the agent sent a handle, the upstream received the real key, and the agent never saw it.
- Use "Attacker replays a leaked handle". It fails because it doesn't come from the agent's network address.
- Advance the clock past the lifetime and try again: expired. Then revoke everything for an agent in one click.