Open Data Infrastructure
Why MCP Servers Need a Governed Data Layer
MCP connects models to tools, but it does not solve the hard part: durable permissions, audit, and meaning at the data boundary.
Giving an agent more tools does not make it safer. It makes the blast radius bigger if the data layer is not governed.
The problem hiding behind tool access
Most MCP excitement focuses on tool access: the model can call an API, query a database, or fetch a document. That is useful. It is not the core risk.
The core risk is that agents turn your data systems into an execution surface. The question becomes: who is allowed to see what, under which policy, with which audit trail, and with what rollback plan?
Core idea: a tool protocol is not a governance model.
What MCP actually standardizes
MCP is a protocol for how clients and servers exchange structured context and tool capabilities. It is intentionally not a full platform. That is why it is gaining traction.
But a protocol cannot guarantee that the data behind a tool call is governed, portable, and auditable. Those are system properties, not message properties.
The governance gap
In production, governance breaks in predictable places:
- Policy drift: access rules exist in one system, but the agent can reach data through another path.
- Meaning loss: the model sees a column name, but not the lineage, freshness, or policy constraints that make it safe to use.
- Audit gaps: tool calls are logged, but you cannot reconstruct the exact data and context that caused an action.
- Portability loss: the agent workflow depends on a vendor-specific data access pattern that cannot be reproduced elsewhere.
MCP does not create these problems. It just makes them visible faster.
What ODI adds
Open data infrastructure treats governed data access as a shared contract layer. That contract is what your MCP servers should depend on.
- Open contracts: open table formats for data and open catalog interfaces for metadata and access.
- Enforceable policy: policy evaluated at query time and recorded as part of the execution trail.
- Auditability: reproducible tool calls that can be tied to inputs, policy decisions, and outputs.
- Interoperability: the agent can change models and tools without changing the governed data boundary.
Put differently, MCP makes tool access portable. ODI makes data access safe and portable.
Checklist for production
If you are deploying MCP servers into an enterprise environment, these questions matter more than the tool list.
- Where is policy evaluated for each tool call?
- Can you prove a tool call only saw data the user was allowed to see?
- Can you reconstruct context and inputs for incident response?
- What happens if you swap catalogs, engines, or storage providers?
- How do you defend against context poisoning and tool misuse?
If the answers are "it depends on the vendor console," you are not building open infrastructure. You are building a brittle integration.
Sources to start with
Start with the protocol docs, then map the security guidance to your actual data access surface.