SuperToolkit is stk, a credential broker for agents. Its one invariant is in the README: “The agent never holds, reads, or receives a credential.” An agent asks for an effect by name, and the broker applies the secret on the way out, where the agent cannot reach it.
The usual way to give an agent a tool is to put an API key in an MCP config file. That file is plaintext, the agent reads it to start the server, and so the key ends up in the agent’s context and its transcripts. I ran into this when I wanted an agent to post to X and had to decide where a write-scoped token should live. The answer was: not with the agent. I wrote more about it in People retain authority.
How it works:
- The broker runs as its own OS user. Clients start with
HTTPS_PROXYpointing at it and a placeholder likeGH_TOKEN=stk:ref:github:v1, which means nothing off that host. - On the wire it substitutes a token, re-encodes a Basic header, signs with SigV4, mints a JWT or refreshes an OAuth grant. Three of those five operations never send a long-lived secret.
- Policy fails safe: reads are agent-callable, writes need approval, anything unclassified counts as a write, and
denyis a floor no profile can lift. - The audit log is append-only and records a fingerprint, never the value.
The README is direct about limits. A client that ignores proxy settings bypasses the broker silently, so stk doctor --probe tests each client before you trust it. Brokered mTLS doesn’t work, and on Linux the store key usually sits in a file beside the ciphertext. For now you build it from source.