MCP-Enabled Integration: How Enterprises Govern AI Agent Actions Across NetSuite, Salesforce, and SAP

The protocol standardizes the connection and, for protected remote servers, defines an OAuth 2.1-based authorization model, but it does not govern the business action: a production-safe deployment adds least-privilege scopes, human approval for writes, and full action logging on top of MCP. McKinsey reported in April 2026 that almost nine in ten companies had deployed AI in at least one business function, yet 94% of respondents were not seeing significant value, with many programs still centered on incremental pilots rather than deeper transformation. That execution and governance gap, not the connection alone, is the real barrier, and it is where Sage IT’s governance control plane sits, managing MCP exposure above your existing iPaaS.

Most enterprises adopting MCP focus on the connection and skip the control layer. A standard connection is necessary, but it does not decide what an AI agent is allowed to do inside NetSuite, Salesforce, or SAP, or prove what it did afterward.

MCP-enabled integration connects AI agents to enterprise systems through the Model Context Protocol, an open standard for exposing tools, data, and actions to a model. The pattern matters because agents need a consistent, authenticated way to reach systems like NetSuite and SAP rather than a bespoke connector built for each model.

MCP-enabled integration is the practice of using the Model Context Protocol (MCP) to give AI agents a standard channel into enterprise systems such as NetSuite, Salesforce, and SAP, with an OAuth 2.1-based authorization model available for protected remote servers. MCP defines how an agent discovers and calls tools, reads resources, and requests actions, so one agent can work across systems without a custom integration for every model-to-system pair. Anthropic released MCP as an open standard on November 25, 2024. By May 2025, OpenAI, Google, and Microsoft had announced MCP support across their agent and developer platforms. The distinction that determines production readiness is simple: MCP standardizes the connection, not the governance of the action. A raw MCP server can expose the ability to create an invoice in NetSuite, but the Model Context Protocol does not decide, on its own, whether that invoice should be created.

The Model Context Protocol (MCP) is an open standard, created by Anthropic and open-sourced on November 25, 2024, that defines how AI applications connect to external tools and data. MCP uses JSON-RPC messages between a host application, its clients, and MCP servers that expose a system’s capabilities as callable tools. OpenAI added remote MCP server support to the Responses API on May 21, 2025; Google announced native SDK support for MCP definitions in the Gemini API at Google I/O 2025; and Microsoft made MCP integration generally available in Copilot Studio on May 29, 2025. In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI, moving MCP from a single-vendor project to shared, cross-vendor infrastructure. Because the connection layer is now common infrastructure, competitive advantage moves up the stack, to how well an enterprise governs what agents do through it.

An MCP host is the AI application a user works in, an MCP client is the connector inside the host that maintains one connection, and an MCP server is the component that exposes a specific system’s tools and data. A Claude or ChatGPT host, for example, runs an MCP client that speaks JSON-RPC to an MCP server wrapping NetSuite, while a second client connects to a Salesforce MCP server. The server advertises the tools it offers, and the agent calls them. The ecosystem around this pattern grew quickly: more than 10,000 active public MCP servers (Anthropic, December 2025), and the official MCP Registry launched in preview on September 8, 2025. A large catalog of servers is a large connection surface, which is precisely why exposure needs to be managed rather than assumed safe.

MCP is not a replacement for your APIs or your iPaaS. MCP standardizes how an agent discovers and calls capabilities at run time, an API defines a fixed contract for a developer, and an iPaaS such as Boomi or MuleSoft moves and transforms data reliably between systems.

MCP differs from a traditional API because MCP is designed for a non-deterministic agent to discover and select tools at run time, while an API exposes a fixed, developer-wired contract. A REST API assumes a developer knows in advance which endpoint to call and when; MCP lets an agent enumerate the available tools on a server and choose among them based on the task. Andreessen Horowitz describes MCP as replacing N-by-M bespoke integrations, one connector per model-and-system pair, with a modular model. Since that 2025 analysis, MCP has strengthened enterprise access management: the Enterprise-Managed Authorization extension became stable in June 2026, enabling centralized identity-provider-based provisioning and audit across supported clients and servers. That solves an important access-management problem, but it still does not decide whether a particular business action should execute, what approval it requires, or how the outcome should be audited. MCP standardizes and secures the connection; enterprises still need policy and execution governance above it.

