Your MCP cache key is part of your authorization model

Caching makes a PostgreSQL MCP server faster.

A weak cache key can also erase the authorization boundary.

Two users may call the same tool with identical arguments while having different tenants, roles, approved views, policies, or environments.

If the key contains only the tool name and JSON arguments, discovery metadata or results can cross scopes.

Start by separating cache classes:

• tool discovery
• schema metadata
• policy decisions
• prepared operation shapes
• database results
• resumable state handles

Then include every attribute that changes what the caller may discover or receive: principal, tenant, execution role, environment, policy version, tool-catalog version, schema version, normalized arguments, and source watermark.

Three details matter in practice:

1. Tool discovery itself can reveal sensitive structure.
2. Single-flight request coalescing must use the same authorization-aware key.
3. A cache hit must preserve freshness, truncation, redaction, and trace evidence.

The negative test is simple: warm the cache, then repeat identical arguments across another tenant, role, environment, revoked approval, and changed schema.

Measure the absence of cross-scope hits—not only the aggregate hit rate.

Full guide: Build an authorization-aware cache for a PostgreSQL MCP server