If you are building a multi-tenant RAG system and your security strategy relies on telling the LLM to 'please ignore other users' data,' you are already compromised. Loreflow, a company-brain product that ingests Slack, GitHub, and docs, recently detailed how they made three specific classes of data leaks structurally impossible in their answer pipeline. The core thesis, published in October 2026, is that prompts are suggestions, but architecture provides guarantees. They stopped trying to teach the model to be safe and started building code that cannot do the wrong thing.

The Pure Function Defense Against Cross-Tenant Leakage

The most critical vulnerability in any multi-tenant retrieval system is the join point where retrieved chunks become the prompt. Loreflow’s solution is radical simplicity: their evidence-projection module is pure and I/O-free. It has no database handle, no request context, no environment variables, and no logger. As the code comment states, 'a wrong anything here still cannot reach another tenant or a provider.' By removing the function's ability to reach out, they eliminate the vector for cross-tenant exfiltration. A bug in this module might degrade answer quality, but it physically cannot leak Company A's secrets into Company B's context window because the code has no channel to do so.

Bounding the Blast Radius of Prompt Injection

Retrieved documents are third-party text, meaning they are potential injection vectors. Instead of trying to sanitize natural language, Loreflow bounded the damage using fixed evidence budgets. Every answer is assembled with a hard cap of 8 items, 1,000 code points each, and 8,000 total code points. Crucially, they count in code points, not UTF-16 units, to avoid surrogate-pair slicing bugs. Live or federated evidence, which carries the highest risk, is restricted to a sub-budget of just 3 slots. The guiding rule enforced by the code is simple: 'The model may interpret evidence. The model may never become evidence.' This ensures an injection inside a Slack message can only influence 1,000 code points of one answer, never rewrite the system's core behavior.

The Spread Operator Is a Security Vulnerability

The subtlest leak isn't an attack; it's developer error. Loreflow banned the JavaScript spread operator ({...chunk}) at the boundary between the database and the model. If a developer adds an internalNotes field to the database model six months from now, a spread operator would silently leak it into the model's context. Instead, Loreflow builds every evidence object field by field, explicitly. This makes the projection a compile-time property. The set of fields a model can ever see is enumerated in one place. Adding a new field requires editing that enumeration, making it a conscious, reviewable act in a pull request. Nothing crosses the boundary by accident.

Key Takeaways

  • Prompts are behavioral suggestions; architecture provides structural guarantees.
  • Pure functions with no I/O handles eliminate cross-tenant leakage vectors.
  • Fixed evidence budgets in code points contain prompt injection blast radius.
  • Banning spread operators prevents silent field leakage from database schema changes.
  • Security properties must be pinned by tests, not just code comments.

The Bottom Line

Stop relying on prompt engineering for security. If your code allows a silent leak, it will happen. Build systems where the mistake is structurally impossible, not just discouraged by a system prompt.