Product Updates

🔐 Entity-Level Create Permissions

Role permissions now extend to creating entities, not just editing and deleting them.

What you can do now

• Control who can create each entity type through role permissions, alongside the entity-level edit and delete permissions already available

Why this matters

You can now decide who is allowed to create new entities, so roles can match how your teams actually work without being over-permissioned.

Try it out

Learn more in the Statsig Access Management docs.

🤖 Statsig MCP v3

The Statsig MCP is now leaner for agents and covers far more of the Console API.

What you can do now

• Work with 18 default tools instead of 93, so agents spend less context on tool definitions and choose the right tool more easily. Additional operations are discovered on demand

• Use api_read, api_write, and api_destructive to discover and run Console API operations across Statsig without needing a dedicated MCP tool for each one

• Manage which users and projects can use MCP with self-serve access controls

Why this matters

Agents work better when they carry fewer tool definitions and can reach more of the platform. V3 gives you both, with governance you control.

Try it out

Learn more in the Statsig MCP Overview.

🎯 Choose Features for Contextual Bandits

You can now specify which context features a cloud contextual bandit trains on.

What you can do now

• Select the features in your context that the ML model should use for training

Why this matters

Not every attribute in your context should drive the model. Choosing the features yourself gives you control over what the bandit learns from.

🧹 Stale Dynamic Config Management

Dynamic configs can live for years without a clear cleanup point. Teams can now find likely cleanup candidates, understand why they were flagged, and decide what to do next.

What you can do now

• Temporary, Permanent, and Stale lifecycle states, with filtering in the Dynamic Config catalog

• Reason-specific guidance on the config page: configs with no recent checks can be archived, while intentionally long-lived configs can be marked Permanent

• A team-defined inactivity window (15, 30, 60, or 90 days; 30 by default)

• Periodic email, in-app, and Slack reminders based on notification preferences

• Lifecycle fields and filters in the Console API

Note: This is advisory only. A stale label does not change evaluation, disable a config, or archive anything automatically. This rollout does not include Feature Gate-only automation such as auto-archive, code-cleanup prompts or PRs, or bulk cleanup.

Why this matters

This closes a governance gap that several customers have raised and makes cleanup easier without introducing runtime risk.

Try it out

Check out the Feature Management page in your Statsig Console to evaluate config staleness.

🔐 Self-Serve RBAC for the Statsig MCP

You can now manage MCP access directly in the console, with project-level and role-level controls.

What you can do now

• Set a project-level MCP scope — No access, Read only, or Read and write — as the ceiling for all roles in that project.

• Configure MCP access per role within that project maximum, including Member and custom roles.

• MCP only exposes tools that the project scope, role permissions, and token scope all allow.

To configure: Go to Project Settings > Roles to set Default Project MCP Scope, then open a role's Permissions > MCP to configure its access.

Why this matters

Before this, teams that wanted to give analysts or stakeholders AI-assisted exploration through the MCP had no way to cap what they could do. Now, you can give some users read-only MCP access for exploration while keeping write access to the people who need it.

Try it out

Go to Project Settings > Roles in the Statsig console to configure MCP access for your team.

Learn more in the Statsig MCP Overview.

🔐 Entity-Level Edit and Delete Permissions

Role permissions now let you control edit and delete access separately for each config type.

What you can do now

Each role can now be configured with independent edit and delete permissions for:

Gates · Holdouts · Dynamic Configs · Segments Experiments · Layers · Autotunes · Parameter Stores · Prompts

Why this matters

Before this, permissioning wasn't specific and allowed for broad experiment and gates access. Now, you can define roles that match how your teams actually own and operate different config types, without over-permissioning anyone.

Try it out

Available now for all Enterprise customers. Go to Settings in the Statsig console to configure granular permissions per role.

Learn more in the Statsig Access Management docs.

🔐 SCIM Role Aliases for Custom IdP Naming Conventions

You can now map your identity provider's role names to Statsig roles without renaming anything in your IdP.

What you can do now

• Create aliases on the Statsig side that translate your IdP's existing role names to first-class Statsig roles. Works with Okta, Microsoft Entra ID, and other SCIM-compatible identity providers with strict or unchangeable naming conventions.

• Self-serve setup in a few clicks. No support ticket or manual intervention needed

Why this matters

Now, SCIM provisioning no longer requires your IdP group names to match an expected role format. You can define the translation on the Statsig side and let provisioning work with whatever names your IdP already uses.

Try it out

Go to Settings in the Statsig console to configure SCIM role aliases for your organization.

Learn more in the Statsig SCIM docs.

🧪 Richer Experiment Configuration via MCP

Create_Experiment and Update_Experiment_Entirely now accept five additional fields, giving you fuller control over experiment setup through the MCP.

What you can do now

Five new fields are now accepted by Create_Experiment and Update_Experiment_Entirely:

secondaryIDType

identifierMappingMode

enabledNonProdEnvironments

links

secondaryMetrics

Why this matters

Now, you can set secondary ID types, identifier mapping, non-prod environments, secondary metrics, and external links without falling back to the console.

Try it out

If you have the Statsig MCP set up, try a prompt like:

"Using the Statsig MCP, create an experiment with a secondary metric of revenue and enable it in staging."

Learn more in the Statsig MCP Overview.

🔭 Pipeline Overview Auto-Provisions for Athena Connections

New Athena Warehouse Native projects now get the Pipeline Overview dashboard set up automatically on connection creation.

What you can do now

• Get the Pipeline Overview dashboard, metric source, and pipeline table created automatically when setting up a new Athena connection

• No manual repair or setup step needed to get DAG and pipeline visibility from day one

Why this matters

Before this, new Athena projects skipped the Pipeline Overview provisioning step entirely, leaving teams with no pipeline observability until someone ran a manual repair. Now, you get full pipeline visibility out of the box from the moment your connection is created.

Try it out

Create a new Athena Warehouse Native connection in the Statsig console to see the Pipeline Overview dashboard provisioned automatically.

Learn more in the Statsig Warehouse Native docs.

🩺 Experiment Daily Checks Now Available via Console API

You can now pull the data behind the Daily Checks column in the experiment list directly over the API.

What you can do now

One new endpoint is available on statsigapi.net/console/v1/:

GET /console/v1/experiments/{id}/diagnostics_checks?lastDays=30

• Use lastDays (1-90) to set a lookback window without computing dates yourself

• Use startDate / endDate if you need an explicit range instead

• is_realtime tells you whether the final day is still filling, so you know not to treat it as a complete day

• Warehouse Native experiments now return real data from the warehouse exposures summary, the same source the console list column uses

Why this matters

Before, the Daily Checks column in the experiment list flagged experiments that were "In Progress" after being pulled from code, or "Decision Made" while still serving traffic and catching those states meant querying your own warehouse. Now, you can surface that signal programmatically and build automated checks or alerts on top of it.

Try it out

Review the full API reference in the Statsig Console API docs.