Separate customer keys from agent conversations, choose who controls encryption keys and prepare evidence for procurement with a scoped Enterprise agreement.
Map each tenant (one separate customer workspace), its credential custody and its response path.
A tenant is one isolated customer workspace.
BYOK means bring your own encryption key.
Your integration handles alerts and key rotation.
Keys · access policy · audit context
Keys · access policy · audit context
Keys · access policy · audit context
Evidence, cost controls, key custody, integration, and incident response. Start with the linked details and verify the fit for your deployment.
Inspect the tamper-evident audit chain (a linked, tamper-evident record of events) and receipt-verification workflow. Verify available timestamp evidence and retention against your requirements. Receipts cover recorded operations.
Audit evidence ↗Register and arm a fingerprint. An observation at a monitored deny.sh decrypt endpoint can reach your configured incident channels. Monitored use only; offline decrypts and provider validation are outside that path.
Decoy alerts ↗Review plan limits, daily caps, and recorded usage before rollout. Confirm your workload and notification requirements against the current plan.
Usage dashboard ↗The BYOK integration wraps server-stored ciphertext (the encrypted data) under your AWS KMS key. Review permissions, availability, and revocation behaviour for your deployment. Revocation does not erase plaintext or keys already obtained outside that boundary.
BYOK walkthrough ↗Evaluate the framework guides, local SDKs, MCP, SAML, and signed-webhook options against your plan. Test one real tool boundary and your response workflow.
Integration guides ↗Use the trust centre, controls map, status page, and draft legal documents as the starting pack. Review the scope and date of each evidence item, then the current assurance status.
Trust centre ↗Review key custody, activity records and service integrations below. Confirm plan eligibility and the behaviour your deployment needs before committing.
01 · live
Add an encryption layer to stored records. Each data encryption key (DEK) is protected by your customer-managed key (CMK) in AWS Key Management Service (KMS). Revoking access blocks future unwrapping, not copies already obtained.
02 · live
Linked records make changes detectable. Signed receipts and trusted timestamps (RFC 3161) support your review of recorded activity.
03 · live
Per-tier daily metering, response headers, 80 / 95 / 100 percent email alerts. Quota events join the audit chain.
04 · live
Keep critical material in AWS Secrets Manager. Send signed event notifications (webhooks) to Datadog, PagerDuty or Slack. Use company sign-in (SAML SSO) with accounts created at first sign-in (JIT provisioning).
05 · live
Trust centre, public controls map against SOC 2 TSC and ISO 27001 Annex A, lightweight status page, honest roadmap blog post.
The SDK is open source (Apache 2.0), so you can run it all yourself. The managed service is for teams who would rather not build and maintain the pieces below themselves: key custody, audit evidence, alerting, and the day-to-day upkeep that comes with them.
With BYOK enabled, supported stored vault records receive an extra encryption layer protected by your AWS KMS key. A DB-only compromise of deny.sh yields no plaintext and no unwrapped ciphertext without your KMS access. We STS-AssumeRole into your account on every wrap and unwrap, so your CloudTrail logs every call we make under our IAM role and a deterministic STS session name (deny-sh-byok-<tenant>). Revocation blocks future unwrapping; it cannot erase data already obtained. Available under an Enterprise contract. Azure Key Vault, GCP KMS and direct hardware security module (HSM) support are planned; release dates are not announced. Setup: /byok-walkthrough. Reference: /docs/byok#byok.
For supported structured types, Honey Mode returns a deterministic, type-correct fake for an incorrect password/control combination. This is separate from generating the deliberate decoy (a believable fake secret or message) plaintext; neither layer guarantees that an attacker cannot distinguish a fake using external evidence. The decoy engine combines an LLM generator with a deterministic validator suite (Luhn, mod-97, BIP39 checksum, JWT structural, PEM tag, more), tuned against attack patterns as they emerge across the tenant base. Per-tier durable daily quotas (survive restarts), proactive 80/95/100% email alerts before the cap, and an in-app usage dashboard. Review generated samples against your own credential formats before deployment.
Attacks against the realism engine and validator-fail signatures get triaged centrally and shipped as validator/signature updates every tenant receives. Customers can use the shared updates in their own review process. Self-hosters get every signature once we ship it.
Per-tenant append-only audit log, hash-chained (each entry binds the previous, so any changed record breaks the chain), third-party timestamped via RFC 3161 timestamp authorities with nonce-verified responses. Signed PDF receipts and an open-source command-line verifier support offline review of recorded activity. They do not prove that all access was observed or guarantee regulatory acceptance. Enterprise customers can receive a scoped compliance evidence pack containing the agreed audit, receipt, custody and control-mapping material. Confirm its scope with your reviewer.
Pad every ciphertext to a fixed size band (padToBucket) so a dumped store reveals only a coarse size class, never the true length of each secret. This reduces length detail; the stored size band remains visible.
The public decrypt API does not expose the real-vs-decoy branch. Your integration must also avoid revealing internal branch metadata or other distinguishing signals. For web and core SDK encryption, both passwords work together and the control file (the file that selects which message opens) selects the plaintext.
An open-source CLI re-proves any audit-chain receipt with no call back to us: hash chain plus RFC 3161 timestamp, verified locally on the regulator's own machine. Hand them the proof, not a promise.
Cyber Essentials certified today. UK GDPR and DPA live, with a published DPA. SOC 2 trust services criteria and ISO 27001:2022 Annex A mapped and operating; the formal SOC 2 Type II examination and ISO 27001 certification are planned. Firm, scope and dates will be announced once engaged. HIPAA, PCI DSS, and FedRAMP are out of scope today. Full posture and procurement-pack contents on /compliance.
Shipped today: SAML SSO (Okta-compatible, JIT provisioning), AWS Secrets Manager as a customer-side custodian for critical encrypted material (we fetch via IAM AssumeRole, never store the value), and signed outbound webhooks for Datadog, PagerDuty, and Slack. OIDC, additional secrets-manager custodians (HashiCorp Vault, Azure Key Vault, GCP Secret Manager), additional log sinks (Splunk, CloudWatch, OpenTelemetry), and Microsoft Teams are on the roadmap. Each integration costs us once and benefits every customer. Self-hosters can use shipped integrations and maintain their own deployment.
Three steps from evaluation to production.
One call. We map where deniable storage fits your stack (key management, backup pipeline, cold storage) and send the architecture memo in writing.
Dedicated or embedded, with commercial licence. Deploy on your infrastructure or ours. Multi-language SDKs for native integration into your existing systems.
Priority engineering support, SLA, security updates. Direct access to the team that built it, not a help desk.
Open source, independently verifiable, built for integration.
AES-256-CTR encryption, Argon2id KDF (t=3, m=64 MiB, p=1, v=0x13), XOR composition layer, 4-byte length prefix inside encrypted zone. Every parameter is auditable.
TypeScript/Node.js (published on npm as deny-sh), Python, Go, Rust. See each SDK’s package for its current dependencies. Browser password-to-key derivation uses hash-wasm for portable Argon2id.
RESTful with OpenAPI 3.0 spec. Full documentation at /docs.
Browser-based cryptographic tests run in-browser. Chi-squared, Kolmogorov-Smirnov, entropy analysis, serial correlation. Run them yourself →
Open source on GitHub: the SDK is Apache 2.0 (free for proprietary embedding), the application layer is AGPL-3.0. Proprietary use that cannot meet AGPL obligations may need the commercial licence at /licensing. Full source review available under NDA.
Browser encryption keeps messages and passwords on your device. Hosted encryption receives those inputs and processes them in memory. Review the separate storage and metadata boundaries before choosing a service.
Honest status. Where we are today, and what's on the roadmap. The single-page reconciled view is at /compliance (procurement-friendly summary, claim-by-claim verifiability table, NDA-gated procurement pack).
Certified 15 May 2026, valid through 15 May 2027. Issued by the IASME Consortium (UK government-appointed accreditation body) and recorded on the BlockMark Registry. Covers boundary firewalls, secure configuration, user access control, malware protection, and security update management. Verify on BlockMark.
UK-registered data controller. Privacy policy covers all processing. Data deletion on request within 7 days. See privacy and DPA for the full position.
SOC 2 trust services criteria mapped and operating today (CC1-CC9, A1, C1, PI1). Independent SOC 2 Type II examination is planned. Firm, scope and dates will be announced once engaged. Full controls map at /compliance.
ISO 27001:2022 Annex A controls mapped against operational policies (A.5 organisational, A.6 people, A.7 physical, A.8 technological). Formal certification on the roadmap; dates not yet announced. Full mapping at /compliance.
No payment card data processed directly. Stripe handles all billing under their own PCI DSS Level 1 certification.
Encryption software. Customers are responsible for compliance with local export laws. UK OGEL covers most commercial use.
Cryptographic implementation review by an independent third-party security firm is on the roadmap. Firm and scope will be announced once engaged. Reach out to hello@deny.sh for current status. Today's verification: Browser-based tests covering statistical indistinguishability, ciphertext invariance, and correctness, runnable in-browser at /verify.
Draft documents available for procurement and security review. Each is being prepared for execution and is not yet legally binding. Contact hello@deny.sh for executable counterparts.
UK GDPR Article 28 DPA covering instructions, security, sub-processors, breach notification, deletion, and audit rights. Annex 2 lists current sub-processors with locations and transfer mechanisms. View draft DPA.
Availability, support windows, incident handling and any service credits are agreed for the deployment in the signed contract. View the draft service-terms framework.
Liability terms for executed Enterprise contracts. 1x ACV standard cap, 2x ACV elevated cap for breach of confidentiality, security, IP indemnity, and wilful misconduct. Worked examples and order of precedence included. View draft MSA Addendum.
One commercial agreement can cover self-hosting the application layer in your product, a private deny.sh deployment, or both. The quote states the exact scope, capacity and operating terms.
Looking at per-seat licensing for a wallet or hardware product instead? See partnerships.
Describe your use case, deployment boundary and procurement needs. Include any deadline in the message.
Looking for individual or team pricing? See standard plans.
deny.sh is built and operated by Treehouse in Valhalla Ltd, a private limited company registered in England and Wales (Companies House no. 15770209). UK registered office, named director, Cyber Essentials certified.
Public construction, verification tools and a controls map support your review. An independent cryptographic audit is planned and is not complete. Self-attested mappings are not independent certification.
Receipts cover recorded operations, not every possible access. Tripwires observe supported deny.sh decrypt endpoints, not offline decrypts or provider validation. Alert delivery and rotation have no guaranteed timing.
Usage visibility is not a promise that every possible cost is capped. Integration effort depends on your architecture; no fixed setup time is promised.
BYOK revocation blocks future unwrapping. It does not erase plaintext, keys or copies already obtained outside that boundary.