Assume-Breach: the Cybersecurity Backend Playbook

01 — The principle, in one sentence

Design every system under the assumption that the backend server is already compromised, and then make sure that assumption doesn't matter.

Most backends are built the opposite way: a hardened perimeter around a treasure chest. Firewalls, intrusion detection, rate limits — and inside, the keys, the plaintext data, the admin console that can command every client. One breach and the attacker inherits the kingdom. Assume-breach inverts this: the server is treated as hostile infrastructure from day one, and the system is engineered so that total server compromise still yields nothing an attacker can use.

02 — The three mechanics

1. Keys live only on paired devices — never on the server. The cryptographic keys needed to read data exist on the user's devices and nowhere else. The server never sees them, never stores them, never backs them up. A breached server can hand over its entire database and it reads as noise, because the keys to unlock it aren't there to steal.
2. Everything is end-to-end encrypted. Data is encrypted on the sender's device and decrypted only on the recipient's device. The backend sees ciphertext in transit — it can route it, store it, count it, but it cannot read it. "Trust us, we don't look" is replaced by "we mathematically cannot look."
3. The backend is a dumb relay — it can't read, and it can't command. The server forwards encrypted messages between already-paired devices. It has no channel through which to issue commands to clients, no admin console that can reach into your machine, no "push update" path an attacker could hijack. Relay-only means even a fully owned server can't turn around and pwn the fleet.

03 — Why this matters most for AI agent tools

An app that lets you orchestrate coding agents from your phone is an unusually high-value target. Think about what a conventional backend for such a tool holds: authenticated sessions to machines that run code, the ability to dispatch tasks to those machines, logs of everything those agents did. If that backend falls, the attacker doesn't just get data — they get a command channel to every connected computer. One breach becomes a fleet-wide compromise.

Under assume-breach design, that channel doesn't exist. The relay can only pass encrypted messages between devices that already trust each other. There is no server-side "run this on all clients" button for an attacker to press — because there was never supposed to be one for the vendor either.

04 — The contrast: breach day

05 — Three questions for any vendor

Before you trust a vendor with your agents, your code, or your data, ask these. The answers are more revealing than any security whitepaper:

1. Do you hold my encryption keys anywhere on your infrastructure? "No — keys exist only on your paired devices" is the right answer. "We encrypt at rest" is not the same thing; it usually means the server holds both the lock and the key.
2. Can your backend read my data even if you wanted to — and how would I verify that? You're looking for a structural answer (end-to-end encryption, open client code, independent audits), not a policy answer ("we would never do that").
3. If an attacker fully owned your servers tomorrow, exactly what would they get? The assume-breach answer: "encrypted blobs we cannot decrypt, and no way to command your devices." If the answer is vague, long, or deflected — assume the worst.

06 — The 60-second check: would your backend survive a breach?

Answer honestly about the service you rely on most. Here, "Yes" is the safe answer.

This self-assessment is informational — it tests your architecture's breach posture, not your vendor's marketing. It is not security advice.

07 — Cybersecurity FAQ