When connecting external tools to an LLM through MCP servers, my first approach was to put API keys in environment variables and let the agent use whatever tools it needed. That works reasonably for a conventional backend, where the code path and credential usage are predictable. With an agent, the model chooses tools dynamically based on the prompt, so the same credential may end up authorizing actions I did not explicitly anticipate.
A secrets vault can control storage and rotation, but it does not decide whether a particular agent, session, tool, or set of parameters should be allowed to use a credential. I keep seeing recommendations to use separate credentials per MCP server and inject them only at runtime.
For people running multi-tool agent systems, what controls are you using? Do you add hard allowlists, proxies, short-lived credentials, or human approval for sensitive actions, or do you treat the MCP layer like a normal backend service?
3 Answers
We moved away from long-lived administrator keys in the agent environment. Instead, an orchestrator issues a short-lived OAuth or JWT-style token for each execution session, scoped to the specific server and operations that session needs. The agent never sees the underlying provider key.
We also put a gateway between the MCP server and the external service. The gateway enforces tool and parameter allowlists, rate limits, and payload validation before adding the real credential. Read-only actions can proceed automatically, while changes to data, spending, or other high-impact resources require confirmation. That way, a prompt injection or hallucinated tool call has a much smaller blast radius.
An environment variable is effectively a capability that anything in that process can spend. We use a separate identity for each MCP server, grant it the minimum permissions required, issue short-lived credentials, and inject them only when a call is made. The vault handles storage and rotation, but authorization has to happen separately.
Read operations can use narrowly scoped identities, while writes go through a deterministic allowlist and, where appropriate, an approval step. Requiring manual approval for every tool call would create too much friction, so we reserve it for genuinely consequential actions.
That distinction between secret storage and call authorization is exactly what I was missing. A vault protects the key, but it does not explain why a particular tool call is permitted.
We treat the agent as an untrusted caller requesting temporary capabilities, not as a trusted backend. At session startup, the runtime leases a scoped credential, and each outbound request is tagged with the session, tool name, and a hash of the arguments for auditing.
The important controls sit outside the prompt: per-role tool allowlists, minimum-permission credentials, approval for destructive operations, and idempotency keys for writes. The adapter rejects calls with expired leases, denied parameters, or disallowed tools before any network request is made. There is some overhead from leasing and request checks, but it is generally small compared with model latency; caching a lease for the session also avoids a full credential exchange on every call.
Short-lived session tokens seem especially useful here. Even if a prompt injection gets a call through, the credential expires quickly and is limited to that session's permissions.