Plomo encrypts protected deal content before persisting it to the database or object storage. Each deal has a separate 256-bit data-encryption key (DEK), wrapped by a key-encryption key (KEK) in Google Cloud KMS. Content encryption uses AES-256-GCM, which checks ciphertext integrity as well as confidentiality. Application authorization, database row-level security, and restricted service access remain necessary; encryption does not prevent a compromised privileged service from accessing data.
Key lifecycle
When a deal is created, Plomo generates its DEK and stores the KMS-wrapped form. Authorized backend workflows unwrap the key into memory for the request or task. The encryption context reuses that key within the workflow and clears its owned mutable key buffer when released.
The current field format binds ciphertext to the owning deal, its purpose, and the immutable resource identity. Existing deployments require a coordinated data cutover before enabling these strict readers. Document chunks also bind it to the immutable object path and chunk position, so moving ciphertext to a different deal or rearranging chunks fails authentication.
This is server-managed encryption: Plomo services decrypt data when needed to display it, process documents, retrieve evidence, or generate answers and presentations. Access checks establish whether a workflow may use the key.
Protected content
This table describes the current implementation. Existing data requires a coordinated cutover: adding encrypted taxonomy and vector storage does not itself remove historical plaintext values or backups. Deployment and stored-data verification establish which protections are active for an existing environment.
Encrypted document uploads
Plomo supports two upload paths with the same authenticated document format:
- Direct encrypted uploads: the browser receives a key scoped to one upload, encrypts the file in chunks, and transfers ciphertext to private storage. The upload key is wrapped by the deal key; the browser does not receive the deal key.
- API uploads: the API encrypts the document before writing it to storage.
Document object names use internal identifiers rather than the original filename. The filename is encrypted separately in PostgreSQL. The cloud document bucket also has server-side encryption configured with Cloud KMS, providing an additional storage layer.
Deal deletion and provider retention
Deleting a deal immediately removes its active PostgreSQL rows, including the wrapped deal key and derived search rows, and atomically records a durable cleanup obligation for object storage. A background cleanup process then enumerates and deletes every live and noncurrent object generation under that deal’s opaque storage prefix. The deleted deal is unavailable through ordinary application access as soon as the database transaction commits.
Storage cleanup is asynchronous and does not mean immediate physical media erasure:
- deleted Cloud Storage generations can remain recoverable during the configured provider soft-delete retention period;
- prior AlloyDB state can remain recoverable through backups and point-in-time recovery; and
- the cleanup obligation is removed after the prefix is confirmed empty, while terminal cleanup failures remain visible for operator intervention.
These recovery controls protect against accidental destruction. A privileged restore may recover prior encrypted objects or database state. Verify the deployed retention settings, legal holds, exports and any independently retained backups before stating a maximum recovery window; the source configuration alone does not prove live settings.
Fields outside per-deal encryption
Application encryption does not cover every database field. Operational values such as IDs, roles, statuses, timestamps, MIME types, and sizes remain queryable. Category labels copied into document metadata, coverage relationships, workspace paths and sharing metadata, hashed search signatures, search coordinates and counts, and some structured metadata remain outside per-deal encryption. User identity fields and captured feedback are also not uniformly encrypted.
Current search writers encrypt numeric vectors, and current taxonomy writers encrypt the complete taxonomy. Search scoring decrypts bounded vector blocks within authorized requests; reusable vector caches store ciphertext.
Those values can still reveal information about a deal. Database authorization, row-level security, infrastructure encryption, and access controls therefore remain necessary alongside content encryption. Authorized AI and document workflows process decrypted content, so provider routing, retention, personnel access, and subprocessors require their own controls.
Encryption in transit
The cloud deployment uses HTTPS for browser access and TLS between the edge and origin. Its edge configuration supports TLS 1.2 and newer, including TLS 1.3 and HTTP/3 where negotiated. The exact protocol depends on the client and network.
Customer-managed wrapping keys
The envelope encryption implementation supports selecting a Google Cloud KMS wrapping key for an organization. This can support a customer-managed key arrangement, subject to provisioning, IAM access, and an agreed key-management process. Contact [email protected] to discuss availability and setup.
Disabling a wrapping key or removing decrypt permission prevents new unwrap operations for the affected deal keys. A workflow that already unwrapped a key may continue until its in-memory context ends. Previously downloaded files and data outside per-deal encryption are not affected. Offboarding also requires stopping active processing and applying the agreed retention and access-revocation procedures.
Disabling a key can be reversed if access and the key are restored. Destroying the required key version can make encrypted data permanently unrecoverable. Key rotation and changes to an organization’s wrapping key require a coordinated migration of existing wrapped keys.
