Your AI Vendor Can Read Everything. Ours Cannot.

Every AI vendor’s security page says roughly the same thing: encryption in transit and at rest, SOC 2, access controls, “we take your privacy seriously.” Read carefully and you will notice what none of them say: our staff cannot read your data. They cannot say it, because it is not true. Somewhere in every conventional SaaS vendor is a set of people, engineers, support staff, subprocessors, who can open your content. The protection between them and your data is policy: rules about who should not look. Policy is better than nothing. But policy is a promise, and promises have exceptions, bad days, subpoenas, and breaches.

The distinction that matters is between two words that get used interchangeably: may not and cannot. “Our staff may not access customer content” is a rule. “Our staff cannot access customer content” is an architecture. Rules bend under incentive; architectures do not care about incentives. Almost the entire industry sells the first sentence formatted to look like the second.

For most tools the gap is a tolerable trade. For the system that holds your company’s entire working memory, every client matter, every deal, every internal decision, we think it is the wrong trade, especially if you are a law firm, a finance team, or anyone whose clients trust you with their secrets. So when we built managed hosting for the Context Engine, we set the harder constraint: the operator must be architecturally unable to read customer content. Not forbidden. Unable.

Here is what that means concretely, mechanism by mechanism. None of this is a marketing abstraction; each piece ships in our control plane, and each is checkable.

You operate, you don’t read

Every engine we manage runs single-tenant, on the customer’s own infrastructure: their cloud account, their bill, their box. Our operations account on that machine is not an administrator. It is a deliberately limited user with a closed allowlist of maintenance commands: health checks, diagnostics, service restarts, upgrade routines. Each allowed command is content-free by construction; the list is enforced by the operating system, not by our good intentions; and opening a shell into a customer’s engine is not on it.

The design principle is worth naming because it generalizes: least privilege as the steady state, not as the aspiration. There is exactly one moment when broader access exists, the initial provisioning, when the system is installed and its keys are minted. That moment is inherently trusted (it creates the secrets), it happens once, and everything after it runs on the narrow account. The steady-state result: we can keep your engine healthy, patched, and monitored without any routine ability to open what is inside it.

Break-glass: the exception is designed, not improvised

Sometimes deep support genuinely requires looking inside: a corrupted state, a gnarly bug. Most vendors handle this moment informally: an engineer gets access, does the work, everyone trusts it went fine. The informality is the vulnerability, because unrecorded exceptions become habits.

We formalized it as break-glass: content-level access exists only as a customer-authorized grant, time-boxed, with the entire session recorded, input and output, and access auto-revoked when the clock runs out. The session logs ship off the box, where the operator cannot quietly edit them.

The point is not that emergencies never happen. It is that the exception has a shape: you approve it, it is bounded, it leaves a tamper-evident trail, and it cannot become the quiet norm, because the norm has no code path.

Backups we cannot open

Backups are where sovereignty claims usually die quietly. A backup must contain everything, and it usually sits, readable, in the vendor’s storage, which means every promise about live access controls is voided nightly by the backup job.

Ours are sealed differently. When your engine is provisioned, it generates a keypair. You hold the private recovery key; the engine keeps only the public key and seals every backup to it. From then on, backups run unattended, no secret required to create one, and we schedule them, store the artifacts, monitor freshness, and verify integrity through a small unencrypted manifest (creation time, version, content checksums). What we cannot do, cryptographically cannot, is open one. Restoring requires your recovery key, pasted in at restore time and never persisted.

Why this exact key model, for readers who think in these terms: a shared passphrase would break unattended backups; a key derived from the application’s own secrets would be hollow, because the operator of the control plane already holds those. Sealing to a customer-held public key is the one arrangement that is simultaneously encrypted, automated, and operator-blind.

The honest fine print, because a sovereignty essay should have some: if you lose the recovery key and chose no escrow, your backups are unrecoverable by anyone, including us. That is not a flaw; it is what “the operator cannot read it” costs. For customers who want a safety net, an explicit escrow option exists, clearly labeled with exactly what it trades away, and it is off by default. Sovereignty includes the right to choose the safety net, and the right to know its price.

The memory itself cannot phone home

Underneath the hosting, the engine has a property worth stating on its own: no autonomous outbound reach. By design it does not send email, post to chat, or push data to arbitrary endpoints on its own; there are no generic webhooks to point anywhere. It is a library, not an actor. Agents your team authorizes read from it, and the narrow messaging paths that exist deliver only human-confirmed content to destinations you configured, with delivery receipts kept.

Security people will recognize what this buys: the exfiltration path most systems must monitor simply does not exist here. There is no code path for the memory layer to leak itself, which also means there is no such path for an attacker, or an operator, to quietly borrow. The ownership piece in our foundations track states this as a buying criterion for any memory product; here it is as a shipped property.

And the data at rest is not a proprietary blob. Your engine’s memory is plain, organized, versioned files you can clone and read by hand, every change tracked. Auditable by you, without us in the room, which converts “trust us” into “check for yourself” for the entire record of what the system knows.

The exit is part of the architecture

The final test of “your data is yours” is what happens when you leave. Our answer is a documented detach, and because the engine already runs on your server, it is genuinely a permissions change, not a migration:

1. A final backup is taken and the engine’s health verified.
2. You accept, in writing, what detaching means: a perpetual license to the version you have, no further updates or SLA.
3. Our operator account, access keys, and monitoring are removed from your machine.
4. Every secret needed to run independently, including the master encryption key, is handed to you once, over a secure one-time channel.
5. A durable record documents what was handed over and when.

You keep the engine, its configuration, and everything it has learned, running where it always ran. If you later want managed operations again, that is a re-attach, not a rebuild. An exit that is cheap, documented, and reversible is the strongest evidence a vendor can offer that the rest of their sovereignty story is real: lock-in and “cannot read your data” almost never coexist honestly.

Policy versus architecture, side by side

Question	Conventional SaaS	This architecture
Can staff read customer content?	Yes, restricted by policy	No; allowlist has no content path
Support access in emergencies	Informal, internally logged	Customer-authorized, time-boxed, recorded
Backups	Readable by the vendor	Sealed to a customer-held key
Can the memory send data out?	Usually, by design	No autonomous egress exists
Data format	Proprietary store	Plain versioned files, readable by you
Leaving	Export, maybe	Documented detach; you keep the system

Why we built it this way

Partly conviction, which the foundations track lays out: the layer holding a company’s memory is exactly the wrong place for vendor trust to be load-bearing. And partly incentive, which is worth being candid about: “we cannot read your data” is a stronger sales argument than “we promise not to,” precisely because it survives the vendor having a bad day. We would rather compete on an architecture we can prove than on adjectives. There is also a selfish operational benefit we did not fully anticipate: an operator who cannot touch content is an operator who cannot be subpoenaed, socially engineered, or tempted into touching it, and that subtraction simplifies everything from our hiring to our incident response.

If your clients’ confidentiality is the thing your business actually sells, ask your current AI vendors the question from our checklist: can your staff read our content, and is the answer enforced by policy or by architecture? Ask for the mechanism, not the certification. If the answer is unsatisfying, the alternative exists, and installing it is a well-worn path.