The Architecture Map as Attack Surface: AI Agents and the New Exfiltration Risk

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

The map was always sensitive — access just changed

Every CISO already knows the enterprise architecture repository is sensitive. It is close to a complete blueprint of the organization: the full system inventory, the dependency chains that hold the business up, the single points of failure, the obsolete and unpatched components, the data-flow paths that touch regulated information, and sometimes the very security measures protecting them. That has been true for years.

What changed is not the data — it is who, or what, can reach it. The moment an AI agent can query that repository, the map stops being a document a few cleared people read view by view and becomes a queryable surface an automated system can traverse end to end. The value of that is real: reasoning over living architecture is genuinely useful. But a new capability to traverse is also a new attack surface, and treating it as anything less is wishful thinking.

What an agent can extract — and why it is different from a human

A human architect reading the repository sees one diagram at a time, at human speed, and leaves a human-visible trail. An agent that can traverse the whole graph does something categorically different: it joins views no single reader would join, at machine speed, and returns them in one structured answer.

Ask the wrong question — or let an over-broad prompt run — and the agent can assemble the reconnaissance an attacker would otherwise spend weeks building by hand. The danger is not malice alone; an honest but over-permissioned query can surface the same blueprint. These are the artefacts a traversal can compose:

• Dependency chains: which systems fall if one upstream component fails
• Single points of failure across critical business functions
• Obsolete and unpatched components, mapped to the services they support
• Sensitive data-flow paths, including where regulated data crosses boundaries
• The shape of security controls — and, by inference, the gaps between them

Prompt injection and over-permissioned agents

Two failure modes turn a useful agent into an exfiltration path. The first is the over-permissioned agent: one given broad, standing access to the whole repository because scoping felt like friction. Whatever an attacker can convince that agent to do, it can do across the entire map.

The second is prompt injection. Agents read untrusted content as part of their work — tickets, documents, model annotations, external pages. If that content carries hidden instructions, it can redirect the agent. Pair an injected instruction with a broadly permissioned agent and a routine query becomes a directed traversal of your most sensitive structure. The lesson is not to trust the prompt, and never to let permissions exceed the task.

The sovereignty dimension: where the answer goes

Exfiltration is not only about what an agent reads — it is about where the answer travels. If the agent is a general-purpose assistant backed by a US-cloud model, the blueprint it assembles leaves your control the moment it is sent for inference. For a regulated EU institution that is a DORA, CSSF, GDPR and EU AI Act concern, not merely a hygiene preference.

This is why we frame the goal as a sovereign context layer rather than just access control. The point is not only who may query, but where the data goes — a data-residency-aware MCP that governs egress and keeps regulated context inside a perimeter you control. To be clear about where we stand: that sovereign layer is the approach we are building toward, conviction and roadmap, not a shipped capability. What exists today is the posture it rests on — EU-region or on-premise hosting you control, and a connected EA model designed around governance.

Controls that contain it — known, not exotic

The honest reading is that the value is real and the controls are known. None of what follows is novel security research; it is the disciplined application of least privilege, egress control and monitoring to a new kind of consumer. Containment is an engineering problem with established answers, not a reason to forbid AI over architecture.

• Least-privilege, permission-aware access: the agent reaches only the slice a task needs, never the whole graph by default
• Redaction and scoping: strip or mask the most sensitive attributes before any answer is composed
• Egress and residency control: govern where any answer can travel; keep regulated context inside a perimeter you control
• Full query logging: every traversal recorded, attributable, and reviewable for an auditor
• Anomaly detection on queries: flag the broad, structure-mapping question that no legitimate task would ask

A CISO's decision: govern the gate, don't ban the agent

The wrong conclusion is to ban AI reasoning over architecture; the capability is too valuable and the controls are too well understood for a blanket no. The right conclusion is to treat the EA repository as exactly what it has become — a high-value asset behind a governed gate — and to decide consciously what passes through it, to whom, and to where.

Start from where your practice actually stands. A useful first step is to know your own exposure: how current your map is, how access is scoped today, and where regulated data flows. ArchiLU's free EA Maturity Assessment scores ten dimensions and returns a prioritized action plan in about ten minutes — a concrete starting point before you connect any agent. As always, treat this as documentation and evidence support for DORA/CSSF scrutiny, not as a guarantee of compliance.

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