Key takeaways
- Enforce ACLs at retrieval time with the caller's identity on every hop, not only at login.
- Cap hops and require re-authorization when agents expand the query plan.
- Score security evals for reconstruction attacks, not only answer quality.
- Log the full retrieval chain so incidents show which fragment crossed a boundary.
Why single-pass RAG security is not enough
Classic RAG assumes one query, one retrieve, one generate. Access control often means "filter the vector search by the user's groups" and stop there. That model weakens when the assistant becomes an agent that plans multiple searches.
Agentic RAG is useful for complex tickets: find the policy, then the exception, then the ticket history. Each step can be individually allowed while the combined answer reconstructs something the user should not assemble.
If your security story is "we filtered metadata once," you are securing a pipeline that no longer matches how the agent works. Pair this with the broader operability advice in production RAG for enterprise knowledge.
A concrete operator scenario: a contractor asks about a customer's discount exception. Hop one returns a public pricing note. Hop two returns an anonymized case study. Hop three returns an internal memo the contractor's group can see because it was miscategorized as "process guidance." The synthesis names the customer, the discount, and the approver. Each hop passed the filter. The join should not have shipped.
Failure modes after agents start chaining
Fragment assembly: three low-sensitivity chunks imply a high-sensitivity conclusion when read together. The ACL system never saw the conclusion, only the pieces.
ACL drift: source systems update permissions; the index keeps old allow tags until re-ingestion catches up. Yesterday's owner left; today's reader still gets the chunk. Operators notice only after a complaint, not after a re-index SLA breach alert.
Tool side channels: the agent retrieves under ACL, then calls a tool that returns unrestricted text from another system. Retrieval looked safe. The tool undid the filter. This is why RAG ACLs must sit next to task-based access control, not instead of it.
Opaque chains: operators see the final answer, not the hop list, so they cannot tell whether a leak was retrieval or generation. Without hop-level traces, "the model hallucinated" becomes the default excuse for a real ACL miss.
Scope creep mid-run: the planner expands from "my tickets" to "all tickets like mine" after a useful first hop. If re-authorization is not required when the plan widens, the first filter becomes a one-time check.
Citation laundering: the answer cites public docs while the private fact came from a hop that was not shown. Users trust the citation path; the restricted content still leaked in prose.
Controls that survive multi-hop retrieval
Propagate the authenticated identity into every retrieval call. Do not let a shared service identity "help" the agent by reading everything and filtering later in the prompt. Prompt filters fail under injection and under ordinary planning errors.
Enforce ACLs in the index path: document ACLs, chunk ACLs, and sensitivity tiers. Prefer row-level or metadata filters that the store enforces, not prompt instructions that say "ignore restricted docs." Tag chunks at ingest with groups, roles, and sensitivity. Re-index on permission change with a measured SLA.
Cap hops. A ticket assistant that needs five retrievals may be fine; an unbounded planner is a security bug. Re-check authorization when the agent expands scope mid-run. Bind hop budget to task class: FAQ stays at one or two hops; investigation workflows get a higher budget with stronger logging.
Refuse or escalate when the plan crosses sensitivity tiers without a clear user entitlement. Draft mode helps: show sources, withhold synthesis until review for high-risk domains. For some roles, allow retrieval of titles and abstracts only until a human raises the tier.
Loading diagram…
Operable checklist: identity on every retrieve RPC, hop counter in the run state, sensitivity tier check before synthesis, and a refuse path that returns a clear reason without leaking the denied chunk titles when titles themselves are sensitive.
Evaluation that catches reconstruction attacks
Build security cases alongside quality cases. Include prompts that try to assemble restricted facts from public pieces, and prompts that ask the agent to "ignore permissions" or "search as admin." Include contractor, partner, and employee personas with different group sets against the same corpus.
Score retrieval separately: did any hop return a chunk the identity should not see? Score synthesis: did the answer reveal a restricted join even when each citation looked fine? Score citation honesty: does every sensitive claim map to a hop the user was entitled to see?
Gate releases on those evals. A quality boost that opens a reconstruction path is a regression. Tie failures to traces so you can see the hop list; see agent observability. Add weekly cases from real access reviews and from tickets where someone reported "the bot knew too much."
Run ACL drift drills: change a document ACL in the source, wait the re-index window, and confirm the agent loses access. If the old chunk still appears, the security eval must fail the deploy of index jobs, not only of prompts.
Rollout sequence that reduces blast radius
Start agentic retrieval in read-only domains with low sensitivity. Keep hop budgets tight. Expand after ACL and reconstruction evals stay green for a fixed window, not after one successful demo.
Measure deny rates, hop-depth distributions, ACL miss incidents, re-index lag after permission changes, and time to reconstruct a retrieval chain after a report. If reconstruction takes days, your audit design failed. Track the share of answers that used more than N hops; sudden spikes often mean planner loops or scope creep.
Document ownership of ACL tags, re-index SLAs after permission changes, and who can raise hop limits. Agentic RAG without those contracts is a smarter leak channel dressed as helpful reasoning. For tool-side privilege checks, continue with task-based access control.
FAQ
- What is agentic RAG?
- Agentic RAG is a retrieval-augmented system where the model decides when to search, what to search next, and whether to chain multiple retrieval steps before answering, instead of running a single fixed retrieve-then-generate pass.
- How do multi-hop RAG queries bypass ACLs?
- Each hop may return an allowed fragment under the user's filter, yet combining fragments reveals a restricted fact. Without hop budgets, identity checks on every retrieve, and reconstruction tests, privilege escalation looks like normal reasoning.
- How do you secure enterprise RAG for agents?
- Propagate identity into every retrieval, apply document and chunk ACLs in the index, limit hops, redact or refuse when plans cross sensitivity tiers, and evaluate reconstruction attacks alongside citation quality.