Sovereign Context Engineering: A Manifesto for Regulated 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

We have a name for what regulated AI is missing

Everyone now agrees that the bottleneck for useful AI is not the model — it is the context. The industry calls the answer context engineering: the discipline of assembling exactly the right information so an agent can reason instead of hallucinate. That is correct, and it is not enough.

Because for a regulated bank, insurer or public institution, the question is never only "what context does the agent need?" It is also "where does that context go, who governs it, and can I prove what the agent was allowed to see?" There is a name for context engineering done under those constraints, and we are going to define it and own it.

We call it Sovereign Context Engineering: context engineering practised under data-residency, governance and auditability constraints, for regulated enterprises. This is the manifesto.

The map is the weapon

Start from what is actually at stake. An enterprise architecture model is not a diagram. It is a near-complete blueprint of the organization: every system, every critical dependency, every obsolete component, every sensitive data flow, sometimes the security measures themselves.

That is precisely the context an AI agent needs to be useful — and precisely the context you cannot afford to lose control of. Connecting a US-cloud LLM directly to that map, as the convenient path invites you to, can turn your most valuable internal asset into your largest attack surface and your clearest regulatory exposure under DORA, NIS2, GDPR and the EU AI Act.

Sovereign Context Engineering begins by taking this seriously. The same context that makes AI powerful is the context that makes a leak catastrophic. You do not solve that with a disclaimer. You solve it with principles.

The five principles

A manifesto is only worth the lines you would defend in a CSSF audit. Here are ours. Each one is a choice between two real things — and a declaration of which we choose when they conflict.

• Context over protocol. MCP is plumbing; nobody is saved by a connector. The value is the quality, freshness and governance of the context that flows through it. We engineer the context first, the protocol last.
• Living over snapshot. A repository that is eighteen months stale will make an agent confidently wrong. Sovereign context is continuously refreshed — an agent-ready model, not an archived artifact.
• Governed over exposed. Every access is permission-aware. An agent sees what its caller is entitled to see, and not one node more. Exposure is the default to be designed away, not the convenience to be accepted.
• Sovereign over convenient. The fastest integration sends your blueprint to someone else's jurisdiction. We choose the path where context stays in the EU and under your control — even when it is harder.
• Auditable over opaque. If you cannot show an auditor what the agent was shown, you have not engineered context — you have leaked it with extra steps. Every answer must be traceable to a governed access.

What this is not

A manifesto earns trust by stating its own limits as plainly as its claims. So, in plain terms:

This is a conviction, not a finished product. A sovereign context layer and a data-residency-aware MCP are the direction we are building toward — we do not claim to have shipped them. What exists today is an EU-region or on-premise EA model you control, native French and English, published pricing, and a free EA Maturity Assessment.

And it is a documentation discipline, not a compliance guarantee. Sovereign Context Engineering helps you document and prove how AI touches sensitive architecture data; it supports a compliance case. It does not, by itself, make any organization compliant. That verdict belongs to your regulator and your legal counsel, not to a tool.

Why the giants will not do this for you

The vendors racing to bolt MCP onto an EA repository — and they are racing — share one unstated assumption: that connecting Claude, ChatGPT, Gemini or Copilot to your architecture is acceptable. For a great many organizations it is. For a regulated European institution, it often is not.

That gap is not an oversight the giants will rush to close, because closing it means optimizing for sovereignty over reach — narrowing the market instead of widening it. The intersection of living context, regulatory reasoning and sovereignty, for EU-regulated finance, is precisely the space a global platform is structurally disinclined to serve well. Sovereign Context Engineering is the discipline that fills it.

What it means for a regulated bank or insurer

Concretely, for a CISO or Head of Architecture at a regulated institution, adopting Sovereign Context Engineering changes how you say yes to AI. You stop choosing between "ban the agents" and "send the blueprint abroad," and start treating context as a governed asset.

It means your architecture model is the System of Context your agents reason over — kept living, hosted where your auditors accept it, accessed under the same permissions as the humans it serves, and logged so every AI-assisted answer carries an evidence trail. When the regulator asks how AI touches your most sensitive map, you have a defensible answer, not a hope.

That is the bet of this manifesto: in regulated AI, the winners will not be the ones who connected an agent fastest. They will be the ones who could prove, on demand, exactly what the agent was allowed to know. If that is the institution you intend to be, start from where your architecture practice stands today — our free EA Maturity Assessment scores ten dimensions and returns a prioritized plan in about ten minutes.

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