The MCP Authentication Design

Design authentication and authorisation for an MCP server.

Deployment: [LOCAL / REMOTE / BOTH]
Who connects: [DESCRIBE THE CLIENTS AND THEIR IDENTITIES]
What it protects: [DESCRIBE THE DATA AND OPERATIONS]
Existing auth in our stack: [DESCRIBE]

Work through:
1. What identity the server needs to know about — the end user, the
   application, the agent, or several
2. How that identity reaches the server
3. Authorisation model: what determines whether a given call is
   permitted
4. Credential storage and rotation
5. What must never be visible to the model or reachable from the
   agent's execution context
6. Session and token lifetime
7. What to log for audit
8. Multi-tenancy: how to prevent one tenant's agent reaching
   another's data

CRITICAL: address the confused deputy problem explicitly. The
server acts with its own credentials on behalf of a caller. What
prevents a caller from using the server to do something the caller
is not permitted to do directly?

Mark every protocol-specific mechanism as [VERIFY AGAINST CURRENT
SPECIFICATION]. Auth approaches in this ecosystem are evolving and
I will confirm the current recommendation before implementing.