Skip to content
Sentinel AI Sentinel AI
Mesh demo Qila demo

For defence

SENTINEL QILA

Prove it never left.

There is no off-country path to switch on, because the defence build ships without one.

Talk to defence →How sovereignty is proved →

Your most sensitive work is the work you cannot put on foreign AI. Classified material can’t touch a model you don’t control; a foreign-hosted cloud isn’t lawful for it; and the moment your capability depends on an overseas provider, someone abroad owns the off-switch. So the fastest-moving tool of the decade is the one your most important missions are locked out of.

Sentinel removes the reason you’re locked out. Inference runs in-country, in Pakistan, on hardware no one abroad can restrict — and for defence it goes further: the Sentinel Qila build is installed fully isolated inside your perimeter with no outbound traffic allowed, so nothing ever leaves your network. What you get back is the ability to use frontier AI on the work that matters most — and an audit trail an assessor can read to prove it never left.

PROOF, NOT PROMISE

Why it's a guarantee, not a switch

Every sovereignty claim comes down to one question: what happens when someone gets the settings wrong?

A toggle answers that badly. It means the off-country path still exists, is reachable, and is one wrong value away from going live — and no amount of process removes that risk. Qila answers it properly: there is no path out, so there is nothing a misconfiguration can open.

That is why this is a guarantee you can hand to an assessor, not a promise to trust.

Commercial deployment versus the Qila defence deployment Two deployments side by side. The commercial deployment — which runs both the Commercial SaaS and the self-hosted Mesh on-premise — can reach outside providers when an operator turns that on; the path exists and stays shut only because a setting keeps it shut, so the guarantee is a promise. The Qila defence deployment is sealed inside your perimeter: there is no outbound path at all, so nothing can leave and no setting could open a way out — the guarantee is something you can prove. COMMERCIAL DEPLOYMENT Commercial SaaS · Mesh on-premise Mesh pipeline auth · guardrails · metering In-country route the default Outside providers a setting keeps this shut QILA DEFENCE DEPLOYMENT Air-gapped · nothing leaves Mesh pipeline auth · guardrails · audit In-country route the only route there is Outside providers NO WAY OUT — NONE TO BUILD YOU PROMISE a setting kept the outside path shut. YOU PROVE there was no outside path to shut.
One guarantee, not a setting to trust: the defence build runs fully isolated inside your perimeter, with no way to reach anything outside it.

What sovereignty rules out

Two risks a foreign-hosted model always carries, and this build does not:

  • No foreign CLOUD-Act reach. Data held by a US-jurisdiction provider can be reached by that jurisdiction no matter where the servers sit. Running in-country on in-country hardware removes the question instead of answering it.
  • No remote kill-switch. Depending on an export-controlled provider means the off switch belongs to someone else. In-country hardware and an in-country build mean nobody abroad can withdraw your capability as a matter of policy.

Aligned with the direction of the National AI Policy 2025: indigenous capability, built and operated inside the perimeter.

A slice with nothing else on it

Shared inference carries a second risk that has nothing to do with routing: other tenants. On a shared node, everyone’s requests draw from the same pool of working memory, and whoever else is in it shapes what you experience — how long a request waits, and when it runs.

Qila does not sit in that pool. It runs on its own dedicated slice of in-country hardware, given to a single tenant, with no cross-access between slices. Nothing else runs alongside your traffic.

That is a hard constraint, not a service level. You share no queue, so no neighbour can infer your workload from how yours behaves — and no scheduling decision depends on who else showed up. It is the same idea as running fully isolated, applied to capacity: the safest property is the one nothing else can reach.

This is not a second stack. It is the same Sentinel Mesh engine, built without the parts a sovereign deployment rules out, running where nothing else runs.

What ships in the enclave

  • Air-gapped — runs fully isolated, with no outbound traffic allowed.
  • A dedicated slice — a slice of in-country hardware carrying one tenant’s traffic, with no cross-access between slices.
  • Internal CA — TLS and identity are handled by an in-enclave certificate authority, so nothing reaches out for a public certificate.
  • Accreditation-grade audit — Sentinel Watch keeps the evidence trail: metadata only, never prompt or response bodies.
  • Classified traffic is not usage-metered — deliberately. Counting it would itself be a leak, so the enclave does not. You pay for the slice; what runs on it is never counted.
  • Flat offline licence — a fixed-term or perpetual licence, verified inside the enclave with no phone-home. No metering, and no invoice that changes with what you run.

BUY IT IN STEPS

Trust is earned, never seized

Sovereign infrastructure is not a thing you can sensibly buy on a slide. The engagement is deliberately built so that every stage is small enough to refuse.

