Adding retrieval to an AI application usually gets pitched purely as an accuracy improvement, and it is one, but it also opens a new data path that most existing security review processes were never built to check. Knowing specifically how that path changes the attack surface is what makes it possible to review it on purpose, instead of just assuming existing controls automatically stretch to cover it, because they usually don't.
A new path around conventional access control
Most organizations already have access control on their document management systems, wikis, and databases: role-based permissions, department-level restrictions, classification labels. A RAG pipeline that indexes content from these sources without carrying that access metadata forward effectively opens a second path to the same data, one that bypasses whatever authorization the original source was enforcing. The document itself didn't get any less sensitive. The retrieval system just never inherited the rule that was supposed to protect it.
This is the single most consequential attack surface expansion RAG brings, and the reason it's so consequential is that exploiting it takes no adversarial behavior whatsoever. An ordinary employee asking an ordinary question can trigger it just by having their query happen to rank a document they were never supposed to see as relevant.
Every writable content source becomes an injection vector
Once a source feeds retrieval, anyone who can write to it has a path to influence what the model eventually sees, and potentially does, for any future query that retrieves their content. A wiki lots of employees can edit, a shared drive with broad write access, a public website that gets scraped and indexed, each one becomes a potential indirect prompt injection vector the moment it joins a retrieval pipeline, whether or not anyone with write access to it has any adversarial intent at all. A single compromised account with write access to a retrieval source now has a much bigger potential blast radius than that same compromise would have had before the source was ever connected to an AI system.
Retrieval quality and security pull in different directions
Systems tuned purely for retrieval quality tend to favor broad indexing, more sources, finer-grained chunks, more aggressive similarity matching, because these choices generally improve the odds of finding something relevant. Every one of them also expands the attack surface right along with it: more sources means more places an attacker could plant content, and more aggressive matching means content further from an exact match has a better shot at getting retrieved and trusted, even when it's only tangentially relevant, or worse, deliberately crafted to look superficially relevant to common queries.
The vector database itself is a new asset to protect
A vector database storing embeddings of an organization's sensitive documents is itself a sensitive asset, even though embeddings aren't directly human-readable at a glance. Depending on the embedding technique, it's sometimes possible to reconstruct meaningful information about the original content straight from its vector representation, and the database's own access controls, authentication, and network exposure deserve the same scrutiny as any other data store holding sensitive information. That scrutiny is easy to skip precisely because the data looks unfamiliar and abstract next to a plain old table of records.
Multi-tenant retrieval adds a specific isolation risk
For any RAG system serving multiple tenants, customers, or user groups off a shared index, failing to properly isolate retrieval by tenant can surface one tenant's data to a completely different tenant's query, a risk that doesn't even exist in a single-tenant deployment and that's easy to miss if tenant scoping wasn't a first-class design consideration from the start.
Reviewing this attack surface deliberately
A useful review starts by listing every source that feeds a given retrieval pipeline, who can write to each one, what access controls the original source enforces, and whether the retrieval system actually carries those controls forward. For each source, ask what the worst outcome would look like if an attacker could plant arbitrary content in it, and whether current retrieval and filtering behavior would actually surface that content to an audience it was never meant to reach.
Where TELEON fits
TELEON's audit trail can log which retrieval sources or tools an agent accessed as part of a given interaction, applied through the gateway or supported middleware, which supports identifying which source likely contributed to an unusual or unauthorized outcome during an investigation.
The core fixes, carrying forward access control metadata into retrieval, restricting write access to feeding sources, and isolating multi-tenant indexes, are pipeline-level design decisions that have to be implemented in the retrieval architecture itself.
A short checklist
- List every source feeding retrieval and who can write to each one.
- Confirm access control metadata from original sources is carried
forward into retrieval filtering.
- Review the tradeoff between broad, aggressive retrieval and attack
surface exposure deliberately.
- Apply the same access control and network security scrutiny to vector
databases as to conventional data stores.
- Verify strict tenant isolation for any multi-tenant retrieval index.
RAG's attack surface expansion is largely invisible in a typical architecture diagram, because it looks like "the model got smarter," not "we added a new data access path." Naming the specific ways that path changes the attack surface is what makes it possible to review and secure deliberately.