PASTKEYS
ARTICLE MCP security

Securing MCP servers' credentials

PastKeys · October 2026

The Model Context Protocol lets an agent call tools, and those tools usually need provider credentials: a GitHub token to open a pull request, a Cloudflare token to change DNS, a database URL to run a query. The common pattern puts those secrets in the MCP server's environment, which means they sit one prompt injection away from the model.

Where MCP leaks credentials

Broker the operation, keep the secret out of MCP

The fix is the same principle PastKeys applies everywhere: the tool should request an authorized operation, not hold the credential. PastKeys ships an MCP server (broker mcp) that exposes pastkeys_authorize and pastkeys_execute as tools. The agent calls them with an operation to perform; the broker checks a default-deny policy, performs the operation with a credential it holds, and returns the result.

With that in place:

Same tools, no secret. Your agent keeps calling tools the MCP way. What changes is that the thing behind the tool is an authorization check, not a stored key.

Practical shape

Run the broker where your MCP server runs, seal the provider tokens to it, and write a policy naming the agent and the operations it may perform. Point the agent at the PastKeys MCP server. The agent asks to "open a pull request on repo X" or "read these DNS records," and the broker does it without ever exposing the token.

See getting started for setup, and why agents should not hold long-lived secrets for the reasoning.

Stop handing agents long-lived secrets.

Create an account Read the whitepaper