MCP and enterprise integration: Architecture, governance and hybrid patterns

Most enterprise AI pilots stall at the same point. The AI works. The data exists. But there is no governed path to connect them. The integration architecture that has served enterprises for a decade — point-to-point APIs, event buses, centrally managed iPaaS — was not designed for autonomous AI agents that need to discover tools, reason across systems and act without constant human direction.

Model Context Protocol (MCP) changes the interface layer between AI and enterprise systems, but it does not replace the integration architecture beneath it. Understanding how MCP fits into existing enterprise integration patterns, and where it requires new architectural thinking, is what separates AI pilots from AI in production.

This article is written for integration architects and senior IT professionals evaluating how to design, govern and deploy MCP-based agentic AI in real enterprise environments.

What MCP changes in enterprise integration

MCP (Model Context Protocol) is an open standard that defines how AI agents discover, authenticate against and invoke external tools and data sources. It replaces the bespoke adapter pattern, where each AI-to-system connection is custom-built, with a standardized, discoverable interface.

Before MCP, connecting an AI agent to a business system meant writing a custom integration for each system. One system, one project, one maintenance burden. Multiply that across the 85+ operational systems a typical large enterprise runs, and you have a pipeline that cannot scale.

MCP collapses the discovery and invocation layer into a protocol. The agent asks what tools are available, authenticates once and calls them through a consistent interface. What it does not change is everything beneath that interface: the authentication infrastructure, the data residency rules, the audit requirements, the access control model, the network topology and the legacy systems that have no API at all.

The key architectural insight

MCP is a protocol, not a platform. It standardizes the interface between AI agents and tools, but it does not govern who can call what, what data can leave the network or what happens when the agent does something unexpected. That is what the enterprise integration layer is for, and why MCP deployed without an integration governance platform creates new risk rather than eliminating it.

The core problem: Legacy systems are AI-blind

The most important architectural reality in enterprise AI integration is one that most vendor conversations skip over: the systems where most enterprise data lives (legacy ERPs, proprietary databases, in-house finance platforms, mainframe-adjacent systems) have no native MCP interface, no modern API in many cases and no pathway to AI connectivity without a middleware gateway.

Modern SaaS platforms (CRMs, communication tools, cloud storage) are increasingly adding MCP connectors directly. An AI agent can already reach Salesforce, Slack or SharePoint through dedicated MCP integrations. But those are not the hard integration problems. The hard problems are the systems enterprises have been running for 10, 20 or 30 years that hold the most critical data and have no pathway to modern connectivity.

The real enterprise AI integration challenge is connecting AI to the SAP system, the in-house finance platform, the custom-built database that holds 20 years of transaction history. These systems are where the gateway pattern becomes essential.

Three Enterprise MCP architecture patterns

There is no single correct architecture for enterprise MCP deployment. The right pattern depends on the system landscape, data sovereignty requirements and the governance model the organization needs. Three patterns cover the majority of enterprise scenarios.

PATTERN: 1

Centralized MCP gateway

A single MCP gateway sits in front of all enterprise systems. All AI agents authenticate to the gateway; the gateway routes and governs all tool invocations. Provides maximum central visibility and policy enforcement. Works well when all systems can be reached from a single network segment. Frends implements this pattern with its control plane governing all Agent-level MCP servers.

When to use it: Organizations with a relatively unified network topology; enterprises that prioritize central governance over distributed deployment; initial MCP deployments where simplicity matters.

Architecture components: Frends control plane (cloud or on-premises) → API Management layer with API Policies → MCP Trigger processes per system → AI agents authenticate to the central gateway.

Governance characteristics: All tool invocations pass through a single policy enforcement point. Role-based tool filtering, geofencing and audit logging are applied centrally. SIEM integration feeds from one log source.

PATTERN: 2

Distributed agent-per-system MCP

