{
  "id": 10201420,
  "title": "Keep your API keys out of your AI agent: a credential pattern for MCP servers",
  "url": "https://urgent.news/2026/09/27/keep-your-api-keys-out-of-your-ai-agent-a-credential-pattern-for-mcp",
  "topic": "ai",
  "section": "AI",
  "published": "2026-09-27T11:08:31.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/rojaneerdev/keep-your-api-keys-out-of-your-ai-agent-a-credential-pattern-for-mcp-servers-4cmo"
  },
  "original_language": "en",
  "account": "When an MCP server is linked to an agent, you might have implemented something like this: mcpServers: billing: command: npx, args: [billing-mcp], env: BILLING_API_KEY: sk-live-... This approach works, but it exposes your live billing key to the least trusted process in the system. The issue arises because agents decide their actions at runtime based on provided text, which can come from outside sources like webpages or documents. Consequently, the agent process is not the ideal place to store secrets. Two problems emerge with the configuration above: The credential exists in the agent's environment. If the agent is compromised via methods such as prompt injection or a malicious payload from a tool, the attacker can easily access your billing key. The blast radius of the agent's mistake encompasses the agent's keys being compromised. The agent has the capability to execute all tools, and the evidence of what it does cannot be proven. To address this issue, introduce a gateway that acts as a buffer between the agent and the MCP server. The gateway is a small trusted process that holds the credentials, preventing them from residing in the agent's environment. The agent receives a short-lived token and a URL that only reaches the MCP server through the gateway. For each tool call, the gateway injects the actual credential before forwarding to the MCP server and removes it from any response received. By implementing this pattern, the agent is deprived of credentials, and any compromise of the agent results in a revocable token rather than the actual billing key. This pattern offers more than a reverse proxy since the gateway serves as a policy decision point. It allows for enforcing which tools each agent may call, enforcing read-only access when necessary, and logging every call and refusal in a single location that the agent cannot alter.",
  "summary": "If you've wired an MCP server into an agent, you've probably done something like this: { \"mcpServers\" : { \"billing\" : { \"command\" : \"npx\" , \"args\" : [ \"billing-mcp\" ], \"env\" : { \"BILLING_API_KEY\" : \"sk-live-...\" } } } } It works. It's also handing your live billing key to the least trustworthy process in the system. The problem An agent is a program that decides what to do at runtime based on…",
  "key_points": [
    "Introduce a gateway as a buffer between agent and MCP server",
    "Gateway holds credentials, preventing them from residing in agent's environment",
    "Agent receives short-lived token and URL, forwarded through gateway"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}