What we see, and when
Choose where your sensitive data is processed. Browser encryption and local code keep messages and passwords on your device; hosted encryption sends them to our server. The table helps answer: do we ever hold the plaintext or the password?
Last updated: 28 May 2026
The short version
Start with the local-versus-hosted distinction. A software development kit (SDK) is a code library; the command-line interface (CLI) runs in your terminal; Model Context Protocol (MCP) connects agents to tools. Local surfaces (browser, CLI, SDK, the three local MCP tools) run the construction on your machine. The server never sees your plaintext, your passwords, or the decoded control file. Hosted surfaces (api.deny.sh endpoints) accept plaintext and passwords in the request body so we can perform the construction for you. We process them in memory, return the result, and do not persist them. Do not assume another service has the same data boundary as these endpoints. Review each integration separately, including AWS KMS Encrypt, other storage services and your own application. Hosted encryption is not zero-knowledge: the server receives the readable message.
If your threat model rules out a server seeing plaintext in flight, use the local path. The encrypted file format (ciphertext) is compatible across both. Changing paths still requires reviewing authentication, inputs and error handling.
Full table
Read the table alongside the relevant tool guide. The Telegram bot processes messages and passwords on the bot server and through Telegram chat. Optional live decoy suggestions send a type label, not your secret.
| Surface | Tier | What the server receives | What we persist | Zero‑knowledge? |
|---|---|---|---|---|
| Local-only construction (server sees nothing) | ||||
| Browser tools /encrypt (local encryption; cloud vault is listed separately) | Free | No message or passwords for local encryption. Optional live suggestions send a type label. | Nothing. | Yes |
| SDKs (TS / Python / Go / Rust) | Free, Apache 2.0 | Nothing. Construction runs in your process. | Nothing. | Yes |
CLI (deny-sh encrypt, deny-sh decrypt, deny-sh deny, deny-sh vault) | Free | Nothing. Local binary. | Nothing. | Yes |
MCP server: 3 local tools (deny_local_encrypt, deny_local_decrypt, deny_local_create_decoy) | Free | Nothing. Runs in your agent process. | Nothing. | Yes |
| Self-hosted server (AGPL-3.0) | Free, you operate it | Whatever your tenants send to your own deployment. We are not in the trust boundary. | Whatever your deployment persists. | Not from your own server |
| Hosted convenience API (server sees plaintext in RAM, does not persist) | ||||
POST /api/encrypt | Free and paid API plans | Plaintext + two passwords in the request body. | No message or password persistence. Request and audit metadata may be recorded. | No |
POST /api/decrypt | Free and paid API plans | Ciphertext + control file + two passwords. | No message or password persistence. Request and audit metadata may be recorded. | No |
POST /api/deny | Free and paid API plans | Plaintext + two passwords (the decoy is generated, then the construction runs). | No message or password persistence. Request and audit metadata may be recorded. | No |
POST /api/text/encrypt, /api/text/decrypt | Same as above | Same as /encrypt, /decrypt (hex I/O). | No message or password persistence. Request and audit metadata may be recorded. | No |
POST /api/generate-control | Free and paid API plans | Two passwords. We derive the control file and return it. | No message or password persistence. Request and audit metadata may be recorded. | No |
MCP server : 7 hosted tools (anything ending _api) | Same as above per tool | Same as the hosted endpoint each one calls. | No message or password persistence. Request and audit metadata may be recorded. | No |
| Ciphertext-at-rest storage (secret content arrives encrypted) | ||||
POST /api/vault/store, /list, /export | Free (25 items) and all paid tiers | Encrypted content, item metadata and account authentication. The browser vault does not send its encryption password. | Encrypted content, labels and other item metadata, associated with your account. | Yes (storage only) |
POST /api/managed-vault/… | Team, Enterprise | Already-encrypted blob. | The ciphertext. | Yes (storage only) |
Audit log (POST /api/audit, /api/consumer/audit/*) | Team, Enterprise | Operation type + SHA-256 hash of the canonical payload (op_payload_hash). | Payload hash and event metadata; not the secret content. | Yes (hash receipts only) |
| Account and key management (no plaintext crypto data) | ||||
Signup, login, set-password (/api/register, /api/consumer/signup, /login, /set-password) | Free and paid accounts | Email + the account password (over TLS). | Email, Argon2id hash of the password. Never the password itself. | : |
API key management (/api/consumer/keys/*) | Free and paid accounts | Key creation requests. Keys are generated server-side, shown once. | SHA-256 fingerprint of the key. Never the key plaintext after issue. | : |
Billing, subscriptions, portal (/api/billing/*, /api/webhook/stripe) | Free and paid accounts | Stripe events, customer IDs, subscription state. | Customer ID, tier, invoice IDs. Card numbers go to Stripe, not to us: Stripe handles PCI scope. | : |
| BYOK: customer-managed encryption-at-rest (we cannot read your ciphertext without your KMS) | ||||
| BYOK AWS KMS wrap of managed vault ciphertext | Enterprise | Already-encrypted blob (same as above). | Ciphertext envelope-encrypted under your AWS KMS CMK via STS-AssumeRole. Revoke key access to block future unwrapping; previously obtained copies are unaffected. | Yes + KMS gate |
Choose the right processing boundary
Local execution keeps plaintext on your machine. Browser tools, SDKs, CLI, three local MCP tools, self-hosted. Everything you need to use the construction without us in the trust boundary is free, open source, and runs on your machine.
Hosted convenience API is server-in-flight. If you use POST /api/encrypt, the server sees your plaintext and passwords during the call and returns the result. We do not store them. This is a deliberate tier for callers who want a hosted endpoint to do the work. It is not zero-knowledge and we do not describe it as such.
Vault data is ciphertext-at-rest. Your data is encrypted in your browser before upload. We store the encrypted bytes. Labels and other metadata remain visible to us. Content protection depends on your password strength and the security of the client.
BYOK adds customer-controlled key access. Under an Enterprise contract, the stored ciphertext is wrapped again under your AWS KMS CMK via STS-AssumeRole into your account. Even our database breach yields bytes that need your KMS to unwrap. Revocation blocks future unwrapping, not data or keys already obtained.
Self-host puts us outside the trust boundary entirely. AGPL-3.0. Your server, your tenants, your rules.
Which surface should I use?
The framing we recommend, in priority order:
- If you can run the construction locally, do. Browser tools, CLI, SDK in default offline mode, MCP local tools. We are not in the trust boundary at all.
- If you need a hosted endpoint for orchestration reasons (server-to-server calls, agent runtime, cross-platform glue), use the hosted API. Server sees plaintext in flight, does not persist. Review this processing boundary against your own requirements.
- If you store ciphertext with us (Vault), the encryption happens in your browser. We receive encrypted content and associated item metadata.
- If you operate a large deployment and need customer control over the extra encryption layer, layer BYOK AWS KMS on top of (3). Your KMS gates every unwrap.
- If you cannot accept us in the trust boundary at all, self-host the AGPL-3.0 build. We are not in the path.
What this page commits us to
This table describes the intended processing boundaries. Review the implementation and relevant tool guide for your deployment. Email hello@deny.sh if you find one.
The audit posture is what it is: Cyber Essentials Certified (IASME, May 2026), independent cryptographic audit on the roadmap, not complete. We will update this page when audit findings land.