Security

How we protect emails submitted to the QPN Catalyst Network.

Who operates this

• Operator: Quantum Privacy LLC, a Delaware Series Limited Liability Company.
• Infrastructure: AWS (US regions only).
• Role: Quantum Privacy LLC receives, stores, and administers submissions; contributors retain the contractual right to keep their involvement confidential (see Submission Terms).

What this protects against

The system is designed to minimize exposure of sensitive content by default, restrict access through least-privilege controls, and ensure that operational tasks never require access to raw submission data.

How submissions are protected

Encryption at rest. Every email is encrypted at the moment it is stored — there is no unencrypted persistence in our storage layer. Encryption is performed with encryption keys managed under our AWS account (AWS KMS customer-managed keys), and two separate keys are used:

• One key encrypts the raw email content.
• A second key encrypts operational metadata (timestamps, verdicts, response mode), which contains no contributor identity.

This separation means operational tasks (e.g., daily intake counts, response mode distribution) never require access to email content.

Encryption in transit. All access to stored data is over HTTPS. Inbound email uses opportunistic TLS — encryption is used whenever the sending server supports it, per the SMTP standard.

Automatic key rotation is enabled on both keys.

Who can access stored data

Access to stored data is controlled through AWS IAM roles assigned to specific services and, in limited cases, to authorized human operators of Quantum Privacy LLC under the constraints described below.

• Least-privilege service access. AWS SES and specific Lambda functions hold narrowly scoped permissions limited to the single operation each needs — for example, encrypt-only for the intake write path, and decrypt-only for the evidence-mode reply function that must read the original email in order to attach it to the reply. No component has broad or unrestricted access.
• Reporting is metadata-only. Generating counts and activity reports uses only the metadata key; the email key is not required. Day-to-day operator activity does not require email-content decrypt.
• Human access is break-glass only. Decrypting email content requires assuming a dedicated break-glass role that has permission only to decrypt the email key and read stored email content — nothing else (no write, no delete, no key administration). Every assumption of the role fires an alert, and the action is recorded in the audit log. Routine operator credentials cannot decrypt email content.
• Email content is never used for analytics, reporting, or routine operations. Decrypt of email content is reserved for incident investigation.
• No public access. Stored email content is not publicly accessible under any circumstance — all public-access controls on the storage are locked off.
• No direct human browsing of email content. No system — website, dashboard, webmail, admin UI — exposes stored email content for browsing. Access occurs only through the audited break-glass workflow described above.

Audit and monitoring

• CloudTrail data events record every read, write, and delete on the email storage.
• GuardDuty S3 Protection flags anomalous access patterns — unusual geolocations, exfiltration-shaped behavior.
• CloudWatch alarms fire on operational failures and unauthorized KMS use; KMS key deletion is restricted to break-glass roles only.
• Spam and virus scanning runs on every inbound email; virus-flagged mail is deleted, spam-flagged mail is quarantined, no reply is sent in either case.
• Per-sender rate limiting prevents the intake addresses from being used to amplify replies against third parties.

What we don’t log

• Contributor email addresses do not appear in operational logs, metrics, or notifications.
• Subject lines and email bodies are never logged.
• The response mode a contributor selects (silent/ack/evidence) is not visible in the internal filenames used for storage — every intake address saves to the same location, so the mode choice is not revealed by the way the data is stored.

Data jurisdiction and retention

• Jurisdiction: US-based AWS infrastructure. Governing law is Delaware (see Submission Terms).
• Retention: Submissions are retained as confidential business records. Accidental deletes or overwrites are recoverable for 30 days via S3 versioning.
• Deletion. Submissions are not user-deletable — there is no self-service UI or API for contributors to remove stored emails. Administrative deletion by the operator is possible, is audit-logged via CloudTrail, and is subject to the 30-day versioned-recovery window described above. A formal deletion-on-request process is not yet published; contributors with a specific deletion request should contact the operator.
• How we treat submissions: Submissions are treated as confidential business information and handled in a manner consistent with trade secret protection under the Defend Trade Secrets Act (18 U.S.C. §1836) and the Delaware Trade Secrets Act (6 Del. C. §2001 et seq.). The legal designation of specific submissions as trade secrets is addressed in the Submission Terms — this page describes how we handle the data, not the legal status of any particular submission.

Security incident notification

If Quantum Privacy LLC confirms a security incident involving stored submissions, affected contributors will be notified at the email address from which their submissions were sent.

Contact

Security questions, deletion requests, or concerns about a specific submission can be sent to info@qpncatalyst.io.

Known limitations

• AWS SES processes inbound email in memory in plaintext for a brief window (seconds) before encrypted storage. This is inherent to managed email ingestion and is not a persistence layer we control.
• Intake email addresses are open to the public internet; spam/virus filtering and rate limiting are the defenses, not an allowlist.