Enterprise-Managed Authorization for Statsig MCP

Connect Claude to Statsig MCP through an identity provider your organization controls, using either Claude-issued identity or Okta OIDC Cross App Access.

Enterprise-managed authorization (EMA) lets an admin configure Claude's connection to Statsig MCP centrally. Members don't supply a personal Console API key or approve the connection themselves. Claude acts as the person already signed in, and Statsig still applies that person's organization membership, project permissions, and review requirements.

Use enterprise-managed authorization when your identity provider decides who can open Claude against Statsig. Use the standard MCP setup when each person authenticates their own connection.

Statsig supports two identity modes, and you pick one per organization:

Identity mode	Trusted issuer you enter in Statsig	Statsig SSO required
Claude-issued identity	The organization-specific issuer Claude shows during setup, such as `https://identity.anthropic.com/issuers/<tenant>`	No
Okta / OIDC Cross App Access	The exact Okta issuer your Statsig OIDC SSO configuration already uses	Yes, though `Strict SSO` remains optional

You configure issuer trust once for a Statsig organization. Each Claude connection then targets a single Statsig project, which you identify with that project's Tenant ID.

Prerequisites

You have the Owner or Admin role in the Statsig organization you're configuring, and you can manage connectors in Claude. Okta mode also needs an Okta administrator.
Your projects belong to a Statsig organization. Organizations are an Enterprise feature, and EMA is an organization setting.
Each member has a Statsig account with a verified email and access to the target project. EMA doesn't provision Statsig users, and the email your identity provider asserts must match the member's verified Statsig email.
For Okta mode only, your organization already has OIDC SSO configured with Okta. The issuer you enter for EMA must match that configuration exactly.

Find your Tenant ID

Both identity modes need the target project's Statsig project ID, which Claude calls the Tenant ID. Copy it before you start:

