MCP and Enterprise Architecture: Building a Sovereign Context Layer for AI

Sovereign context operating model

An AI agent is only as good as the context it can reach. For a regulated enterprise, that context — the architecture repository — is also one of its most sensitive assets.

The operating model that matters is not "expose the repository over MCP"; it is "govern what context leaves, to whom, and under which residency and audit constraints".

• Decide which object types are queryable, and which are never exposed
• Keep context fresh: reconcile the repository against live sources, not a yearly snapshot
• Make every answer traceable to a governed source the user is entitled to see

Execution focus for this topic

Treat MCP as a commodity port; invest in the governed, sovereign context behind it — that is where defensibility lives.

Use this page as a decision support asset: align stakeholders, validate trade-offs, and connect architecture choices to measurable business outcomes.

• Primary query focus: MCP and Enterprise Architecture: Building a Sovereign Context Layer for AI
• Decision scope: strategy, governance, operating model, and execution constraints
• Expected output: clear next actions with ownership and measurable indicators

MCP is the port, not the product

The Model Context Protocol (MCP) has become the standard way to connect an AI agent to an external system. It is, in effect, the USB port of AI: a clean, structured interface an agent can use to read and act on data it does not natively hold. Vendors are racing to announce that their tool 'supports MCP', and enterprise architecture vendors are no exception.

Here is the uncomfortable truth for buyers: MCP is a commodity. Nobody chooses a platform because it speaks a protocol — they choose it because of what is behind the port. So in this article MCP is never the argument. The argument is the context the protocol exposes, and whether that context is fresh, governed and safe to expose at all.

Ardoq and Bizzdesign say, in effect, 'talk to your architecture.' We start from a sharper question: how do you let AI reason on your architecture without losing control of it? That question is where enterprise architecture, regulation and sovereignty meet — and it is the subject of this hub.

EA as the enterprise System of Context

For two decades, enterprises invested in Systems of Record — Salesforce, SAP, ServiceNow — the authoritative stores of who the customer is, what was sold, what ticket is open. AI agents now need something those systems were never designed to provide: a coherent, queryable picture of how the whole estate fits together. That is a new layer. We call it the System of Context.

Enterprise architecture is the natural home of that layer. An EA model already encodes the business capabilities, the application portfolio, the technology stack and — crucially — the dependencies between them. When an agent needs to answer 'what breaks if this application is retired?', the answer is not in any single System of Record; it is in the architecture. The System of Context sits alongside the Systems of Record, not on top of them.

This reframing matters because it changes what an EA repository is for. It stops being a documentation archive that a few architects consult and becomes the live substrate that agents reason over. Which raises the bar: a System of Context is only useful if it is current, governed and trustworthy.

Six EA questions agents should answer in natural language

The promise of an agent-ready architecture is that the questions a CIO, a CISO or an auditor actually asks become natural-language queries against the model — not week-long manual analysis. Six recurring enterprise architecture use cases map cleanly onto this:

• Rationalization: 'Which applications are redundant or overlapping across business units, and what would consolidation cost?'
• Impact analysis: 'If we decommission this core system, which capabilities, integrations and downstream processes are affected?'
• Compliance documentation: 'Show every application processing personal data and where that data is hosted' — evidence, not a verdict.
• Risk and vulnerabilities: 'Which critical business functions depend on components with known vulnerabilities or end-of-support status?'
• Strategic alignment: 'Which initiatives in the roadmap support this strategic objective, and which capabilities do they touch?'
• End-of-life planning: 'Which technologies reach end-of-support in the next 18 months, and what depends on them?'

Thin MCP vs native MCP — and why depth wins

Not all MCP integrations are equal. A thin MCP wraps the protocol around an existing search or export endpoint: the agent gets keyword access to documents or a flat list of objects. It demos well and ships fast. But it treats the EA repository as a pile of text, not as a connected model.

A native MCP exposes the architecture as it actually is — a graph of capabilities, applications, technologies and the relationships between them — so the agent can traverse dependencies rather than guess at them. The difference shows up exactly on the hard questions: impact analysis and rationalization need the relationships, not just the nodes. Bizzdesign has framed this thin-versus-native distinction publicly, and the distinction is real.

Our position is that depth is necessary but not sufficient. A native MCP over a stale or shallow repository is still worthless, and a native MCP that exfiltrates sensitive context is worse than nothing for a regulated institution. Build order matters: context first, then regulatory intelligence, then the protocol.