MCP does not replace your iPaaS. Boomi and MuleSoft handle durable data movement, transformation, error handling, scheduling, and monitoring between systems, none of which the Model Context Protocol performs. MCP gives an agent a live channel to invoke actions, while the iPaaS remains responsible for how data actually flows and reconciles across the estate. A commissioned Forrester Total Economic Impact study from September 2025 reported that the Boomi Enterprise Platform delivered 347% ROI and 9.8 million dollars in net present value over three years for a composite organization, a vendor-commissioned result rather than independent benchmarking, but a signal that governed integration produces measurable value. The practical stance for MCP-enabled integration is the same one we apply to iPaaS: keep Boomi or MuleSoft where it works, and add a governed MCP layer where agents need to take auditable action.

An MCP-enabled integration runs on a simple loop: the host’s MCP client opens a connection to an MCP server, the server advertises its tools and resources, and the agent calls them over JSON-RPC. Authorization is where most of the enterprise engineering work concentrates.

An MCP server connects an AI agent to an enterprise system by wrapping that system’s operations as callable tools and exposing them to the agent over JSON-RPC. An MCP server for NetSuite, for example, can expose tools to read a sales order, query a customer, or create an invoice, while an MCP server for Salesforce exposes opportunity and account operations. The agent, running in a host such as Claude or ChatGPT, calls those tools through its MCP client, and the server executes each call against the underlying system. A single agent can hold connections to several MCP servers at once, which is what lets one agent span NetSuite, Salesforce, and SAP in the same task rather than stopping at one system boundary.

MCP uses OAuth 2.1 as its authorization baseline for protected remote servers. When authorization is implemented, the MCP specification (revision 2026-07-28) requires authorization servers to implement OAuth 2.1, clients to implement PKCE and verify support, clients to use the S256 code challenge method when technically capable, and MCP servers to validate that access tokens were issued specifically for them as the intended audience. Clients must also apply RFC 9207 issuer validation before redeeming authorization codes and implement Resource Indicators (RFC 8707). The specification recommends Client ID Metadata Documents; Dynamic Client Registration is deprecated but retained for backward compatibility. Enterprise-Managed Authorization can centralize provisioning through an organization’s identity provider, but these controls govern access to the connection, not whether a particular business action should run. Deciding that requires least privilege, policy gates, approval, and audit above the protocol.

Connecting an agent and governing an agent are two different problems. MCP solves the first with a standard, authenticated connection. Governing the action, deciding whether an agent may transact and proving what it did, sits above the protocol and is where most enterprise programs stall.

Connecting an agent exposes a system’s tools to a model, while governing an agent decides which actions are allowed, requires approval for consequential ones, and records every decision. A raw MCP server can hand an agent the ability to create invoices in NetSuite or refund an order in Salesforce, but the Model Context Protocol does not enforce least privilege, human approval, or an audit trail by itself. McKinsey reported in April 2026 that almost nine in ten companies had deployed AI in at least one business function, but 94% of respondents were not seeing significant value; it also observed that many efforts remained focused on incremental pilots rather than deeper transformation. Connectivity is not enough for these programs. Governed execution is the reframe every MCP-enabled integration has to absorb before it reaches production.

A governed MCP layer adds zero-trust authentication, least-privilege authorization, an action allowlist, human-in-the-loop approval, full action logging, and an emergency kill switch on top of the MCP connection. Sage IT delivers this as a governance control plane, a policy-enforced execution bridge that sits between agent platforms and enterprise systems and manages MCP and API exposure above any iPaaS, including Boomi and MuleSoft. The control plane authenticates each agent with role-based access control, checks every action against active policy before it reaches a system of record, logs the decision, and can terminate an agent instantly. In a Sage IT manufacturing engagement, we delivered Order-to-Cash and Procure-to-Pay across NetSuite, Boomi, Shopify, and Procore and reached production in eight weeks with zero custom middleware. The control plane, not the connector, is what made that deployment auditable.

MCP carries real security risks, several of which its own specification documents. The protocol authors name confused-deputy attacks and forbid token passthrough, and independent researchers have already found critical vulnerabilities in MCP tooling.

The main security risks of MCP are prompt injection, tool poisoning, token theft, and confused-deputy attacks. A peer-reviewed 2026 study in the Journal of Cybersecurity and Privacy identified tool poisoning, malicious instructions hidden in a tool’s description or parameters rather than in user input, as the most prevalent client-side MCP vulnerability, and documented a real incident in which a poisoned support ticket exfiltrated integration tokens through Supabase and Cursor. The MCP specification itself names the confused-deputy problem, where an MCP server acting as an intermediary to a third-party API is tricked into misusing its authority, and states that an MCP server MUST NOT pass through the token it received from the client. A standard connection, in other words, can be weaponized through the very metadata that describes its tools.