In the Statsig console, open the project you want Claude to connect to.
Go to Settings > Info > Organization, which holds the organization name, SSO configuration, and access management settings.
Under Access Management > MCP Enterprise Managed Auth, select Enable (Click Configure if you're already Enabled) and then turn on Enable enterprise managed auth and then click Save. You must first enable EMA before you can access the Tenant ID, issuer, and access fields.
Click Configure again and then, in the Connect Statsig section, copy the Tenant ID (project ID) value and the MCP URL, https://api.statsig.com/v3/mcp.

Statsig shows Configure whether or not SSO is enabled, because Claude-issued identity doesn't require SSO. Only the Okta option stays disabled until you configure SSO.

The Tenant ID must be the target Statsig project ID. A Statsig organization ID, an Okta client ID, or a Claude tenant ID doesn't resolve, and a blank field breaks the connection.

Confirm that the dialog names the organization you intend to configure before you save.

Set up Claude-issued identity

Claude-issued identity works without Statsig SSO, so it's the shorter path.

In Claude's organization connector settings, add or select the Statsig connector and open its managed-authorization setup. To add a custom connector, use https://api.statsig.com/v3/mcp.
Select Claude-issued identity, then copy the exact issuer Claude shows for your Claude organization. A generic https://claude.ai URL or another organization's issuer doesn't work.
In Statsig, go to Settings > Info > Organization, select Claude-issued identity, and copy/paste the issuer into Trusted issuer URL.
Set Maximum MCP access to either Read only or Read and write.
Turn on Enable enterprise managed auth, then click Save.
Re-open the MCP enterprise managed auth modal, find the Connect Statsig section, and copy the Tenant ID.
Back in Claude, paste the Statsig project's Tenant ID into the Tenant ID field, select the roles and scopes you want to permit, then run the connection test.
Finish setup after the test passes, then confirm the connection resolves to the right project.

If Claude doesn't offer Claude-issued identity, ask your Claude administrator to enable it before you continue.

Set up Okta / OIDC Cross App Access

Okta mode reuses the identity provider your members already sign in with. It requires an existing Statsig OIDC SSO configuration, but it doesn't require Strict SSO, the setting that forces every member except the Owner to sign in through your provider.

Four values look similar and cause most setup failures when they're interchanged:

Field	Value
Statsig Trusted issuer URL	Your exact Okta SSO issuer, using the org authorization server
Okta resource app Issuer URL	The Statsig authorization-server issuer from the connector's discovery information
Okta resource app Audience/tenant ID	Your Statsig project ID, copied from the EMA dialog
Agent/client registration	Claude's registration details, not Statsig's login-app credentials

Configure OIDC SSO for the Statsig organization with the Okta SSO guide, and record its exact issuer.
In Okta, register and activate Claude's AI agent against the app your members use to sign in to Claude, following the setup guide Claude supplies. A Claude SAML login can take part in this flow, but it doesn't replace Statsig's separate OIDC SSO prerequisite.
Configure the Statsig resource app for Cross App Access, then connect the Claude AI agent to it with the scope policy you want. For the Okta-side steps, refer to Okta's Cross App Access guide.
In Statsig, go to Settings > Info > Organization, select Okta / OIDC Cross App Access, enter the matching Okta issuer, set Maximum MCP access, turn on Enable enterprise managed auth, then save. The signed assertion must contain the user's email.
Re-open the MCP enterprise managed auth modal, find the Connect Statsig section, and copy the Tenant ID.
In Claude, paste the Statsig project's Tenant ID into the Tenant ID field, select the permitted roles and scopes, sign in through the linked Okta app, then run the connection test.
Finish setup after the test passes, then confirm the connection resolves to the right project.

Keep the Claude requesting app and the Statsig login and resource apps separate. Don't reuse a shared app's credentials or change an existing SSO integration to make a test pass.

Set read-only or read/write access

Three controls decide what Claude can do: Statsig's maximum MCP access, the scopes and roles you select in Claude, and, for Okta mode, the resource app and agent connection policy. Align all three.

Intended access	Statsig maximum	Claude scope selection	Okta policy
Read only	Read only	`personal_read_only` only	Allow `personal_read_only`
Read and write	Read and write	Include `personal_read_write`	Allow `personal_read_write` and every other scope Claude requests

The scopes the server advertises are the capabilities it supports, not the permissions every organization grants. Write access still depends on each member's existing Statsig permissions: selecting read and write doesn't elevate a role or bypass a review.

If Claude requests both scopes while your identity provider allows only read-only, Okta returns invalid_scope. Continue through setup to reach Claude's scope controls, remove the write scope, then rerun the test. Check that the requested scopes contain only what you intend. Don't widen the identity provider policy to pass a read-only test.

Verify the connection

A successful setup completes discovery, identity assertion, access-token exchange, and the connector probe. Test labels vary by Claude version.

To confirm the connection resolved to the right project, ask Claude:

Use the Statsig connector to show the connected project name and my access level. Do not make any changes.

Check that Claude names the project and organization you configured. A read-only connection reports personal_read_only and no write access. Test writes separately, in a dedicated test project, with an authorized user.

Troubleshooting

Problem	What to check
The Okta option is disabled in Statsig	Configure OIDC SSO for the organization the dialog names. `Strict SSO` is optional.
`invalid_scope` when requesting identity	Compare the scopes Claude requests against the scopes Okta allows, and narrow Claude's selection for a read-only policy.
`invalid_subject_token_no_delegation_link`	Confirm the active agent links to the app used for Claude SSO and has the intended resource connection, then reauthenticate.
Identity succeeds, but the exchange returns `invalid_grant`	Check that EMA is enabled for the organization, the issuer matches exactly, the Tenant ID is the target project ID, and the member has a verified email and project access. Read the server error before assuming one cause.
The exchange returns `503 server_error`	Investigate authorization-server health. A `503` isn't evidence that scopes or SSO settings need to change.
The login redirect doesn't match	Check which console environment and callback the login app allows. Diagnose a redirect mismatch separately from EMA token exchange.

Was this helpful?