# Integration fabric How agents reach company systems: one standard way to connect tools, one gateway every request passes through, and the checks, credentials and audit record applied there. Author: Murali Sid (https://linkedin.com/in/muralisid) Source: https://www.agenticarchitectureskills.com/layers/r03-integration-fabric Published: 2026-08-20 Updated: 2026-10-15 Licence: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/ Cite as: Murali Sid. Integration fabric. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/layers/r03-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](/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 [#what-sits-in-this-layer-today] | System category | Electricity distributor | Water utility | Hospital network | Generator, oil and gas, or miner | | ------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Integration bus and API gateway | Integration bus or platform (SAP PI/PO or Integration Suite, MuleSoft, Boomi, TIBCO, IBM MQ). API gateway | Same as the distributor | Integration engine (Rhapsody, InterSystems HealthShare, Mirth, Cloverleaf). API gateway (Azure API Management, Apigee, MuleSoft) | Integration platform or bus (MuleSoft, Boomi, SAP Integration Suite) | | File transfer and messaging | Managed file transfer (SFTP) | Managed file transfer (SFTP) | Secure clinical messaging (HealthLink, Medical-Objects, Telstra Health Argus) | File transfer for market bids | | Market or national hub | Gateway to AEMO's B2B e-Hub in Australia. The registry file hub in New Zealand | None. Water has no market messaging | My Health Record gateway. Healthcare Identifiers Service | AEMO bidding API and Markets Portal. Links to the grid operator (ICCP) | | Standard data servers | Event streaming (Kafka) in newer estates | IoT platform for sensors | FHIR server (Azure Health Data Services, InterSystems IRIS for Health, Smile CDR, HAPI). Terminology server (CSIRO Ontoserver) | OPC servers (Kepware, Matrikon). MQTT broker with Sparkplug for one shared plant namespace (HiveMQ) | | Plant-to-office boundary | One-way data path from OT to IT through a buffer zone (DMZ) | Same as the distributor | None listed | DMZ with historian copies. Data diodes, which let data flow one way only (Waterfall, Owl) | | Field and partner links | None listed | None listed | Referrals in by fax, secure message, e-referral form or email | Equipment maker telematics (Caterpillar, Komatsu). Rail and port scheduling links for miners | 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](/use-cases/utilities), [healthcare](/use-cases/healthcare) and [energy](/use-cases/energy) pages. ## What agents add [#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](/architecture/system-view). Agent tools are added to the existing bus and gateway, not beside them. ### One gateway for every tool call [#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-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 [#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](/architecture/agent-lifecycle), applied to tools. ### Events, older bots and the legacy core [#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 [#the-parts-and-where-they-run] | Part | What it does | Where it runs | | ------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------- | | MCP gateway | Routes, authorises, supplies credentials, inspects and records every tool call | Your API management, or a dedicated proxy | | MCP servers | Expose governed APIs as tools, with labels for read-only and destructive actions | Your private catalog, pinned to a version | | Private registry | Lists which tool servers exist and are approved | The API catalog tooling you already run | | Event stream | Wakes agents on business events | Your existing streaming tools | | RPA bots | Carry out fixed steps where no API exists | Your existing RPA platform | | Wrapped legacy APIs | Give governed access to old core systems | Your existing gateway, in front of mainframe systems | ## What must be true before an agent touches it [#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](/architecture/delegation-chain) intact from the person to the system. The identities and rules it checks come from [security and identity (R10)](/layers/r10-security-and-identity). **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](/architecture/enforcement). Inside each business system, the system's own checks still apply, as the [systems of record (R04)](/layers/r04-systems-of-record) page explains. ## Choices and their verdicts [#choices-and-their-verdicts] Each entry is the common choice, tested against the simplest credible alternative. The full records are in the [decision catalog](/decisions). * [A dedicated MCP gateway or your API management](/decisions#cd-2): 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](/decisions#cd-3): keep them, supervised. Replace one only when a workload earns it. * [Agent-to-agent protocols now or plain APIs](/decisions#cd-4): not yet for most. Use them only for links between organisations. * [Modernise the integration bus first or work around it](/decisions#cd-5): wrap the old bus and retire it piece by piece. Govern before you wrap. ## Concerns this layer must honour [#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](/architecture/concern-matrix). ## Evidence and limits [#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 [#next-step] See this layer at work in [prioritising vegetation inspections](/use-cases/vegetation-inspection), where tool servers already reach the work order system. Then read the next layer, [systems of record (R04)](/layers/r04-systems-of-record).
Explore this topic * [Integration fabric findings](/library/layers/r03-integration-fabric/findings) and [sources](/library/layers/r03-integration-fabric/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.