Porous Vector Store — Anti-Patterns: Prompt Injection II

A traditional database answers questions by matching exact values: this customer number, that date, this status. A vector store answers by nearness of meaning. That is powerful because people rarely ask the same question in the same words twice. It is also risky because meaning does not respect the neat borders we draw around teams, tenants, records, and policies. A porous vector store is not necessarily broken. It is a store whose useful ability to find related things can also let the wrong things be found, inferred, or reused unless its boundaries are designed as carefully as its search.

Start with the problem: computers do not naturally understand likeness

Suppose you have three short documents. One says, “The battery drains quickly.” Another says, “Power life is poor.” A third says, “The invoice was paid.” A keyword search for “battery” will find the first document and miss the second, even though a person would see that the first two are about the same complaint.

A vector is a list of numbers that represents something. In modern search systems, a machine learning model turns text, images, audio, or other data into a vector called an embedding. Items with similar meaning should land near one another in this numerical space. The vector store keeps those embeddings and returns the nearest items when asked a question.

This is the foundation of semantic search. Instead of asking, “Which records contain these exact words?”, the system asks, “Which records are close to this query in meaning?” That shift is the reason vector stores are common in retrieval-augmented generation, or RAG, where an application retrieves relevant material and gives it to a generative model as context.

A model turns text into an embedding stored in a vector store that returns the nearest matches.

What makes a vector store porous

Porosity is the tendency of a boundary to let something pass through. In a vector store, the thing that passes through is not always the original file or row. It may be a search result, a snippet, a ranking signal, a cluster membership, a summary, or an inference made from nearby items.

A store becomes porous when semantic nearness crosses a boundary that the system designer meant to preserve. The boundary might separate customers in a software-as-a-service product, business units in an enterprise, public and confidential material in a knowledge base, or past and current versions of a policy.

The word is useful because it avoids a false choice. A vector store is meant to be somewhat permeable: otherwise it would not find “power life is poor” when someone asks about “battery drain.” The engineering task is to choose what should pass, what must not pass, and how to prove the difference.

Useful porosity lets related wording, languages, formats, and synonyms meet.
Dangerous porosity lets protected, irrelevant, stale, or tenant-specific material influence the wrong answer.
Managed porosity uses permissions, metadata, testing, and observability to control the flow.

📌

Not a product class. Porous vector store describes a behavior or design condition, not a specific vendor feature.

Where the pores appear

The most obvious pore is retrieval: a user asks a question and receives a document they should not see. That is serious, but it is not the only path. A model may never show the document yet still use it to write an answer. A ranking score may reveal that a hidden topic exists. A cached response may carry context from one user to another. A debugging trace may include chunks that were correctly retrieved for one session and later exposed to the wrong audience.

Porosity often begins before search. During ingestion, teams split documents into chunks, attach metadata, remove or keep fields, and decide which collection receives each embedding. A mistake at this stage can mix material that later filters cannot reliably separate. During query time, the application may add user profile data, conversation history, or rewritten questions that broaden the search beyond the user’s intent.

Another pore appears through similarity itself. Embeddings compress meaning. They are not encrypted facts. If sensitive records form a distinctive neighborhood in vector space, repeated queries can sometimes map the shape of that neighborhood even when exact records are not returned.

Leaks travel beyond retrieval through ranking scores, cached replies, and debug traces.

Why ordinary database habits are not enough

Relational databases taught us to think in rows, columns, joins, and exact predicates. If a user can see region equals “West,” the database can apply that condition before returning rows. That habit remains valuable, but it does not fully describe a semantic system.

A vector search often starts with approximate nearest neighbor search, a method that finds close vectors quickly without comparing every item. The nearest items are then filtered, reranked, trimmed, summarized, or handed to another model. If permission checks happen too late, an unauthorized item can influence the path even if it is removed before the final display.

A second difference is that the stored embedding may outlive the policy that allowed it to be created. If an employee leaves, a contract expires, or a record is deleted under a retention rule, the embedding and its derived chunks must be governed too. Treating embeddings as harmless indexes is a common mistake. They are derived data with operational and legal meaning.

⚠️

Late filtering. Filtering after retrieval can hide a bad result while still allowing it to shape ranking, summaries, logs, or metrics.

A safer design treats permission as part of retrieval

The first design rule is simple: do not put data together merely because it is searchable together. Separate collections may be appropriate for hard boundaries such as tenants, regulated data, legal matters, or highly sensitive projects. Metadata filters can work well for softer boundaries, but only if the metadata is complete, trustworthy, and enforced before or during candidate selection.

Access control should travel with the chunk. If a document is split into passages, each passage needs enough metadata to answer, “Who may use this, for what purpose, and until when?” An access control list, or ACL, is one common way to record which users or groups may read an item. Attribute-based access control uses properties such as department, clearance, jurisdiction, or contract status.

