|
|
MCP Server Authentication and API Keys
Author: Venkata Sudhakar
An unsecured MCP server exposes its tools to any process that can launch it. In production, MCP servers that access sensitive data - customer records, financial systems, or internal APIs - must authenticate callers before executing any tool. The standard pattern is API key authentication: the server reads an expected key from an environment variable and rejects requests that do not present the correct key.
When using stdio transport, the ADK agent passes credentials to the MCP server via environment variables set in StdioServerParameters. The server validates the key on startup and on each tool call. For HTTP/SSE transport, the key is passed as a request header. This keeps credentials out of the agent instruction and out of the conversation history entirely.
The below example shows a ShopMax India MCP server with API key authentication and an ADK agent that supplies the key securely via environment variables.
Connect the ADK agent, passing the API key via environment variable,
It gives the following output,
Q: Get the profile for customer CUST-001.
A: Customer CUST-001: Priya Sharma, Mumbai.
Membership Tier: Gold | Wallet Balance: Rs 15,000.
Q: List all Gold tier customers.
A: ShopMax India Gold Tier Customers:
1. CUST-001 - Priya Sharma (Mumbai) - Balance: Rs 15,000
Never embed API keys in the agent instruction string - they appear in logs and conversation history. The pattern above passes the key only via the env parameter of StdioServerParameters (subprocess env) and as a tool argument. In production, load the key from Google Cloud Secret Manager at startup rather than from an environment variable: this gives you key rotation, audit logs, and access controls without redeploying the server. Rotate MCP API keys on a schedule and invalidate old keys immediately if a server is compromised.
|
|