Published November 4, 2026 · Announcement: November 3, 2026
Supabase now accepts Claude-issued identity grants for enterprise-managed MCP access. Supabase's side is generally available for Team and Enterprise organizations with SSO. Claude auto-connect remains a beta for Claude Team and Enterprise.
The August 24 launch already introduced administrator-approved MCP access using identity-provider-issued grants.
What the connection still requires
The Supabase guide requires configured SSO, a previous SSO login by each member and matching email addresses. An owner or administrator must authorize Claude. Register Claude’s URL under ID-JAG Issuer. Each issuer URL serves only one Supabase organization. An ID-JAG, or Identity Assertion JWT Authorization Grant, yields a short-lived token with the member's existing permissions.
Anthropic's documentation says Claude checks membership and email, not IdP authentication, MFA or the connected service's login rules. Claude-issued auth itself does not require SSO; provider-specific requirements still apply.
Two decisions before switching
Supabase trusts one issuer per SSO provider. Replacing the IdP issuer with Claude means rejecting IdP-signed grants, potentially interrupting other AI tools.
For offboarding, remove the person from both Claude and Supabase. Suspending the IdP account alone is insufficient. Already-issued tokens remain valid until expiry, so removal is not an immediate token kill switch.
With SCIM directory sync, Claude removes members after directory deletion, but not merely suspension or an inactive flag. Anthropic also warns against reusing email addresses before removing the old accounts from connected services.
A practical rollout review
The following is our editorial checklist, not an additional vendor requirement. Treat the change as an administrative decision with named owners and an acceptance record. A successful connection is useful evidence, but it cannot answer every question about how your organization intends to manage access.
- Write the objective first. Identify the team, the work it needs to perform and the information it should reach. Ask the service owner to approve that description before choosing implementation settings. This gives reviewers something concrete against which to judge the result.
- Separate the people doing the checks. Have an operator perform the configuration and another reviewer inspect the resulting access. Use ordinary test identities rather than only administrator accounts. Record expected refusals alongside expected successful requests, and investigate any difference.
- Rehearse the handover. Run a tabletop exercise involving IT, the application owner and whoever handles employee departures. Give each person a specific step, evidence to collect and an escalation contact. Include a case where the departure happens outside normal support hours.
- Prepare a reversible rollout. Document the previous configuration, dependencies and rollback owner before making changes. Keep the first group small enough to support directly. Define what would stop expansion, then review actual results rather than treating a quiet support queue as proof that everything works.
The useful outcome is a documented decision: who may use the connection, who maintains it and how the organization will verify that access ends when intended. Keep unresolved questions visible before expanding the rollout. Set a review date and store the evidence somewhere the next on-call administrator can find it. A short, maintained record is more useful than a detailed setup document nobody owns.