> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plomo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# How Plomo Encrypts Deal Data at Rest and in Transit

> How Plomo uses per-deal envelope encryption to keep your deal data cryptographically isolated, with in-transit security and enterprise BYOK.

Encryption in Plomo is designed around a simple principle: data from one deal should be cryptographically inaccessible to anyone working on a different deal, even if something goes wrong at the application layer. Plomo achieves this through per-deal envelope encryption — every deal gets its own data-encryption key, and that key is managed by a cloud key management service rather than stored alongside the data it protects.

## Per-Deal Encryption Keys

When you create a deal in Plomo, the platform generates a unique **data-encryption key (DEK)** for that deal. This key is used to encrypt and decrypt deal content throughout its lifecycle. The DEK itself is wrapped (encrypted) by a **key-encryption key (KEK)** managed in a cloud-hosted key management service.

This envelope encryption pattern means:

* The raw DEK is never stored persistently — only the KMS-wrapped form is persisted
* The DEK is unwrapped only briefly, inside the backend, for authorized workflows
* Compromising the application database does not expose plaintext deal content without also compromising the KMS key

## What Is Encrypted Per Deal

The following content fields are encrypted at rest using the deal's data-encryption key:

| Category           | Encrypted fields                             |
| ------------------ | -------------------------------------------- |
| **Documents**      | Original uploaded document bytes             |
| **Metadata**       | Deal names and document filenames            |
| **Copilot**        | Chat messages and session content            |
| **Classification** | Classifier reasoning and evidence spans      |
| **CIM**            | CIM content fields and slide data            |
| **Other**          | Rich customer-content fields across the deal |

### Encrypted Document Storage

Uploaded documents benefit from two independent encryption layers:

1. **Plomo application encryption** — the document blob is encrypted with the deal's DEK before being written to storage
2. **Cloud storage encryption** — the underlying cloud storage bucket applies its own server-side encryption on top

This means a document at rest is encrypted twice: once by Plomo (deal-scoped) and once by the storage provider (infrastructure-level).

## What Is NOT Encrypted

Some operational fields are stored in plaintext because the product needs them to function correctly — queries, indexes, and status checks depend on these values being readable without decrypting the full deal:

* Opaque internal IDs
* Status fields (e.g., processing, complete, error)
* Timestamps
* MIME type and file size
* Category labels assigned to documents

These fields contain no customer content — they are structural metadata used to route and display information in the UI.

## In Transit

All traffic between your browser and Plomo is encrypted in transit:

* **Edge layer**: HTTP/3 (QUIC + TLS 1.3) via the Cloudflare edge network — the connection from your browser to Cloudflare uses the latest transport security
* **Origin layer**: HTTP/2 with TLS from Cloudflare to Plomo's backend — traffic never travels over the public internet in plaintext

## Enterprise: Bring Your Own Key (BYOK)

Enterprise customers can supply a **customer-managed key** as the wrapping key (KEK) in the envelope encryption scheme. Under BYOK, Plomo's managed key service is configured to use your key rather than a Plomo-managed key to wrap the deal DEKs.

This gives your organization a cryptographic off switch: if you revoke or disable your wrapping key, the deal DEKs cannot be unwrapped, and all encrypted deal data becomes unreadable — even to Plomo's infrastructure. This is useful for contractual off-boarding, regulatory holds, or situations where you need a guaranteed termination mechanism.

To enable BYOK for your organization, contact **[admin@plomo.ai](mailto:admin@plomo.ai)**.

<Warning>
  Key revocation under BYOK is destructive. If you revoke or disable your customer-managed wrapping key, all deal data encrypted under that key becomes permanently unreadable. This action cannot be undone unless the key is restored. Test key rotation in a non-production context before applying it to live deals.
</Warning>