← Back to blog

Why we built deny.sh, the deniability infrastructure

Launch day · 4 July 2026 · 5 min read

Most encryption assumes a clean game. You hold the key, the attacker doesn't, the bytes stay safe. But bytes leak. Backups get stolen. Cloud providers get breached. Devices walk off. AI agents get prompt-injected into surrendering whatever sits in their context. Once the bytes are out, standard encryption gives the attacker exactly one answer: try the key. If they have it, the file opens. If they don't, they keep trying.

deny.sh adds a different shape. The same ciphertext decrypts to completely different content depending on which key you use. One key gives the real plaintext. Another gives a plausible decoy. Both decryptions are valid. The bytes themselves don't tell an attacker which is which.

That primitive is the wedge. The actual product is bigger than the primitive, and we call it deniability infrastructure: a cryptographic library (the Encrypt pillar, Apache 2.0, free), a hosted operational runtime with per-tenant isolation and audit posture (the Operate pillar, paid), and a verifiable published trust posture (the Verify pillar, free, public). The category argument lives in its own post (why deniability needs infrastructure, not just a library); this post is the launch.

The pivot matters because the audiences that actually need this aren't single users encrypting one file. They are AI agent platforms holding ten thousand customers' OAuth tokens. Custody products with exchange creds in a hot wallet. Healthcare PHI stores where breach safe-harbours apply. Security teams whose breach playbook has to keep working after the playbook itself has been read by the attacker. For them, the algorithm is the smallest part of the problem.

How it works

1. You pick two passwords. A primary password and a control password. The primary protects the real content. The control generates a small key (the control file) that tells the ciphertext which plaintext to reveal.

2. You write a decoy. A low-balance wallet. Stale notes. Whatever you want an attacker to recover when they reach the file. deny.sh produces a second control file that opens the exact same ciphertext to the decoy.

3. The bytes leak. Backup stolen, agent prompt-injected, drive seized. The ciphertext is identical either way. The decoy control file is the one sitting in the obvious place. The real one stays separated. No hidden partition. No metadata difference. No statistical tell.

The maths is the maths. It just stops working in the attacker's favour.

Open primitives, no obscurity

Built on scrypt key derivation, AES-256-CTR, and XOR composition for the deniability layer. All standard. All open. The construction page walks through the full algorithm with named primitives at every step. Every claim is verifiable in your browser at deny.sh/verify: 22 tests covering chi-squared analysis, entropy measurement, and fuzz testing. Don't trust us. Run them.

The codebase is split. The SDKs and the MCP server wrapper ship under Apache License 2.0 from version 1.1.0 onward, so you can embed deny.sh as a primitive in any product, proprietary or open, without copyleft surface. The application layer (hosted vault, dead-man's-switch dispatcher, inheritance app, website source) stays AGPL-3.0. Commercial licensing for the application layer remains available; the SDK does not need it. The licensing page (/licensing) walks through the split.

How to verify any of this

A deniability product gets held to a higher bar, and it should. Four trust anchors are live alongside the launch, each one independently checkable:

The verification walkthrough has concrete commands for each layer. An independent third-party cryptographic audit is in scoping for Q3 2026, results published in full when complete (the good and the bad). Until then we are explicit: the construction is novel and unaudited, the primitives are not. If that trade-off is too expensive for your threat model, wait for the audit.

What you can do with it today

Open deny.sh/encrypt in any browser. Type a message. Pick two passwords. Get a ciphertext and a control file. Generate a second control file with a decoy of your choice. Hand over either one. Watch them both decrypt to different things.

That's the whole product. Everything else is the same primitive in a different shape:

Agents-first from day one

Cloudflare scanned the 200,000 most-visited sites on the web. Fewer than fifteen had an Agent Skills index. deny.sh is one of them, on day one.

The next wave of users for tools like this won't all be humans. AI agents need to discover what a service does, what its tools are, how to authenticate, and what content rules apply. We shipped the full stack:

None of this changes the encryption. It just means the next time an agent needs deniable crypto for storing secrets the agent itself shouldn't be able to surrender, it can find us, read the tools, verify the skills, and call them. That feels like the right way to launch in 2026.

What deniable encryption isn't

It isn't a defence against an adaptive attacker who already knows the tool exists in your life. If someone is watching you, holds your subscription records, or otherwise knows you store things with deny.sh, they don't stop after the first decoy. They keep asking for more passwords. The maths holds up. The behaviour around it does not. If your threat model is observed targeted pressure, this product isn't what you need.

It also isn't a substitute for not having the file. If you're carrying something genuinely high-risk, the right move is still: don't carry it. deny.sh is for the case where bytes need to exist somewhere and you want them to fail closed when they leak.

Plausible deniability also requires plausibility. The decoy has to make sense in context. A wallet with $0 in it doesn't. A wallet with $150 and three transactions in 2024 does. The product gives you the cryptographic guarantee. The believability is on you.

And the construction is novel. We've published the maths in the whitepaper and the prose-and-proof-sketch version on the /security page. The primitives (AES-256-CTR, scrypt) are well-studied. The composition that produces multiple plausible plaintexts from one ciphertext is what is novel, and what an external audit will check.

Lifetime Pro, launch week only

For launch week we're offering a one-time Lifetime Pro at $499. 100,000 API calls per month. Forever. Capped at 200 keys. It's the lowest API price we'll ever publish, and once those 200 are gone they're gone. Free tier (500 calls/month, browser, no account) stays free always.

The point

Standard encryption protects bytes from people who don't have the key. Deniable encryption protects you from the bytes themselves. When a backup leaks, when a device walks off, when an agent gets prompted out of a secret, the file decrypts to your decoy. The real content never appears in the breach.

Have a play. Tell us what breaks.

One ciphertext. Multiple plausible plaintexts.

No account. No tracking. Everything in your browser.

Encrypt now
// read next
Why deniable encryption matters more than you think
The third dimension above standard crypto
Your AI agent handles secrets. Does it handle them well?
MCP, prompt injection, and what to do about it
Hacker News · @usedeny on X · GitHub