Grounding a sovereign model without sending the question abroad

What leaves when an agent searches

An agent phrases its own retrieval. The query it sends is not a keyword; it is the question its operator is trying to answer, in the operator's framing, with the entity, the place and the time window in it. A single query may be harmless. A month of them from one organisation is a description of what that organisation is working on, in the order it started working on it.

Attached to every query is the API key, and to every key an account. Whatever a provider does with the record afterwards, the record was created at the moment of the call, in the provider's jurisdiction, under the provider's law. That is the fact residency policies tend to miss: for retrieval, processing location is disclosure location.

What a provider can and cannot promise

A provider can undertake not to retain query text, to keep only aggregates, to fingerprint rather than store. unlob cloud makes exactly those undertakings in its privacy policy, and they are worth having. But they are undertakings about what happens after the call. They cannot make the call not have happened, and they cannot move where it happened.

The distinction is between a policy and an architecture. Not retaining is a policy, and policies are revisable, subpoenable and breachable. Not seeing is an architecture: the query is processed inside your boundary because the index is inside your boundary, and there is nobody outside it to receive the question. For a sovereign programme, only the second is residency.

Why only an own-index provider can offer this

A search API that resells Google or Bing results, or adds a retrieval layer over another provider, forwards your query upstream by construction. It cannot be deployed inside your boundary because the thing that answers the query is not theirs to deploy. The same is true, less obviously, of the own-index providers that serve from one jurisdiction on their own terms: the index exists, but it is not offered inside yours.

unlob builds and serves its own index, which is what makes a deployable edition possible: the index, the coverage graph and the receipts move inside the boundary as one unit, and at query time nothing crosses it. Snapshots of the index come in on a schedule you set. No telemetry goes out. The model that reasons over the evidence is whichever one you run.

# Against a sovereign installation the endpoint is yours; the API is unchanged.
curl -H "x-api-key: $UNLOB_API_KEY" \
  "https://evidence.example.gov/ground?objective=flood+defence+funding+announcement&max_age=7d&min_independent_origins=2"

Keep the record, and do not anonymise it

Once retrieval runs inside the boundary, the instinct is to treat the query log the way a public cloud provider would: aggregate it, fingerprint it, keep as little as possible. Inside the boundary that instinct is wrong. The log is now your audit trail, and an audit trail that cannot say who asked what, when, and what evidence they were given is not one.

Record the query in full. Attribute it to the calling principal — the key, the service account, the user — not merely the tenant. Join it to the coverage receipt the call produced, so a reviewer can replay the exchange: this agent asked this, was handed these passages with this provenance, and was told these gaps. Set retention by your policy and enforce it inside the boundary. You are the data controller of a fully identifying record, and that is the point.

State the symmetry to whoever signs off the deployment. A foreign provider already holds exactly this record about you, created at the moment of every call. The question was never whether the queries are recorded. It is only who holds the record.

What the layer must not do

A public body deploying retrieval beneath a model has one further constraint: nothing in the stack may decide what is true. A system that labels content is politically and procedurally undeployable in a democracy, whatever its accuracy. A system that records who reported what, where the claim first entered the record, how many independent origins corroborate it and what evidence is missing is deployable, because the judgement is visibly the model's and the people's.

That is the line unlob holds. The receipt says how well a claim is supported and by whom; it never says whether the claim is correct. Keep that line in your own design too: put corroboration thresholds and source-role preferences in written policy, applied uniformly, and let the model reason from the receipt rather than from a verdict.