AI Agents

Pincer-MCP proxy tokens: keep real API keys out of agent memory while preserving MCP tool access

Sahil Kathpal

• 3 min read

Agents often need credentials to be useful. They also read files, execute tools, and ingest untrusted content. That combination makes plaintext API keys in .env files, shell profiles, and agent config a poor default. Pincer-MCP takes a proxy-token approach: the agent receives a limited token, while real API keys stay behind a gateway.

The short version

  • Do not give an agent long-lived provider keys if a narrower credential will work.
  • Proxy tokens reduce blast radius because the agent can use a capability without reading the underlying secret.
  • This pattern complements MCP permissions; it does not replace tool allowlists, approval flows, or network controls.
  • Validate current Pincer-MCP behavior from its repository before production use; some public descriptions come from listings and launch posts.

The credential problem in agent workflows

A coding agent with workspace access can often read the same files you can: .env, ~/.config, shell history, npm tokens, cloud credentials, and MCP server configs. If a prompt injection convinces the agent to “debug” by printing or forwarding those values, traditional secret storage has already failed at the agent boundary.

Secret managers help when applications fetch credentials at runtime under narrow identities. But a local desktop agent often still needs some credential to talk to the secret manager, provider, or MCP server. If that credential is readable by the agent, it can be exfiltrated.

Pincer-MCP’s published design is a gateway: store real credentials outside the agent, issue the agent a proxy token, authorize which tools or providers that proxy token can use, and exchange the token for real credentials only inside the gateway path.

How proxy-token architecture helps

The useful security property is not that a proxy token is magical. It is that the token can be scoped, rotated, audited, and revoked separately from the real provider key.

A typical flow looks like this:

  1. Operator stores a real API key in the Pincer-managed vault or OS-backed storage.
  2. Operator registers an agent identity.
  3. Pincer issues a proxy token such as pxr_....
  4. The MCP client or agent is configured with only the proxy token.
  5. On a tool call, Pincer checks whether that proxy token may perform the requested action.
  6. Pincer calls the upstream provider with the real credential and returns the result.

The agent never needs to see the upstream key. If the proxy token leaks, you revoke it and inspect its audit trail. You should still assume leakage is bad, but it is less bad than leaking a provider root key used by humans, CI, and production systems.

Configuration pattern

Keep the agent config boring:

{
  "mcpServers": {
    "pincer": {
      "command": "pincer-mcp",
      "args": ["serve"],
      "env": {
        "PINCER_PROXY_TOKEN": "pxr_agent_local_dev_..."
      }
    }
  }
}

Then enforce policy in the gateway, not in the prompt:

agents:
  local-coder:
    token: pxr_agent_local_dev_...
    allow:
      - provider: openrouter
        models: ["anthropic/claude-sonnet-4.5"]
      - tool: gpg.sign
        require_approval: true
    deny:
      - provider: billing
      - tool: export_all_keys

Treat this as a shape, not exact Pincer syntax unless confirmed against the version you install.

What to scope

Start with these dimensions:

  • Provider or upstream service.
  • Model or endpoint.
  • Read versus write capability.
  • Maximum spend or request count.
  • Workspace, tenant, or repo.
  • Time-to-live.
  • Allowed MCP tools.

For model providers, a proxy token might be allowed to call only selected models with a cost ceiling. For signing tools, require a human approval for each signature. For SaaS APIs, issue separate tokens for read-only documentation lookup and write-capable operations.

Operational checklist

Before adopting a proxy-token gateway, verify:

  • Where real credentials are stored and encrypted.
  • Whether the agent process can read the vault files or keychain entries directly.
  • How proxy tokens are revoked.
  • Whether audit logs include agent identity, tool name, upstream provider, timestamp, and verdict.
  • Whether failed policy checks fail closed.
  • How secrets are scrubbed from logs and error messages.
  • Whether the gateway itself can be network-isolated from the agent.

The gateway becomes sensitive infrastructure. Run it with least privilege. Do not mount your whole home directory into it. Do not log upstream Authorization headers. Back up only encrypted state.

Tradeoffs

Proxy tokens add a hop. They can break provider-specific SDK features if the gateway does not implement them. They also centralize trust: a compromised gateway can use the real credentials it protects.

They also do not stop an authorized bad action. If the proxy token can call delete_project, a prompt-injected agent can still ask for that call unless policy or approval blocks it. Pair proxy tokens with MCP call policy, egress controls, and human review for irreversible operations.

If you want that separation in day-to-day agent work, we have been building Grass: a way to run coding agents on a managed VM or your own machine, then control them from your phone. That pairs cleanly with proxy tokens: put only delegated credentials on the agent host, keep real provider keys behind a gateway, and use the Grass app to approve tool requests and review diffs while execution stays on the selected machine.

Try it at https://codeongrass.com.

Conclusion

Pincer-MCP’s core idea is sound: agents should hold delegated capabilities, not raw long-lived secrets. Use proxy tokens for local agents and MCP tools when you need API access but do not want keys in model context, files, or environment variables. The win is smaller blast radius, cleaner revocation, and a better audit boundary.

Sources

  • Pincer-MCP public server listing and launch discussion
  • MCP official tools specification
  • Descope MCP vulnerability guidance on scoped credentials