What is data matching and why do enterprises need it?

Data matching is the process of comparing records across datasets to identify entries that refer to the same real-world entity. Enterprises need it because fragmented records create duplicates that inflate costs, weaken analytics, and create compliance risk. According to Gartner, poor data quality costs organizations an average of $12.9 million per year.

What is the difference between deterministic and probabilistic data matching?

Deterministic matching compares fields for exact equality and works well when unique identifiers are present. Probabilistic matching assigns weighted scores to field comparisons and calculates overall match probability, making it effective when data is incomplete or inconsistent. Most enterprise implementations use both approaches.

How accurate is fuzzy matching for enterprise data?

With proper threshold tuning, fuzzy matching typically achieves F1 scores between 0.88 and 0.95. Combining fuzzy matching with probabilistic weighting across multiple fields pushes accuracy higher. Accuracy depends on the algorithm, threshold, and input data quality.

Can data matching run on-premise for regulated industries?

Yes. On-premise data matching platforms process all data within your secured infrastructure, ensuring sensitive records never leave your network. This addresses data residency requirements under HIPAA, GDPR, SOX, and industry-specific mandates.

How do you measure data matching quality?

Three metrics matter most: Precision (percentage of declared matches that are correct), Recall (percentage of true matches found), and F1 Score (harmonic mean of precision and recall). Enterprise benchmarks target F1 above 0.95.

What is blocking in data matching and why is it necessary?

Blocking partitions records into subsets sharing a common attribute so the system only compares records within the same block. Without it, 10 million records would require 50 trillion comparisons. Blocking reduces this by 99%+ while preserving high recall.

Air-Gapped Agentic Workflows: Running MCP in Regulated Environments

An air-gapped agentic workflow is an AI-agent-operated process in which the model, the protocol traffic, and the executing platform all run inside a network with no external connectivity. With MCP, the pattern pairs a self-hosted LLM with an on-premise platform: the agent proposes and sequences work locally, a human confirms, and nothing leaves the boundary, neither data nor instructions.

The question comes up because agent tooling assumes the cloud by default, while the environments that most need automated data work, in government, defense-adjacent industries, healthcare, and finance, often forbid it. This article covers the postures available and what a fully contained deployment of entity resolution and matching workflows requires.

Key Takeaways

An air-gapped agentic workflow keeps everything inside the boundary. The model, the protocol traffic, and the executing platform all run in a network with no external connectivity.
A cloud-hosted LLM breaks the gap even when the data wall holds. The control conversation itself leaves the network, which some environments cannot permit.
Three network postures cover the field. Cloud control plane, private network with a self-hosted model, and fully air-gapped; each has a defined footprint.
The operating rule survives isolation. The AI proposes, you confirm, and every action is logged, whether the model runs in a cloud or in a sealed rack.
On-premise platforms make the pattern practical. When the engine already runs inside the boundary, adding a self-hosted model completes the loop.

Why Does the Usual Agent Stack Break the Air Gap?

The standard setup reaches a cloud-hosted model. Even in a strong control-plane design where records never cross the protocol, the conversation itself does: goals, workflow proposals, confirmations, and status summaries all transit to wherever the model runs.

For most enterprises that is an acceptable footprint, because the sensitive asset is the data and the data stays home. For an air-gapped environment it is disqualifying by definition, since the gap admits no external traffic of any kind.

The fix is not to abandon the pattern but to relocate the model. Everything else about agent operation works identically inside the boundary.

What are the Three Network Postures for MCP Workflows?

Deployments cluster into three postures, distinguished by exactly one question: what leaves the network.

Posture	What leaves the network	Model location	Fits
Cloud control plane	Instructions and status only; never records	Hosted (for example, Claude via Claude Desktop)	Most regulated enterprises where data residency is the binding constraint
Private network	Nothing in normal operation	Self-hosted model inside the corporate network	High-sensitivity environments with strict egress policies
Fully air-gapped	Nothing, by physical or logical isolation	Self-hosted model inside the isolated enclave	Classified, defense-adjacent, and sealed operational environments

The postures are a spectrum of the same architecture rather than three products. Moving between them changes where the model runs and how updates arrive, and nothing about the operating rule.

What Does a Fully Air-Gapped Deployment Require?

Four components, all inside the boundary. A self-hosted model, typically an open-weight model on local hardware; an MCP client that runs locally; the on-premise platform with its MCP server; and an offline update process for moving model weights and software versions across the gap under change control.

The protocol itself cooperates. The Model Context Protocol supports local transports between client and server, so no part of the connection depends on external services once the components are inside.

Capability trade-offs deserve honest treatment. Self-hosted models trail the strongest hosted models on complex orchestration, which argues for keeping air-gapped agent scope focused on routine, well-defined workflows where the proposal quality gap matters least.

Does the Operating Rule Change Inside the Gap?

No, and that is the point worth internalizing. The AI proposes, you confirm; the approval gate, the data wall between the model and the records, and per-action logging all function identically whether the model is hosted or sealed in the enclave.

If anything, isolation raises the value of the gate. Air-gapped environments are usually air-gapped because the records are exceptionally sensitive, and a logged human confirmation in front of every change is what makes agent operations defensible there at all; the full security stack is laid out in our guide to MCP server data security.

What Does This Look Like in a Working Deployment?

Consider a government benefits agency whose case systems hold 5.6 million case and constituent records, roughly 310,000 unique constituents once case history and correspondence are separated. Policy forbids any external connectivity for the enclave that processes them, and the agency still faces the same duplicate-constituent problem as any large organization.

Inside the enclave, a self-hosted model connects to the platform's MCP server and a data steward directs monthly data deduplication passes in plain language. Proposals appear, the steward confirms, the engine executes, and the complete log stays inside the boundary with everything else.

MatchCore fits this posture because the platform side is already inside: it deploys on-premise, and pairing its MCP server with a self-hosted model extends the same containment to agent operations. The run mechanics are identical to the connected case described in our walkthrough of the MCP server for entity resolution and data matching.

Conclusion

Air-gapped agentic workflows are not a contradiction; they are a relocation. Move the model inside the boundary, keep the on-premise platform where it already runs, and agent-operated matching works in environments that will never touch a cloud API.

The constants matter more than the posture. The AI proposes, you confirm, the model never accesses the records, and the log stays wherever your rules require it to stay.

Frequently Asked Questions

Can AI agents work without internet access?

Yes. A self-hosted model running on local hardware, an MCP client running locally, and an on-premise platform form a complete agent loop with no external connectivity. The pattern is in production use in isolated environments as of mid 2026.

Does MCP require cloud connectivity?

No. The protocol supports local transports between client and server, so the connection works entirely inside a private network or an air-gapped enclave. Cloud involvement is a property of where the model runs, not of the protocol.

What kind of LLM can run air-gapped?

Self-hosted open-weight models deployed on local hardware. They trail the strongest hosted models on complex orchestration, so scoped, routine workflows are the right assignment, with a human confirming each proposal as in any posture.

Does any data leave the network in the private or air-gapped postures?

No. In the private network posture nothing leaves in normal operation, and in the fully air-gapped posture nothing can leave by construction. In the cloud control-plane posture, instructions and status transit to the hosted model while records stay inside.

Is agent operation auditable in an air-gapped environment?

Yes, and the audit trail is often stronger there. Every proposal, confirmation, and tool call is logged inside the boundary, so attribution of each change survives without depending on any external service.