MCP Governance: How to Control What AI Agents Can Do in Your SaaS
AI agents now call your SaaS tools through the Model Context Protocol. MCP governance is how you decide what they're allowed to do, prove what they did, and shut them off in seconds. Here's the model.
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.
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.
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.
An MCP governance checklist
A practical starting point. If you can answer yes to each, you have governance, not just connectivity:
- 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?
- Is every tool call authorized against policy before it reaches the SaaS?
- 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.
Frequently asked questions
What is MCP governance?
MCP governance is the practice of controlling, authorizing, and auditing what AI agents can do when they call tools through the Model Context Protocol. It gives each agent a registered identity, scopes its access to specific tools, evaluates every tool call against a policy before it reaches your SaaS, logs the call, and lets you revoke access instantly.
What is the difference between MCP authorization and MCP governance?
MCP authorization is the per-call decision of whether a specific agent may invoke a specific tool. MCP governance is the broader program around it: registering agents as identities, assigning roles and scopes, logging every call, reviewing access periodically, and revoking it on offboarding. Authorization is one control inside governance.
Why aren't API keys enough to govern AI agents?
An API key is a raw credential with no identity, no per-call policy, no expiry by default, and no audit trail of what the agent actually did. It typically inherits the full access of whoever created it, survives that person's offboarding, and can't be revoked without finding and rotating the key everywhere it was pasted.
What is an MCP gateway?
An MCP gateway is a server that sits between your AI agents and your SaaS tools. Agents call tools through the gateway instead of holding credentials directly. It authenticates the agent, checks each tool call against policy, forwards allowed calls, blocks the rest, and writes an immutable audit log. It's the natural enforcement point for MCP governance.
What is shadow MCP?
Shadow MCP refers to MCP servers and AI-agent connectors deployed without security review or central governance, often by individual developers or teams. Like shadow IT, they hold live credentials to production SaaS and stay invisible to the security team until they're discovered and brought under governance.