Mitigate MCP security risks by validating tool metadata, scoping tokens to a single audience, requiring human approval for writes, logging every action, and keeping MCP tooling patched. A critical remote-code-execution flaw in Anthropic’s MCP Inspector (CVE-2025-49596, CVSS 9.4) allowed an attacker to compromise a developer’s machine simply by luring them to a malicious website, until Anthropic patched it in version 0.14.1. More recently, the National Vulnerability Database recorded CVE-2026-44192 in the Ansible Lightspeed MCP server, where indirect prompt injection could cause unauthorized file writes and malicious command execution. NIST AI 600-1 classifies direct and indirect prompt injection as information-security risks, while NIST AI 800-5 reports broad agreement that AI agents introduce novel security threats and that established cybersecurity practices require adaptation. A governance control plane centralizes these mitigations, applying authentication, scoping, approval, and logging once at the execution layer rather than re-implementing each control inside every MCP server.

Enterprise data can leave your boundary when an agent uses MCP, because the model processes whatever a tool returns, so data governance has to be designed in rather than assumed. An MCP server that exposes a broad read-customer tool can hand full records, including personally identifiable information, to a model running outside your network. Apply data minimization: scope each MCP tool to the narrowest fields the task needs, redact sensitive attributes at the server, and prefer deployment models that keep data inside your own VPC. NIST AI 600-1 treats data leakage and data poisoning as information-security risks to manage, and a governance control plane enforces field-level scoping and logs exactly what data each agent action touched. For regulated workloads and the frameworks that apply, such as the EU AI Act and the NIST AI Risk Management Framework, see our guide to enterprise AI agent governance.

MCP-enabled integration rolls out in stages, from read-only access to governed cross-system execution. The goal is to earn autonomy from a clean audit trail, not to grant it on day one.

Stage the rollout in five steps: start read-only, move to propose-only, require human approval for writes, grant scoped autonomy in one system, then expand to governed cross-system execution. Begin with read-only MCP access so an agent can retrieve data from NetSuite or Salesforce without changing anything. Move to propose-only, where the agent drafts an action but nothing executes. Add human-in-the-loop approval for any write that carries financial, legal, or safety consequence, using a propose-then-approve pattern. Grant least-privilege write access in a single system once approvals are clean, and only then expand to cross-system workflows such as Order-to-Cash. An emergency kill switch and full action logging stay on at every stage, so autonomy is always reversible.

The cost of MCP-enabled integration scales with scope and governance depth, and the larger decision for most enterprises is whether to build the governed layer in-house or buy it. A read-only agent on one system is inexpensive; a governed, cross-system deployment carries build, approval-design, and ongoing operating costs.

The cost of MCP-enabled integration is driven by the number of MCP servers, the depth of governance controls, approval-workflow design, monitoring, and the ongoing maintenance tail. Each MCP server that wraps a system such as NetSuite or SAP needs building, securing, and patching, and MCP tooling has already required urgent fixes such as CVE-2025-49596 and CVE-2026-44192. Governance adds authentication, least-privilege scoping, human-approval routing, and action logging, which are one-time to design and continuous to operate. The 2026 MuleSoft Connectivity Benchmark, surveying 1,050 IT leaders, found 88% on track for partial or full agentic transformation, but 50% of AI agents run in isolated silos. MuleSoft calls it an orchestration-and-governance gap, not a connection gap. Ungoverned MCP sprawl widens that gap rather than closing it. Treat MCP-enabled integration as a governed platform with a run cost, not a one-off connector, and see our guide to reducing enterprise integration costs for the maintenance-tail argument.

Build a governed MCP layer in-house only if you can carry the security and maintenance burden; otherwise, buying or partnering reaches production more reliably. Building gives full control but means implementing authentication, scoping, approval, logging, and patch management across every MCP server as the specification and threat landscape evolve. Buying or partnering delivers the governance control plane, a policy-enforced execution bridge above your iPaaS, without rebuilding those controls system by system. Sage IT delivered a governed Order-to-Cash and Procure-to-Pay deployment across four systems in eight weeks with zero custom middleware by standing up the control plane rather than hand-coding it.

A full governance layer is not required for every MCP-enabled agent. Matching the control to the risk avoids overbuilding where a lighter approach is safe and defensible.

You do not need a full governance layer when an MCP-enabled agent is read-only, single-system, and low-risk. A support agent that summarizes tickets in one system, or an analyst agent that runs read-only queries against a data warehouse, can rely on that system’s native role-based access control and logging combined with MCP’s OAuth 2.1 handshake. A governance control plane earns its place when agents write, transact, or act across multiple systems such as NetSuite and SAP, when an action carries financial or regulatory consequence, or when many agents share one enterprise stack. Reach for execution-layer governance when the blast radius of a wrong action crosses a system boundary, and keep the approach proportionate when it does not.

