---
title: "Enterprise-Managed Authorization for Statsig MCP"
description: "Connect Claude to Statsig MCP through an identity provider your organization controls, using either Claude-issued identity or Okta OIDC Cross App Access."
product: general
lang: en
token_estimate: 2499
---
# Enterprise-Managed Authorization for Statsig MCP

> For AI agents: a documentation index is available at [/llms.txt](/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`.

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](https://docs.statsig.com/integrations/mcp/manual-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](https://docs.statsig.com/access-management/sso/okta_sso). 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:

1. In the Statsig console, open the project you want Claude to connect to.
2. Go to _Settings > Info > Organization_, which holds the organization name, SSO configuration, and access management settings.
3. 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.
4. 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.

> **Warning:**
>
> 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.

1. 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`.
2. 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.
3. In Statsig, go to _Settings > Info > Organization_, select **Claude-issued identity**, and copy/paste the issuer into **Trusted issuer URL**.
4. Set **Maximum MCP access** to either **Read only** or **Read and write**.
5. Turn on **Enable enterprise managed auth**, then click **Save**.
6. Re-open the MCP enterprise managed auth modal, find the Connect Statsig section, and copy the **Tenant ID**.
7. 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.
8. 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 |

1. Configure OIDC SSO for the Statsig organization with the [Okta SSO guide](https://docs.statsig.com/access-management/sso/okta_sso), and record its exact issuer.
2. 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.
3. 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](https://developer.okta.com/docs/guides/xaa-agent-to-app/main/).
4. 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.
5. Re-open the MCP enterprise managed auth modal, find the Connect Statsig section, and copy the **Tenant ID**.
6. 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.
7. 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. |