MCP Governance: How to Control What AI Agents Can Do in Your SaaS

What is MCP governance?

MCP governance is the practice of controlling, authorizing, and auditing what AI agents are allowed to do when they call your tools through the Model Context Protocol (MCP). In practice it means giving every agent a registered identity, scoping its access to specific tools, checking each tool call against a policy before it reaches your SaaS, logging the call, and being able to revoke that access instantly.

It's the same discipline you already apply to employees, applied to the software now acting alongside them. Humans get SSO, roles, audit logs, and offboarding. Agents, until recently, got an API key pasted into a config file and nothing else. MCP governance closes that gap.

The work splits into four layers, each covered below: the MCP servers your organization allows, the tokens and credentials those servers use, the individual tools an agent may call and with which parameters, and the agents themselves, as identities with owners. A program that covers one layer leaves the other three open.

Why MCP changes the access problem

The Model Context Protocol, released by Anthropic in late 2024, has become the standard way AI agents connect to external tools. Instead of every agent shipping a bespoke integration for every SaaS app, agents call tools through MCP servers: standardized middleware that brokers the connection. Claude, and a growing list of other clients, speak it natively.

That standardization cuts both ways. It makes agents dramatically more capable, because one protocol unlocks every connected tool. And it concentrates risk, because a single agent with the wrong access can now read, write, and act across your entire SaaS estate through one channel. The same property that makes MCP useful, a single connective layer, is exactly what makes it the right place to put controls.

Why API keys aren't governance

The default way an agent gets access today is simple: someone generates an API key, pastes it into the agent's configuration, and the agent starts calling APIs. That key is a raw credential. It usually inherits the full access of whoever created it, it rarely expires, and nothing records what the agent actually did with it.

The point isn't that API keys are bad, it's that a credential is not a control. Governance is what you wrap around the credential so it can be reasoned about, reviewed, and revoked. For the full picture of why traditional identity tooling misses agents entirely, see The AI Governance Gap.

Governance vs. authorization

These two terms get used interchangeably, and they shouldn't be.

You can have authorization without governance, a gateway that allows or blocks calls but keeps no durable record and never gets reviewed. That passes a demo and fails an audit. Governance is what an auditor, a regulator, or your future self actually needs.

The MCP gateway pattern

The cleanest way to govern agents is to stop letting them hold credentials at all. Instead, put a server between your agents and your SaaS tools. Agents call tools through it; it holds the credentials, makes the decisions, and keeps the record. This is the MCP gateway (sometimes called an MCP proxy), and it's the equivalent of what an API gateway does for services or a reverse proxy does for web traffic.

A governing MCP gateway does five things on every request:

• Authenticates the calling agent and maps it to a registered identity and role
• Evaluates the tool call against policy before forwarding it to the target SaaS
• Forwards allowed calls, using credentials the agent never sees
• Blocks calls that violate policy, and can open an access request for review
• Writes an immutable log entry: which agent, which tool, what parameters, what outcome

What that enforcement looks like in practice:

The two DENY lines are the whole point. Logging what happened is table stakes; governance is about stopping the wrong thing from happening in the first place, and being able to prove you did. For a hands-on walkthrough of wiring an agent through a gateway with scoped access, see how to connect Claude to Slack via MCP with access controls.

The five controls of MCP governance

Whatever tool you use, a complete MCP governance model rests on five controls. If any one is missing, you have a gap an auditor (or an incident) will find.

1. Identity

Every agent is registered as a first-class identity: a name, an owner, a stated purpose, and an expiry. Not a service account, not an anonymous key. When a tool call happens, you know which agent did it and who is accountable for it.

2. Least-privilege scope

An agent gets explicit bindings to the specific tools it needs, and nothing more. A summarizer that reads Slack and posts to one channel does not get write access to your CRM. Scopes are narrow by default; broadening them is a deliberate, logged action.

3. Policy-based authorization

Each tool call is checked against policy in real time. Read versus write, rate limits, parameter constraints, and PII rules are evaluated before the call reaches the SaaS. Anything outside policy is blocked, not logged-after-the-fact.