Each Frends Agent acts as an independent MCP Server, deployed co-located with the system it governs. An AI agent that needs to call SAP reaches an MCP server running inside the SAP network segment; one that needs the internal database reaches a separate MCP server in that segment. The AI orchestration layer coordinates across multiple independent MCP servers. Provides the strongest data isolation per system.

When to use it: Organizations with strict network segmentation; regulated environments where data from one system must never transit the same network path as data from another; scenarios where different systems have different residency requirements.

Architecture components: Frends control plane → Multiple independent Frends Agents, each acting as its own MCP Server → AI Connector v2 orchestrates across multiple scoped toolboxes → Each agent enforces its own API Policies.

Governance characteristics: Per-agent access control means the AI can only see the tools it has been explicitly permitted to reach in each reasoning step. If the credit-risk agent is authorized for the company registry and the loan system, it cannot reach the HR system — even if the AI model attempts to do so.

PATTERN: 3

Hybrid cloud + On-premises MCP

Cloud-hosted MCP servers handle modern SaaS and cloud system integrations; on-premises Frends Agents handle legacy and sensitive systems that must not leave the corporate network. AI orchestration runs in the cloud, but tool invocations that touch regulated data execute on-premises. The control plane governs both from a single management interface. This is the most common pattern for regulated European enterprises.

When to use it: Organizations with a mixed landscape of modern SaaS and legacy on-premises systems; regulated industries with GDPR data residency requirements; enterprises where some data must remain on-premises but operational efficiency argues for cloud-managed orchestration.

Architecture components: Frends control plane (cloud, customer-selected Azure region) → Cloud Agents for SaaS integrations → On-premises Agents with MCP Trigger for legacy systems → All agents establish outbound connection to control plane; no inbound internet connections to on-premises agents.

Critical security note: In Frends' architecture, all agents establish an outbound connection to the control plane. There are no inbound connections from the internet to on-premises agents. The agent initiates; the control plane responds. This means legacy systems behind a corporate firewall can participate in MCP orchestration without opening inbound firewall rules.

Governance layer architecture: What needs to sit between AI and systems

Deploying MCP without a governance layer is the same as giving an AI agent direct database access without any access control. The agent can reach anything it can discover, do anything the credentials permit, and there is no record of what it did.

A production-grade enterprise MCP governance layer has six components. Each one maps to a specific class of compliance or operational risk.

The governance components above are not independent tools assembled from different vendors. In Frends, they are all part of the same platform that already governs your REST APIs. IT does not learn a new security model; it extends the model it already operates.

The BPMN audit trail: Making AI reasoning readable for humans

Every enterprise AI governance framework eventually runs into the same question: when something goes wrong or when a regulator asks, can you show what the AI did and why?

Log files answer this question for developers. They do not answer it for compliance officers, auditors or business stakeholders who need to understand the decision chain without writing a query against a log database.

BPMN visualization of the AI reasoning chain is the mechanism that makes AI actions auditable by humans without code. Every Thought → Action → Observation step in the ReAct reasoning loop is rendered directly in the Frends BPMN process canvas with the same visual representation that developers, IT and compliance teams already use to read integration logic.

How the ReAct reasoning loop maps to BPMN

The ReAct pattern (Reason + Act) is how modern AI agents think. Each iteration has three steps:

1. Thought: The AI reasons about the current state and decides what to do next

2. Action: The AI calls a specific MCP tool with specific parameters

3. Observation: The AI receives the tool result and reasons on it before the next step

In Frends, this loop is not a black box. Each iteration is a visible step in the BPMN canvas, with the tool invoked, the parameters passed, and the result received all logged and displayed. A compliance officer reviewing a flagged insurance claim can see exactly which systems the AI queried, in what order, what data it retrieved and what conclusion it drew, without needing a developer to translate the log file.

For EU AI Act compliance, this is a must-have. High-risk AI systems, those making or influencing decisions that significantly affect individuals, must be able to demonstrate transparency and human oversight. A BPMN-visualized reasoning trail is what makes that demonstrable in practice.

