Security

Effective 2026-05-28 · DUEX (duex.app) · Toronto, Canada

DUEX is in an early private-pilot phase. This page describes, in plain language, how we handle data, access, and incidents for pilot conversations.

How we handle your data

• Your pilot data is used to run the review, produce a decision record, and — during early pilot — to debug and improve the review engine. Pilot inputs and the resulting memos are saved to DUEX's database for that purpose during the pilot, and deleted within 30 days after the pilot ends or on your written request — whichever comes first — unless we need to keep them for security, legal, or billing reasons. Copies may remain in encrypted backups until they expire under normal cycles.
• Your pilot data is not used to train shared models that serve other companies. DUEX calls each provider's business API endpoint (the frontier-model providers listed on our Subprocessors page), whose contractual defaults do not train on submitted inputs — this is materially different from those providers' consumer chat products.
• How long each outside provider keeps your data, and how it watches for misuse, depends on the provider and the setup we agree for your pilot. The current list of providers, with links to their data terms, is at duex.app/subprocessors.
• We keep your pilot data only as long as we need it for the agreed pilot scope. The Privacy page has the full retention table.

Who can access your data

• Access to your data is limited to authorized DUEX personnel with a need to operate, secure, or support the pilot — currently the founder. We do not use shared administrative accounts for production systems.
• Multi-factor authentication is required on all founder accounts that can reach production systems (Railway, Cloudflare, Google Workspace, the model-provider consoles).
• The Slack permissions we ask for are limited to what the review actually needs (Slack delivery is on the roadmap; nothing is granted today).
• Security credentials (passwords, API keys) are stored in managed secret/configuration systems outside our product code. We rotate or revoke credentials on suspected compromise, provider change, or end of need.

Transport and storage

• Public site traffic uses an encrypted web connection (HTTPS, TLS 1.2 or later), with HTTP Strict Transport Security (HSTS) telling browsers to keep using HTTPS.
• Traffic between DUEX and our review providers uses encrypted web connections (HTTPS/TLS). When the Slack delivery surface ships, DUEX will use Slack's standard signed-request and approval process.
• Web hosting and DNS for the public site are managed by Cloudflare. Application hosting and the database where pilot data is stored are managed by Railway, in a single US region; the region is confirmed before each pilot.
• Pilot data stored in DUEX's database (hosted on Railway) is encrypted at rest using AES-256, the default for Railway's managed Postgres.

Service hardening

• The public site sits behind Cloudflare, which provides DDoS protection, a web application firewall (WAF), and edge filtering.
• Every public API endpoint enforces a per-IP request rate limit and per-IP plus global daily spend caps, so a stuck script or a hostile burst cannot exhaust the demo budget or starve real pilot traffic.
• Submitted deal context is capped at 32 KB and rejected at the network edge before parsing, so an oversize payload cannot be used as a denial-of-service lever.
• DUEX's API only accepts cross-origin requests from duex.app and www.duex.app. Origins outside that list are rejected at the preflight step — no wildcard.
• The public site ships a Content Security Policy (CSP), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a strict Referrer-Policy, and a tight Permissions-Policy (geolocation, microphone, camera, payment all off).

Review integrity

Customer input is wrapped in a marked-out fence before it is sent to any review model, and an explicit security preamble instructs the model to treat anything between the markers as data, never as instructions. This is applied to every reviewer prompt, the synthesizer, and the audit verifier. We cannot guarantee that every adversarial input will be caught, but the fencing and security preamble materially reduce the prompt-injection risk.

Every review is checked by an independent cross-provider audit model that re-reads the deal input, the four reviewer perspectives, and the final memo, and flags math errors, fabricated facts (numbers or policies not in your input), internal contradictions, or hedging. Reviews that fail the audit on a material issue are refined once before they ship; the audit result is shown on the response. This is a product feature, but it is also a privacy/security control — the second model is from a different provider, so a single provider's outage or model defect cannot silently degrade output quality.

Vulnerability management and patching

DUEX uses dependency scanning on our application code, enforces pre-deployment review of all changes, and applies security updates on a risk-prioritized basis. Critical vulnerabilities that affect pilot data are reviewed promptly and remediated or mitigated as soon as reasonably practicable.

Logs and backups

DUEX uses operational logs (request timings, errors, model selections, cost per review) for security, debugging, and reliability. We avoid logging full customer deal content in our runtime logs. Logs are typically retained up to 90 days unless needed for an investigation. Pilot data is deleted from active systems within 30 days after the pilot ends or on your written request — whichever comes first; copies may remain in encrypted backups until they expire under normal cycles, unless earlier deletion is technically feasible.

DUEX maintains daily encrypted backups of the production database, and a documented disaster-recovery plan designed to restore core service functionality promptly in the event of an infrastructure failure.

Incidents

• If DUEX becomes aware of a security incident that materially affects customer pilot data, we will notify the named pilot contact without undue delay and, where feasible, within 72 hours after becoming aware of the incident. The notice will include known facts, the categories of data and people affected, mitigation steps taken or proposed, and a contact for follow-up. We will provide reasonable updates as the investigation continues.
• We log operational events so we can review what happened after an incident, and we keep an internal runbook for incident response.

Reporting a security issue

If you think you have found a security issue in DUEX, email [email protected] with the affected web pages, how to make the issue happen again, and what the impact is. Please do not include third-party personal data or customer deal data in your first report.

Safe harbor. If you act in good faith — testing only your own account or test data, not exfiltrating customer data, not running destructive tests, and giving us a reasonable chance to respond — we will not pursue legal action against you for the report. We aim to acknowledge security reports within two business days.

Changes

This page evolves with the product. The effective date above reflects the most recent revision.