Security model

Sensitive work happens in your cloud.

DeleteRail is designed around data minimization. The public service and build intake do not need consumer identifiers, DROP request lists, record samples, API credentials, or production access.

Information DeleteRail accepts

Business contact and payment information, high-level architecture, database or resource names, field names, selected DROP list types, deployment target, and processor system names. Field names must not contain personal values.

Information DeleteRail does not accept

• Raw or hashed consumer identifiers
• DROP request CSV or ZIP files
• Production database exports or record samples
• DROP, cloud, database, or processor credentials
• Legal conclusions about exemptions

Execution boundary

The generated repository is installed in the customer's environment. Secrets are supplied there through its secret manager. Deterministic code performs standardization, SHA-256 hashing, matching, status-file production, and evidence logging. Language models may draft schema mappings, tests, and runbook text from schema metadata; they do not receive records or choose dispositions.

Production controls

Deletion, opt-out, exemption, and downstream instructions remain review-gated. The customer names authorized owners, validates connectors, approves production execution, controls credentials, and retains the evidence store.

Build integrity

Each package includes exact dependency locks, source code, automated tests, environment templates without secrets, a dry-run mode, and a change manifest. Customers can inspect or modify every component and may operate it without an ongoing DeleteRail account.

Report a security concern

Email security@deleterail.com. Do not include consumer data, credentials, or exploitable secrets in an initial report.