MCP standardizes how agents connect to tools. It does not govern them. IBM's Orchestrate release shows the gap

Model Context Protocol did for agent tools what USB did for peripherals: one standard way to plug things in. That is why adoption has been fast. It is also why governance is behind. A standard connector says how a tool is called; it says nothing about which tools may be called, by whom, how often, with what inputs, or what happens when a call looks wrong.

IBM’s end-of-September release of watsonx Orchestrate is a useful look at what that missing layer contains.

What IBM shipped

The release notes from the watsonx Orchestrate team, published September 22, include:

• Tenant-scoped MCP registration. Remote MCP servers can be registered directly into a tenant namespace from the catalog, so a team can use a tool without publishing it to the global catalog.
• Custom controls on tools. From a unified Controls page, administrators can define validation rules, monitor tool execution counts and add runtime safeguards. The controls apply to MCP tools, OpenAPI specifications and ZIP plugin packages, alongside IBM’s built-in controls.
• Workspace-scoped monitoring. Dashboards can be filtered by private workspace to inspect performance, usage and operational metrics. IBM notes this filter is IBM Cloud only.
• Agent-to-Agent (A2A) protocol support for connecting external agents, plus other items such as real-time call transcription for Genesys Cloud Agent Assist.

None of this is dramatic on its own. Together, it describes the controls a platform team needs once MCP stops being a developer experiment.

The tool governance layer, piece by piece

1. MCP server registered to a tenant
2. Tool allowed for named agents
3. Input and output validation rules
4. Execution counts and limits
5. Runtime safeguards on behavior
6. Usage monitored per workspace

• Who may use it: MCP server registered to a tenant · Tool allowed for named agents
• How it may be used: Input and output validation rules · Execution counts and limits · Runtime safeguards on behavior
• Evidence: Usage monitored per workspace

ScopePolicy on each call

Scope. A tool registered to one tenant or workspace is not automatically available to every agent. This is the difference between an internal app store and a shared drive.

Validation. Rules on inputs and outputs catch the obvious failures: a payment tool called with an amount above a threshold, a lookup that returns personal data the agent should not see, a parameter outside its allowed range.

Limits. Execution counts are a reliability and cost control. An agent stuck in a loop calling the same tool a thousand times should hit a ceiling, not an invoice.

Runtime safeguards. Policy that runs at call time, outside the agent’s reasoning, is the same principle we described in our analysis of agent containment: the boundary has to sit where the agent cannot argue with it.

Monitoring. Per-workspace usage is the evidence an owner needs to answer “which agents used this tool, and how often?”

What platform controls do not cover

A control layer governs how your agents use a tool. It does not make the MCP server itself trustworthy. A third-party server can change its behavior, return poisoned content or have its own vulnerabilities. Treat each external MCP server as a supplier: who maintains it, how it is updated, what data it receives, and what its terms say. Pinning versions and reviewing changes matters as much as for any other dependency.

Identity is the other half. Controls on tools work best when every call already carries a user or agent identity, which is the subject of our analysis of why enterprise MCP starts with identity.

On a Microsoft stack

IBM’s controls are IBM’s; they do not exist inside Microsoft products. The questions are the same, though. In Copilot Studio, MCP servers are added through connectors, so Power Platform data policies and environment boundaries are the natural place to decide which agents may use which tools. In Foundry, the gateway in front of tools carries that role. Whatever the platform, write the same five controls down: scope, validation, limits, runtime policy, monitoring.

For U.S. companies with SOC 2 or SOX obligations, an MCP tool that can change data in a financial system is in scope like any other integration. Auditors will ask how access to it is granted and reviewed, and how changes to it are approved.

What to do now

1. Inventory MCP servers in use across platforms, including developer-added ones.
2. Register tools per team or workspace, not globally, and keep an allowlist per agent.
3. Write validation rules for high-impact tools first: payments, record changes, data exports.
4. Set execution limits on every tool, with alerts before the limit.
5. Treat third-party MCP servers as suppliers: owner, version pinning, change review, data received.
6. Check feature availability by deployment model (IBM notes some monitoring is IBM Cloud only) before designing around it.

The bottom line

MCP solved the plumbing. Every platform will now compete on the valves: scope, validation, limits, runtime policy and evidence. Whether you run IBM, Microsoft or another stack, the governance layer is yours to define, and it should be in place before the number of connected tools makes it painful.