M7. MCP authorization (OAuth code flow)

[sajeetharan]

Why

Today the MCP server relies solely on origin-header validation and localhost binding — safe for a single-user local machine, but there is no authorization layer. Any remote, hosted, or shared agent deployment (team agent, CI runner, cloud-hosted assistant) currently has no supported way to authenticate a caller. The MCP spec defines an OAuth 2.1 authorization-code flow for exactly this; adopting it unlocks hosted/agentic scenarios without falling back to master keys.

This is the natural companion to confirmation/elicitation (item M3): authorization answers "who is allowed to call," M3 answers "what may they do."

Proposed behavior

• Implement the MCP authorization-code flow for the HTTP transport: advertise the authorization server, validate bearer tokens on each request, and map the authenticated identity onto the shell's existing Entra/RBAC connection so tool calls run with least-privilege, per-caller credentials rather than a shared session.
• Keep localhost/no-auth as an explicit opt-in for the current single-user experience.

Acceptance criteria

• Unauthenticated remote requests are rejected.
• A client can complete the authorization-code flow and call tools with a bearer token.
• Identity flows to the Cosmos/ARM credential.
• Localhost no-auth mode preserved behind a flag.
• Threat model + docs/mcp.md updated.

---

Filed from the Agentic & Automation Roadmap (docs/agentic-roadmap.md), item M7, Wave 2. Priority P1.

[0xbrainkid]

This is the right boundary to draw for hosted MCP. One test case I would add to the threat model: authenticated caller identity should survive the hop from MCP authorization into Cosmos/ARM authorization without becoming a shared shell/session identity.

A useful acceptance criterion might be:

• two different authorized callers hit the same hosted MCP server
• each receives a different effective principal in Cosmos/ARM audit logs
• a token minted for one resource/audience cannot be replayed against another MCP resource
• localhost no-auth mode cannot be reached from a non-loopback bind unless explicitly enabled

That keeps OAuth as authorization, while preserving the audit subject that downstream data-plane policy needs. It also leaves room for agent identity/verifier layers above this, without requiring the shell to decide reputation or trust score itself.

[mkrueger]

I would close that

Current MCP is loopback-only and inherits the shell user’s Cosmos credentials.
OAuth, per-caller identity propagation, and remote hosting would introduce a substantially different security and deployment model.

Any opinions?