Security and privacy

How POMA protects your documents.

Your documents are yours

POMA is built in Germany — a country that, within living memory, learned twice over what it costs when personal information is turned against the people it describes. Here, privacy isn't a compliance checkbox; it's a reflex. That conviction, more than any regulation, is why this page exists.

In practice: we don't sell your data, we don't train on it, and we keep the number of hands that touch it as small as we can. Our infrastructure runs in the EU (Frankfurt and the Netherlands), and your data is processed in the EU — or, for the few providers based outside it, under a safeguard the EU itself recognizes: Canada's adequacy decision, or EU standard contractual clauses with no-training and contractually limited retention. We serve customers worldwide, and because we hold ourselves to the strictest bar by default, you get that bar wherever you happen to be.

In one paragraph

When you ingest a document into POMA, three different layers of cryptographic protection are applied before anything is written to our vector database or content storage, so your document text, search vectors, and keyword tokens are all protected at rest. 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.

Where your data is processed — and who touches it

We'd rather show you the list than ask you to trust a slogan. Every provider below is bound by a data-processing agreement with a no-training commitment and contractually limited retention or zero retention. For each, we name the one location that matters — its home country, or where it actually runs.

🇪🇺 8 processed in the EU · 🇨🇦 1 EU-adequate

Every provider above processes your data in the EU, or — if based outside it — under a safeguard the EU itself recognizes (Canada's adequacy decision, or EU standard contractual clauses with no-training). One standard, the strict one, applied to every customer no matter where you are.

When your text is processed in the clear

Most of your data only ever exists in our systems as protected vectors, hashed terms, or encrypted text. A few AI steps — understanding document structure, reading images, and (only on the advanced retrieval tier) reranking results — do process text in the clear, because that's what the model has to read. We'd rather say so plainly than imply otherwise. Three things keep it contained:

• Every such provider is contractually bound — data-processing agreement, no-training, limited or zero retention.
• We keep that list as short as possible — and we keep cutting it; we recently removed a provider outright.
• The standard retrieval tier sends no document text to any external ranking provider at all — plaintext reranking happens only when you explicitly choose the advanced tier.

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 labels are hashed the same way — opaque to the vector database, matchable only by exact equality. Two kinds of metadata are deliberately kept in plaintext so they stay queryable: range-queryable integers (range comparisons are mathematically incompatible with hashing) and opt-in "unencrypted" string fields for wildcard filtering. Those plaintext fields are visible to the vector database, so they are clearly named and meant for non-sensitive values — anything sensitive belongs in a hashed label. We tell you exactly which is which 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).
• We do not intentionally log customer document content or PII.
• 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 on Google Cloud in the EU — compute in the Netherlands (europe-west4), the search index and storage in 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.