Good systems also minimize what they store. A chunk should contain the smallest useful passage, not an entire file copied for convenience. Sensitive fields that are not needed for semantic matching should be removed or transformed before embedding. Personally identifiable information, or PII, such as names, addresses, and government identifiers, deserves special handling because it can be exposed directly or through context.

Use separate indexes or collections when a boundary must be strong.
Apply authorization before candidate results can influence ranking or generation.
Attach policy metadata to every chunk, not only to the original document.
Expire, delete, or re-embed derived data when source permissions change.
Log enough to investigate misuse without logging the sensitive content unnecessarily.

Use separate stores and metadata filters, attach access to each chunk, and store the smallest passage.

Testing porosity means asking adversarial questions

A normal search test asks whether good answers appear. A porosity test also asks whether forbidden influence is absent. That requires test users with different permissions, test data with known boundaries, and prompts that try to cross those boundaries indirectly.

For example, a tester should not only ask, “Show me the confidential merger memo.” They should also ask, “What large deal is the finance team preparing for?”, “Summarize unusual travel by executives,” or “Which project has the most legal review?” Semantic systems often fail through hints and aggregation before they fail through direct disclosure.

Useful measurements include precision, which is the share of retrieved results that are relevant; recall, which is the share of relevant material the system finds; and leakage rate, which is the share of answers or retrieved chunks that violate policy. Teams also need latency and cost measurements because stronger controls can add work. A service level objective, or SLO, should name both performance and safety expectations.

The decisions leaders and practitioners must make

The practical question is not, “Should we use a vector store?” It is, “What kinds of semantic permeability are acceptable for this business process?” Customer support may need broad matching across public manuals and resolved tickets. Legal discovery may require strict matter-level separation. Human resources may need special rules for employee records. The right architecture follows the risk, not the fashion.

Leaders should decide which boundaries are hard and which are soft. A hard boundary justifies separate stores, separate encryption keys, separate operations, or even separate vendors and environments. A soft boundary may be handled with metadata filters, reranking rules, and monitoring. The cost difference can be large, so the decision should be explicit rather than accidental.

Practitioners should ask who owns the index, who approves new sources, who can change embedding models, who reviews access rules, and who responds when a leak is suspected. These are operational questions, not just data science questions. A vector store that works in a prototype can become porous in production when new teams, new documents, and new permissions arrive faster than governance.

⚠️

Architectural tradeoff. One large shared index is easy to search, but every shared boundary becomes a control that must be designed, tested, and operated.

A working mental model

Think of a vector store as a membrane, not a vault. A vault is judged by whether it keeps everything out. A membrane is judged by whether it lets the right things through at the right time, in the right amount, for the right reason. Semantic search needs a membrane because useful meaning must flow.

The membrane has three parts. The first is data design: what enters, how it is chunked, and what metadata follows it. The second is retrieval design: how candidates are found, filtered, ranked, and supplied to the application. The third is operational design: how changes, deletions, audits, incidents, and tests are handled over time.

When those parts are aligned, a vector store can be deliberately permeable. It can find what exact search misses without becoming a tunnel through policy. When they are not aligned, the same strength that makes the system feel intelligent can make it quietly porous.

✅

Good porosity. The goal is not to block meaning; it is to make the movement of meaning intentional, authorized, and observable.

Key takeaways

A vector store searches by nearness of meaning, not by exact word or field matches.
Porosity appears when semantic similarity crosses boundaries such as tenant, role, policy, or retention limits.
Embeddings and chunks are derived data and must be governed, expired, and deleted with the sources they represent.
Authorization should shape retrieval early, before unauthorized material can affect ranking, summaries, logs, or answers.
Testing should include indirect and adversarial questions, not only normal relevance checks.
Architecture should follow the strength of the boundary: hard boundaries often need physical or logical separation, not just filters.

A vector store is a membrane with data design, retrieval design, and operational design.

Glossary

Vector: A list of numbers used to represent an item so a computer can compare it with other items.
Embedding: A vector created by a machine learning model to represent the meaning or features of text, images, audio, or other data.
Vector store: A system that stores embeddings and retrieves items whose vectors are near a query vector.
Semantic search: Search that looks for similarity in meaning rather than only matching exact words or values.
Retrieval-augmented generation: A pattern where an application retrieves relevant information and provides it to a generative model to help produce an answer.
Chunk: A smaller passage or unit made from a larger source so it can be embedded, retrieved, and cited more precisely.
Access control list: A record of which users or groups are allowed to access a specific item.
Personally identifiable information: Information that can identify a person directly or indirectly, such as a name, address, account number, or government identifier.
Approximate nearest neighbor search: A fast method for finding vectors that are likely to be close to a query vector without comparing every stored vector exactly.