supertoolkit

The standard way to give an agent a tool is to put an API key in an MCP config file. That file is plaintext, any process can read it, and the agent reads it to start the server — so the credential ends up in the agent’s own context, and from there in the transcript and wherever transcripts are kept.

supertoolkit holds the credential in a process the agent cannot read, and puts it on the wire on the way out. The agent’s environment carries a placeholder:

GH_TOKEN=stk:ref:github:v1

If the agent reads that, it has read nothing. It means nothing off this host.

Five operations

Substitute a token, substitute inside a Basic header, sign with SigV4, mint a JWT, or refresh an OAuth 2.0 grant. Three of the five never put a long-lived secret on the wire at all.

A read is the agent's

A write needs you. Defaults come from the catalogue and fail safe: anything unclassified is treated as a write, and deny is a floor no profile lifts.

A record that answers

What was done, under which policy, and what the provider said — with a fingerprint where the credential would be, never the value.

Runs on your machine

No account, no telemetry, no update check. The only hosts it contacts are the providers you connect and the token endpoints they publish.

The one failure mode that cannot be fixed

A client that ignores proxy configuration entirely goes around the broker, and fails silently — it sends the placeholder to the provider and gets a plausible 401 back, which reads as a credential problem rather than a routing one.

Nothing inside a proxy can detect a client that never speaks to it. What can be done is detect it from outside, which is what stk doctor --probe is for. Run it before trusting a new client. See Limitations.