The sovereignty risk the incumbents leave unaddressed

Ardoq (first to market with a generally available MCP) and Bizzdesign are racing to own 'MCP × EA' and 'context engineering'. Both rest on an unstated assumption: that connecting Claude, ChatGPT, Gemini or Copilot to your EA repository is acceptable. For regulated finance, it often is not.

Consider what an EA map actually contains: a near-complete inventory of your systems, your critical dependencies, your obsolete and unpatched components, your known vulnerabilities, your sensitive data flows, and sometimes your security measures. It is, quite literally, a blueprint of where the organization is fragile. Sending that to a US-cloud LLM is a DORA, CSSF, GDPR and EU AI Act landmine — the most sensitive description of your institution leaving your jurisdiction in a single API call.

Nobody is owning the sovereignty side of this conversation. The incumbents own the 'talk to your architecture' narrative; the governance question — should this context leave your control at all, and under what conditions — is the white space. That is the conversation we want to have.

What a regulated framework actually requires

Most MCP implementations stop at permission-awareness: they check who is allowed to query what. That is necessary but incomplete. A framework fit for regulated finance has to govern two things at once.

It has to be permission-aware — enforcing that an agent acting for a given user can only reach the context that user is entitled to. And it has to be data-residency-aware — governing where the answer is computed and where the underlying data physically goes, so that the most sensitive description of the institution does not cross a border or land in an uncontrolled model. Most of the market addresses the first and ignores the second.

This is what we mean by a data-residency-aware MCP and Sovereign Context Engineering: context engineering done under data-residency and governance constraints, not in spite of them. The output a CISO and an auditor both want is the same: AI can reason on the architecture, and the institution can prove the reasoning never compromised sovereignty.

• Permission-aware: every query respects the asking user's actual entitlements.
• Data-residency-aware: where the data goes is governed, not just who queries it.
• Auditable: each access is logged as evidence an auditor will accept.
• EU-hostable: the context can be served from a region and infrastructure you control.

Where ArchiLU is heading (vision, honestly labelled)

We will be precise about what exists and what does not. ArchiLU does not ship an MCP server today. A sovereign, governed, data-residency-aware MCP is the direction we are building toward — a conviction about where regulated AI context has to go, not a feature you can switch on this afternoon.

What exists today is the foundation that makes that destination credible: a connected EA model (capabilities, application portfolio, dependencies), EU-region or on-premise hosting you control, native French and English, published pricing with unlimited users, and a free EA maturity assessment. We are building the living context and the regulatory intelligence first, because a sovereign MCP is only as valuable as the governed context underneath it.

If a vendor tells you their MCP server makes you compliant, be sceptical. A context layer helps you document and prove — it is an evidence and documentation aid, not legal compliance and not a substitute for your own regulatory judgement. We hold ourselves to the same standard: convince by being honest about the boundary, not by blurring it.

Start from your maturity, not from the hype

MCP, agents and the System of Context are only worth building on top of an architecture that is current and trustworthy. Before chasing the protocol, it is worth knowing where your practice actually stands — how fresh your repository is, how complete your dependencies are, how governed your access already is.

ArchiLU's free EA maturity assessment scores ten dimensions and returns a prioritized action plan in about ten minutes. It is a concrete, no-hype way to see whether your architecture is ready to become a System of Context that agents — and auditors — can trust.

Regulated AI context KPIs

Measure whether your context is trustworthy and governed, not how many queries the agent runs.

• Context freshness: median age of architecture objects vs live reality
• Share of answers traceable to a governed, permission-scoped source
• Sensitive object types covered by redaction/residency policy
• Audit coverage: prompts and responses logged and reviewable

Common mistakes

Most MCP-for-EA initiatives fail on context quality and governance long before they fail on the protocol.

• Exposing the full architecture repository to external LLMs without data-residency controls
• Treating MCP as the differentiator instead of the governed context behind it
• Connecting an 18-month-old, hand-maintained repository an agent cannot trust
• No permission-awareness, logging, or redaction of sensitive object types

Practical checklist

Run this before connecting any AI agent to your architecture repository.

• Confirm where prompts and responses go, and whether data stays in your region
• Enforce permission-aware access so the agent only sees what the user may see
• Classify and redact sensitive object types (vulnerabilities, data flows, controls)
• Log prompts and answers for audit, and keep a human in the loop for any change