Quotable takeaway: The Model Context Protocol standardizes the connection; it does not govern the action. Anthropic released MCP on November 25, 2024, and OpenAI, Google, and Microsoft had announced platform support by May 2025.

Quotable takeaway: McKinsey reported in April 2026 that almost nine in ten companies had deployed AI in at least one business function, yet 94% of respondents were not seeing significant value.

Quotable takeaway: A raw MCP server exposes tools to an agent; a governance control plane exposes auditable business actions and records every decision.

Quotable takeaway: The MCP specification (revision 2026-07-28) requires OAuth 2.1, PKCE, S256 when technically capable, Resource Indicators (RFC 8707), issuer validation, and token-audience binding; those controls secure the connection, not the business decision.

Quotable takeaway: Keep Boomi or MuleSoft where it works, and add a governed MCP layer where agents need cross-system, auditable execution.

Quotable takeaway: Enterprise-Managed Authorization can centralize who may connect to MCP servers; it still does not decide which business actions an agent may execute.

The most common mistake is treating MCP as the finish line, standing up MCP servers straight to production systems and granting agents broad write access without an execution-layer control. A standing MCP connection with over-broad OAuth scopes creates the kind of production governance gap Gartner highlighted in May 2026: Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents because governance failures become visible only after production incidents. The fix is to classify agents by autonomy and blast radius, enforce zero-trust authentication and least-privilege scopes at run time, gate consequential actions with meaningful human approval, and log every action, so governance is something the system does at the point of action rather than something a design document asserts.

MCP adoption is not the same as agent value because the protocol solves connectivity, and connectivity alone does not create enterprise impact. McKinsey’s State of AI, published in November 2025, found that 88% of organizations used AI in at least one function, up from 78% a year earlier, but only about one-third had begun scaling AI programs across the enterprise. Its April 2026 analysis reported that 94% of respondents were not seeing significant value. Widespread adoption alongside limited enterprise impact reinforces the point: the constraint is governed, cross-system execution, not access to a model or connector. MCP-enabled integration creates value only when the agent can act safely across systems, which is a governance outcome, not a protocol feature.

Map your AI agent use cases against a governance model before you wire MCP servers to production. Sage IT’s MCP-enabled integration assessment classifies which of your workflows are single-system and read-only versus cross-system and transactional, identifies which agent actions need least-privilege scoping and human approval, and shows where native controls are sufficient and where a policy-enforced execution bridge is warranted. The output is a prioritized, auditable rollout plan you can take to security, integration, and the business.

MCP-enabled integration is an architecture decision, not a connector install. The Model Context Protocol standardized how AI agents connect to NetSuite, Salesforce, and SAP, and platform adoption is now broad, but widespread AI use alongside limited enterprise value shows that connection is not enough. Keep your iPaaS where it works, govern the action above the protocol with least privilege, approval, logging, and a kill switch, and the connection finally becomes safe to act on.

Anthropic, Introducing the Model Context Protocol (Nov 25, 2024)

OpenAI, New tools and features in the Responses API: remote MCP server support (May 21, 2025)

Google, Google I/O 2025 Gemini updates: native MCP SDK support (May 2025)

Microsoft, MCP is generally available in Copilot Studio (May 29, 2025)

Model Context Protocol Specification, Authorization (revision 2026-07-28)

Model Context Protocol Specification, Authorization Security Considerations (revision 2026-07-28)

Model Context Protocol, Enterprise-Managed Authorization: Zero-touch OAuth for MCP (June 18, 2026)

Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation (Dec 9, 2025)

Andreessen Horowitz, A Deep Dive Into MCP and the Future of AI Tooling (2025)

NVD (NIST), CVE-2025-49596: MCP Inspector RCE (CVSS 9.4)

NVD (NIST), CVE-2026-44192: Ansible Lightspeed MCP server path traversal and indirect prompt injection (July 22, 2026)

Journal of Cybersecurity and Privacy (MDPI), MCP Threat Modeling and Tool Poisoning (2026)

NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative AI Profile (2024; updated Apr 2026)

NIST AI 800-5, Security Considerations for AI Agents (May 18, 2026)

MuleSoft, 2026 Connectivity Benchmark Report

McKinsey, The State of AI in 2025: Agents, Innovation, and Transformation (Nov 5, 2025)

McKinsey, Where AI Will Create Value – and Where It Will Not (Apr 29, 2026)

Gartner, Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure (May 26, 2026)

Forrester Total Economic Impact of the Boomi Enterprise Platform (commissioned, Sept 2025)