Sovereign intelligence reference architecture: layers, planes and boundaries

What is this reference architecture for?

A reference architecture is a shared map. It does not tell you which products to buy. It tells you which components a sovereign environment needs, where the boundaries between them sit, and which decisions you have to make at each one. Use it to check a design you already have, to brief a vendor, or to plan a build.

The map follows the structure of the Sovereign Intelligence Platform: six layers in a fixed order, with a trust and governance fabric running through all of them. The fabric is not a seventh layer. Each section below is a view of the same system: the layers, the planes, the boundaries, the lifecycle of one action, the deployment options, and what a minimal version looks like. A shorter, narrative treatment is in the post on sovereign AI reference architecture; the category pillar gives the framework this sits inside.

What are the six layers and what lives in each?

Each layer should be replaceable without rebuilding the others. That is the architectural expression of supply-chain sovereignty: you can change a model, a vector store or a hosting provider behind a stable interface. Where the interface is a standard, such as the Model Context Protocol, which Anthropic donated to the Agentic AI Foundation (opens in a new tab) in December 2025, replacement is easier still.

How does the trust fabric become planes?

The thirteen facets of the trust fabric are Identity, Access, Data controls, Policy, Security, Privacy, Compliance, Risk, Human oversight, Auditability, Traceability, Evidence and Monitoring. In an architecture they land in three planes that cut across the six layers.

Separating the planes has two practical benefits. First, the control plane can stay in the organisation's hands even if parts of the data plane run elsewhere, which is the pattern many hybrid designs rely on. Second, the evidence plane is a place where records are stored in a form the organisation can read independently of the product that produced them. That is the substance of governance sovereignty: the proof stays with you.

Where do the trust boundaries sit?

A trust boundary is a line where the rules change: who is acting, what data may cross, what is logged. A sovereign design draws these lines on purpose and puts an enforcement point on each.

• Organisation boundary. Data and context leaving the organisation's environment, for example to a hosted model API. Controlled by data classification and the approved-model list.
• Model boundary. Between the agent runtime and any model. A model gateway applies routing, redaction and logging, and limits which data classes reach which model.
• Tool boundary. Between an agent and the systems it acts on. Every tool call is authorised against the agent's permissions, not the user's session alone.
• Human boundary. Where an approver decides. The approval request must carry enough context to decide, and the decision is recorded as structured data.
• Tenant or business-unit boundary. Separating one team's data and context from another's inside a shared environment.
• Operator boundary. Between the people who run the platform and the content it handles. Operators should not need to read customer content to run it, and their access is itself logged.

The infrastructure sovereignty and data sovereignty deep dives cover how legal jurisdiction interacts with these boundaries. For the legal exposure that a foreign provider can create regardless of data location, see the CSIS analysis of the US CLOUD Act (opens in a new tab).

How does identity flow through the system?

The most common architectural gap in enterprise AI is identity. Systems authenticate the person who clicked, then let the agent act with whatever the integration account can do. The reference pattern is different: every actor has its own identity, and delegation is explicit.

1. People sign in through the organisation's identity provider and carry roles and groups.
2. Agents have their own service identity, owned by a named person or team, with permissions defined by the Trust Profile.
3. Workflows run as an identity too, so that a scheduled run is attributable.
4. Delegation is recorded: when an agent acts for a user, the record shows both, and the effective permission is the intersection of the two, never the union.
5. Tools and data sources receive scoped, short-lived credentials from a secrets service, and the agent never holds long-lived keys.

Where enterprise single sign-on and provisioning are not yet available in a given product, say so in your design and plan for it. Swfte's trust page lists enterprise SAML SSO and SCIM provisioning as in development, and shows target dates as placeholders to be confirmed.

What is the lifecycle of one agent action?

This is the sequence a governed action follows, using the AI Procurement Agent preparing a draft PO above its approval threshold. Each step names the plane it runs on.

