Permission-aware and data-residency-aware: governing AI agent access to your EA

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

Two control dimensions, not one

When an AI agent reads your enterprise architecture, there are two distinct questions to answer, and they are easy to conflate. The first is a question of entitlement: of everything in the repository, what is this particular user allowed to see? The second is a question of geography and custody: wherever the answer comes from, where is that data allowed to physically go?

Most of the conversation in the market is about the first dimension. It is the easier one to reason about because it maps onto access control we already understand. The second dimension is the one regulated finance cannot skip — and the one incumbents tend to under-serve. Getting both right is what separates a demo from something a CISO or a CSSF-facing team will actually sign off.

Permission-aware: only what the requesting user may see

Permission-aware access means the agent returns only what the requesting user is entitled to see, scoped by role, by object and by sensitivity. The agent acts on behalf of a person; that person's identity and entitlements must propagate all the way through to the answer. An architect in payments should not, via a chatbot, surface objects they could never open in the application itself.

This is a real and important control, and it is fair to credit those who highlight it. Ardoq, for instance, emphasizes permission-aware access so the agent respects each user's existing entitlements. We agree it is necessary. Our argument is not that permission-aware is wrong — it is that, on its own, it is incomplete for a regulated context.

• Scope by role: the agent inherits the requesting user's entitlements, never a superset
• Scope by object: per-object access, not all-or-nothing repository access
• Scope by sensitivity: classify objects so critical ones are treated differently
• Propagate identity: the user behind the agent is who the gate evaluates

Why permission-aware alone is insufficient for regulated finance

Imagine a perfectly permission-correct answer. The user is entitled to every object in it; nothing leaked across an entitlement boundary. Now ask the second question: to produce that answer, did the prompt — your dependency map, your critical-function inventory — travel to a US-hosted model? If so, you can be fully permission-aware and still have created a DORA, CSSF or GDPR exposure, because the issue was never who asked. It was where the data went.

An EA map is close to a complete blueprint of the organization: system inventory, critical dependencies, obsolete components, known vulnerabilities, sensitive data flows. Scoping who can read it does not change the fact that, once an answer is computed, the underlying context may have left your jurisdiction. Permission control governs visibility; it does not govern residency. That gap is the missing dimension.

A practical control model: classification to logging

A workable model puts two gates in series between the agent and the repository, and logs across both. Start with classification, then default-deny the most dangerous objects, then control egress. The order matters: decide what may be seen before you decide where it may go, and record both decisions.

Default-deny on critical-function objects is the deliberately conservative stance. For the systems that underpin a critical or important function, the safe default is to withhold unless a request is explicitly allowed — the opposite of a permissive map where everything is reachable until restricted. Redaction handles the items that should never leave at all: known vulnerabilities, security measures, and similar material that has no business in an external prompt even for an entitled user.

• Classify every object by sensitivity, flagging critical-function systems
• Default-deny on critical-function objects: withhold unless explicitly allowed
• Redact items that must never leave (known vulnerabilities, security measures)
• Apply egress control before any prompt or response crosses a boundary
• Log who asked what, what was returned, and where it went

Data-residency-aware: governing where the data goes

The residency gate governs the geography and custody of every prompt, response and embedding. The practical levers are deployment choices: an EU-hosted model, an on-premise deployment under your own control, or a European LLM where the inference itself stays in the jurisdiction. Embeddings deserve explicit attention — vectorizing your architecture can quietly persist a derivative of sensitive content in a place you did not intend.

Concretely, in EU-regulated finance, the question a CISO asks is rarely 'can the agent see this?' alone; it is 'if it sees this, where does the computation happen and where do the artifacts rest?'. A residency-aware layer makes that answer a configured, auditable property rather than an accident of which model was cheapest to call. This is the part of the picture that, today, most platforms leave to the customer.

• EU-hosted inference, on-premise deployment, or a European LLM option
• Egress control on prompts and responses, not just on stored data
• Treat embeddings as residency-bearing: they persist a derivative of the content
• Make residency a configured, auditable property, not an implicit default

The data-residency-aware MCP: where we are heading

Tie the two gates together and you get what we call a data-residency-aware MCP: a context layer that governs not only who queries the architecture but where the data physically goes when it does. To be clear about claim discipline: this is our conviction and our roadmap, the approach we are building toward — not a shipped product. We will not write that it exists when it does not.

What we can stand behind today is the foundation it needs: EU-region or on-premise hosting you control, native French and English, a connected EA model built around DORA/CSSF documentation needs, and a free EA Maturity Assessment to see where your practice stands. And one honest caveat throughout: this control model is a documentation and risk-framing aid, not legal compliance. It helps you show an auditor how AI access to your architecture is governed; the compliance judgment remains yours to make.

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