Integration fabric

The integration fabric layer (R03) connects company systems to each other. It holds the integration bus, API gateways, file transfer, market and industry hubs, and event streams. It is one of the fourteen layers. Agents add one thing above all: a tool gateway that every agent request passes through. There the request is checked, given short-lived credentials, and recorded. Tools come from your own approved list, not from the public internet. Start by extending the API management you already run.

What sits in this layer today

The standards between these systems differ by industry. Australian electricity uses AEMO B2B procedures (aseXML) and NEM12 and NEM13 meter files. New Zealand uses EIEP files. Hospitals use HL7 v2, FHIR R4 (AU Base, AU Core, NZ Base) and DICOM. Plants use OPC UA, Modbus, DNP3, IEC 61850, and MQTT with Sparkplug. Vendor names are examples from industry knowledge (typical, unsourced). The full estates are on the utilities, healthcare and energy pages.

What agents add

This layer becomes the tool path for agents. It hosts the tool gateway, one of the seven capabilities an agent platform provides. Agent tools are added to the existing bus and gateway, not beside them.

layer · architecture

The governed tool path

No direct model-to-server connections: one gateway enforces allowlists, identity exchange, credential injection, description integrity, and audit on every tool call.

1. 01Agent

   Agent

   Agent

   Holds no credentials

2. 02Control

   Control

   MCP gateway

   Allowlist, RFC 8693 token exchange, credential injection, description-integrity check, classification routing, rate limits

3. 03System

   System

   MCP server

   Curated catalog entry; version-pinned

4. 04System

   System

   Governed API

   Entitlement, validation, audit already enforced

5. 05System

   System

   System of record

6. 06Evidence

   Evidence

   SIEM

   Action-granular audit

The gateway enforces the arriving auth standards (EMA/XAA, ID-JAG); it does not replace them.

Diagram description: Tool path architecture from agent through gateway enforcement stages to MCP server, governed API, and system of record, with SIEM audit tap. The map contains Agent: Holds no credentials; MCP gateway: Allowlist, RFC 8693 token exchange, credential injection, description-integrity check, classification routing, rate limits; MCP server: Curated catalog entry; version-pinned; Governed API: Entitlement, validation, audit already enforced; System of record; SIEM: Action-granular audit. Its connections are agent to gateway for every tool call; gateway to server; server to api; api to record; gateway to siem for audit tap. Important boundary: The gateway enforces the arriving auth standards (EMA/XAA, ID-JAG); it does not replace them.

One gateway for every tool call

The Model Context Protocol (MCP) is the open standard for connecting agents to tools and data. It is the contract between an agent and a tool. A gateway sits between them. It can be a dedicated product or an extension of your API management. There are no direct connections from a model to a tool server. The gateway does six jobs on every call. It checks which agent is calling and for whom. It checks the tool is on the approved list. It supplies credentials at the moment of the call, so the agent never holds a secret. It checks whether the tool's description has changed. It routes by data classification and applies rate limits. It writes an audit record to the security team's central event system.

MCP has changed fast, and what a gateway can enforce depends on the version it speaks. The 2026-07-28 version lets ordinary web gateways route and authorise calls without reading the request body. The standard moved to the Agentic AI Foundation, under the Linux Foundation, on 9 December 2025. That makes long-term investment in a gateway built on it easier to defend.

Tools that are safe by default

Tools are read-only unless marked otherwise. MCP lets each tool declare itself read-only, destructive, or safe to repeat. The gateway uses those labels to decide what needs approval. Every tool that changes something carries a repeat-safe key, so a retried call does not repeat the change. It also returns a receipt. The undo step is written before the tool ships, not after the first duplicate. Approvals go through the gateway, using MCP's built-in way for a tool to ask a person. That keeps approvals out of each agent's own code.

Your own approved list of tools

The public MCP registry has about 2,000 entries and is a preview. It helps you find tools. It is not a sign that a tool is safe. Run a private registry as the single source of approved tools. Treat tool descriptions like code: reviewed, versioned and checked for changes. New tools and changed descriptions pass tests before agents can use them. That is the change stage of the agent lifecycle, applied to tools.

Events, older bots and the legacy core

A business event on a stream can wake an agent. That beats polling, asking again and again whether anything changed, on both speed and cost. Robotic process automation (RPA), the older screen-clicking bots, stays where no API exists. The agent reasons, and the bot carries out fixed steps under supervision. Replace a bot only when a workload earns it.

Old core systems are wrapped behind governed APIs and retired piece by piece. Do not wait for a full replacement. Of surveyed mainframe modernisation programmes, 74 percent fail to complete. Existing gateways can expose governed APIs as tools with no change to the system behind them. Govern each API path before agents use it.

The parts and where they run

What must be true before an agent touches it

Every tool call goes through the gateway. No agent connects straight to a tool server.

The agent holds no secrets. Credentials are supplied at the moment of the call and expire soon after.

The agent acts with the permissions of the person who asked. The gateway exchanges the person's identity for a narrow token, using the RFC 8693 standard. That keeps the delegation chain intact from the person to the system. The identities and rules it checks come from security and identity (R10).

A changed tool description is approved again. Models read tool descriptions as instructions. A hidden instruction in a description can take over an agent. So the gateway compares each description with the approved version.

