Skip to content

Security and your data

This page describes the hosted service at api.limma.ai. Limma can also run inside your own network, where nothing leaves it: install Limma inside your network.

Where your data is

In Amazon Web Services (AWS), in one region: US East (N. Virginia). The API and the worker that reads documents run in private subnets with no public address; the only door from the internet is a load balancer behind AWS's web application firewall. The database (Amazon RDS for PostgreSQL), the queue (Amazon ElastiCache for Redis) and the model server each accept connections only from Limma's own API and worker.

what where kept
What Limma read from your documents — page text, facts, records, search vectors the database until you delete it
A document's original file a private S3 bucket seven days, then deleted by the bucket's own rule — or at once when you delete the document
A document waiting to be read the queue until it is read, then an hour; a job that failed, 24 hours
The record of each call (below) the database, and an archive in S3 see deletion

Which models read your data

  • The reader — Qwen3-30B-A3B-Instruct-2507, an open-weights model (Apache-2.0), which Limma runs itself with vLLM on its own GPU server inside its private network. It has no public address, only Limma's API and worker can reach it, with a key, and it logs no request.
  • Search vectors — Amazon Titan Text Embeddings V2, through Amazon Bedrock in the same AWS region. The text of each passage, and each question, is sent to it to be turned into a vector.
  • Scanned pages are read by OCR (Tesseract) inside Limma's own containers.

No model of Anthropic, OpenAI or any other provider outside AWS is sent your content. The production service refuses to start unless its reading model sits at a private address inside its own network, and its AWS permissions let it call one model on Bedrock: the Titan embedding model. Your agent's own model is yours to choose; Limma sees only the calls your agent makes.

Organizations are kept apart

Every key belongs to one organization. Every call — each MCP tool, each REST route, each upload — is checked against the key's organization before anything is read or written, and a key can be narrowed further to some workspaces or some documents. All customers share one database: organizations are kept apart by these checks at every door, not by separate databases. Limma's test suite walks every route of the API as another organization's admin, and as a key scoped to a different workspace, and checks that no route lets either read or change the workspace.

Encryption

  • In transit: between your agent and Limma, HTTPS only, TLS 1.2 or 1.3; a plain HTTP request is redirected to HTTPS. Inside Limma's private network, the database requires TLS and the queue uses TLS. The load balancer's hop to the API and the API's calls to the model server stay inside the private network and are not encrypted.
  • At rest, with keys AWS manages: the database and its backups, the queue and its snapshots, every S3 bucket, and the model server's disk.

Keys

  • A key is stored only as a SHA-256 hash: the welcome page shows it to you once, and Limma cannot show it again.
  • A key sent in a URL (?api_key=) is refused, so it never reaches an access log.
  • Limma's logs and audit trail name a key only by its id (key_…, made from the hash).

Logs

Request logs record each request's method, path and status, and the network address it came from; with the API's and the worker's other log lines they are kept for 30 days. A filter on every log handler of the API and the worker removes document content, and anything shaped like an upload link's token, from every line they write. The model server logs no request.

Deleting

  • A document — limma sync --delete, or POST /v1/public/delete_document: every version of the document, its facts and its file go, and every record of an event about it keeps only what happened and when — its name, its text and its figures are erased; the reply reads the store back to prove it, those records included (deleting a file).
  • A workspace — DELETE /api/workspaces/{id} with your admin key: every table of the database is checked, and the reply is a success only when nothing of the workspace is left ("residue": {}). The database's record of each call keeps who called which verb and when; what the call said is erased.
  • Everything, when your subscription ends: under the Terms, your content is deleted 30 days after the subscription ends.

What a deletion does not reach at once

  • Backups: the database's daily backups are kept for 7 days, and the queue's snapshots for 3 days. A deleted document leaves them when they expire.
  • The audit archive: a copy of the record of each call is archived in a private, encrypted S3 bucket for seven years. It holds, for each call, the key's id, the verb, the workspace, the time and the result — never the text of a question or search, the names of documents, or the users a call was made for: none of your content is archived. A deletion does not remove these records; write to contact@limma.ai about records of yours in it.
  • Request logs: 30 days. They hold no document text.

No training on your data

Limma does not train or fine-tune any model on your content: the reader runs fixed weights, pinned to one published revision. What Limma learns from your own use — the ranking and the confidence calibration your feedback teaches — is kept in your workspace and used for nobody else.

Sub-processors

AWS (hosting, storage, search vectors, e-mail) and Stripe (payments). The full list, with what each one does: sub-processors.

Reporting a security issue

Write to contact@limma.ai.