Sovereign AI, bought in steps small enough to refuse You never commit to the whole thing at once. Phase 0 is a scoped session and live demonstration on your own hardware, with no procurement commitment. Phase 1 delivers one operational workflow you choose, against one agreed success metric. Phase 2 scales and hardens, transferring runbooks and training so your team ends up running it. A go/no-go gate sits between each phase, and every gate is also an exit — so the commitment never accumulates into something you cannot walk away from. EACH STEP IS ENTERED ONLY BY CLEARING THE GATE BEFORE IT — AND SMALL ENOUGH TO REFUSE Phase 0 · days scoped session, live demo on your hardware nothing leaves GATE Phase 1 · one workflow a problem you choose, one agreed success metric go / no-go at the end GATE Phase 2 · scaled & hardened widens only after the gate cleared runbooks + train-the-trainer handover is the goal Exit at any gate — fixed scope, no open-ended engagement, and delivery risk sits with the vendor
The commitment never accumulates. Each phase is entered only by clearing the gate before it, and every gate is also an exit — which is what makes a first step on sovereign infrastructure something you can actually authorise.

Phase 0 — days. A scoped session and a live demonstration on your hardware, inside your perimeter. Nothing leaves. No procurement commitment, and the only decision at the end is whether there is one workflow worth doing next.

Phase 1 — one workflow, end to end. A single operational problem you choose, delivered against one agreed success metric, with a go / no-go gate at the end. Engineers work alongside your operators against real workflows, not against a specification written months earlier.

Phase 2 — scaled and hardened. The system widens only after the gate before it was cleared on evidence. Runbooks, documentation and train-the-trainer transfer as it goes, so capability accumulates on your side rather than ours.

What that means commercially

  • Fixed-scope phases — no open-ended engagement, and an exit at every gate.
  • Milestone-gated — delivery risk sits with the vendor, not the defence budget.
  • Joint IP from day one — the platform, the data and the roadmap stay inside the institution.
  • Handover is the goal, not the exception — your certified engineers run the system and we step back to advisory. An engagement that cannot end is a dependency, which is the thing this whole page exists to avoid.

Every claim on this page is citable, and the sources are available on request.

Governance you can hand to an assessor

The evidence trail is yours to read, not just ours: Sentinel Watch is scoped to your own traffic for a defence account, so the audit an assessor asks for does not require going through us — and it never exposes another tenant’s rows.

Sentinel Watch records what was served, by which model, and whether it stayed in-country — metadata only, never the prompt or response body — and counts guardrail refusals separately from served traffic, so a refused request is never mistaken for one that ran. It is read-only: no provider can be turned on from it, because the defence build has none to turn on.

What Sentinel Watch records, and what it never does Each served request produces a metadata-only audit record: time, tenant, model, provider, the in-country or external route it took, the guardrail verdict, and token counts. Prompt and response bodies are never recorded. The records roll up into a sovereignty posture — the share of traffic that stayed in-country, with any external-provider traffic flagged — and a guardrail attestation that counts blocks and redactions apart from served traffic. Each served request through the Mesh Audit record METADATA ONLY · time · tenant · model · provider · route: in-country / external ← the proof · guardrail: allow · redact · block · tokens (prompt + completion) Prompt & response bodies never recorded — not stored, not surfaced Sovereignty posture % in-country external-provider traffic flagged if it appears Guardrail attestation blocks · redactions counted apart from served traffic
The evidence an accreditation asks for, kept automatically. Each request leaves a metadata-only record of the route it took; the bodies are never stored. Served traffic rolls up into a sovereignty view, and guardrail refusals are counted apart from it.

The audit is granted by tier, not by role. Because accreditation-grade evidence is part of what a defence deployment is sold, access to it is decided by the account’s tier — it does not depend on a user’s internal role, so a cleared operator does not have to be made a workspace administrator just to read the trail their accreditation requires. That is one rule inside a single access policy that decides every action from the subject, the action, and the resource it touches, and refuses anything it does not recognise. The roles themselves stay deliberately small — a manager runs the workspace, a developer builds on it — and the policy is the same one the platform publishes and enforces, not a defence-only exception bolted on.

Read how the boundary is drawn in Sovereignty, and the enclave detail in Sentinel Sovereign.

Underneath, it is the Sentinel Mesh gateway — the same one described under For telcos & builders, built without the parts a sovereign deployment rules out.

Who builds and holds it

Delivered by Mercurial Minds, with cleared Pakistani engineers drawn from NUST, MCS, EME and Air University alongside retired technical officers. The intent is an engineering partner embedded with your operators and a route to an independent in-house team — not a black box you cannot inspect, and not a dependency you can never exit.

Prove it never left.

Talk to defence →How sovereignty is proved →