[Security] Enforce scoped MCP token drive boundaries across all hybrid API routes #417

Summary

Scoped MCP token restrictions are not enforced consistently across API routes that allow mcp authentication.

Why this breaks zero-trust

Scoped tokens are supposed to enforce least privilege at drive boundaries. Inconsistent scope enforcement means token trust boundaries depend on which endpoint is called.

Current behavior (evidence)

• Scope policy/helpers are defined in apps/web/src/lib/auth/index.ts (getAllowedDriveIds, checkMCPDriveScope, checkMCPPageScope).
• Some routes enforce scope, for example apps/web/src/app/api/mcp/documents/route.ts (checks token scope before page access).
• Other hybrid routes allow mcp but do not apply MCP scope checks, e.g.:
  • apps/web/src/app/api/tasks/route.ts
  • apps/web/src/app/api/ai/chat/route.ts
  • apps/web/src/app/api/ai/chat/messages/route.ts

Risk / impact

A scoped MCP token may access data outside its intended drive scope through routes that only check user-level permissions and ignore token-level drive restrictions.

Proposed remediation

• Add a mandatory MCP-scope enforcement layer for all session|mcp routes.
• For page-scoped endpoints: call checkMCPPageScope(auth, pageId) once pageId is known.
• For drive-scoped endpoints: call checkMCPDriveScope(auth, driveId).
• For multi-drive list endpoints: apply filterDrivesByMCPScope before query or before response.
• Add regression tests proving scoped token denial on out-of-scope resources.

Acceptance criteria

• A scoped token cannot read or mutate resources outside allowedDriveIds on any hybrid auth route.
• Unscoped MCP tokens and session auth behavior remain unchanged.
• Test coverage includes at least tasks + page AI chat + message history endpoints.