1. Trigger (data plane). A buyer or workflow asks the agent to prepare a purchase. The request carries the user's identity and a new run ID.
2. Identify and load profile (control plane). The agent's identity is resolved and its Trust Profile is loaded: owner, risk level, approved models, data classification, permitted systems, allowed and restricted actions, approval rule, retention and policy set.
3. Retrieve context (data plane). The agent reads approved supplier information. Data controls filter what it may see, and the retrieval is logged with the sources used.
4. Call a model (data plane). The request passes through the model gateway, which checks that the model is approved for the data class, applies any filter, and logs model and version.
5. Propose an action (data plane). The agent decides to create a draft PO. The tool call is intercepted by a policy enforcement point.
6. Evaluate policy (control plane). The policy decision returns one of Allow, Deny, Warn, Filter, Escalate or Require human approval. Creating a draft is allowed. A payment would be denied. A purchase above threshold requires human approval.
7. Approve (data plane, human boundary). The workflow pauses until a named approver decides. The decision, any edits and the reason are stored.
8. Act (data plane). The tool call executes with a scoped credential. The result is returned to the agent and to the workflow.
9. Record (evidence plane). Identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome are written under the run ID.
10. Close the loop (evidence plane to data and control planes). Later outcomes attach to the run, and reviewed signals feed context, evaluation and policy, as described in the closed intelligence loop.

Two properties make this safe. The enforcement point is in the path, so a denied action does not happen rather than being reported afterwards. And policy fails closed: if the control plane cannot be reached, the agent's high-impact actions pause. Read runtime governance for why that matters.

Which deployment topologies does the architecture support?

The architecture is independent of where it runs. These are the topologies it is designed for. Availability depends on the engagement: private, dedicated and hybrid deployments are scoped with you and are not self-serve. Customer data on the standard service is in AWS eu-west-1 (Ireland) today; the trust page is the place to check current status.

Each step towards the organisation's own infrastructure moves operational responsibility with it. Weigh that against sovereignty benefits. The post on private AI economics and the vLLM deep dive cover the cost and serving sides.

What should the evidence plane record?

Log enough to reconstruct an action, and no more than your data controls allow. The minimum record per run is the list from the procurement example: identity, data accessed, model used, output, tools called, policy applied, decision, approval, action, outcome. Add four things that make it operable.

• Versions. Model version, prompt or workflow version and policy-set version, so behaviour can be tied to a specific configuration.
• Sources, not just answers. Which documents or records supported an output.
• Denied and escalated attempts. What the agent tried and was stopped from doing is some of the most useful evidence you have.
• Administrative changes. Who changed a policy, permission or autonomy level, and when.

Retention and access are policy decisions. Regulations such as the EU AI Act set record-keeping expectations for high-risk systems, and the Digital Omnibus on AI moved the stand-alone high-risk dates to 2 December 2027, as summarised by Gibson Dunn (opens in a new tab). Check the Official Journal text for your situation. The platform provides technical controls, governance mechanisms and evidence; the exact posture depends on your use case, jurisdiction, deployment and configuration.

What is the minimum viable version, and what is the full one?

Not every organisation needs every component on day one. The order matters more than the completeness.

The sequence is walked through in the ten-step build guide, starting with defining sovereignty requirements and ending with operating and learning. The post on building the stack layer by layer shows the same order as a narrative.

What are the common architectural anti-patterns?

• Governance as a seventh layer. A separate governance product that watches from outside and reports after the fact. It cannot stop anything. The fabric must be in the path.
• The shared integration account. One credential with broad access used by every agent. It makes attribution impossible and widens every blast radius.
• Logs the vendor owns. Evidence readable only through a vendor dashboard. If you cannot export and read it, you do not hold it.
• Model coupling. Application code written against one model's quirks. Swapping the model then means rewriting the application.
• One-size policy. The same controls for every use case, which blocks the low-risk ones and under-protects the high-risk ones.
• Unbounded memory. Agent memory that accumulates data with no classification, retention or deletion path.
• Approval theatre. Human approvals that carry no context, so approvers click through. Oversight that cannot be exercised is not oversight.

A design that avoids these is not yet finished, but it is built on the right grain. For the thesis that explains why the controls and the capability belong in one system, read capability plus control. If you want a starting point for your own situation, the readiness assessment runs entirely in your browser.