Governing MCP, the Protocol That Connects AI Agents to Business Systems
Updated: 6 days ago
Title: Governing MCP, the Protocol That Connects AI Agents to Business Systems
Date: 15 April 2026
Type: Paper
Author: SAASiQ (contact@saasiq.ai)
Word count: 2937 words
Reading time: 11 min
Published: 15-04-2026
About 1,200 people attended the MCP Dev Summit in New York on 2 and 3 April, where Anthropic's David Soria Parra said the Model Context Protocol's software development kits are now downloaded more than 110 million times a month. On 31 March NetSuite added support for MCP Apps to its AI Connector Service, and in February Workato began selling managed MCP servers with audit logging. This paper explains how MCP works, what its specification secures and what it leaves to the systems behind it, and sets out a framework for governing it.
What MCP is and who looks after it
Anthropic published the Model Context Protocol in November 2024 as an open standard for connecting AI applications to the data and tools they need. OpenAI's chief executive Sam Altman announced support on 26 March 2025, starting with OpenAI's Agents SDK. At Build on 19 May 2025 Microsoft and GitHub joined the protocol's steering committee, and Microsoft announced native MCP support in Windows 11. An official MCP Registry, a public catalogue and API for listing servers, went into preview on 8 September 2025.
On 9 December 2025 Anthropic handed MCP to the Linux Foundation's new Agentic AI Foundation, alongside Block's goose and OpenAI's AGENTS.md. The foundation's platinum members are Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. The MCP maintainers said the governance model 'continues as is': the Linux Foundation does not set the protocol's technical direction, and changes still go through written proposals the project calls SEPs. They put usage at the time at more than 97 million SDK downloads a month and 10,000 active servers.
By the New York summit the foundation had 170 member organisations. MCP support now ships with products from the main model providers and many enterprise software vendors, so a connection between an agent and a business system can arrive in a product update as well as through a project.
How the protocol works
MCP takes its design from the Language Server Protocol that code editors use. The host is the AI application the user works in, such as Claude, ChatGPT or a developer's IDE. Inside it, a client holds a connection to one server, and the server exposes the capabilities of a system. Messages use JSON-RPC 2.0, and the connection is stateful: the two sides negotiate what each supports when they connect.
Servers offer three kinds of thing. Tools are functions the model can call, such as running a query or raising a ticket; resources are data for the user or the model to read; and prompts are templated messages or workflows. Clients can offer servers three features in return. With sampling, a server asks the host's model for a completion, with roots it asks which files or locations it may work within, and with elicitation, added in June 2025, it asks the user for more information part-way through a task.
There are two standard transports. A local server runs on the user's own machine and talks to the client over standard input and output, known as stdio. A remote server is reached over Streamable HTTP, which replaced the original HTTP and server-sent events transport in the March 2025 revision of the specification.
Since that revision, tools can carry annotations saying, for example, whether they only read data or can destroy it. The specification says such descriptions 'should be considered untrusted, unless obtained from a trusted server', and that hosts must get the user's consent before invoking any tool. MCP Apps, the first official extension, went live on 26 January 2026. It lets a tool return interactive screens, such as forms and dashboards, that appear inside the conversation.
What the specification secures
Authorisation arrived in the 2025-03-26 revision, as a framework based on OAuth 2.1. The 2025-06-18 revision changed its shape. An MCP server is now classed as an OAuth resource server: it publishes metadata telling clients which authorisation server issues its tokens, and it must validate every access token it receives and check that the token was issued for it. Clients must use resource indicators (RFC 8707), which bind a token to the server it was requested for, so that a malicious server cannot obtain a token meant for another.
The same revision forbids what the specification calls token passthrough, where a server accepts a token issued for some other service and forwards it to a downstream API. It says MCP servers 'MUST NOT accept or transit any other tokens'. A server that calls an upstream API has to act as an OAuth client in its own right and use a separate token. Servers that sit in front of third-party APIs must collect the user's consent for each client, and the security guidance says servers must not use sessions for authentication.
The 2025-11-25 revision, which is the current one, added OpenID Connect discovery, incremental scope consent (a server asks for a wider permission only when a privileged operation is first attempted) and OAuth Client ID Metadata Documents as the recommended way for clients to register.
Authorisation itself is optional in the specification, and local servers using stdio are told to take their credentials from the environment instead, which in practice means whatever keys and tokens are configured on the user's machine. The specification also says that 'MCP itself cannot enforce these security principles at the protocol level'. OAuth settles whether a client may call a server on a user's behalf. What the agent may then do in the system behind the server is decided by that system's own roles and data rules.
Where it has gone wrong
Asana launched an MCP server on 1 May 2025 and on 4 June found a flaw in its tenant isolation that could let users see data belonging to other organisations. It took the server offline from 5 June and restored it on 17 June, as BleepingComputer and The Register reported.
In July 2025 JFrog disclosed CVE-2025-6514, rated 9.6 out of 10, in mcp-remote, a package that lets local clients connect to remote servers. A malicious server could run operating system commands on the user's machine through a crafted authorisation endpoint address. The package had been downloaded more than 437,000 times, and version 0.1.16 fixed it. In September Koi Security found postmark-mcp on npm, a copy of an email-sending server that worked normally for 15 versions. Version 1.0.16 added a line that sent a blind copy of every email to an outside address. The package had 1,643 downloads.
At the New York summit the security researcher Jonathan Leitschuh demonstrated DNS rebinding, in which a web page reaches a server running on the user's own machine. His targets included the official MCP Inspector, Docker's MCP gateway and an AWS Labs server, and he disclosed a flaw in Google's Database Toolbox that had been unpatched for more than 90 days.
The OWASP Top 10 for Agentic Applications, published on 9 December 2025, covers both kinds of problem. Tool Misuse and Exploitation (ASI02) is an agent using a legitimate tool in an unsafe or unintended way, and Agentic Supply Chain Vulnerabilities (ASI04) covers the third-party tools, registries and components that bring risk in with them.
Gateways and registries
The MCP roadmap that David Soria Parra, the lead maintainer, published on 9 March lists the problems enterprises keep running into: audit trails, authentication tied to single sign-on, how gateways should behave, and configuration that can move between tools. It says most of this work will arrive as extensions rather than changes to the core specification, and that no enterprise working group exists yet. Its transport work aims to let Streamable HTTP servers run without holding session state, so that they can sit behind ordinary load balancers.
Vendors have filled the gap with gateways. A gateway is a proxy between agents and MCP servers that holds the list of approved servers and applies authentication, logging and rate limits in one place. InfoQ's report of the summit, on 9 April, said AWS, Uber, Docker, Kong and Solo.io had converged on 'a centralized gateway paired with a registry as the control plane for all agent interactions'.
Uber described its own deployment. Its MCP gateway and registry expose internal service endpoints to agents, and traffic bound for outside models passes through Uber's GenAI Gateway, which redacts personal data first. Uber gave figures of more than 10,000 internal services, 1,500 monthly active agents and more than 60,000 agent executions a week. James Hood of AWS said Amazon uses a central registry to check combinations of tools against what he called the 'lethal trifecta': access to private data, exposure to untrusted content and the ability to communicate externally. Alex Salazar, founder of Arcade, argued that an agent's permissions should be intersected with the user's, which he called an 'AND gate', instead of being granted through a service account.
Amazon Bedrock AgentCore became generally available on 13 October 2025, and its Gateway turns APIs and Lambda functions into MCP tools, connects to existing MCP servers and accepts AWS IAM as well as OAuth. Workato launched production MCP servers on 5 February for Google Calendar, Google Sheets, Google Directory, GitHub, Gong, Slack, Jira and Okta, with role-based access control, audit logging and what it described as 99.9 per cent uptime, and said it would release more than 100 during 2026. Microsoft said on 9 March that Agent 365, its registry and control system for agents, would be generally available on 1 May at $15 per user per month, with agents' tool calls passing through a gateway where threats can be blocked. n8n, the workflow company that raised $180 million at a $2.5 billion valuation in October 2025, has since April 2025 shipped nodes that turn a workflow into an MCP server or call outside servers from inside one.
Oracle's MCP support
Oracle supports MCP at the database, in Fusion Applications and in NetSuite. Its SQLcl command-line tool has included an MCP server since July 2025, and since 23 December 2025 each Autonomous AI Database on Serverless infrastructure, on 19c or 26ai, has had its own managed MCP server, which applies the database's existing roles, auditing and Virtual Private Database policies. Oracle's database announcements in London on 24 March included the Autonomous AI Database MCP Server and Deep Data Security, which passes the identity of the end user, or of an agent acting for one, to the database so that SQL policies decide which rows, columns and cells come back.
In Fusion, AI Agent Studio gained MCP support at Oracle AI World on 15 October 2025. Release 26A added a tool that lets agents call external MCP servers without custom REST wrappers, and agent teams can now be called from other applications through a REST API, with access decided by the roles assigned to the team. Oracle says agents follow Fusion's security configurations, so an agent acting for a user reaches only what that user's roles allow. OCI Enterprise AI, announced on 24 March for developers building their own agents, supports MCP for tools and the A2A protocol for calls between agents.
NetSuite's AI Connector Service, announced at SuiteWorld on 7 October 2025, is built on MCP and comes with standard and custom MCP tools. At SuiteConnect London on 31 March NetSuite added support for the MCP Apps extension, which brings NetSuite filters, selectors and forms into AI assistants. Oracle says access runs through role-based access controls, with 'MCP-ready roles' that provide preconfigured access patterns.
SAASiQ's view is that in an Oracle estate the role design, whether in Fusion, NetSuite or the database, is where MCP access is actually decided, so it is the first thing to review before any agent is connected.
Step one: find the connections that already exist
The framework starts with an inventory of every MCP client and server in use. That covers desktop assistants and IDEs where users add servers themselves, SaaS connectors that administrators switch on, and servers that vendors ship with their products.
Local stdio servers need the closest look, because they run on the user's machine with the user's privileges. The specification's security guidance says a client offering one-click installation of a local server must show the exact command and get explicit approval before running it.
For each connection, record the host, the server, who published it, the version, the systems it reaches and the credentials it uses. Agent 365 and the registries described at the summit are commercial versions of this list, but a spreadsheet will do to begin with.
Step two: classify servers by what they can do and who built them
Sort each server first by what its tools can do. Some only read, some can write to a system of record, and some can act outside the organisation, for example by sending email. Then sort by origin: first-party servers from the system's own vendor, servers from an integration platform such as Workato, community packages, and servers built in-house. A community package with write access to a finance system needs the most scrutiny.
Tool annotations help with the first sort, but the specification treats them as untrusted, so the check has to be made against what the server's code and credentials allow. Hood's 'lethal trifecta' gives a rule for combinations. Where one agent can reach private data, read untrusted content such as inbound email or web pages, and send data out, the combination should be blocked or redesigned, whatever the individual servers are rated.
Step three: decide how identity flows
There are two basic models. In the first, the agent acts for a named user through OAuth and can do no more than that user could. In the second, the server holds a shared service account and every agent that connects gets its permissions. The first keeps an audit trail that points to a person and lets the system's existing controls apply, and it is the model Oracle uses for Fusion agents and for Deep Data Security in the database.
For remote servers, the specification already requires the parts that matter: tokens issued for that server alone, validated on every request, and never passed through to another service. The security guidance adds scope minimisation, starting with a small set of low-risk permissions and asking for more only when a privileged tool is first used. Procurement questions should ask vendors whether their servers meet the 2025-06-18 authorisation rules or later.
Separation of duties still depends on the user's roles. If a user could both create and approve a payment, an agent acting for that user can too, so role conflicts should be cleared before agents are connected. Local servers should not hold long-lived keys in plain configuration files, since the specification leaves their credentials to the environment.
Step four: route remote traffic through a gateway
Remote MCP traffic should pass through a gateway that allows only registered servers, logs each call with the user, the agent, the tool, the arguments and the result, applies rate limits, and inspects data leaving for outside models, as Uber's GenAI Gateway does with personal data.
Because audit trails and gateway behaviour are not yet standardised, each gateway's configuration is specific to its vendor. The approved-server list, the classification from step two and the policy rules should therefore be kept in a form the organisation owns, so that they can be moved if the gateway changes. A gateway also adds a network hop to every call, which should be measured for any latency-sensitive workflow before it goes live.
Step five: control the supply chain
Pin server versions and review each update before it is deployed. The postmark-mcp change arrived in a new version, and the mcp-remote fix depended on users moving to version 0.1.16. The MCP Registry supports private sub-registries, so an organisation can publish its own approved list and point clients at it.
Run local servers in a sandbox with restricted access to files and the network, as the specification's guidance recommends, and bind any local HTTP server to an authorisation token so that a web page cannot reach it through DNS rebinding.
Step six: pilot, measure and review
Start with one read-only server on one system and check that the logs can answer four questions: which user, which agent, which tool, and what data came back. Add write access only after that, with a person approving actions that change records or send anything outside the organisation.
Review the approved list whenever the specification changes. The stateless transport work in SEP-1442 will change how remote servers are deployed and scaled, and the roadmap ties releases to working group progress without committing to dates.
What it costs and where it breaks
The framework has running costs. Gateways and registries have to be bought or run, and Agent 365, for example, is priced at $15 per user per month. Each new server needs a review of its code, its credentials and its classification, and someone has to keep the inventory current.
Tool definitions also consume the model's context. InfoQ reported that Claude Code cut token usage by roughly 85 per cent by loading tool definitions only when they are needed.
MCP standardises the connection. It does not decide what an agent should be allowed to do in a ledger or an HR record, and a server with weak permissions behind it inherits those weaknesses whatever the protocol version.
This framework covers connection and governance. It does not cover model selection, agent-to-agent protocols such as A2A, or the contract terms for data handling with server vendors.
Microsoft's Agent 365 becomes generally available on 1 May, the same day Oracle's 26B update reaches the first Fusion test environments, and the MCP maintainers have not set a date for the next specification revision.
SAASiQ - Intelligent Solutions for SaaS ©
