About Nexus
Sovereign software for automation, AI, and security.
We build a platform and a line of products that run inside the environments regulated and security-conscious organisations already control, rather than asking them to move their data, models and credentials somewhere else first.
- prebuilt connector actions
- 1,480+prebuilt connector actions
- trigger sources
- 46trigger sources
- supported code languages
- 8supported code languages
- deployment topologies
- 4deployment topologies
Category
A sovereign automation and AI platform, with a security product line built on it.
Nexus started from a simple observation: automation, AI and security tooling increasingly expect an organisation's most sensitive data, models and credentials to leave its own environment. For regulated and security-conscious buyers, that trade is not acceptable.
One execution layer
One execution layer for systems, infrastructure, people, and AI underpins every product we ship. Workflow automation, infrastructure actions, human approvals and AI inference all run through the same engine, with a single audit trail.
Not an on-premises connector to a cloud platform
A platform that runs inside your environment. The distinction matters because it decides who can see the data, who holds the credentials, and who is accountable when something goes wrong.
Why sovereign
Control has to mean more than where a data centre sits.
Sovereignty, as we use the word, means data, models, credentials, execution, knowledge, audit records and evidence stay under customer control. Not merely regional data residency inside somebody else's shared service.
What stays under customer control
- Data used in workflows and AI retrieval
- Model weights and endpoints in the self-hosted model registry
- Credentials, held in vault-managed secrets rather than a third party's vault
- The execution history and audit record for every run
- Knowledge bases and guardrail configurations
- Deployment topology: on-premises, private cloud, sovereign cloud, or air-gapped
What we do not ask customers to accept
- Sending production data to a shared multi-tenant service to get automation working
- Sending source code, credentials or model prompts to a third-party API by default
- A fixed Kubernetes distribution or cloud region as a condition of deployment
- Losing the audit trail once a workflow crosses into an AI step
Product line
One platform underneath a focused set of products.
Nexus Atlas, Nexus Cerberus, Nexus Sentinel and Nexus Shield each address a distinct problem, and each is built on the same execution layer that we also sell directly as the Nexus Platform.
Nexus Platform
The execution layer for systems, infrastructure, people and AI. Prebuilt connector actions, code nodes in several languages, human approval steps, and the deployment model everything else is built on.
Nexus Atlas
External attack surface discovery, enumeration, validation and reporting, run against what an organisation actually exposes to the internet.
Nexus Cerberus
AI application security: an endpoint registry, AI red-teaming, OWASP LLM Top 10 testing mapped to MITRE ATLAS, AI-BOM and model supply-chain scanning, and signed reporting.
Nexus Sentinel
Sovereign security operations: SIEM and SOAR functions running on infrastructure the customer controls, rather than a shared multi-tenant cloud service.
Nexus Shield
Self-hosted web application and API protection, deployed alongside the rest of the line rather than sold as a standalone perimeter product.
Engineering principles
How we decide what to build and how to build it.
These are the recurring rules that shape the platform and every product built on it.
Prebuilt where it exists
1,480+ prebuilt connector actions and 46 trigger sources cover the integrations most teams need on day one, so effort goes into the work that is specific to a given organisation.
Programmable where it does not
Code nodes in Python, Bash, Go, Java, .NET, PHP, PowerShell and JavaScript or TypeScript via Deno, plus HTTP, GraphQL, SOAP, SAP RFC and direct database access, cover what a connector library never fully will.
People stay in the loop
Automate the known. Apply AI to the ambiguous. Keep people in control. Approval, correction, rejection and escalation are workflow steps, not an inbox a process gets thrown over the wall to.
Decisions become intelligence
Turn operational decisions into institutional intelligence: what gets approved, corrected or rejected is captured as structured data your teams can use to improve rules, prompts and policies deliberately.
Sovereignty is control, not geography
Data, models, credentials, execution, knowledge, audit records and evidence stay under customer control. That is a stronger claim than data residency, and it shapes how every product is built and deployed.
Kubernetes-agnostic by design
The platform deploys on-premises, in a private cloud, in a sovereign cloud region, or fully air-gapped, using the customer's own Kubernetes distribution rather than a fixed one we require.
Regulated buyers
Built for teams that have to answer hard questions about data and control.
Public sector, financial services, healthcare and defence and national security teams share a common requirement: they need to explain, in detail, where data goes, who can act on it, and what evidence exists afterwards.
Deployment on your infrastructure
The platform is Kubernetes-agnostic and deploys on-premises, in a private cloud, in a sovereign or regulated cloud region, or fully air-gapped, using infrastructure the customer already operates.
Access and identity controls that map to existing policy
SSO, MFA, RBAC and AD or LDAP integration let access follow the identity and authorisation model an organisation already runs, rather than introducing a parallel one.
Evidence for audit and compliance conversations
Audit and observability are part of the platform, not an add-on, so a compliance or security review has a run-by-run record to work from rather than a summary produced after the fact.
Frameworks referenced honestly
Where our approach aligns with or maps to a recognised framework, including MITRE ATLAS for AI-specific threats, we say so in those terms. We do not describe ourselves as certified against frameworks that certify products, not vendors.
How we work
A direct relationship with the teams who will run the platform.
Regulated deployments succeed or fail on detail: network topology, identity integration, data classification, and who owns what once the platform is live. We work through that detail directly rather than handing it off after a sale.
Architecture first
Before a deployment begins, we work through the topology, the integration points and the data flows with the team that will actually operate the platform.
Scoped assessments before commitments
Where the problem is not yet fully defined, a scoped assessment of an automation, AI or attack-surface question is a lower-commitment way to establish what a deployment would need to cover.
Ongoing engineering contact
Questions about a running deployment go to engineers who understand the platform, not a generic support queue disconnected from how it was built.
Next step
Talk to us about where sovereign software fits your environment.
Whether you are evaluating the platform, a single product, or a specific deployment constraint, our team will work through it with you directly.