Fighting shadow AI with light(er) MCP governance

AI tech needs good governance.

Just before their Summit event last week, Snowflake announced it was acquiring Natoma, a two-year-old startup that runs governance for AI agents. It wasn’t the flashiest news at Summit, but it’s honestly the underpinning for every other AI announcement they made.

That’s because of how crucial good governance is for AI adoption. In Snowflake’s case, it’s obvious that data warehouses are a gold mine of context for agents. It’s likewise obvious that you can’t let agents run wild in your warehouse. Without the right governance, companies either don’t adopt, or their teams run shadow agents and open up gaping security vulnerabilities.

We’re big fans of Natoma’s approach (the Statsig MCP is an official connector with them). But as we build our own governance systems for our MCP, we’ve been approaching things a little differently than how Snowflake did.

Rather than adding a whole separate control plane, we rely on the access controls already built into Statsig, with just a few lightweight knobs on top. Here’s why we went that lighter route, and where we’re taking it next.

What does Statsig MCP do?

In case you haven’t used it yet, the Statsig MCP is a hosted server that exposes Statsig’s product surface as a set of tools an agent can use. We currently have around 40, including feature gates, experiments, dynamic configs, segments, layers, metrics, and audit logs.

To use the MCP, you just connect your agent once with a quick sign-in. From then on, you can ask the agent to do tasks with Statsig like “List the gates rolling out this week” or “Summarize my most recent experiment’s results.”

If you’re an agentic power user, the MCP can cut a ton of friction from your Statsig workflow. For example, instead of switching between the Console UI and your codebase, you work directly from your coding agent to implement feature gates.

Why does MCP access need governance?

Say you have a feature gate that’s exposed to multiple team members. You’ve rolled it out, everything’s good, and you’re excited to see some experiment results. A week later, you check in on it, and it’s been overridden. All the log says is “Updated from Claude.”

Now imagine that instead of a feature gate in Statsig, it’s data in your warehouse. Just gone. Poof! All that’s left is a note (maybe) that an agent did it.

These are exactly the kind of situations that shouldn’t happen with your human coworkers, and they likewise shouldn’t happen with agentic ones.

And as we thought about all the main governance use cases and edge cases, we realized that governance needs for agents are essentially the same as for humans:

• Permissions. Agents need guardrails for the actions they’re allowed to take, just like humans need individual permissions and RBAC.

• Audits. Every tool call needs a record of who took what action, where the action originated, and when it happened. Just like for humans.

• Respecting review processes. Tool calls have to fit into the procedural guardrails around larger workflows. If human pull requests go through a review, so do agent ones.

• Org-level control. Orgs can set access rules for agents separately from their users, and orgs should still be able to quickly enforce new rules globally.

• Practicality. It doesn’t matter how rigorous your governance system is if it isn’t practical enough to actually use. Without it, you don’t get adoption, or you’re back in the AI shadowlands.

Our solution for Statsig MCP governance

Instead of figuring out the intricacies of giving MCP direct access to your product, avoiding prompt injection from bad actors, or answering the existential questions of agentic personhood, we realized we could simplify.

We arrived at that realization by connecting two separate ideas: 1) we already have all that human governance built into Statsig’s public API, and 2) the primary purpose of an MCP tool is to make interacting with existing APIs more user-friendly.

So we built each MCP tool as a controlled wrapper around Statsig’s existing public API. The bulk of the governance is then handled in the API endpoints. There’s nothing an individual’s agent can do that the individual couldn’t do themselves, and everything is tracked.

On top of that, we are adding additional org-level controls, like a new “agents are read-only” switch. But so far, we’ve made sure any bonus governance meets that last point above of practicality. This “lighter” approach to governance reduces the burden on admins and end-users, making it easier to adopt safe and responsible AI habits.

(And don’t get us wrong, the governance is still rigorous; we just couldn’t resist the bad pun against “shadow” AI.)

How does Statsig MCP governance actually work (what your CISO cares about)

1. Least-privilege RBAC by default. When you connect an agent, it acts with your permissions. A read-only user’s agent can only read; it can’t modify a flag in production.

2. An org-wide “agents are read-only” switch. Admins can let their whole org explore with agents while guaranteeing no agent can change anything, even as those same humans keep full edit rights in the Statsig UI.

3. End-to-end traceability. Every agent action is logged and tied to a real person. There’s no anonymous “the bot did it.” Each tool call is recorded and attributed to the human who authorized it, and changes show up in the audit log.

4. Agent changes still go through review. If your team requires approval to change a feature gate, that requirement still applies when the change comes from an agent. The MCP is not a bypass.

5. Guardrail and tool annotations. Just like Salesforce, we enforce annotation parameters for MCP tools (e.g., readOnlyHint or destructiveHint) so the AI knows exactly what actions it is allowed to execute.

6. Hard tenant isolation + opt-in. Agent/API access is something an org owner deliberately turns on, and the platform blocks any agent from reaching another customer's data at the framework level.

What’s coming next?

As our new team got ramped up on the MCP tech, we’ve been fielding a ton of RBAC requests from customers. Keep them coming!

Thanks to your requests, we just shipped the ability for read-only users to connect with the MCP for read-only access. The org-level read-only setting is currently behind a feature gate, so let us know if you want access to it. We’re planning to make it self-serve for admins soon.

We’re also working on more granular permissions for tools. Currently, you have to set all endpoints as read-only or read-write, but we know that some actions require stricter control than others (like if you want to say agents can update feature gates but nothing else). This will be available for self-serve access soon, too.

Finally, with strong governance in place, we’re excited to expose more of the Statsig product surface to MCP. Check our Product Updates page for new tools as they drop.

Agents are a powerful new way to use Statsig. With great power comes great responsibility. By making that responsible usage follow the same guardrails that protect human users, we’re building a practical governance structure that encourages good AI usage. We’re extremely excited to see what you’ll do with it.