Quivr: 274 Fingerprints, 266 Titles, and a Retrieval Layer That Holds Both Keys and Knowledge

Retrieval-augmented generation moved from a demo pattern to an internal tool quickly, and the products that implement it inherit a specific combination of assets: the documents that were ingested, the embedding vectors derived from them, and the provider credential that answers the questions. Quivr is one of the self-hosted options, and the exposure profile follows from that asset list.

What the measurement shows

Measured through ZoomEye on 2026-10-23, page size one, all sub-types:

• app="Quivr" returned 274.
• title="Quivr" returned 266.

Search link: https://www.zoomeye.ai/searchResult?q=YXBwPSJRdWl2ciI%3D

The figures agree to within three per cent, which is the second-closest pairing in this series. As with StreamPark, the agreement means the population is homogeneous: instances that present the product's own interface, with little embedding and little title customisation. Two hundred and seventy-four hosts is small enough to treat as a named population rather than a statistical one.

The three assets

A retrieval platform holds more than a chatbot interface. Consider what a single deployment contains:

• Source documents. Whatever was uploaded to build the knowledge base, in original form. Internal policy, contracts, support transcripts and technical runbooks all appear in knowledge bases, and they appear unredacted because redacting them would break retrieval.
• Embedding vectors. Derived data that is not directly readable, but which leaks through similarity search. A user who can query the collection can extract content by asking the right questions, which makes the vector store a disclosure surface even when the original files are protected.
• Provider credentials. The key used to generate embeddings and answers. Like any agent platform, it is metered, long lived and scoped to an account.

The combination is unusual. Storing documents is common. Storing credentials is common. Storing both, behind an interface designed to make arbitrary questions easy, is a configuration where one misjudged permission exposes a corpus and a billing relationship at once.

The permission question

The interface exists to answer questions about ingested content. That purpose produces two recurring mistakes:

• Collection sharing without scope. Deployments that let users share a knowledge base by link tend to share the ability to query it, which means the sharer cannot control which parts of the corpus the recipient extracts.
• Tenant separation by convention. A self-hosted instance built for one team rarely implements isolation between collections beyond naming, so a user account is effectively a reader of the whole store.

Neither of those is visible from outside. Both decide whether an exposed instance is a chatbot or a disclosure tool.

Prompt handling as a secondary channel

Ingested documents get placed in a prompt. A document containing text that reads like an instruction is, to the model, an instruction, and retrieval platforms make it easy to plant such a document because uploading is the normal workflow. Where the platform also lets the model call tools or fetch URLs, a crafted document becomes a path from the corpus to the deployment's network position.

Treating ingestion as an untrusted input path is the correction. A document that arrived from outside the organisation should not be able to influence what the model does beyond summarising itself.

Practical review

• Confirm whether the instance requires authentication, and whether it is reachable beyond the team that owns the corpus.
• Enumerate collections and the source documents behind them. Knowledge bases accumulate files that were uploaded for one experiment and never removed.
• Scope the provider key to the deployment with a spend limit, and store it in a secret mount rather than a served directory.
• Restrict retrieval to collections the requesting user is entitled to, and test that restriction from a second account.
• Review ingestion for documents that originate outside the organisation, and treat their contents as untrusted input to the model rather than as trusted reference material.

Limitations

ZoomEye figures are observations from one crawl window and will vary with later queries. A fingerprint match does not establish authentication state, collection contents, key configuration or whether tool invocation is enabled. The percentage comparisons describe how consistently the product presents itself, not the security posture of any individual deployment.

References

• ZoomEye application fingerprint query for Quivr, run 2026-10-23, total 274.
• ZoomEye title query for Quivr, run 2026-10-23, total 266.
• Quivr documentation covering knowledge base ingestion, collection sharing and model provider configuration.