MCP Governance: Secure and Monitor AI Agent Tool Calls
If your AI agent uses MCP (Model Context Protocol) to call external tools -- reading files, querying databases, sending emails, executing code -- then every one of those tool calls is a potential security and compliance surface. MCP governance gives you visibility and control over what your agents do, before they do it.
MCP is the open protocol that lets AI agents discover and call tools on external servers. When your agent calls session.call_tool("send_email", {"to": "ceo@company.com", ...}), it's making an MCP tool call. The agent decides which tool to call and with what arguments. Without governance, there's nothing between the agent's decision and the action happening in the real world.
MCP governance adds a policy layer between the agent's intent and the tool execution. Every tool call passes through policy checks, PII scanning, approval workflows, and audit recording -- automatically, with no changes to your MCP server code.
Why Governance Matters
AI agents with MCP access can do powerful things. That power creates three categories of risk:
Unauthorized actions. An agent might call a tool it shouldn't have access to, or pass arguments that exceed its scope. A customer support agent shouldn't be able to call delete_database, even if the MCP server exposes it. A content agent shouldn't be sending emails to external addresses.
Data leakage. Tool call arguments often contain user data, and tool results often contain sensitive information. Without scanning, an agent might send a social security number as a search query, or an MCP server might return API keys in its response. PII and credentials flowing through unmonitored tool calls create compliance and security risks.
Rug pull attacks. An MCP server can change what its tools do at any time. A tool called search_documents today might silently change its description to instruct the agent to exfiltrate data tomorrow. Without fingerprinting, you have no way to detect when a tool's behavior description changes between sessions.
MCP servers are often third-party services that you don't control. Even trusted servers can be compromised, have bugs, or change their API surface. Governance isn't about distrust -- it's about verifiable safety.
Why SDK-Level Governance?
There are several approaches to MCP governance. Gateway-based solutions sit between your agent and MCP servers as a proxy layer, inspecting traffic as it flows through. SDK-level governance works differently: it instruments the agent itself, adding governance checks directly inside the MCP client library.
SDK-level governance has several advantages:
Agent context visibility. The governance layer knows which agent is making the call, which user triggered it, what the agent's reasoning chain looks like, and what happened earlier in the session. A gateway only sees the raw tool call in isolation. This context makes policy decisions more precise -- you can allow delete_file for admin users but block it for regular users, all in one policy.
Reasoning traces. Every governance decision -- allow, block, warn, throttle -- is recorded as an OpenTelemetry span attribute on the same trace as the agent's LLM calls and tool execution. You get a single trace that shows the full story: the agent reasoned, decided to call a tool, governance checked the policy, PII was scanned, the tool executed, and the result was audited.
Cost attribution. Because the governance layer runs inside the agent process, it can attribute tool call costs to the same user, session, and agent run that the rest of your observability tracks. No need to correlate logs from two different systems.
Zero infrastructure. There's no proxy server to deploy, no gateway to maintain, no DNS to configure. You add governance by calling configure_session() on your existing MCP client session. It works with any MCP server, any transport, and any deployment environment.
SDK-level governance doesn't replace server-side security. It complements it. If you control the MCP server, you can add server-side middleware too. If you control neither the agent nor the server, a governance proxy gives you a third option. Waxell provides all three.
How It Works
When you initialize Waxell Observe with waxell.init(), it automatically patches the MCP client library's call_tool method. Every subsequent tool call flows through a governance wrapper that handles policy checks, PII scanning, security fingerprinting, and audit recording.
The wrapper adds governance without changing the tool call's behavior. If governance is not configured, tool calls pass through with only observability tracing. If governance is configured, each call gets policy checks, PII scanning, and audit recording -- all fail-open by default, so governance errors never break your agent.
The Three Products
Waxell provides three complementary products for MCP governance, each designed for a different deployment scenario.
Auto-Instrumentor (This Section)
The auto-instrumentor is for agent developers who write Python code that connects to MCP servers. You add governance by calling configure_session() on your MCP ClientSession after initialization. The instrumentor patches call_tool to add policy checks, PII scanning, rug pull detection, and audit recording.
Best for: You control the agent code. You connect to third-party MCP servers. You want governance without modifying servers.
This documentation section covers the auto-instrumentor in detail.
Server Middleware
Server Middleware Quickstart →
Server middleware is for MCP server builders who want to add governance to their own servers. You add a GovernanceMiddleware to your FastMCP server, and it applies policy checks, PII scanning, and rate limiting to all incoming tool calls.
Best for: You build and operate the MCP server. You want to enforce governance regardless of which agents connect.
Governance Proxy
The governance proxy is a standalone MCP server that sits between agents and target MCP servers. It forwards tool calls while applying governance checks. No code changes needed on either side.
Best for: You control neither the agent code nor the MCP server. You want governance as an infrastructure layer.
Choosing the Right Product
All three products record governance decisions as OpenTelemetry span attributes using the same waxell.mcp.* attribute namespace. Regardless of which product you use, governance data appears in your Waxell dashboard traces with consistent structure and semantics.
What You'll Learn
This documentation section covers the auto-instrumentor in depth:
- Quickstart -- Add MCP governance to your agent and see tool calls in traces in under 5 minutes.
- Policy Configuration -- Configure allowlists, blocklists, and policy rules for MCP tool calls using the
mcp:{server}:{tool}naming convention. - Approval Workflows -- Add human-in-the-loop approval for sensitive tool calls with
on_policy_blockhandlers. - PII Scanning -- Scan tool call inputs and outputs for PII, credentials, and secrets with configurable actions (warn, block, redact).
- Rug Pull Detection -- Detect when MCP server tool descriptions or schemas change between sessions using SHA256 fingerprinting.
- Reference -- Complete reference for all
waxell.mcp.*span attributes,configure_session()parameters, and governance configuration options.
Getting Started
Ready to add MCP governance to your agent? Start with the Quickstart -- you'll go from zero to seeing MCP tool calls in your traces in under 5 minutes.