[FEATURE] Per-user authentication for organisation MCP connectors

Resolved 💬 3 comments Opened Apr 10, 2026 by GBR-Rise Closed Apr 13, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Organisation-level MCP connectors on claude.ai currently use a single shared OAuth token for all
users in the org. This makes it impossible to build user-scoped MCP servers — where the API
returns only the data a given user is authorised to see.

The problem

We built an internal MCP server with user-scoped auth: each user authenticates with their own
credentials, and the API enforces data visibility based on their permissions. This is the correct
security model for a multi-tenant internal tool.

When configured as an org connector on claude.ai, this falls apart completely:

  • All users share one token — whoever re-authenticates last sets the token for everyone
  • If a user without full access re-auths, they break the connector for the whole org
  • There is no way to enforce that each user's requests are scoped to their own identity

Expected behaviour

When a user in an org invokes an MCP connector, claude.ai should authenticate as that user, not as
a shared org identity. The OAuth flow should be triggered per-user, and tokens stored and used
per-user.

Why this matters

This is a hard blocker for any internal tool that has row-level or user-level data access control.
The current model only works for connectors backed by a single service account (public APIs,
shared databases). It cannot support the far more common case of enterprise tools where "what you
see depends on who you are."

Proposed Solution

  • Allow org admins to mark a connector as "per-user auth required"
  • On first use, each user goes through the OAuth flow individually
  • Tokens are stored and refreshed per user, not per org

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

MCP server integration

Use Case Example

  1. We built an internal real estate deal management tool (ValueTrack) with an

MCP server that exposes deal, company, and asset data to Claude.

  1. The MCP server uses user-scoped authentication — each user logs in with

their own credentials, and the API returns only the data they are
authorised to see (row-level access control).

  1. When configured as an org connector on claude.ai, all users in the org

share a single OAuth token. Whoever authenticates last sets the token for
everyone. If a user with limited access re-auths, they break the connector
for the whole org.

  1. This makes it impossible to use claude.ai as a front-end for any

internal tool with per-user data access control. The feature would unblock
this entire class of enterprise MCP integrations.

Additional Context

The current shared-token model works fine for connectors backed by a public
API or a single service account (e.g. weather, search). It fundamentally
cannot support the common enterprise pattern where "what you see depends on
who you are."

Proposed behaviour: org admins can mark a connector as "per-user auth". Each
user goes through the OAuth flow individually on first use. Tokens are stored
and refreshed per user, never shared across the org.

This is consistent with how OAuth is designed to work and how every other
enterprise SaaS handles delegated access.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