4. Immutable audit trail

Every call, allowed or denied, is written to a tamper-evident log with full context: agent, tool, parameters, response, and the policy that applied. That log is exportable as evidence for SOC 2, ISO 27001, and the EU AI Act's logging requirements.

5. Revocation and review

You can suspend an agent globally in one action, a kill switch that stops access across every tool at once, without hunting down credentials. Access is time-boxed (expiry forces a periodic decision to renew), reviewed on a schedule, and flagged automatically when the agent's owner is offboarded. An agent whose creator has left should never keep running silently; see when the employee leaves but the agent stays.

MCP server governance: which servers, which versions, who connects

Every capability an agent has arrives through an MCP server. Before you can write policy about tool calls, you need to know which servers exist in your organization, who approved them, and which agents and people connect to each one. MCP server governance is that inventory and the approval process around it.

Inventory the servers you actually run

MCP servers come from three places, and each carries a different kind of risk:

• Official vendor servers. Remote servers published and hosted by the SaaS vendor, such as Notion's hosted MCP server. The vendor maintains the code, but the server still exposes read and write tools side by side and acts with whatever OAuth grant the user gave it.
• Community servers. Open-source servers written by third parties, often installed as a local process on a developer's machine. They run with the permissions of that machine and the credentials placed in their configuration, and their code changes whenever the maintainer publishes a new version.
• Internal servers. Servers your own teams build to expose a database, an internal API or a data warehouse. They are rarely reviewed like production services, even when they reach production data.

For each server, the inventory records who publishes it, where it runs (a local process or a remote endpoint), which tools it exposes, which credential it uses to reach the system behind it, who owns it internally, and which agents connect to it. That record answers an auditor's first question: what can your agents reach?

Approve servers before agents connect

An allow-list turns the inventory into a control. Each server is reviewed once, on its publisher, its tools, the credential it needs and where its data goes, and only approved servers can be connected. Anything else is blocked or surfaced for review. Without an allow-list, the set of servers in use is whatever individual developers happened to install, which is how shadow MCP starts.

Pin versions and re-review tool changes

An approved server is not approved forever. A new version can add tools, change what an existing tool does, or rewrite its description, and tool descriptions are passed to the model, which reads them when it decides what to call. Pin the version you reviewed, compare the tool list when a new version ships, and treat a new write or delete tool as a new approval rather than a routine update. In Lutril, the proxy applies this rule to the vendor servers it fronts, such as Notion's: tools on a known read list pass on a read binding, and any tool outside that list is treated as a write that needs an approved grant, so a tool the vendor adds later is not callable by default.

Decide who can connect what

The last question is the pairing: which agent, or which person, may use which server, and at what level. A support agent may need to read tickets; it does not need the CRM server at all. Recording each pairing as an explicit binding with a read or write scope keeps it reviewable. In Lutril, an agent's bindings decide what it sees: only the tools of the integrations it is bound to are registered for it, so an agent bound to Slack alone is shown Slack tools and nothing else.

Shadow MCP: the part nobody watches

There's a governance problem that sits one level up from policy: the agents and MCP servers you don't know about. A developer spins up an MCP connector to a SaaS tool for a side project. A team wires an internal agent to your data warehouse. None of it goes through security review. This is shadow MCP, the AI-native cousin of shadow IT, and it holds live credentials to production systems while being invisible to the people responsible for them.

You cannot govern what you cannot see. Discovery, finding ungoverned MCP servers and agent connectors and pulling them under the controls above, is the precondition for everything else. It's the same muscle as shadow AI discovery, pointed at a new surface. Most access-governance tools assume agents arrive already registered; the harder and more valuable step is surfacing the ones that didn't.

MCP token and credential governance

An MCP deployment involves two sets of credentials, and both need governing. The first is what the agent presents to the MCP server. The second is what the server uses to reach the SaaS behind it: an OAuth access token or an API key. For remote servers, the MCP specification bases authorization on OAuth 2.1 and requires servers to reject tokens that were not issued for them. It does not decide where your organization keeps those tokens, how long they live, or who can revoke them. That part is governance.

