Sovereignty
Your systems. Your data. Your models. Your control.
Nexus executes inside your environment. Business data, security telemetry, AI prompts and models, and workflow execution do not need to transit a vendor cloud for the platform to do its work.
Workflows
Execution engine and runtime
AI models
Self-hosted endpoints
Integrations
Connections to your systems
Secrets
Vault-backed credentials
Logs
Execution and access records
Products
Atlas, Cerberus, Sentinel, Shield
No dependency path out to a vendor runtime. Nothing in the diagram above requires a vendor cloud to execute.
- platform, not a hosted service
- Self-hostedplatform, not a hosted service
- operates with no external route
- Air-gap capableoperates with no external route
- models hosted in your estate
- Customer-controlled AImodels hosted in your estate
- and vault-backed secrets
- Your identityand vault-backed secrets
What sovereignty means in Nexus
Six operational principles, not a positioning statement.
Sovereignty is only meaningful if you can point at where each part of the system runs. These are the parts that matter.
Compute stays in your environment
The execution engine runs on infrastructure you operate. Workflow logic is evaluated there, not forwarded to a service someone else runs.
Data stays in your boundary
Business records, security telemetry and documents processed by a workflow are read and written inside the deployment.
AI models are yours to host
Model endpoints are services in your estate. Prompts, retrieved context and responses follow the same boundary as the rest of the workflow.
Identity follows your organisation
Authentication and authorisation resolve against your identity provider and directory, using the groups and roles you already maintain.
Secrets stay in vault-backed storage
Credentials for connected systems are stored centrally and referenced by workflows, so they are never written into workflow definitions.
Evidence and audit stay with you
Execution history, approvals and product reports are produced and retained inside the deployment, under your retention rules.
Architecture
Not an on-premises connector to a cloud platform.
Many platforms describe themselves as on-premises capable and mean that an agent runs locally while the logic runs elsewhere. The distinction changes what leaves your boundary.
Cloud-dependent pattern
A local agent that forwards work outward
- 01Local systems are reached by an agent or gateway installed in your network.
- 02The agent opens an outbound connection to an externally operated control plane.
- 03Logic, AI processing and state live in the vendor service, outside your estate.
- 04Losing that connection degrades or stops the automation.
Nexus sovereign pattern
The control and execution plane runs inside your estate
- 01The platform itself is deployed into infrastructure you operate.
- 02Workflow logic, policy and AI inference execute on that infrastructure.
- 03Credentials, execution records and evidence are written to storage you control.
- 04Operation continues without any connection to an external service.
The practical test is simple: if the external service is unreachable, does the automation still run? In a sovereign deployment the answer does not depend on anyone else's uptime.
Deployment choices
One platform, installed where your requirement puts it.
The deployment model is an architectural decision, and it is usually driven by jurisdiction, connectivity and who is permitted to operate the infrastructure.
- On premises
- Installed in your own data centre on infrastructure your teams operate and monitor.
- Private cloud
- Deployed into a tenancy you control, keeping processing within accounts you administer.
- Sovereign cloud
- Deployed into a national or sector cloud where jurisdiction over the infrastructure is part of the requirement.
- Air-gapped and disconnected
- Operates with no route to external networks, including sites where connectivity is intermittent by design.
- Kubernetes-agnostic footprint
- Runs on vanilla Kubernetes as well as the enterprise and cloud distributions your platform team already standardises on.
Choosing between them
Most organisations start from a constraint rather than a preference: a regulator that requires processing in a jurisdiction, a site with no connectivity, or an internal policy on who may hold production credentials. The deployment architecture page sets out the footprint for each option in detail.
Sovereign AI
AI as a governed step inside the boundary.
AI is one node in a workflow rather than a separate destination for your data. That framing is what allows model use to inherit the same controls as everything else.
- 01
Internal data
Documents, tickets, telemetry from your systems
- 02
Self-hosted model
Registered endpoint running in your estate
- 03
Workflow action
Model output becomes one governed step
- 04
Human approval
Named approver, recorded decision
- 05
Internal system
Action executed against your systems
Prompts, retrieved context, embeddings and model responses stay on infrastructure you operate, because the model endpoint is one of your own services.
What stays inside
- Self-hosted models registered as endpoints in your deployment.
- Knowledge bases and the embeddings built from your documents.
- Prompts, retrieved context and model responses.
- Guardrail configuration and the record of what a model was asked to do.
Why it is governed, not autonomous
A model output can be treated as a recommendation that a named person approves before the workflow acts on it. The prompt, the response, the approver and the resulting action are all part of the same execution record, so an AI-assisted decision can be reviewed the same way any other automated decision is.
Identity, access and secrets
Your identity authority governs who can do what.
Sovereignty over data is incomplete without sovereignty over access. Nexus defers to the authority your organisation already runs.
Single sign-on and MFA
Users authenticate through your existing provider, so joiner and leaver processes apply to Nexus without a separate account store.
Role-based access control
Permissions are granted to roles rather than individuals, and scoped to the workflows, connections and environments a team is responsible for.
Directory and federation
Groups from your directory services can drive role assignment, keeping entitlement decisions with the teams that already own them.
Vault-backed credentials
Connection secrets are held centrally and injected at execution time, so a workflow author never needs to see a production credential.
Least-privilege by construction
Each connection carries only the access its purpose requires, and scope is reviewed as part of the change process you already run.
Approvals tied to identity
A human approval step records the authenticated approver, making the decision attributable rather than anonymous.
Audit, evidence and chain of custody
Keeping the proof of what happened, not just the data.
If the record of an automated action lives in a vendor system, you depend on that vendor to answer questions about your own operations.
Trigger
What started the run and from where
Actor
The identity behind the request
Version
The workflow revision that executed
Approval
Who approved, when, and on what
Outcome
Steps taken and their results
Record
Retained in your storage under your policy
Execution history, workflow version history, the acting identity, approvals and timestamps are generated by the platform as work happens. Product evidence such as the signed dossier from Atlas or the signed risk reporting from Cerberus is produced inside the same deployment.
Because the records originate inside your boundary, an internal audit or a regulator request is answered from material you already hold, on your own retention schedule.
Products inherit sovereignty
Powered by Nexus, so they run where Nexus runs.
Each product is a complete offering, and each one operates on the platform's execution, identity, secrets and audit layers.
Offensive assurance
Nexus Atlas
Attack-surface data, validation results and the signed dossier are produced and retained inside the estate that runs the assessment.
AI security posture
Nexus Cerberus
Registered AI endpoints, test corpora, model supply-chain evidence and signed risk reporting stay within the deployment.
Security operations
Nexus Sentinel
Telemetry, detection content, correlation output, cases and response history remain in the environment you operate.
Request protection
Nexus Shield
Request inspection, policy and exclusions, behavioural decisions and request-level evidence stay inside the boundary.
Nexus Foundry extends the same platform with governed self-service across infrastructure, platform services, applications, workflows and AI agents, using the identity and approval model described above.
Operational independence
Control matters beyond privacy.
Sovereignty is often discussed as a data protection question. In practice, the operational consequences are what buyers feel.
Operate while disconnected
Sites with no external connectivity keep running the same workflows as connected sites, because nothing in the execution path is remote.
No foreign runtime dependency
Processing does not depend on a runtime operated in another jurisdiction, which removes a category of question from procurement review.
Continuity under your controls
Availability, backup and recovery follow the infrastructure practices your organisation already applies to critical systems.
Change on your schedule
Version upgrades and configuration changes move through your own change windows and approval process.
Procurement and jurisdiction
Where a tender requires processing in a named jurisdiction, the deployment model is the answer rather than a contractual assurance.
Estate-wide consistency
The same operating model applies across every product on the platform, so control does not vary by which capability a team adopts.
Regulatory and institutional context
Designed to support organisations with control and residency obligations.
Nexus is architecture, not a compliance product. What it provides is the control over processing and the evidence that assurance work depends on.
Where the architecture helps
Organisations working toward NIS2 obligations, EU AI Act governance expectations, ISO 27001 and ISO 42001 aligned control sets, public-sector security policies or internal assurance frameworks generally need to show where processing happens, who authorised an action and what evidence exists. A sovereign deployment supports those questions directly because the answers live in systems you operate.
What it does not do
Deployment architecture does not certify anything and does not substitute for policy, training, risk assessment or independent audit. Nexus helps evidence control; the organisation still owns the control itself. The compliance page sets out how execution records map to typical evidence requests.
Sovereignty is not the same as security
Running inside your boundary removes an external dependency. It does not remove risk. Access policy, network segmentation, retention periods and operational discipline remain the deploying organisation's responsibility, and they determine how much the architecture is worth in practice.
FAQ
Questions we are asked in architecture review.
- Does Nexus require a cloud control plane?
- No. The control plane and the execution plane are both deployed inside the environment you operate. Nexus does not need to reach an externally hosted service to run workflows, evaluate policy or execute AI steps.
- Can Nexus run fully air-gapped?
- Yes. Nexus is designed for disconnected operation, including environments with no route to the public internet. Content and updates move through the transfer process your organisation already uses.
- Can we use our own AI models?
- Yes. Models are registered as endpoints you host and operate inside the deployment. Workflows call those endpoints, so no external model API is required for Nexus AI steps.
- Does application or security telemetry leave our environment?
- No. Execution history, product telemetry, detections, findings and reports are written to storage inside your boundary and are governed by your retention policy.
- How are secrets handled?
- Credentials for connected systems are held in vault-backed storage and referenced by workflows rather than embedded in them. Access is scoped to the roles your administrators define.
- Can Nexus integrate with our existing identity provider?
- Yes. Nexus supports single sign-on with multi-factor authentication, role-based access control and federation with directory services, so your identity authority remains the source of truth.
- Does sovereign deployment automatically make us compliant?
- No. A sovereign architecture gives you control over processing and the evidence to demonstrate it, but compliance still depends on how you configure the platform, the policies you set and how your organisation operates them.
- How do Nexus products inherit sovereignty?
- Atlas, Cerberus, Sentinel and Shield are powered by Nexus and run on the same deployment. They use the same identity, secrets, execution and audit layers, so their data and evidence stay where the platform is installed.
Architecture session
Define the boundary first. Then automate inside it.
Tell us where processing has to happen, who has to authorise it and what evidence you need to produce. We will walk through the deployment architecture that fits.