How it works

How dwaar keeps every request in India.

One decision per request: which approved model endpoint in India serves it. Here is what dwaar checks, what you get back, and the record it keeps.

Get started Request the security pack

1CheckThe registry and your policy decide which endpoints in India may serve the request.
2ServeAn approved endpoint answers; outbound traffic can only reach approved hosts.
3RecordA signed record of where the request ran comes back with the answer.

01The decision

Every request passes one decision.

Before anything is sent, dwaar checks the request against a signed registry of model endpoints in India and against your policy. The request goes to an approved endpoint in an Indian data centre, and if none fits, dwaar says exactly why.

THE CHECKS, IN ORDER
#	Check	Field	Set by
01	Signed registry	snapshot	dwaar, signed each release
02	Residency tier	min_tier	key, request
03	Zero retention	zdr	key, request
04	Allowed providers	only · ignore	key, request
05	Data-centre pin	data_center	key, request
06	Capabilities	tools · stream · …	request
07	Preference	order · sort	request
→	An approved endpoint, or 503 no_india_provider with a count per rule

The stricter rule wins.

A request can narrow its key’s policy. It can never widen it.

Key policy	Request asks	Applied
zdr = true	zdr = false	zdr = true
min_tier = "A"	min_tier = "B"	min_tier = "A"
only = [a, b]	only = [b, c]	only = [b]

How routing works

02Edge cases

You always know what happened.

The situations your risk team will ask about, and what dwaar does in each. Nothing is sent to an endpoint your policy does not allow.

Situation	What dwaar does	You get back
A team asks for a model that’s only served abroad	It isn’t in the registry, so nothing is sent	404 model_not_found
A request needs zero retention and no endpoint for the model offers it	Refuses before sending, and counts the rules that excluded each endpoint	503 no_india_provider
An endpoint’s host fails the egress check on the way out	Stops it at the proxy, then tries the next approved endpoint under the same policy	200, or 502 egress_denied
A provider stalls in the middle of a stream	Ends the stream with an error. It never resends a request a provider may have processed	upstream_timeout
The signed registry passes its expiry	The gateway won’t start on it until a new one is signed	refused at start

IN DETAIL · NO MATCHING ENDPOINT

Your data: Stays in the gateway. Nothing is sent.
You get back: 503 no_india_provider, counting each rule that excluded an endpoint.
Retry: None. A retry would be refused for the same reason.
Evidence: The refusal body and its request id.
You do: Relax the request or pick another model. A request can’t loosen the key’s policy.

IN DETAIL · BLOCKED AT THE EDGE

Your data: Stopped at the egress proxy before any byte left.
You get back: The next approved endpoint answers, or a refusal if none is left.
Retry: Only before sending. Never after a provider may have seen the request.
Evidence: The blocked attempt is listed in the routing record.
You do: Nothing for the request. Your operator reviews the blocked host.

03Records

A record you can check yourself.

Every served request gets a signed record of where it ran, which you can check without asking us. When a request cannot be served, the answer names the rule.

REFUSAL · gateway response503

HTTP/1.1 503 Service Unavailable
x-should-retry: false
x-dwaar-registry-version: dev+<test registry>
x-request-id: <uuid>

{
  "error": {
    "message": "No endpoint for 'demo/echo' satisfies this request: 1 offered; 1 excluded by data_center (request). Request preferences cannot relax key policy; choose another model from /v1/models or contact the gateway operator with x-request-id. See docs/errors.md#no_india_provider",
    "type": "api_error",
    "param": null,    "code": "no_india_provider"  }
}

Gateway test against a mock provider · dwaar-gateway 0.1.0 · commit 722ea112967d

ROUTING RECORD · signed200

{
    "receipt_id": "<uuid>",
    "issued_at": "<timestamp>",1"route": {"data_center": "chennai", "endpoint": "chennai", "host": "api.chennai.test", "provider": "chennai", "region": "in", "selected_on": "<date>", "tier": "A", "upstream_model": "mock-echo"},2"attempts": [{"endpoint": "pune", "result": "egress_denied"}],
3"registry": {"content_sha256": "<sha256 of the test registry>", "serial": 0, "version": "dev+<test registry>"},
4"policy": {"key_id": "evidence", "policy_hash": "4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945"},
    "outcome": {"http_status": 200, "status": "completed", "usage": {"completion_tokens": 2, "prompt_tokens": 1}, "usage_complete": true}
}

Gateway test against a mock provider · dwaar-gateway 0.1.0 · commit 722ea112967d

Where it ran. Provider, region, data centre and residency tier of the endpoint that answered.
What was tried. Every attempt before sending, including ones the egress proxy blocked.
Which registry. The signed snapshot that made the decision, by serial and hash.
Which policy. A hash of the key and request policy that applied.

VERIFY IT YOURSELF · offlineno call to dwaar

$ dwaar-receipt verify --keyset keys.json receipt.json

dwaar enforcesWhich endpoints are eligible, and that outbound traffic reaches only approved Indian hosts.

The signature authenticatesThat dwaar issued the record and it hasn’t changed since.

Rests on contracts and auditsWhere the provider processes and stores data once it arrives.

Request the security pack Signing keys

04Compared

What dwaar adds to a cloud region.

Hyperscaler Indian regions are endpoints dwaar routes to. The difference is who holds the line when the stack changes, and how much review each change costs.

Aspect	Calling one cloud region directly	Through dwaar
Choice of model	What one provider offers in India	Indian providers and hyperscaler Indian regions, behind one API
Switching models	A new integration, and often a new security review	A config change under the policy you already approved
A developer changes the region	Caught in review, if someone notices	Refused at the gateway
A provider has an outage	Your team reroutes by hand, sometimes abroad	The next approved Indian endpoint, before sending
Policy per request	Per account, through IAM	Per key and per request: tier, retention, providers, data centre
Record for your auditors	Cloud logs, assembled per provider	One signed routing record per request
Indian languages	Whatever that provider’s models handle	Routing by script to models built for it
Billing	Per-cloud invoices, often in USD	One INR invoice with GST

05In your code

What you see as a developer.

A normal chat completions call. dwaar adds a request id and a record id to every response, so you can trace any request later.

Developers

RESPONSE HEADERS200

x-dwaar-receipt-id: <uuid>
x-dwaar-receipt-status: okx-served-by: mumbaix-dwaar-registry-version: dev+<test registry>
x-request-id: <uuid>

Gateway test against a mock provider · dwaar-gateway 0.1.0 · commit 722ea112967d

Start building with sovereign AI.

Open models, hosted in India, behind one API key.

Get started Talk to our team