Where the tokens live

The usual starting point is a JSON configuration file on a laptop, with an API key or a personal access token in an environment variable for each server. Those credentials get copied between machines, committed to repositories by accident, and outlive the projects they were created for. Nobody can list them, so nobody can revoke them all.

The governed alternative keeps upstream tokens in one place, server-side and encrypted, and gives the agent a single credential that identifies it to the gateway and nothing else. The agent never holds the Slack or HubSpot token; the gateway attaches it when a call is allowed. In Lutril, registering an agent issues one MCP token for that agent. The SaaS credentials stay with the proxy, agent credentials are stored encrypted, and only a hash of the agent's secret is kept for verification.

Short-lived, scoped credentials instead of static keys

A static API key grants everything its creator could do, for as long as it exists. A short-lived credential scoped to one agent and one set of tools limits both dimensions: a leaked token stops working soon, and while it is valid it only reaches what the agent was bound to. Where a vendor supports OAuth, prefer tokens with narrow scopes over account-wide keys, and prefer one credential per agent over one shared by several, so that revoking one agent does not break the others.

Rotation and revocation

Rotation is a schedule, not an incident response. Credentials rotate on a fixed cadence, with a short overlap so a running agent does not fail mid-task while it picks up the new one. Revocation happens at one point and takes effect everywhere: when an agent is retired, when its owner leaves, or when a token may have leaked. Lutril's agent registry rotates or expires an agent's keys on a schedule, keeps the previous credential valid for a grace period until the rotation is confirmed, and suspends an agent at the proxy in one action, which stops its calls without touching any upstream SaaS token.

MCP tool governance and permission management

Approving a server is too coarse on its own. One server commonly exposes search, read, create, update and delete tools together, and an agent that summarizes pages has no reason to delete them. MCP tool governance sets permissions at the level of the individual tool call.

Policy per tool and per parameter

A useful policy names the tool and constrains its arguments. These rules are hard to express with a key and simple to express at a gateway:

• Allow search and get_page, deny delete_page
• Allow posting messages only to a named set of channels
• Allow reading deals, deny bulk contact exports
• Cap the number of calls an agent can make per minute
• Detect and redact personal data and secrets before the model sees them

Lutril's MCP proxy matches each call on the agent's role and the tool before the request leaves your perimeter, with a per-tool switch and a read, write or destructive classification. Its prompt DLP runs on the device, in the browser, so the same detection applies to chat, copilots and MCP tool calls.

Separate read from write

Most of the risk in an agent's access sits in its write and delete tools. Reads can leak data; writes can change or destroy it, send messages in your name, or trigger downstream workflows. A sound default grants read access with the binding and treats every write as a separate, explicit decision. The gateway enforces that distinction, not the agent: if the only thing preventing a write is the agent choosing not to make it, there is no control.

Human approval for sensitive calls

Some calls should be possible, but not unattended: a write to a production system, a bulk export, a deletion, a message to a customer. For these, the gateway holds the call and asks a person. The request carries its context (which agent, which tool, which parameters, on whose behalf), goes to a reviewer who can judge whether the action makes sense, and has a limited validity, so one approval does not become a permanent grant. In Lutril, read calls can be allowed while writes require a human approval in Slack, Teams or the app UI. The decision is logged with the call, and a grant can be time-boxed or single-use.

An MCP governance framework and checklist

The five controls describe what a governed deployment has. A framework describes the order in which you build it, because each step depends on the one before.

The six steps

• Discover. Inventory every MCP server, agent and credential in use, including the ones nobody registered.
• Approve. Put servers on an allow-list and register each agent with a named owner, a purpose and an expiry.
• Scope. Bind each agent to the servers and tools it needs, read by default, with write as a separate decision.
• Enforce. Route every call through a gateway that holds the credentials, applies per-tool and per-parameter policy, redacts sensitive data and asks for approval where required.
• Record. Write every call, allowed or denied, to an immutable log that can be exported as audit evidence.
• Review and revoke. Rotate credentials, review agent access on a schedule, re-review servers when their tools change, and keep a kill switch for every agent.

