I spent about twenty years building software. On almost every system I worked on, someone at the company could read the data if they really wanted to.
Fine for most things. Not for a will or a client's tax file.
That's why I started Privatt.
Jay Leno says a widow tried to sell him a Ferrari for $350,000, so he helped her turn it into $3,750,000 instead.
“I get enough free stuff like that, that’s right, that’s very nice. You don’t need to start screwing people over.”
“I said, ‘If I can get you close to 4 million for that car, will you bake me some cookies?’ And she said, ‘Why? It’s not worth that much.’ I go, ‘It’s worth that much.’”
“I don’t like it when I hear people tell me a story how they screwed some old guy out of a car. I hate those kind of stories. I like these kind of stories.”
Bring your own agent moves the trust boundary, it doesn't remove it.
The vendor still decides what the tool hands over, and once that lands in your agent's context you own the retention question for a copy you didn't choose to create.
So the setting that matters isn't retention, it's scope. Retention limits how long a copy lives. Scope decides whether it exists.
Worth separating two things that usually get bundled: contractual controls and architectural ones.
Zero retention and a BAA are promises about what a vendor will do with data it can read. Client side encryption changes what it can read at all. The first is enforceable after the fact, the second is enforceable in advance.
For client files I'd want to know which one a tool is actually relying on.
I build client side encrypted storage, so this is my daily argument:
The helpful/creepy line usually isn't about how much data a feature uses. It's about where the work happens.
Personalization computed on the device, from data that never leaves it, reads as helpful. The same feature computed server side against a stored profile reads as surveillance, because now a copy exists that outlives the session.
Users feel that difference well before they can name it.
I build client side encrypted storage, so this is my daily argument:
Agree on verifying the whole flow, and that's where the hard part hides.
Encrypted end to end is straightforward right up until the model has to compute on the data. At that moment something sees plaintext, unless you are inside attested hardware or paying the homomorphic tax.
So the question worth asking any sovereign stack is narrow: at the point of inference, who could read the prompt if they wanted to, and what proves they can't?
The detail I'd chase first: does the MCP hand the model a copy of the return data, or a scoped query it answers server side? Those look identical in a demo and behave very differently in an incident.
Three questions that separate them: what plaintext is retained after the session ends, who at the vendor can read it, and whether you can revoke access to data already sent.
Most tools answer the first two and go quiet on the third.
Where your files physically sit is not a technicality. It decides whose laws can reach them.
A file stored by a company in another country can be handed to that country's government without you ever being told.
Encryption matters. So does the passport your data holds.
Love this. "Quality software knows its limits." I'd add one: it knows the limits of what it should be able to do with your data. The best tools make betrayal impossible, not just unlikely. That's restraint you can't see, which is the whole point.
The encryption here is the easy part, and they did it right (AES-SIV, local model, nothing hits the cloud).
The parts that actually decide if this is safe are the endpoints and the metadata. The plaintext still lives on both devices, and the network still sees that you two talk, when, and how often.
Steganography hides the content, not the relationship. Clever build, just point it at the right threat.
A VPN changes who can see your traffic. It does not remove the need to trust someone. You are moving trust from your network to the VPN provider.
Worth it for what it actually does: hiding traffic from the local network and your ISP.
It does nothing for the files and messages you store or send. Those have to be encrypted before they leave your device.
A test for any privacy product:
Ask them which mode, if any, lets them read your data.
A straight, specific answer means they've thought hard about the trade-offs. A vague "everything's encrypted" means they're hoping you won't ask.
"Private" cloud storage usually means private from other users, not from the company hosting it.
They can still read what you store. Fine for most things, not the ones you'd never want read.
The fix isn't trust. It's encrypting your files before they leave your device.
This is the part people underestimate. If a provider can scan your messages, assume it can read everything else you store there too.
Your files, your documents, your backups. Same servers, same access.
The only real fix is encrypting on your device first, so what they hold is ciphertext they can't read even if they're compelled to.
Your real threat model probably isn't a genius attacker.
It's the third-party tool your vendor plugged in, the admin with standing access, and the plaintext copy someone made for convenience.
Most data doesn't get stolen. It gets picked up off the floor.
Privacy shouldn't be a premium tier.
Encryption that only the paranoid or the wealthy get isn't privacy. It's a privilege. Either it's the default, or you don't get to call your product "private."
That belief is the whole reason Privatt exists.
The tax-data theft in the news this week didn't happen because someone cracked strong encryption.
It happened because sensitive client files were sitting in plaintext inside a help-desk tool, attached to support tickets.
Attackers don't break crypto. They find the copy nobody encrypted.