Hybrid deployment decision framework

The right deployment model for enterprise MCP is determined by four factors: data sensitivity, network topology, sovereignty requirements and operational complexity tolerance. The decision tree below maps these factors to deployment options.

Decision point 1: Does any regulated data stay strictly on-premises?

Yes → On-premises Frends Agent with MCP Trigger is required for that system. The agent runs inside the corporate network; no data leaves. The control plane can be cloud-hosted; only configuration and telemetry (not payload data) transit to it. This is the model for GDPR-regulated data under strict interpretation, HIPAA-protected health information, financial data under PCI DSS with internal network requirements and air-gapped environments in defence, critical infrastructure or public sector.

No → Cloud-hosted Agents or hybrid model is viable. Proceed to Decision Point 2.

Decision point 2: Are there air-gapped or zero-internet-access requirements?

Yes → Fully on-premises deployment with local AI model (e.g. Ollama). Frends control plane runs on-premises. No data at any layer (model inference, tool invocation, audit logs) leaves the customer's network. Frends supports this architecture natively; it is the only enterprise iPaaS that does.

No → Hybrid or cloud deployment is viable. Proceed to Decision Point 3.

Decision point 3: Are there multiple network segments with different data classifications?

Yes → Distributed Agent-per-System pattern. Deploy separate Frends Agents per network segment, each acting as an independent MCP Server. AI Connector v2 orchestrates across segments with scoped toolbox access per step. No data from one segment transits another's network path.

No → Centralized gateway or standard hybrid pattern is appropriate. A single Frends Agent (or cluster for HA) handles all systems. Centralized governance, single audit log stream, simpler operations.

Critical architecture note: agent connection model

In Frends' architecture, all Agents establish an outbound connection to the control plane. There are no inbound internet connections to on-premises Agents. This means legacy systems behind a corporate firewall can participate in MCP orchestration without any firewall rule changes for inbound traffic. The Agent reaches out; the control plane directs it. This is architecturally significant for enterprises with strict perimeter security models.

Scoped toolbox design: Least privilege for AI agents

The most common enterprise AI governance failure is over-permissioned agents. An AI agent is given access to everything it might conceivably need, all systems, all operations, all data. This is the equivalent of giving every employee a master key. It simplifies the initial configuration, and it creates catastrophic blast radius when something goes wrong.

Least-privilege tool access for AI agents means each reasoning step can only invoke the tools it has been explicitly authorized to use for that step. Not the agent overall, but the individual reasoning step. A five-step AI workflow should have five different toolboxes, each containing only what that step needs.

How scoped toolboxes work in practice

In Frends AI Connector v2, each AI reasoning step is assigned an explicit toolbox with a defined list of MCP tools that step is permitted to call. If the AI model attempts to invoke a tool outside the assigned toolbox for that step, the call is rejected before execution. The attempt is logged.

A credit risk pre-screening workflow with three AI steps illustrates the pattern:

The AI model never has access to the HR system, the finance ledger, or any write operations on data systems — not because those tools don't exist on the platform, but because they are not in the toolbox for any of these three steps. Even if the AI model were to generate a request for those tools, the governance layer would reject it before execution.

This pattern satisfies the principle of least privilege as articulated in SOC 2, ISO 27001, and EU AI Act guidance on human oversight of high-risk AI systems. It is enforceable, auditable and visible in the BPMN canvas.

Connecting MCP to existing enterprise infrastructure

Enterprise MCP governance does not operate in isolation. It must integrate with the monitoring, security and operational infrastructure organizations already operate. The integration points that matter most in practice are SIEM integration, DevOps pipeline, API management, and human-in-the-loop workflows.

SIEM integration

Frends supports integration with SIEM tools (Splunk, Microsoft Sentinel, and equivalents) for continuous security monitoring. Every MCP tool invocation generates a log entry with agent identity, tool called, parameters, output, duration and outcome. These logs can be exported to SIEM in real time, enabling security operations teams to detect anomalous agent behaviour, such as unusual invocation patterns, attempts to call out-of-scope tools, excessive call volumes, by using the same detection rules they apply to human user activity.

