Security and sovereignty are properties of the platform, not features on top of it.
One permission decision on every path into your data. Nothing runs unless the platform can prove where it came from. Tenants that cannot reach each other. And a platform that keeps working with the uplink pulled out.
The short version #
Four claims carry most of a security review. Each is structural: it holds because of where it sits on the path a request has to take, not because someone remembered to apply it. If you read nothing else on this page, read these four tiles, each of which opens the property behind it.
One permission decision
The same rules are enforced whether the caller arrives over REST, SQL, natural language or a graph query, because they are evaluated once on a path all four have to take.
How it is enforced →Fail-closed by default
When a check cannot be resolved the platform refuses rather than assumes, so an unusual route in does not become an open door.
How it is enforced →Verified before it loads
Signed provenance, a bill of materials and a signature check stand between a build and execution, and untrusted or AI-authored code is sealed away from everything else.
How it is enforced →Runs disconnected
No runtime dependency on an external model host or network provider, including at fully air-gapped sites, so sovereignty is not a deployment option bolted on at the end.
How it is enforced →What you are left holding if you leave #
Dependence is rarely sold as dependence. It arrives as convenience and turns into leverage the moment the cost of leaving exceeds the annual bill, which is when terms change and the price of staying is whatever the supplier decides it is. The only durable answer to that is mechanical, so here is the mechanism rather than the adjective.
Sovereignty is not a clause in a contract. It is the list of things that still work after the contract ends.
The data is in your storage, in open formats
Datasets rest on tenant-scoped object storage in open columnar and vector-native formats: our sovereign store, or an S3-compatible bucket you already own. Nothing is written into a proprietary container that only we can open.
The weights are yours to keep serving
Open models are imported once into a content-addressed store the platform holds inside your boundary. There is no runtime call to an external model host, so nobody upstream can reprice, deprecate or withdraw the model your service is built on.
Applications are artefacts, not accounts
Each application compiles to a deterministic, content-addressed package carrying a bill of materials and a signed provenance record. You can hold that artefact, read what is inside it and prove where it came from without asking us.
Identity stays where it already is
People sign in through your own OIDC provider and are provisioned from your own directory over SCIM. We do not become your identity provider, so removing us does not orphan a single account.
The audit record is yours to export
The ledger correlating data access and privileged actions to the identity behind them is held inside your instance and exportable to you. It is not a report we compile on request and could decline to.
Which jurisdiction reaches it is your decision
The platform runs in the United Kingdom sovereign cloud we operate, or on infrastructure you place in a jurisdiction you choose. Whose law reaches your data follows from where the hardware sits, not from a supplier's corporate domicile.
We test for the attacks that arrive with agents #
Penetration testing here covers the ordinary application surface, and then deliberately goes after the failure modes that only exist once a language model is making decisions and an agent is holding credentials. Adversarial prompts. Instructions smuggled in through retrieved content. Attempts to capture an agent mid-task and turn its permissions against the system that granted them.
That is a different exercise from testing a web application, and it is the one that matters if you are about to give an autonomous system access to your data. It is also why the containment model on this page is built the way it is: the test assumes an agent will eventually be persuaded to do the wrong thing, and the platform is designed so that when it is, there is nothing on the other side of the sandbox to reach.
An agent with real permissions is a new class of target, and it is tested as one.
Assured independently, as well as by construction #
Structure is one half of assurance. The other half is an assessor outside the company examining how we run, on a schedule we do not get to set.
- ISO 27001 certified
- Our information security management system is certified to ISO 27001 and audited annually, so how we govern security is examined on a schedule rather than asserted once.
- Cyber Essentials certified
- We hold Cyber Essentials, the United Kingdom's government-backed baseline for the technical controls that turn away the most common attacks.
- Penetration testing aimed at agent risk
- Testing covers the ordinary application surface and, deliberately, the failure modes that arrive with language models and autonomous agents: adversarial prompts, and attempts to capture an agent and turn its permissions against the system.
- Encryption at rest and in transit
- Data is encrypted where it rests and on every hop between services, with key custody a decision you make rather than one made for you.
- Physical security controls
- The environments we operate are physically controlled. Where you run the platform in your own estate, that boundary is yours to set, and we will tell you exactly which controls move with it.
A certificate tells you the management system is examined. It does not tell you how a request is authorised, where a model runs or what becomes of a prompt. So for a security review or a procurement process we will take your team through the architecture, the controls on this page, the deployment options and the trade-offs behind each decision, in as much depth as you need.
Start a security reviewSecurity and privacy enquiries #
Start a conversation with us, or write to our privacy address and we will route it to the right people.
[email protected]How it holds #
Below are the structural properties behind those claims. Each one is a place a request has to pass through rather than a policy somebody has to remember, so open the two or three your review actually turns on and leave the rest closed.
One permission path, however you ask
Data rules belong to the data, not to the client asking, so they are evaluated once on a path every query has to take.
- Row filters, column masks and deny decisions are evaluated on every read, so REST, Arrow Flight SQL, the PostgreSQL wire endpoint, natural language and graph queries enforce identical rules.
- A rule that cannot be resolved denies. Governance never defaults open for the caller that took an unusual route in.
- Generated and hand-written queries alike are read-only by default, with mandatory limits and a bounded cost ceiling.
- Natural-language questions are planned into permission-aware SQL with citations back to the exact data used, and the planner declines rather than guesses.
Tenants that cannot reach each other
One platform projects a private, server-enforced slice of every service per tenant, down to the accelerators.
- Tenant scope is derived server-side from validated session or token state, never from a client-supplied header, hostname or routing hint.
- Row-level security and mediated data access mean even shared services cannot read or write across the tenant boundary.
- Heavy workloads get their own per-tenant database, search and inference clusters, composed automatically by the platform.
- Accelerators can be assigned exclusively to a tenant, or shared from a pool under enforced per-tenant budgets, so utilisation stays high without leaking capacity.
Nothing runs unless it is verified
Every application compiles to one artefact whose origin the platform can prove before it will load it.
- An application compiles to a deterministic, content-addressed package: identical input yields a byte-identical bundle and digest, and drift fails the build.
- Every build emits a signed SLSA provenance attestation recording exactly how the artefact was produced.
- A CycloneDX software bill of materials enumerates every component inside it, for audit and vulnerability response.
- Cosign signatures bind the artefact, its attestation and the identity that built it, and are checked before anything loads.
Untrusted and AI-authored code, contained
Trust level decides where code may run, and the platform refuses every combination outside those bounds at the moment of execution.
- Every application carries a trust level, from first-party signed through to AI-authored, that governs how strongly it must be isolated.
- Admission rules map each trust level to the runtime profiles it is allowed on, and refuse every other pairing with a stable, recorded reason.
- Tenant-untrusted and AI-authored code runs in a WebAssembly sandbox, or a microVM where the workload requires it, with no ambient access to the platform around it.
- Import allowlists, execution deadlines, resource quotas and per-run cleanup apply on every host, and anything that crash-loops or fails verification is quarantined.
Sovereign by construction
Nothing the platform needs at runtime lives somewhere you cannot reach, including at sites with no connectivity at all.
- Datasets rest on tenant-scoped object storage: our sovereign store, or your existing S3-compatible backend. Where data lives is your decision.
- The private model hub is a content-addressed store of weights the platform owns. Import once and serve forever, with no runtime dependency on any external model host.
- External providers are optional and policy-gated: you decide which may serve a request and whether data may leave the cluster.
- Credentials are vault-referenced, never returned, never logged, and brokered through one audited gateway that can route to your own vault.
- Networking, DNS and edge routing are run by the platform itself, and remote sites keep serving their loaded models when the core is unreachable.
Operated with the evidence to prove it
Control is only real if you can see what happened, so assurance here is a working record rather than a statement of intent.
- Layered fail-closed gates stand before promotion: contract validation, automated tests, adversarial code and security review, then live tests against deployed services.
- Releases are immutable artefacts promoted by declaration. Rollout is progressive, rollback is automatic the moment health regresses, and a deployment is complete only when the cluster is observed healthy.
- A canonical, redacted audit ledger correlates every data access and privileged action to the identity, session and query behind it.
- Metrics, dashboards, alerts and distributed traces ship with the platform, so degradation is visible before it becomes an outage.
Where control shows up elsewhere #
Control is a property of the whole platform, so the detail sits beside the thing it protects as well as here.
Deployment options
How each way of running the platform moves the boundary between what we operate and what you do, from a managed instance to a sealed box.
Compare the options →Where it runs
The sovereign cloud we operate in the United Kingdom, and sovereign deployment into infrastructure you run in your own jurisdiction.
See the placement decision →The principles behind it
What we commit to when we say sovereign, why the platform is built this way, and what we will not trade away to make it simpler.
Read the principles →