What changed
On August 24, 2026, Supabase added enterprise-managed authentication for its hosted MCP server on Team and Enterprise plans with SSO. An organization owner can authorize an MCP client for the organization, while an identity provider such as Okta supplies an ID-JAG under the MCP Enterprise-Managed Authorization extension. The client exchanges that identity assertion for a short-lived, non-refreshable Supabase token. Individual users no longer need to separately approve the client, but every MCP request still runs with the authenticated member’s existing Supabase organization, project and role permissions. Removing the organization authorization or offboarding a user at the identity/organization layer revokes access without rotating a shared MCP credential.
Why it matters
Connecting an AI client to a database platform is a high-impact permission decision: Supabase MCP includes tools that can inspect schemas and logs and, depending on configuration, execute SQL, apply migrations, deploy functions or manage projects. Enterprise-managed authorization replaces a sprawl of individual approvals or long-lived personal tokens with an identity-linked control plane. For platform teams, that makes MCP access easier to onboard and revoke without giving every AI client a new authorization model. It does not make MCP inherently safe: the user’s existing permissions still define what the agent can do, and Supabase continues to recommend development projects, read-only mode and tool scoping where possible.
The organization approves the client once
Without enterprise-managed authentication, each employee authorizes an MCP client individually against Supabase. Under the new model, an organization owner explicitly authorizes the client in Supabase while the organization’s identity provider establishes the user’s identity. Employees can then access the approved MCP client through the same enterprise SSO they already use.
The token exchange preserves the individual user boundary
Supabase implements the MCP Enterprise-Managed Authorization extension using an Identity Assertion JWT Authorization Grant. The MCP client obtains an ID-JAG from the identity provider through an RFC 8693-style token exchange and presents it to Supabase. Supabase verifies organization membership, the matching SSO identity and the organization-level client authorization before issuing a short-lived access token. That token cannot be refreshed and cannot grant more access than the member already has.
Offboarding and revocation move back to normal identity operations
An administrator can revoke the approved MCP client for the whole organization from Authorized Apps, while removing or changing an employee’s Supabase/SSO access changes what that individual can reach. This is operationally important because an organization does not have to find and rotate developer-created MCP tokens during offboarding or incident response.
Existing permissions are both the strength and the risk
The new authorization layer prevents the AI client from exceeding the authenticated user’s normal permissions, but a highly privileged developer can still expose highly privileged actions to an agent. Supabase MCP includes database, account, Edge Function and other tools. Teams should combine SSO-managed authorization with read-only/project scoping, restricted feature groups, non-production data and ordinary human tool approvals rather than treating SSO as an agent-safety boundary.
This differs from network and IDE MCP governance
Other MCP governance approaches focus on allowlisting servers in an IDE or forcing network traffic through a controlled gateway. Supabase is enforcing authorization at the service itself, linking a known enterprise identity and an approved client to the user’s existing platform role. Those controls are complementary: client/network policy controls which MCP paths may be used, while server-side enterprise authorization controls who the upstream service actually lets act.