For regulated enterprises, SIEM integration is not optional. SOC 2 Type 2 audit requirements and ISO 27001 controls both require evidence of continuous monitoring. Frends' audit logs are structured, queryable, and designed for SIEM ingestion.

DevOps pipeline and version control

Every Frends process — including MCP Trigger processes that govern AI tool access — is subject to the same DevOps pipeline as any other integration. Changes go through Dev → Test → Production with version control, automated testing, and one-click deployment. Environment variables handle system-specific connection strings so the same process logic works across environments without modification.

This means AI tool governance is treated as code: versionable, reviewable, deployable, and rollback-capable. When a governance rule changes, the change goes through the same change management process as a business-critical integration update.

API management and centralized policy enforcement

MCP tools in Frends are governed by the same API Policies that govern all REST APIs: OAuth 2.0, JWT validation, rate limiting, IP whitelisting and data masking. IT does not operate a separate security model for AI agent access. The same team, the same tooling and the same policies, extended to cover AI invocations.

This architectural decision has a practical consequence: when a new AI agent is onboarded or a new MCP tool is created, the governance team does not need to learn anything new. They apply the API Policy framework they already operate. AI governance becomes an extension of API governance, not a parallel discipline.

Human-in-the-loop and long-running processes

Not every AI decision should execute autonomously. For high-stakes actions, like approving a credit limit above a threshold, settling an insurance claim above a value and creating a financial journal entry, the appropriate architecture includes a human approval step before the AI proceeds.

Frends' Long-Running Process (LRP) feature, introduced in version 6.2, enables AI workflows to pause at a defined step, send a notification to a human approver, and resume when the approval is received, without losing state. The AI reasoning completed so far is preserved; the human sees the AI's recommendation and the evidence behind it in the BPMN canvas; the human approves or overrides; the process continues.

This pattern directly satisfies the EU AI Act's human oversight requirement for high-risk AI systems. It is not a workaround but an architecturally clean way to build human oversight into AI workflows from the start.

Deployment checklist for production MCP in regulated environments

The following checklist covers the minimum architecture decisions required before deploying MCP-based AI workflows in a regulated enterprise environment.

Network and infrastructure

• Determine which systems require on-premises Agent deployment (regulated data that must not leave the network)
• Confirm outbound-only firewall rules for Agent-to-control-plane connections (no inbound internet access to on-premises Agents required)
• Configure VPC or private network segmentation for MCP infrastructure
• Enable TLS 1.2+ on all Agent communication channels
• For air-gapped environments: deploy Ollama locally and confirm no AI inference traffic leaves the network

Identity and access

• Configure SSO with Azure Entra ID (or equivalent IdP) for control plane access
• Define RBAC roles for: process developers, IT governance operators, compliance reviewers, business monitors
• Create API Policies for each MCP tool: OAuth 2.0 / JWT required, rate limiting set, IP restrictions applied
• Assign scoped toolboxes per AI reasoning step — deny-by-default, explicit allow-list per step

Audit and compliance

• Enable immutable audit logging for all MCP tool invocations
• Configure SIEM export (Splunk, Sentinel, or equivalent) with real-time log forwarding
• Verify audit log retention policy meets regulatory requirements (GDPR: minimum 6 months recommended; HIPAA: 6 years)
• Confirm DPA with Frends covers both storage and processing of regulated data
• Review BPMN reasoning trail readability with compliance officer before go-live

AI model and tooling

• Confirm BYOAI model: Azure Inference API (cloud) or Ollama (on-premises) — no Frends AI model credits charged for BYOAI
• Test scoped toolbox enforcement: attempt to invoke out-of-scope tool from AI reasoning step — confirm rejection and logging
• Validate human-in-the-loop step if any AI decision exceeds defined risk or value threshold
• Run EU AI Act conformity assessment if any deployed AI workflow qualifies as high-risk

