KB Sandbox
Sign In

Data Sovereignty Is Not a Setting. It Is a Set of Guarantees You Can Prove.

9/6/2026

A single question with your name on it, asked at every step

One AI interaction can send your data on a trip around the world before you see a response: stored in one country, processed in another, run through a model built somewhere else entirely, and maybe triggering an action in a fourth. That is not a hypothetical -- it is the default shape of most agentic systems today. At every one of those steps, there is exactly one question worth asking: who is in control?

Ask most AI vendors about data sovereignty directly and you get a reassuring sentence instead: your data stays yours, it is encrypted, it is not used to train anyone else's model. That sentence is usually true and almost never sufficient, because sovereignty is not a promise about intent. It is a set of guarantees an organisation can verify, at any moment, without asking permission to look.

Industry framing on this -- IBM has written about it clearly -- breaks the idea into four related but distinct forms of control: operational (who runs the environment and holds the keys), data (who can reach the data, and who can prove it), technology (can you leave without rebuilding everything), and AI (which models are allowed to touch which content, and who governs them). Treating "sovereignty" as one checkbox collapses four separate engineering problems into a single, unverifiable adjective.

The part that actually gets tested: data sovereignty

Of the four, data sovereignty is where the gap between claim and system is easiest to expose, because it has a concrete, falsifiable question behind it: if I restrict something today, does every path to it -- including the vendor's own admin tooling -- actually respect that restriction, or only the paths a user is likely to try?

Most access-control systems answer that question well for ordinary users and poorly for privileged ones. An administrator, a support engineer, or "the platform itself" quietly retains a bypass -- for debugging, for support tickets, for the next feature that needed a shortcut. Each bypass is individually reasonable. Collectively, they mean the sovereignty guarantee has an asterisk nobody wrote down.

A stricter version is possible, and it is a genuinely different design decision, not a bigger checkbox: build the restriction into the same enforcement layer that already gates every other read of that data, and give it no bypass at all, for any role, including the person who created the restriction in the first place. Restrict something and forget to grant yourself access, and you lose access too. That is inconvenient exactly once, and it is the inconvenience that makes the guarantee real instead of aspirational.

What this looks like inside KB Sandbox

This is not a design aspiration for us -- it is how Project Evidence Access Controls actually works today, and we built it to fail the audit on purpose:

  • A restriction is a real, auditable record. A project owner classifies a source directly -- Internal Confidential, Commercial Confidential, Security Restricted, Customer Confidential -- and that classification, along with who set it, when, and why, lives in its own table with a full append-only history. Nothing about it is a flag flipped quietly in application code.
  • The audience is named explicitly, not implied by platform role. A restriction grants access to specific people or specific named groups you define per project -- "these four people can see this" -- never "curators can see this."
  • The gate lives at the database's own row-level policies, not the UI. A restricted source doesn't just lose its link in the interface; a direct query for it, from any code path in the application -- including Ember's own retrieval tool -- returns nothing for someone without a grant. We verified this the hard way this month: signed in as a project member with no grant, queried the underlying retrieval table directly, got back an empty result, no error, no hint anything was ever there. Signed in as a member who was granted access, and the same query returned the real content, correctly, live in a project conversation.
  • There is no owner bypass, on purpose. Restrict a source and forget to grant yourself, and you lose access too, same as everyone else. We confirmed this with the team explicitly before shipping it: the alternative -- quietly exempting the person who set the restriction -- is exactly the kind of asterisk that makes a sovereignty claim unverifiable.
  • Derived content inherits nothing automatically -- and we chose not to try to fix that by inheritance. A Wiki article synthesized by AI from a restricted source does not become restricted by association; it is a fully independent piece of content, and that's true no matter how good the eventual auto-classification logic might get. Rather than build a "most restrictive classification" inheritance system -- a harder problem than it looks, because classification isn't a ranked severity scale, and a correct label after the fact doesn't undo an LLM having already blended restricted and unrestricted material into one paragraph -- sensitive sources simply never become AI-synthesis input at all. They stay retrievable in their original, access-controlled form, live, in a conversation, for whoever actually has a grant.
  • The people without access can still ask. A locked-out project member sees that a restricted source exists -- not its content, just that it's there -- and can request access with one click. The request routes to whoever manages the restriction, who can approve or reject it right from the notification, and the requester gets told the outcome either way. No dead end, no need to know who to email.

AI sovereignty is the same problem, one layer up

Once an AI system can read organisational data at all, "which humans can see this" and "which AI models are allowed to process this" turn out to be genuinely separate questions, not the same setting asked twice. An organisation might be entirely comfortable with a document being read by its own staff and simultaneously want zero external inference providers anywhere near it -- a compliance boundary, not a visibility boundary. KB Sandbox keeps these as two independent settings on the same resource for exactly this reason: a source can be open to the whole project team and simultaneously restricted to internal-only AI providers, or the reverse. Conflating the two collapses a distinction our customers actually need to draw.

Sovereignty is not the thing slowing you down

It's easy to treat sovereignty as friction -- more rules, more restrictions, more steps between an idea and a working system. That gets the causality backwards. Convenience never guaranteed security, trust, or accountability; it just deferred the cost of not having them to the moment someone actually tries to exploit the gap, which is the worst possible time to discover it. The point of building this in at the enforcement layer, rather than bolting it on as policy, is that it stops being a tax on shipping -- the same guarantee that satisfies an auditor is the one that lets a team move faster, because they already know the answer to "who is in control" before anyone has to ask.

That's the bet KB Sandbox is making: sovereignty as architecture, not as a paragraph in a security questionnaire.

This article provides general information and does not constitute security, legal, or compliance advice.