What Sovereign Automation Actually Means

Sovereign automation means the platform that runs your automated work operates inside a boundary you control, and that its core operation does not depend on a vendor runtime or an external model API. The workflows execute on your infrastructure. The data they touch stays in systems you administer. The models they call are endpoints you host. Identity is resolved against your directory, credentials sit in your vault, and the record of what happened is written to your storage.

That definition is deliberately operational. It does not say anything about where a company is headquartered or which flag appears on a data centre. It describes who can start, observe, interrupt or compel the work. If the answer to any of those is an organisation other than yours, the automation is not sovereign, however the storage is labelled.

The rest of this article turns that into six surfaces you can inspect: execution, data, models, identity, secrets and evidence. Each one has a question with a factual answer, and each one can quietly leave your boundary while everything else appears to stay put.

Three claims are routinely used as if they were the same claim. They are not.

Data residency is a statement about geography at rest. Rows live in a named region. It is a real and often mandatory requirement, and it answers exactly one question: where the bytes sit when nothing is happening to them.

Self-hosting is a statement about who installs the software. It is closer to the point, but a self-hosted component that phones an external service for licensing, scheduling, model inference or telemetry has moved the binary without moving the dependency.

Sovereignty is a statement about control during operation. It covers the moment the work actually runs, which is when data is in memory, credentials are decrypted, a model is called and a decision is made.

The common failure mode is easy to describe and surprisingly hard to spot on a diagram: a regional data centre holding the database, with the control plane, a licence check or a model endpoint sitting outside it. Everything in the compliance questionnaire about residency is satisfied. Meanwhile a third party can observe metadata about every run, decide when the platform is upgraded, and stop the automation by ending a service. That is the risk institutions were trying to remove.

One more clarification before the six surfaces. Sovereign is not a synonym for secure and it is not a synonym for compliant. Running a platform inside your estate gives you the controls. It does not configure them for you, and it does not by itself evidence any regulatory obligation. What it does is make the controls yours to hold, which is the precondition for everything else. Our regulatory alignment page describes what that supports and where the customer obligation begins.

Take each surface in turn. For each one there is a definition, a question you can ask in an architecture review, and a description of what a hidden dependency looks like when it is present.

1. Execution

Execution is where the workflow runtime and the control plane run. The control plane holds workflow definitions, schedules work and tracks state. The execution plane does the work. Both have to be inside the boundary for the claim to hold, because a runtime that receives its instructions from outside is a runtime someone else operates. The split between the two is described in more detail on the platform architecture page.

Review question

Can a representative workflow complete a full run with every outbound route blocked?

Hidden dependency looks like

A run that starts and then stalls on a callback, a licence validation, a hosted job queue or a remote scheduler. The symptom is usually a timeout rather than an error that names the dependency.

2. Data

Data is not only the database. It is the inputs a trigger carries, the intermediate state a workflow holds between steps, the payloads sent to each system, the outputs written back and the telemetry the platform itself emits. Residency covers the first and last of those and misses the middle entirely.

Review question

What leaves the boundary during a run, and can each outbound flow be listed, inspected and switched off?

Hidden dependency looks like

Usage analytics, error reporting or metering that ships payload fragments, workflow names or identifiers to a vendor endpoint by default, described as diagnostics rather than as data flow.

There is an important distinction to keep explicit here. If you deliberately connect a workflow to a third-party service, data will leave your estate, and that is your configuration decision rather than an architectural property of the platform. The sovereignty question is whether the platform itself requires any outbound path to do its job. Those are two different conversations and they should not be merged.

3. Models

AI belongs in this list because an AI step is the newest and least examined way for sensitive material to leave a boundary. A model call carries the prompt, the context retrieved to build it and the response back. In practice the retrieved context is where regulated content usually enters, which means the sensitivity of an AI step is set by retrieval scope rather than by the instruction text. The sovereign AI page covers how inference is registered and versioned as a governed artefact.

Review question

Can inference run against an internal endpoint with no call to an external model API, and who versions that model?

Hidden dependency looks like

An AI feature that works in a demonstration but degrades to unavailable when external routes are closed, or a self-hosted model whose safety filtering or evaluation still calls out.

4. Identity

Identity determines who can build, run, approve and read. In a sovereign deployment authentication and authorisation resolve against your directory, with your own single sign-on, multi-factor policy and role model. Roles should be enforced by the platform, not reproduced in it by hand.

Review question

If every vendor connection stopped today, who could still authenticate and administer the platform tomorrow?

Hidden dependency looks like

A vendor-hosted identity service in the login path, a break-glass account held outside your directory, or a support role with standing access that your own administrators cannot see or revoke.

5. Secrets

Automation is credential-dense by nature. Every connection to a business system is a credential, and an automation platform accumulates them faster than most applications. The relevant properties are where they are stored, who can read them, whether they appear in logs and whether they can be rotated without editing workflows.

Review question

Is any credential recoverable by anyone outside the estate, including through a support channel or a backup?

Hidden dependency looks like

Credentials held in platform configuration rather than a vault, echoed into execution logs, or included in a diagnostic bundle that gets sent to a vendor during a support case.