Operations and observability

• Configure monitoring dashboards for: process execution counts, MCP tool invocation rates, error rates, latency percentiles
• Set alerting rules for anomalous agent behaviour (unusual tool call volume, repeated out-of-scope attempts)
• Test rollback: verify that reverting an MCP Trigger process version restores previous governance behaviour
• Document the governance model: which agents are authorized for which tools, per step — treat this as architecture documentation

Frequently Asked Questions

What is the difference between an MCP server and an MCP gateway?

An MCP server exposes tools that AI agents can discover and invoke. An MCP gateway is an MCP server that also enforces governance (access control, authentication, logging, routing policy, and content safety) before allowing a tool invocation to reach the underlying system. In Frends, each Agent acts as both MCP server and MCP gateway simultaneously: it exposes the process as a callable tool and enforces all API Policies before the invocation executes.

Can Frends MCP Trigger connect to systems with no REST API?

Yes, with important nuance. The MCP Trigger wraps a Frends Process as an AI-callable tool. That Frends Process can use any of Frends' 400+ open-source connectors, including connectors for legacy protocols (file-based, database-direct, SOAP, proprietary adapters). The underlying system does not need a REST API but a Frends connector, which can be built with the .NET Connector SDK if a pre-built connector does not exist. The MCP layer above it is protocol-agnostic: the AI sees a governed tool; what happens inside the process is invisible to the model.

How does Frends prevent AI agents from accessing systems they are not authorised for?

Through scoped toolboxes and deny-by-default API Policies. Each AI Connector step is assigned an explicit list of permitted MCP tools for that step. Any invocation attempt against a tool not in the toolbox is rejected at the API Policy layer before execution and logged as an unauthorized attempt. The AI model never receives an error that exposes system details, it simply sees a permissions error. This is enforced at the infrastructure layer, not the application layer, so it cannot be bypassed by prompt injection or model misbehaviour.

How do we connect Frends audit logs to our SIEM?

Frends supports SIEM integration natively. All process execution logs, including MCP tool invocations, can be exported in real time via standard log forwarding protocols. For Microsoft Sentinel, Frends provides direct Azure Monitor integration. For Splunk and other SIEMs, logs can be forwarded via syslog, HTTP Event Collector or Azure Event Hub depending on the SIEM configuration. Contact the Frends solutions team or consult docs.frends.com for connector-specific configuration guidance.

What is the Frends control plane, and does it see production data?

The Frends control plane handles configuration, deployment, monitoring metadata and governance policy distribution. It does not process payload data from process executions by default. Process execution happens on Frends Agents, which can run on-premises in the customer's network. You control what log data is sent to the cloud control plane, and none of the protected payload data needs to leave the Agent. For the highest sensitivity environments, the control plane itself can be deployed on-premises.

How does Frends support the EU AI Act's human oversight requirement?

The EU AI Act requires that high-risk AI systems allow qualified humans to effectively oversee the AI system. Frends supports this in two ways: (1) Long-Running Processes enable AI workflows to pause at defined decision points and request human approval before proceeding, preserving AI reasoning state while a human reviews. (2) BPMN-visualized reasoning trails give compliance officers a readable record of every AI decision, accessible without developer involvement, satisfying the auditability dimension of human oversight. Both features are available in Frends 6.2 and 6.3 respectively.

Can different AI models, like Claude, GPT-4 or local models, be used with Frends MCP?

Yes. Frends uses a BYOAI (Bring Your Own AI) model. The AI Connector supports Azure AI Inference API, which provides access to models including Claude, GPT-4, and Azure-native models. For on-premises and air-gapped deployments, Ollama is supported for locally-hosted models. Frends does not require a specific AI model vendor, the platform is model-agnostic at the orchestration layer. Customers using their own Azure or Ollama models pay zero additional Frends Credits for AI model usage.