Changes are safe to retry and can be undone. Each change carries a repeat-safe key and returns a receipt. Timeouts, automatic cut-offs for failing systems, and alerts on retry storms complete the set. When a system fails, work falls back to a human queue.

The gateway itself is hardened. Attacks on tool connections already happen. A malicious tool package, postmark-mcp, reached about 300 organisations in September 2025. A flaw at the Smithery hosting service leaked tokens for more than 3,000 tool servers in October 2025.

There is a kill switch at the gateway. It stops an agent's tool calls at once.

The gateway is the enforcement point for every tool call. It sits outside the model, so the model cannot talk its way past it. This is enforcement outside the model. Inside each business system, the system's own checks still apply, as the systems of record (R04) page explains.

Choices and their verdicts

Each entry is the common choice, tested against the simplest credible alternative. The full records are in the decision catalog.

• A dedicated MCP gateway or your API management: extend what you have by default. Add a dedicated gateway for description checks, approvals and links across several runtimes.
• Replace RPA bots or keep them: keep them, supervised. Replace one only when a workload earns it.
• Agent-to-agent protocols now or plain APIs: not yet for most. Use them only for links between organisations.
• Modernise the integration bus first or work around it: wrap the old bus and retire it piece by piece. Govern before you wrap.

Concerns this layer must honour

A concern is a requirement every layer must honour. This layer carries a specific duty for seven of the ten.

• Identity and access. The gateway enforces identity on every call. Credentials are supplied at the call, never held.
• Traceability and audit. Every action is recorded to the security team's event system, with who approved what.
• Impersonation and authenticity. Tool servers are checked against the approved list, with signed and pinned versions.
• Sovereignty and residency. The gateway routes calls by data classification.
• Safety and oversight. Tools are read-only by default. Destructive tools need approval. The gateway holds a kill switch.
• Cost. Calls are metered per tool and per agent. Rate limits act as budgets.
• Resilience. Timeouts, cut-offs and safe retries, with a fall back to human queues.

The full grid of concerns against layers is the concern matrix.

Evidence and limits

The attack record is dated, and most incidents carry public vulnerability identifiers. The gateway features come from the MCP specification and vendor documents. The estate figures about API governance come from surveys, and are reported as surveys.

What the sources do not show is a gateway that stops every attack. The Smithery case shows the gateway can become the target. This guide recommends treating the gateway as a system to harden, not as a guarantee.

Next step

See this layer at work in prioritising vegetation inspections, where tool servers already reach the work order system. Then read the next layer, systems of record (R04).

Explore this topic

• Integration fabric findings and sources.

MCP versions

• 2024-11-05: the first release.
• 2025-03-26: added OAuth 2.1, Streamable HTTP transport and tool annotations.
• 2025-06-18: added resource servers (RFC 8707) and elicitation, a way for a tool to ask the user for input.
• 2025-11-25: added OpenID Connect discovery.
• 2026-07-28: a stateless core with header-based routing, so gateways need not parse request bodies.
• 2026-07-28 also added an extensions framework, including Enterprise Managed Authorization.
• 2026-07-28 also added a deprecation policy, cached list results and the multi-step input_required flow.
• Governance moved to the Agentic AI Foundation, under the Linux Foundation, on 9 December 2025.

Gateway controls

• Token exchange per RFC 8693, and on-behalf-of flows.
• Cross App Access, adopted as MCP Enterprise Managed Authorization.
• The IETF ID-JAG draft, an identity assertion grant, enforced as it arrives.
• Per-tool role-based access control on the caller's identity.
• Description checks that compare each tool description and force approval again on change.
• The gateway enforces the arriving authorisation standards. It does not replace them.

The attack record

• Tool poisoning, hidden instructions in a tool's description, was demonstrated in April 2025.
• The MCPTox benchmark measured up to 72.8 percent attack success across 20 models.
• In MCPTox, models refused under 3 percent of those attacks.
• The postmark-mcp backdoor (September 2025) reached about 300 organisations.
• CVE-2025-6514 scored 9.6 on CVSS. The affected package had 437,000 downloads.
• The MCP Inspector flaw is CVE-2025-49596.
• Asana had a leak across customers (June 2025).
• Supabase had a data theft chain that ran through a support ticket (July 2025).
• A path traversal flaw at Smithery leaked tokens controlling more than 3,000 servers (October 2025).

Registry and legacy

• The public MCP registry held roughly 2,000 entries, at preview quality.
• 87 percent of surveyed mainframe shops run IBM's CICS, at about 30,000 transactions per second at peak.
• 74 percent of mainframe modernisation programmes fail to complete.

Survey figures on API governance

• Under half of enterprise APIs are managed. Some 27 percent are ungoverned.
• Under 40 percent of organisations enforce central API governance.
• 19 percent of security chiefs claim full API visibility.

Refusals and checks

• Refused: a widely circulated share of API gateway vendors shipping MCP by the end of 2026. No primary source was found.
• Re-verify each quarter: MCP registry maturity.
• Re-verify each quarter: progress of Enterprise Managed Authorization and ID-JAG.
• Re-verify each quarter: gateway vendor support for the 2026-07-28 specification.