Academy Essay
Your AI Vendor Can Read Everything. Ours Has to Ask.
Every hosted AI vendor can reach your data. What matters is what is separated by design, what is policy, and whether you can see it. Here is ours.
Every AI vendor’s security page says roughly the same thing: encryption, certifications, access controls, “we take your privacy seriously.” Read carefully and you will notice what none of them say plainly: the people who run this service can reach your data. It is true of almost every hosted product, because somebody has to run the machines, fix the bugs and answer the support tickets. The protection between those people and your content is mostly policy: rules about who should not look, and when.
Policy is better than nothing, but a rule you cannot see is only a promise, and promises are broken by exceptions, bad days, subpoenas and breaches. The useful questions are narrower than “is my data safe”: which boundaries are built into the system, which are rules, and which of the rules can you watch being kept?
Context Engine is a hosted service: one memory that ChatGPT, Claude, Claude Code and Cursor read from and save to, and that your team uses in the app. For a hosted service, “we cannot read your data” would not be true, so we will not say it. What follows is what we can say, sorted into architecture (what is built into the system) and policy (rules we follow).
Architecture: your engine is not a row in someone else’s table
In Context Engine your memory lives in engines: one for you, one per client or project, one for a team. Every engine gets its own database, its own search index and its own Worker on Cloudflare. Isolation between engines is physical, not a filter on a shared table.
That matters because in software that serves many customers from shared systems, data most often leaks through a bug rather than a malicious employee: a query that forgot its filter, a cache keyed slightly wrong, a search that returned the neighbour’s results. When the database another customer’s memories live in is not attached to the process answering your request, a bug of that kind has nothing to return. And across engines, even a memory’s title and its engine’s name are shown only to someone who can reach that engine.
This protects you from other customers and from mistakes in shared code. It does not, by itself, protect you from us. We run the platform those databases live on, so that part needs a rule, and you can see the rule being kept.
Policy you can watch: support has to ask
Context Engine support opens an engine only when an owner or admin approves a request, for the time the request names, and every visit is logged. The request shows on Home with a Review request button, which opens the engine’s security settings. There it says who is asking, why, what they could do and for how long, with Approve and Decline. Under it is the visit log.
There is one exception, and we would rather you read it here than find it later. When we have a legal or safety duty to open an engine, it opens at once, the owner is told at once, and the visit is logged like any other. Every vendor has that exception, because a court order or a credible threat to someone’s safety does not wait for approval. Most leave it unwritten. We put it in writing because you can hold us to an exception that is written down, announced and logged.
This is policy, enforced in software we operate, and we will not present it as more than that. It is specific and visible: you know who asked, you made the decision, and the log says what happened. A rule that leaves a record you can read is one you can check for yourself.
What happens to the content itself
Your content is sent to models only to answer you. It is never used to train a model, it is not sold, and it is not used for advertising.
One boundary is outside our control, and you should know about it. When ChatGPT or Claude reads a memory from your engine, that memory is now part of a conversation in their product, under their terms. Context Engine controls what each connection may reach. A connection reaches only the engines you tick, each at Can read or Can read and save. A viewer’s connections only read. An owner or admin sees every connection reaching their engine, with its access and last use, and can cut it off. What the AI tool’s own vendor does with a conversation is a question for that vendor. Ask them the same questions you are asking us.
Leaving is a download
The final test of “your data is yours” is what happens when you go. Export gives you one ZIP of Markdown and JSON that opens without us. Every memory is a Markdown file with YAML frontmatter, so a text editor works, grep works, and any notes app that reads the format opens it. An illustrative memory, as exported:
---
type: decision
title: Retainer moves to quarterly billing
rationale: Monthly invoices were costing the client's finance
team a week of approvals each cycle.
decided_at: 2026-09-12
---
Agreed on the 12 September call. Starts with the Q4 invoice.
An export can be restored into an empty engine, which is also how you would move an engine to another region. Deleting an engine is scheduled a day ahead, so you can take that export; then it is gone, with its database, search index and stored files.
Where it lives, stated exactly
If you choose the EU when you create an engine, its database and stored files are kept in the EU. That is the whole claim. We do not claim EU residency for the search index or for the models that answer you, and you should be wary of any vendor whose residency claim is broader than the parts it can name.
An engine can require two-step sign-in. If the memory has to sit on a server your organisation owns, Enterprise runs Context Engine there, for you alone, installed and run by Relote.
Architecture versus policy, side by side
| Question | Typical hosted AI tool | Context Engine |
|---|---|---|
| Is your data separated from other customers’? | Usually by a filter on shared tables | Own database, search index and Worker per engine |
| Can the vendor’s staff open your content? | Yes, restricted by internal policy | Only on an owner’s or admin’s approval, for a stated time, logged |
| Exceptions | Usually unstated | Legal or safety duty: opens at once, owner told at once, logged |
| Training on your content | Varies, often opt-out | Never |
| Leaving | Export, sometimes | One ZIP of Markdown and JSON that opens without us |
| Data location | Often unspecified | EU option for database and stored files, and only those |
Why we sorted it this way
Using a hosted service means trusting the vendor and checking its controls. Anyone who tells you that their staff reaching your data is mathematically impossible is overselling. What a vendor can honestly offer is three things: the boundaries that really are architecture, built as architecture; the rules that remain, made specific, visible and logged; and an exit cheap enough that you are never staying because leaving is hard.
We would rather compete on that sorting than on the word “secure.” If your clients’ confidentiality is what your business actually sells, ask every AI vendor you use the questions from our ownership checklist: who can open our content, under what approval, and where would we see that they did? Ask how each answer is enforced; a certification alone does not tell you.
Our answers are above. The plans are on pricing, and you can start free and check them for yourself.