Security and privacy
How POMA protects your documents.

We aim to speak plain English about security for our customers, partners, and security reviewers. We are specific where we want to share openly what distinguishes us, but stay deliberately abstract where naming the exact algorithm would help no one but an attacker. Please contact us if you still have open questions after reading this page!

In one paragraph

When you ingest a document into POMA, three different layers of cryptographic protection are applied before anything touches our vector database or our content storage. The text of your documents is encrypted with AES-256-GCM, the same authenticated-encryption standard used by Signal and by every modern cloud provider for data at rest. The numerical embeddings used for search are transformed with a per-tenant mathematical key so that the vector database stores them in a form that isn't directly readable. The keywords used for text-matching search are one-way keyed hashes, so the vector database sees only opaque tokens — never the plaintext terms. Every layer's key is derived from your tenant secret, which is generated once, stored encrypted, and never reused across tenants or shared with any third-party service.

What each layer actually does

Document content is encrypted. When you ingest a PDF, web page, or any other document, the extracted text is AES-256-GCM-encrypted before it's written to our storage bucket. The key is HKDF-derived from your tenant secret. If someone got read access to our storage bucket — through a misconfiguration, a hostile insider, a stolen backup — they would see opaque ciphertext. There is no recovery path without your key. This is encryption in the strict cryptographic sense.

Search vectors are protected by an asymmetric transform. Modern search works on numerical embeddings — vectors of a few thousand floating-point numbers per chunk. We apply a mathematical transformation to every embedding before it's stored, and a related-but-different transformation to your queries before they're sent to the vector database. The vector database can still find the right matches, because the two transformations are designed to preserve relevance scoring — but the transformation used to store documents is structurally different from the one used to ask questions. An adversary who compromised just one half of the system wouldn't automatically be able to read or simulate the other half. This is a meaningful step beyond a single-key obfuscation, and it's been the direction of the field for several years (see "asymmetric scalar-product preserving encryption" in the academic literature — we don't ship the exact primitive from any specific paper, but the family is well-studied).

BM25 search tokens are HMAC-keyed. Lexical search ("does this chunk contain the word 'Toyota'?") works on a vocabulary index. We hash every token through HMAC-SHA-256 with a key derived from your tenant secret, so the vector database stores rows like a4f1b6e8c3d2 9e8d4c2a7f81 b3c5d8e2a4f6 … instead of Toyota revenue operating income. The same query word produces the same hash, so the index works; but the operator of the vector database — or anyone with read access to the index — cannot recover the original vocabulary without your tenant secret.

Identifiers (document IDs, namespaces, tags) are HMAC-keyed too. What you give us as doc_id = "patient-12345" becomes a 128-bit keyed hash before it touches any external service. Customer metadata tags are hashed the same way. Range-queryable integer metadata stays as plaintext integers, because range queries are mathematically incompatible with hashing — we tell you this explicitly in the API documentation.

Padding hides vector dimensionality. Each protected vector carries extra "padding" dimensions filled with per-document deterministic noise, mixed into the same transformation as the real content. An adversary inspecting the stored vectors can't tell from the wire format which of the dimensions carry real meaning and which are noise.

Key management

  • One tenant secret per project. A 256-bit random secret is generated once at project creation, encrypted with a master key held in our cluster, and stored in a database your project metadata points to. It's never reused across tenants, never logged, never returned by any API.
  • Keys are rotatable. If you ask us to rotate your tenant secret — for compliance reasons, after a personnel change, or just on a schedule — we can do so without data loss. During the rotation window the system reads from both the old and new keys; once every document has been re-protected under the new key, the old one is retired.
  • Per-collection key isolation. If your project has multiple distinct document collections that should be cryptographically independent of each other, we can derive independent subkeys per collection from one tenant secret. Useful when, for example, you don't want the same key protecting your customer support data and your legal documents.

What we don't claim

We're a service that holds your secret in memory in order to do search on your behalf. That means we're not a "zero-knowledge" service in the strict sense — at search time we operate on your data with your key in hand. We don't promise the operational properties of fully homomorphic encryption or trusted-hardware enclaves; those would either be orders of magnitude slower than search latency tolerates, or would shift the trust to a different party (the hardware vendor) rather than eliminate it.

But what you can expect:

  • The text of your documents at rest in our storage is encrypted with a current best-practice algorithm.
  • The wire format used by our vector database does not contain your data in any plaintext form.
  • Doc-side and query-side cryptographic keys are different; a compromise of one half of the wire format does not automatically expose the other.
  • Your tenant secret is per-tenant, never reused, and rotatable on request.
  • Our protections survive a snapshot leak of the vector database without giving up your content or search vocabulary.

If you have a specific threat model in mind — regulated industries, nation-state adversaries, multi-tenant isolation requirements — talk to us; we can describe in detail what each protection does and doesn't defend against, and we have engineering paths to harden specific layers further (for instance, splitting the doc-write and query services so neither holds both halves of the key) when a customer's threat model warrants it.

Operational properties

  • All cryptographic primitives are standard, peer-reviewed, open implementations (Python cryptography library, NumPy linear algebra with float64 precision, HMAC-SHA-256 from the standard library).
  • No customer-supplied PII is logged.
  • Audit trail: every ingest job and search request carries a job ID; per-tenant access logs are retained for the contracted period.
  • Region pinning: we run primarily on Google Cloud Europe (Frankfurt / europe-west3). Region pinning, no-training guarantees against third-party LLM providers, and DPA execution are documented in our standard customer agreement.

For technical reviewers wanting the precise threat model — what each layer defends against and where the residual risks sit — talk to us directly. We'd rather walk a security team through it under NDA than publish a blueprint.