Government and defence
Your mission should not depend on someone else's cloud.
Nexus gives public institutions one sovereign platform for automation, AI, infrastructure operations and security, running inside the estate you already govern. Data, models, credentials and evidence stay under institutional control, including in disconnected and air-gapped environments.
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
- execution record for every run
- Auditableexecution record for every run
Why public institutions struggle
The constraint is rarely the process. It is where the processing is allowed to happen.
Most automation and AI programmes in government stall on the same six points, and none of them are solved by a better user interface.
Sensitive data cannot always leave the jurisdiction
Citizen records, case files, defence data and security telemetry are frequently bound by policy or statute to processing inside a specific national boundary.
Disconnected environments break cloud-dependent tooling
Classified networks, field sites and segregated enclaves cannot reach an externally hosted control plane, which rules out much of the mainstream automation market.
Automation, AI, security and infrastructure arrive as separate stacks
Each is procured, accredited and operated on its own terms, which multiplies integration work, licensing and the number of environments that need assurance.
Legacy and specialist systems are unavoidable
Registers, case systems and mission-specific applications remain the system of record long after a modernisation programme starts, so automation has to reach them as they are.
AI adoption stalls at the data boundary
When prompts, documents and context have to transit an external model API, the assessment usually stops before the use case is ever tested.
Procurement needs evidence, not assurances
Evaluation teams have to see where processing happens, who authorised an action and what record exists, in a form they can put in front of an auditor.
What Nexus gives a public institution
One governed environment for operations, AI and security.
The point of a single foundation is not consolidation for its own sake. It is that one deployment model, one identity model and one audit trail cover every kind of work.
Foundation
One sovereign execution layer
The control plane and the runtime are installed in infrastructure the institution operates, on premises, in a sovereign cloud or air-gapped.
Reach
Automation and integration
1,480+ pre-built connector actions and 46 trigger sources connect enterprise, departmental and specialist systems without bespoke middleware.
Depth
A real code escape hatch
Where low-code stops, code nodes run in eight language families, including Python, Bash, Go, Java, .NET, PHP, PowerShell and JavaScript or TypeScript through Deno.
Operations
Infrastructure automation
Kubernetes and infrastructure operations are driven from the same workflows and the same approval model as everything else.
Judgment
Self-hosted AI
Model endpoints, knowledge bases and guardrails run inside the deployment, so an AI step is subject to the same boundary as a database step.
Control
Identity, approvals, secrets and audit
Access resolves against the institution's own identity authority, credentials sit in vault-backed storage and every run leaves an execution record.
From requirement to workflow
How a requirement becomes a governed, audited process.
This is the shape of most Nexus deployments, whatever the department and whatever the systems involved.
- 01
Trigger
A form submission, a scheduled review, an inbound message or an event published by a departmental system starts the run.
- 02
Integration
Connector steps pull the records the process needs from enterprise systems such as SAP or Salesforce, or from a departmental register through its database or file interface.
- 03
Rules + Code
Deterministic rules apply policy thresholds, and a code node in the language the team already uses, Python for example, validates and transforms the payload.
- 04
Sovereign AI
A self-hosted model classifies the request or extracts structured fields from unstructured attachments, inside the estate.
- 05
Human Approval
The workflow pauses for a named, authenticated officer who reviews the assembled evidence and decides.
- 06
System Action
The approved outcome is written back to the systems of record through their own interfaces.
- 07
Audit
Trigger, retrieved data, rule outcomes, model output, approver identity and write-back are retained as one execution record, with every credential drawn from the vault.
The same workflow can also be exposed as a callable function, so another system or an internal portal can invoke it on demand rather than waiting for a schedule.
Sovereign AI
AI that can actually be approved for use.
The blocker in government AI adoption is usually not model quality. It is that the assessment cannot get past where the data goes.
Model endpoints you host
Models are registered as services inside the deployment and called by workflows like any other internal system.
Knowledge inside the estate
Knowledge bases built from internal documents, and the retrieval that serves them, stay on the institution's own infrastructure.
No external model API required
Nexus AI steps do not depend on a hosted provider, which is what makes AI viable in segregated and air-gapped environments.
Guardrails and scoped use
Guardrail configuration and the scope of a model's task are set by the institution and recorded with the workflow version.
Human approval where policy requires it
A model output can be framed as a recommendation that a named officer must accept before the workflow acts on it.
Reviewable AI decisions
The prompt, the response, the approver and the resulting action sit in the same execution record, so an AI-assisted decision can be examined like any other.
A model is a step, not a system of record
Treating inference as one node in a larger workflow keeps the institution's controls in place around it: the input comes from a governed integration, the output is reviewed where policy requires review, and the whole sequence is recorded. Model output informs a decision; it does not replace the officer who makes it.
Security products on the same foundation
Four products, one deployment and governance model.
Each product is complete in its own right, and each one runs on the platform the institution has already accredited and operates.
Nexus Atlas
External assurance
OpenNexus Cerberus
AI application security
OpenNexus Sentinel
Detection and response
OpenNexus Shield
Request-layer protection
OpenNexus Foundry, governed self-service on the same platform
Nexus platform foundation
- Workflow orchestration
- Integration and connectors
- Multi-language code nodes
- Self-hosted AI
- Human approval
- Identity and RBAC
- Vault-backed secrets
- Execution history and audit
Products are deployed on the same foundation, so they inherit the deployment model, identity, secrets handling and audit trail the institution already governs.
- Nexus Atlas
- Sovereign offensive assurance. Continuous external attack-surface mapping, explicitly authorised and consent-gated non-destructive validation, and a cryptographically signed dossier produced inside the estate.
- Nexus Cerberus
- Sovereign AI application security. Register AI endpoints, red-team against the OWASP LLM Top 10, map findings to MITRE ATLAS, assess the model supply chain and AI-BOM, and produce signed risk reporting.
- Nexus Sentinel
- Sovereign SIEM and SOAR. Security telemetry, open Sigma detection content, MITRE ATT&CK coverage, correlation, cases, investigation and governed response with a full audit trail.
- Nexus Shield
- Sovereign web application firewall and behavioural protection. Request inspection, attack classification, scoped rule tuning, behavioural decisions and request-level evidence.
Use cases
Where institutions apply the platform.
These are patterns we see across central and local government, defence, national cyber organisations and public healthcare.
Cross-agency workflow automation
Processes that span departments run as one governed workflow, with entitlement rules applied at the point of exchange.
Legacy integration and case processing
Case data is assembled from registers and older systems through connectors, database steps and code nodes rather than manual lookup.
Secure document and data processing
Documents are parsed, validated and routed inside the estate, with extraction handled by a self-hosted model where the content is unstructured.
Sovereign AI assistants over internal knowledge
Staff query internal knowledge through a model and retrieval layer that never leaves the institution's infrastructure.
Infrastructure and Kubernetes operations
Provisioning, scaling and remediation run as approved workflows, so infrastructure change carries the same record as business change.
National CERT and SOC operations
Sentinel centralises telemetry, applies open detection content and drives governed response inside the sovereign environment.
External attack-surface assurance
Atlas maintains a continuous view of exposed assets and produces signed evidence for internal and oversight reporting.
AI governance and red-teaming
Cerberus tests AI applications and models, then reports findings against recognised AI threat taxonomies.
Governed internal service catalogue
Foundry publishes infrastructure, platform services, applications, workflows and AI agents for request, approval and provisioning under policy.
Air-gapped and disconnected operations
Continuity when external networks are unavailable.
Disconnected operation is a design property of the platform rather than a restricted mode with reduced function.
No vendor-cloud runtime dependency
Workflow execution, policy evaluation, AI inference and evidence generation all happen on infrastructure the institution operates. There is no external service that has to be reachable for the platform to keep working, and no licensing check that requires a call outward.
The same platform at connected and disconnected sites
A workflow authored in a connected environment behaves the same way at a segregated site, which keeps operational procedures consistent across an estate that mixes both. Updates and content move through the transfer process the institution already runs.
Governance, identity and evidence
Built for proof.
In public institutions the record of what happened is part of the deliverable. Nexus produces it as a by-product of running the work.
Identity from your own authority
Single sign-on with multi-factor authentication, role-based access control and federation with directory services, so joiner and leaver processes apply without a separate account store.
Vault-backed secrets
Credentials for connected systems are held centrally and injected at execution time, scoped to the roles administrators define.
Policy-driven human approval
Approval steps are part of the workflow definition, so the requirement for a human decision is enforced rather than assumed.
Execution history
Every run records what ran, on which workflow version, with which inputs and what result.
Attributable decisions
Actions and approvals resolve to an authenticated identity, which is what makes an execution record usable as evidence.
Signed product artefacts
Where a product produces formal output, such as the Atlas dossier or Cerberus risk reporting, that artefact is generated and retained inside the estate.
Regulatory and institutional context
Control and evidence, not automatic compliance.
Nexus is architecture. It supports the assurance work an institution has to do; it does not perform that work on the institution's behalf.
Where the architecture helps
Institutions working toward NIS2 obligations, EU AI Act governance expectations, ISO 27001 and ISO 42001 aligned control sets, national public-sector security policies or internal assurance frameworks generally have to show where processing happens, who authorised an action and what record exists. A deployment inside the estate answers those questions from systems the institution already operates.
Institution-owned assurance
Accreditation of the environment, policy, training and independent assessment remain with the organisation. Nexus supplies execution evidence for those reviews. The compliance page sets out how execution records map to common evidence requests.
Sovereignty is not the same as security
Running inside your boundary removes an external dependency. It does not remove risk. Access policy, segmentation, retention and operational discipline determine how much the architecture is worth in practice, and those remain the institution's responsibility.
Why Nexus instead of a tool zoo
One foundation is cheaper to govern than four.
Every additional platform in a public institution carries its own accreditation, identity integration, credential store and audit surface.
Automation, AI, infrastructure and security in one place
The same execution engine that automates a departmental process also drives Kubernetes operations, runs AI steps and powers the security products. That means one deployment to assess rather than several that each need their own assurance track.
Prebuilt where it exists, programmable where it does not
Pre-built connector actions cover the common systems. Where a specialist or legacy interface has no connector, a code node in a language your teams already maintain closes the gap without a vendor engagement.
Products inherit the model you already approved
Because Atlas, Cerberus, Sentinel and Shield run on the platform, adopting one does not introduce a new deployment model, a new identity integration or a new place where evidence lives.
Procurement and architecture review
Eight questions to put to any platform.
These are the questions that separate a sovereign architecture from a hosted service with a local component. They apply to us as much as to anyone else.
- Q01
Where does the control plane run?
If the logic that decides what happens sits outside your estate, the deployment is a client of someone else's service.
- Q02
Can workflows continue with no internet route?
Disconnected operation is either an architectural property or it is not available at all. It cannot be added contractually.
- Q03
Can AI inference run without external model APIs?
Ask where the model executes and where the prompt goes, not whether the vendor offers a private option.
- Q04
Where are credentials stored?
Vault-backed storage under your access controls, or embedded in workflow definitions and vendor-held configuration.
- Q05
Can human approval be enforced and attributed?
An approval that is not tied to an authenticated identity and a timestamp is not evidence.
- Q06
Can it integrate with legacy systems without a bespoke vendor project?
Look for pre-built coverage plus a genuine code path, so unusual interfaces do not become change requests.
- Q07
Who controls upgrade timing?
In regulated environments, change windows and revalidation are your process, not a vendor release schedule.
- Q08
Where does the evidence live?
If the record of what happened is held by the vendor, answering an audit question depends on the vendor.
Use cases
Processes public sector teams run on Nexus.
Each combines two or more systems in one governed run, with approval and audit.
Microsoft 365 + ServiceNow + Jira
Citizen request to case resolution
Requests arriving by email become tracked cases, with technical work handed to engineering and updates sent back.
View use caseWorkday + Okta + Microsoft 365
Joiner, mover, leaver for public employees
Workforce changes become policy-checked identity changes, with collaboration set up and removed on time.
View use caseSAP + ServiceNow + Microsoft 365
Procurement exception handling
Procurement and invoice exceptions reach a named owner, and SAP changes happen only after approval.
View use caseMicrosoft Azure + SAP + ServiceNow
Cross-agency file intake and validation
Files from other agencies are validated before they touch finance records, and problems become tickets.
View use caseFAQ
Common questions from evaluation teams.
- Does Nexus require a connection to a vendor cloud?
- No. The control plane and the execution engine are deployed inside the institution's estate, so workflows, policy evaluation and AI steps do not depend on an external service being reachable.
- Can Nexus operate in a disconnected or air-gapped environment?
- Yes. Nexus is designed to run with no route to external networks. Content and version updates move through the transfer process the institution already operates.
- Do we have to use an external AI provider?
- No. Model endpoints are hosted inside the deployment. Prompts, retrieved knowledge and model responses stay on infrastructure the institution operates.
- How does Nexus work with legacy departmental systems?
- 1,480+ pre-built connector actions and 46 trigger sources cover common enterprise systems, and multi-language code nodes handle interfaces that have no connector, so integration does not require a bespoke vendor project.
- How is human accountability enforced?
- Approval steps pause a workflow until a named, authenticated person decides. The approver, the decision and the timestamp become part of the execution record.
- Where do credentials for connected systems live?
- In vault-backed storage under the institution's access controls. Workflows reference a credential rather than containing it, so authors do not handle production secrets.
- Does a sovereign deployment make us compliant?
- No. It gives the institution control over processing and the evidence needed for assurance work, but compliance depends on configuration, policy and how the organisation operates the platform.
- How do the security products relate to the platform?
- Atlas, Cerberus, Sentinel and Shield are powered by Nexus and run on the same deployment, so they inherit the same identity, secrets, execution and audit model.
Architecture session
Bring us the constraint, not just the requirement.
Tell us where processing has to happen, which systems are in scope and who has to authorise an action. We will walk through the deployment architecture and the workflow shape that fits.