Skipping a step does not save time. Enforcement without discovery governs only the agents you already knew about, and a log without review records drift without correcting it.

The checklist

If you can answer yes to each question, you have governance, not just connectivity:

• Is there an inventory of every MCP server in use, with its publisher, its owner and the agents connected to it?
• Can only approved MCP servers be connected, with versions pinned and new tools re-reviewed?
• Is every agent registered with a named owner, purpose, and expiry date?
• Does each agent have explicit, least-privilege bindings instead of a broad key?
• Are upstream OAuth tokens and API keys kept out of agent configuration files and laptops?
• Do agent credentials rotate on a schedule, and can one be revoked without breaking the others?
• Is every tool call authorized against policy before it reaches the SaaS?
• Are write, delete and export tools gated separately from reads, with human approval for the sensitive ones?
• Do agents call tools through a gateway, rather than holding raw credentials?
• Is there an immutable, exportable log of every call with full context?
• Can you suspend any agent across all tools in one action?
• Are agent access rights reviewed on a schedule and revoked on owner offboarding?
• Do you actively discover ungoverned (shadow) MCP servers and agents?

The frameworks here aren't new, we spent two decades getting them right for humans. What's new is the urgency of applying them to agents before deployments grow past the point where you can retrofit controls. The control point already exists: it's the MCP layer. The question is what you enforce there.

How to choose MCP governance tools

Four categories of product can enforce governance policies on MCP server deployments. They overlap, but each starts from a different problem, and the right choice depends on what else you need governed. The examples below are the products compared in detail in MCP gateways compared.

Dedicated MCP gateways

A dedicated gateway sits between AI clients and MCP servers and handles authentication, policy and logging for tool calls. MintMCP is an example, with programmable middleware that can block on tool name, argument values or prompt content, signed append-only audit records and an org-wide kill switch. Its scope stops at MCP tool entitlements, so it fits when access governance for the people behind the agents is handled elsewhere.

Authorization decision points

A decision point evaluates policy and returns a decision; it does not proxy traffic itself. Cerbos is an example: an open-source policy decision point that a gateway such as agentgateway calls before a tool runs, with policy written as code. It suits teams that already operate a gateway and want one policy language across applications and agents.

Identity-aware proxies

An identity-aware proxy enforces policy inline, in front of applications as well as agents. Datawiza is an example: an Agent Gateway between agents and the tools, APIs, MCP servers and SaaS systems they reach, which brokers credentials so agents do not hold secrets and applies policy before tool calls, alongside an Access Proxy for legacy and on-premises applications.

Access governance platforms with an MCP proxy

In this category the MCP proxy is one part of a platform that also governs employees. Lutril is an example: agents are registered with an owner and scopes, every call is checked against the same role-based policy used for employees, calls land in an append-only log, prompt DLP runs in the browser, one kill switch pauses any agent, and the same product runs shadow AI discovery, access reviews, onboarding and offboarding, with approvals in Slack, Teams or the app UI. It is a SaaS hosted in France, without a self-hosted option.

Choosing when you run many agents

With one or two agents, most of these products will do. The differences show once dozens of agents are owned by different teams. These questions separate the options at that point:

• Does the product proxy calls itself, or only decide on calls that another component routes?
• Does every agent have its own identity and a named owner, or do agents share credentials?
• Can policy constrain parameters, not only tool names?
• Is the audit log tamper-evident, and does it record denied calls as well as allowed ones?
• Can you pause one agent, and all of them, from one place?
• Where do human approvals happen, and are they logged with the call?
• Does it find agents and servers that nobody registered?
• Do agents go through the same access reviews and offboarding as the employees who own them?
• Can it run where your data has to stay: self-hosted, or in a specific region?

The MCP gateway comparison answers these questions for MintMCP, Cerbos, Datawiza and Lutril, citing each vendor's public documentation.