Trust & Security

Every deposit is encrypted before it is stored, with its own 256-bit data key. The key is generated by AWS Key Management Service (KMS) and wrapped by a regional key that never leaves KMS; the wrapped key only unwraps for the same organisation, agreement and deposit.

• Deposit files are encrypted as a stream in our CEE1 format: AES-256-GCM in authenticated chunks, so any reordering, truncation or tampering is detected.
• Stored objects are also encrypted at rest by the storage service (SSE-KMS) and are written once under a compliance-mode retention lock: nobody, including CodeEscrows, can delete or shorten the retention of a sealed deposit.
• Traffic to the application is encrypted in transit with TLS.
• Standard custody: CodeEscrows (escrow agent) can decrypt a deposit only through the worker identities that run verification and an approved release. Staff cannot read deposit contents in the console.
• Sealed custody (2-of-3): the data key exists only as three shares — depositor, beneficiary and CodeEscrows. Any two are needed, so CodeEscrows alone cannot decrypt. Using the agent share needs approval by two different escrow officers. Sealed custody is not offered on this service yet.

Each organisation chooses a data region when it is created. Regions offered: not available right now

• Deposit files, their replicas and the keys that encrypt them stay in the chosen region. Deposits sealed in one region are never moved to the other.
• The region can be changed in organisation settings until the first deposit.
• Account, agreement and audit records are kept in one shared primary database for all regions. Its location: Primary database region: to be confirmed by the owner

Every sealed deposit gets a Deposit Certificate with a signed receipt that anyone can verify, without an account and without trusting our systems.

• The receipt is an in-toto statement in a DSSE envelope, signed with an ECDSA P-256 key held in AWS KMS. The public key is published at /.well-known/codeescrows.json.
• The statement binds the deposit's Merkle root over every file's SHA-256 hash, the manifest hash, the byte count and the custody mode.
• Each receipt is timestamped by independent RFC 3161 timestamp authorities (DigiCert and Sectigo), proving when the deposit existed.
• Check any certificate at /verify or with the codeescrows verify command, or offline as described below.
• Security-relevant actions are written to an append-only, hash-chained audit log per organisation.

Release follows the agreement. CodeEscrows (escrow agent) applies deterministic rules; automated assistance never decides a release.

1. The beneficiary files a release request citing a release condition, with evidence, after an identity check of the requesting Authorised Person.
2. A notice goes to every depositor Authorised Person by e-mail and in the application. Legal notices cannot be muted.
3. The objection window opens, counted on the governing-law calendar stated in the agreement (for example 10 business days). The depositor may file a contrary instruction; the request then becomes a dispute and follows the agreement's resolution procedure.
4. Without an objection, release needs approval by two different escrow officers, each re-authenticating. Ending a window early also needs two officers and is refused once a contrary instruction exists.
5. The release package is re-encrypted to a key only the beneficiary holds, and a signed Release Certificate records what was delivered.

• Level 1 — inventory and integrity check: every deposit. Archive safety, file manifest with hashes, malware and secret scanning, before sealing.
• Level 3 — independent build by an engineer: ordered per agreement, optionally witnessed, with a signed report.

Level 2 automated build checks are not offered on this service yet.

"Verified" is used only for a completed deterministic check. Text written by the AI assistant is labelled as assistant analysis and is advisory only.

• SOC 2 Type I: in preparation. Compliance status: to be confirmed by the owner Controls are mapped to SOC 2 and evidence is collected in the product.
• SOC 2 Type II and ISO/IEC 27001: planned after Type I. Not certified.
• GDPR: a data processing agreement (Art. 28) is available at /legal/dpa. Data-subject requests (export, deletion, correction) are handled within 30 days.
• Sanctions: organisations and Authorised Persons are screened against the OFAC, EU and UK consolidated lists at onboarding and nightly. Service is not offered in embargoed jurisdictions.
• Hosting and storage providers hold their own attestations (for example SOC 2 Type II and ISO 27001 reports); these cover the providers, not CodeEscrows.

Legal documents marked DRAFT are under counsel review and are not yet in force.

The third parties that may process personal data, what they do and where, are listed in the sub-processor list. Deposit contents are stored only in the CodeEscrows vault on AWS in the organisation's region.

• Professional indemnity (errors and omissions) cover: Insurer and limit: to be confirmed by the owner
• Cyber liability cover: Insurer and limit: to be confirmed by the owner
• Liability cap under the escrow agreement: Cap: to be confirmed by the owner The binding terms are those of your signed agreement.

Report a vulnerability to [email protected] Security mailbox: to be confirmed by the owner. Machine-readable details are in /.well-known/security.txt (RFC 9116).

• Do not access other customers' data or deposit contents while testing.
• Do not run denial-of-service tests or social engineering against staff.
• Response times and safe-harbour terms for good-faith research: To be confirmed by the owner

Please do not use the feedback board or public channels for security reports.

You need the receipt and the published public key. Neither step trusts a CodeEscrows server once you have downloaded them.

1. Download the receipt: https://staging.codeescrows.com/verify/<receipt-id>/receipt.json (parties can also download the full certificate JSON, which includes the RFC 3161 tokens).
2. Download the public key: https://staging.codeescrows.com/.well-known/codeescrows.json and pick the key whose kid matches the envelope's keyid.
3. Base64-decode the envelope payload and compute the DSSE pre-authentication encoding: "DSSEv1" SP len(type) SP type SP len(payload) SP payload with type application/vnd.in-toto+json.
4. Verify the base64 DER signature over that encoding with ECDSA P-256 and SHA-256 using the key's PEM (for example openssl dgst -sha256 -verify key.pem -signature sig.der pae.bin).
5. Check that the statement's subject[0].digest.sha256 equals the Merkle root printed on the certificate, and that the deposit and agreement ids match.
6. For each RFC 3161 token, run openssl ts -verify against the SHA-256 of the canonical DSSE envelope and the timestamp authority's certificate chain.

The /verify page performs the signature and Merkle-root checks for you and shows each result. It reports the timestamp authorities' times and status; full validation of the timestamp certificate chains is done with the openssl step above.