Sovereignty

SOVEREIGNTY

The dependency nobody prices in

A capability that can be taken away is not one you have; it is one you are renting under terms you do not control.

THE PROBLEM

The best AI models come from a handful of foreign providers, and your access to them is not a given — it is a business and political arrangement. The terms, the pricing, the rate limits, which models you may use, and the export rules underneath them are all decided somewhere else, and can change without notice and without appeal.

That is a switch, and someone else owns it. Most AI plans assume it will never be flipped, because it usually isn’t — right up until a policy, a sanction or a licence review makes the decision for you. A capability that can be taken away is not one you have; it is one you are renting under terms you do not control.

That is a switch, and someone else owns it.

The answer is where the request runs, not a checkbox

Sentinel runs your AI in-country, on hardware no one abroad can restrict. The model, its weights and the machines all sit inside the country and inside the operator’s reach — so no one outside can decide whether you still have it tomorrow. Sovereignty here is a property of where the work happens, built in and not switched on.

The dashed line is the whole product. Requests reach the in-country model and stop there. Outside providers sit beyond the boundary — off by default, and never serving sensitive traffic. Sentinel Qila goes further: it runs air-gapped, with no outbound traffic allowed, so nothing ever leaves. This is about where a request is handled, not which API you call: Sentinel answers to the OpenAI, Anthropic and Gemini formats in-country (see Quickstart).

Your data stays in-country

Inference runs on dedicated in-country hardware in Pakistan. Requests to the sovereign path never leave the country. The live model is a leading 35B model with a large context window, running on a dedicated slice of in-country hardware — the exact model in force is listed in the console.

Nothing leaves your network

Every request goes to the in-country model by default. Sending it anywhere else is a per-request choice you make, so turning on the outside pool never quietly moves traffic you already have. Sensitive and defence traffic stays on the in-country endpoint no matter the policy. Sentinel Qila goes further: it runs fully isolated inside your perimeter — no outbound traffic allowed, so nothing ever leaves. There is no path out to switch off, and you can prove it both at the network edge and in the deployment itself.

Hardware no one abroad can restrict

Sentinel runs on in-country hardware that sits outside foreign export controls — the restrictions that hold back regional competitors do not reach it. Because the model, its weights and the machines all stay inside the country and inside the operator’s reach, sovereignty is built into the deployment rather than promised in a contract term.

HOW MESH RUNS

Three ways to run Mesh

One engine — Sentinel Mesh — runs three ways, and only two of them are sovereign:

Reseller SaaS — pay-as-you-go on Sentinel’s own in-country cloud. Sovereign by default: outside providers stay off and only touch a request when you choose them, per request. Priced per use on local rails.
Mesh on-premise — the same full gateway, run on your own servers for your own internal routing. You decide which providers it uses and whether it reaches out, so it is self-hosted — but not sovereign and not isolated. It sits between the SaaS and Qila, on one flat annual licence.
Sentinel Qila — the air-gapped defence version. It runs fully isolated with no outbound traffic allowed, so sovereign is the only way it can run. Sovereign-only, on one flat annual licence.

Whichever you choose, you always see your own usage and Sentinel Watch — a licence changes how you pay, not what you can see.

LIMITS

Capacity and control

Priority: defence › paid › free.
Every key has a limit: each key has request-rate and daily caps; none run uncapped.
Priced per use: each call is metered in PKR, with safety checks on the sovereign path.

The proof is in the record, not the label

A sovereignty claim is only as good as the evidence behind it. Every reply tells you which model answered and whether it stayed in-country, and every request is written to the audit trail with the path it actually took — so "it ran in-country" is a record you can check afterward, not a promise you have to take on trust. The model name is a description; the recorded path is the proof.

The model name is a description; the recorded path is the proof.

GOVERNANCE

Governance — Sentinel Watch

Sentinel Watch is the evidence spine. For every request it keeps an audit record of the details only — time, tenant, model, provider, whether it stayed in-country or went outside, the safety verdict, and how many tokens it used — and never the prompt or the reply itself. Those records roll up into a live sovereignty posture (the share of traffic that stayed in-country, with any outside traffic flagged the moment it appears) and a guardrail attestation that counts blocked and redacted requests separately from served ones, so a refused request is never counted as one that ran.

What Watch keeps, and what it refuses to keep. The audit trail records the details of each request — which path it took — but never the prompt or the reply. Served requests roll up into a sovereignty posture; blocked ones are counted separately, because a refusal is not traffic.

Watch is observe-only — you cannot turn on a provider from it — and access is scoped: platform operators see it across every tenant, while a defence-tier or manager account sees Watch over its own traffic and no one else’s. Hardware and throughput dashboards live alongside it.

Sovereignty here is a property of where the work happens, built in and not switched on.

Whichever you choose, you always see your own usage and Sentinel Watch — a licence changes how you pay, not what you can see.

Sell it as your own Prove it never left