6. Evidence

Evidence is what lets you answer questions about work that already happened: what ran, on which workflow version, triggered by whom, approved by whom, with what result. It is the surface institutions notice last and need longest, because an audit or an incident review asks about a run from a year ago, not a run from this morning. The governance and audit page describes what is recorded at each step.

Review question

Can you produce a complete record of a run from a year ago without asking a vendor to retrieve it?

Hidden dependency looks like

Execution history retained in a vendor console with a short window, or approvals captured in a messaging tool where the decision is not bound to the run it authorised.

Put the two architectures side by side and the difference is a single arrow. In the first, an agent or gateway installed in your network reaches your systems locally and then opens an outbound connection to a control plane operated elsewhere. The installation is local. The control is not.

This is why a local agent does not resolve the question. The agent was introduced to avoid exposing internal systems to the internet, which it does. It also reintroduces the dependency it was meant to remove, because the logic, the state and often the AI processing still live on the other side of that connection. Lose the connection and the automation degrades or stops.

In the sovereign pattern the deciding happens inside the boundary. The control plane, the execution plane, the model endpoints, the vault and the evidence store are all in infrastructure you operate, and no part of a run needs to cross the line.

The execution model behind this is worth reading alongside the diagram, because the boundary is only meaningful if the runtime inside it is genuinely complete.

Cloud is not the opposite of sovereignty. Nexus can run on premises, in a private cloud, in a sovereign cloud, or in an air-gapped environment. A regulated organisation may place its private or sovereign cloud inside the same operational boundary as its physical data centres and treat both as parts of one controlled estate.

From the Nexus perspective, the architectural distinction is customer-controlled execution versus dependency on an external vendor runtime. The location and ownership model of the infrastructure matter, but they do not decide sovereignty by themselves. What matters is whether the organisation can operate the platform and complete its work without a third party controlling the runtime.

The review questions therefore stay consistent across every hosting model. Who controls execution, identity, secrets, models, evidence and upgrades? Which connections can carry data outside the boundary? Who decides whether that egress exists, and can the platform continue to operate when it does not?

This keeps the discussion precise rather than ideological. On premises, private cloud, sovereign cloud and air-gapped deployment can all support operational control when the required runtime and authority remain inside the customer boundary. The deployment options page explains how those models fit different estates.

A short factual mapping rather than a feature list. Nexus is a self-hosted platform, deployed on premises, into a private or sovereign cloud, or into an air-gapped enclave. The control plane and execution plane both run in that estate.

Execution and data stay in the deployment. Core platform operation does not require a vendor runtime, so a run completes without any call to a service we operate. Outbound connections exist only where you configure an integration that needs one.

Models are self-hosted endpoints you register. Prompts, retrieved context and responses stay on infrastructure you operate, and inference does not depend on an external model API.

Identity resolves against your directory, with federation, multi-factor policy and role-based access control administered by your own team.

Secrets are held in vault-backed storage inside the estate and referenced by workflows rather than embedded in them.

Evidence means execution history, approval records and workflow versions written to your storage under your retention policy.

The Nexus products follow the same model rather than a separate one. They deploy into the same estate, use the same identity and secrets handling, and write to the same audit trail. Our sovereignty page goes surface by surface in more depth, and the public sector page covers what this looks like for institutional buyers specifically.

These eight questions are vendor neutral. Ask them of any platform, including ours, and record the answers in the decision document rather than in a meeting note. Architecture decisions outlive the people who made them, and the reasoning is what a successor needs.

1. 01

   Where does the control plane run?

   Name the machines. If the component that schedules work, stores workflow definitions and holds state is operated by someone else, the rest of the review is about a service you rent rather than a platform you run.

2. 02

   Can a workflow complete with no outbound route?

   Block egress in a test environment and run a representative workflow end to end. Anything that fails is a dependency, whether it is a licence check, a scheduler callback or a hosted queue.

3. 03

   Can AI inference run without an external model API?

   Ask which endpoint the AI step calls and who operates it. If the answer is a public API, the prompt and the context assembled to build it leave your estate on every run.

4. 04

   Where are credentials stored, and who can read them?

   Look for vault-backed storage inside the boundary, an explicit read path, and confirmation that no credential is recoverable by anyone outside your organisation.

5. 05

   What telemetry leaves the environment, and can it be turned off?

   Product analytics, crash reporting and usage metering are all outbound traffic. You need the list, the payload contents and a supported way to disable it.

6. 06

   Can human approval be enforced and attributed?

   An approval that lives in a chat message is not a control. The platform should pause execution, require a named identity to act, and bind that decision to the run it authorised.

7. 07

   Who controls upgrade timing?

   Ask who decides when a new version reaches production, what the rollback path is, and how updates reach an estate with no inbound or outbound internet route.

8. 08

   Where does the evidence live, and for how long?

   Execution history, approvals and workflow versions should be in storage you control under your retention policy, retrievable years later without a vendor request.

A useful discipline: insist on an observable answer rather than a described one. Blocking egress in a test environment and running a real workflow answers question two more reliably than any document, and the exercise usually surfaces one dependency nobody knew was there.