Agni Blog

When we started Agni, we asked a simple question: what happens if someone gains root access to our servers? For most cloud services, the answer is catastrophic. Emails, files, and metadata are all plaintext or trivially decryptable.

We chose a different path. In Agni's architecture, the server never possesses decryption keys. When you create an AgniMail account, your PGP private key is generated in your browser, encrypted with your password, and the ciphertext is stored on our servers. We cannot decrypt it. We cannot read your emails. We cannot hand over plaintext to anyone — because we don't have it.

Technical implications

This design choice makes some features harder. We can't do server-side search. We can't recover forgotten passwords (we can only reset them, which creates a new key). We can't scan for spam using server-side ML models.

But these trade-offs are worth it. The threat model we optimize for is not a script kiddie guessing passwords — it's a nation-state with a court order. In that scenario, we can truthfully say: we have nothing to give you.

Every tech company now claims "end-to-end encryption." But dig deeper and you'll find three distinct architectures, only one of which deserves the name:

1. Server-side encryption (fake E2EE)

The server encrypts your data before storing it. The server also holds the keys. This protects against disk theft but not against the service provider, hackers, or governments. Most "encrypted email" services fall into this category.

2. Client-side encryption with key escrow (weak E2EE)

Your device encrypts data, but the service holds a backup of your keys. This is convenient for password recovery, but it means the provider can decrypt everything. Many modern chat apps use this model silently.

3. True zero-knowledge (real E2EE)

Keys are generated on your device and never leave. The provider stores only ciphertext. Password recovery is impossible — if you lose your password, you lose your data. This is the only model where the provider genuinely cannot access your information.

Agni uses model 3. It's less convenient. It's more secure. We think that's the right trade-off.

When we launched AgniVault and AgniVPN, each product had its own auth system. This created a frustrating experience: three passwords, three login screens, three sets of session cookies.

We rebuilt the auth layer to use a single JWT session stored in `localStorage`. Now when you log in on agni.sh, that same session works on agnimail.me, priv.agni.sh, and files.agni.sh. No redirects. No re-authentication.

How it works

The session token is signed with a shared secret across all services. Each product verifies the JWT independently and extracts your plan tier, account ID, and role. This means AgniVault knows you're a Pro user without calling a central auth server.

Security note: the JWT is signed (HS256) with a 256-bit key rotated per deployment. It expires after 30 days. You can revoke all sessions from the dashboard.

Modern messaging apps love bespoke protocols: Signal's Double Ratchet, WhatsApp's Noise Pipe, Matrix's Olm. These are elegant, but they're also opaque. You can't inspect them. You can't verify them independently. You're trusting the app to implement them correctly.

OpenPGP is the opposite. It's a documented standard (RFC 4880) with multiple independent implementations. You can export your AgniMail keys and use them in Thunderbird, GpgSuite, or any OpenPGP-compatible client. If Agni disappears tomorrow, your keys still work.

We use Sequoia-OpenPGP on the backend (Rust, audited) and OpenPGP.js in the browser (JavaScript, widely reviewed). Both implement the same standard, ensuring interoperability.

Is OpenPGP perfect? No. It's complex, the user experience is mediocre, and key management is a pain. But for email — the most interoperable communication protocol ever built — it's the only game in town. We chose compatibility over convenience.