MCP Governance Means Governing Every Tool Action

MCP expands the agent action surface

Model Context Protocol can make enterprise tools easier for agents to discover and invoke. That convenience also means a newly connected server can expose several capabilities to an acting workload. The protocol connection doesn't decide whether a particular agent should use every tool or whether every argument is safe. Treat the MCP server, tool catalogue, credentials, action policy, data path, and target systems as part of one governed integration.

Establish trust before exposing a server

Register approved MCP servers, verify their ownership and deployment, review the tools they expose, and define who may connect them to production agents. Track version and configuration changes because a trusted server can later expose a new tool or alter behaviour. Separate development and production environments. Do not let an agent discover arbitrary servers and decide which one is trustworthy based on names or tool descriptions alone.

Filter tool discovery by agent identity and job

An agent should see only the tools required for its approved purpose. A customer-service agent may need order lookup and ticket creation but not payroll or production administration tools. Tool visibility reduces accidental selection but shouldn't replace action-time authorisation. Bind the agent identity to an approved server, tool, resource scope, operation, threshold, and delegated context. Review unused tools and remove access when the job changes.

• Approved server and deployment environment
• Visible tool set for the agent job
• Permitted operations and target resource scope
• Argument constraints and business thresholds
• Delegated person and owner context
• Credential lifetime, egress, and what the run trail should retain

Validate the resolved action, not the model intent

A plausible tool choice can still contain unsafe arguments. Validate identifiers, organisation ownership, amounts, paths, destinations, methods, schemas, and current business state before execution. Recheck long-running or retried actions because resources may have changed since the agent planned the step. The control layer should decide using the resolved request and current policy, not rely on the agent's explanation of what it intended.

Control credentials and network paths

MCP tools can become a route to external services and enterprise systems. Use scoped, short-lived credentials where possible and keep them outside prompts and model-visible tool output. Restrict outbound destinations to the approved server and target path. Prevent a tool from turning an allowed connection into arbitrary egress. Record credential and connection references without logging secret values.

Preserve the action chain across delegation

When one agent delegates to another or a tool invokes another service, the evidence should preserve the parent job, identities, authority, policy decisions, and resulting action. A new hop shouldn't silently start with broader access. Define whether the child receives a subset of the parent authority, a separate job-specific grant, or no delegated authority at all. Record which system ultimately changed and which agent initiated each step.

Test the MCP boundary with a forbidden action

Use an approved server with one permitted and one prohibited operation. Verify that the agent only discovers the correct tool set, an allowed request succeeds, an invalid argument is rejected, a protected field is transformed, and an out-of-policy action is blocked before the target system changes. Then alter the server or tool version and confirm that the governance process detects or reviews the change. Inspect the evidence from agent request through policy result to target-system outcome.

Treat server and tool changes as authority changes

A trusted MCP server can expose a new tool, widen an argument schema, change its target service, or return different data after an update. Version and review the integration rather than assuming an approved server remains unchanged.

• Server owner, deployment, publisher, transport, authentication, and trust status
• Tool name, version, description hash, schema, destination, and data classes
• Agents and jobs permitted to discover the tool
• Allowed operations, resources, arguments, thresholds, and credential scopes
• Network destinations and downstream services reached by the server
• Change detector for new tools, removed tools, schema expansion, and version drift
• Approval required before changed capability reaches production agents
• Evidence linking agent request, MCP action, downstream result, and final outcome