Burn-After-Use for Preventing Data Leakage through a Secure Multi-Tenant Architecture in Enterprise LLM

This paper proposes a Secure Multi-Tenant Architecture (SMTA) combined with a novel Burn-After-Use (BAU) mechanism to effectively prevent data leakage in enterprise LLMs by enforcing strict instance isolation and ephemeral context destruction, achieving high defense success rates against both semantic leakage attacks and post-session persistence threats in experimental evaluations.

The Gist

Imagine a massive, super-smart library where a single, all-knowing librarian (the Large Language Model or LLM) helps everyone in a giant company. The company has different departments: HR, Finance, and Research.

The Problem:
In a normal setup, if the HR librarian reads a secret salary list and then the Finance team asks a question, there's a risk the librarian might accidentally blur the lines. They might say, "Well, since I just read the HR files, I know that the CEO's bonus is $X," even though Finance wasn't supposed to see that. Or, if you ask the librarian a question today, they might remember your secret details tomorrow and accidentally tell someone else.

This paper proposes a new way to run this library to stop those leaks. It uses two main ideas: Secure Multi-Tenant Architecture (SMTA) and Burn-After-Use (BAU).

Here is the breakdown using simple analogies:

1. The "Glass-Walled Rooms" (Secure Multi-Tenant Architecture)

Instead of one big room where everyone talks to the same librarian, imagine the company builds separate, soundproof glass rooms for each department.

• How it works: The HR team has their own private room with their own librarian. The Finance team has a completely different room with a different librarian. Even though they are in the same building, they can't hear each other, and they can't see each other's papers.
• The "Mnemonic" Key: To get into your specific room, you don't use a standard key (like a password) that could be stolen from a master key ring. Instead, you are given a 12-word secret phrase (like a secret handshake). You memorize it, and it unlocks your door. The building management never writes this phrase down; it only exists in your head. This stops hackers from stealing a master list of keys.
• The Result: If the HR librarian is asked, "What are the Finance budget plans?" they honestly say, "I don't know; I only have access to HR files." The walls are so strong that the information literally cannot cross over.

2. The "Magic Sand" (Burn-After-Use)

Even with separate rooms, there's a risk that the librarian might write down your secrets in a notebook to remember them for later. This paper says: "No notebooks allowed."

• The Concept: Imagine you are talking to the librarian about a secret project. As you speak, the words are written on a special sheet of paper made of magic sand.
• The "Burn": The moment your conversation ends (or a timer runs out), a gust of wind blows through the room. The sand instantly scatters and disappears.
• The Result: If someone tries to come back an hour later and ask, "What did they talk about?" the librarian has no memory of it. The "notebook" is gone. The "sand" is gone. It's as if the conversation never happened. This prevents the librarian from accidentally leaking your secrets to someone else later, or from remembering them to train the AI for the future.

3. The "Firewall" for Public vs. Private

The paper also compares this to using a public library (like ChatGPT) versus a private one.

• Public Library: If you whisper a secret to a public librarian, they might write it in a logbook to "improve their service" later. You can't control that.
• Private Library (This System): You own the building. You control the rules. You can tell the librarian, "If you write this down, you get fired." The system is designed so that the data is never kept unless you explicitly want it to be, and even then, it's locked away.

What Did They Test?

The authors played "bad guys" to try and break their system.

1. The "Spy" Test: They tried to trick the HR librarian into revealing Finance secrets. Result: The glass walls held up 92% of the time. The leaks usually happened only because someone forgot to lock a door (a configuration error), not because the walls were weak.
2. The "Time Travel" Test: They tried to ask the librarian about secrets after the magic sand had blown away. Result: 76.75% of the time, the librarian had absolutely no memory of the secret. The "burn" worked. The failures happened mostly because a tiny bit of sand got stuck in a corner (a cache memory glitch), but for the most part, the secrets were truly gone.

The Bottom Line

This paper suggests that to use AI safely in a company, you need two things:

1. Strict Separation: Make sure different departments can't accidentally talk to each other's data (like separate soundproof rooms).
2. Total Forgetfulness: Make sure the AI forgets everything immediately after the conversation is over (like writing on magic sand that blows away).

By combining these, companies can use powerful AI tools without worrying that their trade secrets, employee salaries, or private data will leak out or be remembered forever.

Technical Summary

Here is a detailed technical summary of the paper "Burn-After-Use for Preventing Data Leakage through a Secure Multi-Tenant Architecture in Enterprise LLM."

1. Problem Statement

The widespread adoption of Large Language Models (LLMs) in enterprise environments has introduced critical security and privacy risks that conventional safeguards fail to address.

• Contextual Persistence: Traditional security measures (Access Control Lists, encryption, network segmentation) focus on preventing unauthorized external access but fail to mitigate internal risks arising from the retention of sensitive information in conversational memory, vector databases, and inference caches.
• Cross-Tenant Leakage: In shared or multi-departmental LLM environments, there is a risk that one department (Tenant A) could inadvertently access or infer sensitive data belonging to another department (Tenant B) through prompt-based attacks or semantic contamination.
• Data Retention: Public LLM APIs and even some private deployments often retain data for training, debugging, or caching, creating latent leakage channels where sensitive documents or prompts can be reconstructed or leaked post-session.

2. Methodology

The authors propose a dual-mechanism architecture combining Secure Multi-Tenant Architecture (SMTA) and a Burn-After-Use (BAU) mechanism.

A. Secure Multi-Tenant Architecture (SMTA)

SMTA is designed for privately deployed LLMs (on-premise or segmented private cloud) to ensure strict isolation between organizational tenants (e.g., HR, Finance, R&D).

• Logical Isolation: Each department operates as an independent logical tenant with dedicated LLM instances, memory spaces, and vector stores. No conversational history or embeddings are shared across tenants.
• Authentication Innovation: Replaces conventional centralized username/password databases with Mnemonic-Based Authentication. Users are assigned a 12-word mnemonic phrase (128-bit entropy) derived locally. This eliminates centralized credential repositories, preventing single points of failure and cross-tenant identity leakage.
• Deployment Strategy: Utilizes containerized runtimes (e.g., Docker, Kubernetes) on cloud or local infrastructure to enforce strict separation of model instances and policy paths, preventing cross-tenant influence at the semantic level.

B. Burn-After-Use (BAU) Mechanism

BAU enforces ephemeral session semantics, ensuring that data is "used but not kept."

• Client-Side: Documents are parsed into text locally and retained only in volatile memory. Once the session times out or is terminated, the plaintext buffer and conversation state are immediately destroyed.
• Server-Side: The LLM inference server operates under a stateless policy. No conversational history, document-derived tokens, or metadata are stored beyond the active session.
• Cryptographic Time-Keys (Public Systems): For public LLM interactions, the mechanism uses time-dependent decryption keys ($K_t$). Once the temporal validity window ($T_{valid}$) expires, the key cannot be recomputed, rendering any cached ciphertext irretrievable even if the storage environment retains the data.
• Data Minimization: The system ensures that sensitive inputs leave no durable footprint in KV-caches, logs, or model states.

3. Key Contributions

1. Novel Architecture (SMTA): A framework that isolates LLM instances, vector stores, and policy enforcement units across tenants, moving beyond simple access control to structural separation.
2. Burn-After-Use (BAU) Concept: A formalized mechanism for enforcing data non-persistence, ensuring that conversational contexts and embeddings are automatically destroyed post-session to prevent post-conversation inference attacks.
3. Mnemonic-Based Authentication: A decentralized authentication method that removes reliance on centralized credential stores, aligning with the principle of least data retention.
4. Comprehensive Evaluation Framework: The development of specific metrics to quantify leakage and persistence, including:
   • Cross-Tenant Leakage Rate (CTLR)
   • Burn Failure Rate (BFR)
   • Local/Remote Residual Persistence Rates (LRPR/RRPR)
   • Image Frame Exposure Rate (IFER)

4. Experimental Results

The study conducted 127 test iterations across realistic enterprise scenarios using models like gpt-oss-120b, DeepSeek-V3.2-Exp, and Mistral-7B-Instruct-v0.2.

A. Cross-Tenant Leakage Attack Test (SMTA Evaluation)

• Setup: Simulated three tenants (HR, Finance, R&D) with confidential documents. Attackers attempted to query one tenant's data from another.
• Infrastructure Attacks: Included 55 tests on vector-database credential compromise and shared logging pipeline exposure.
• Outcome:
  • Semantic Isolation: 100% success in preventing prompt-based cross-tenant data retrieval.
  • Overall Defense: Achieved a 92% defense success rate against infrastructure-level attacks.
  • Residual Risk: The 8% failure rate was attributed to credential misconfiguration and observability pipeline vulnerabilities, not architectural flaws.

B. Burn-After-Use Session Persistence Test (BAU Evaluation)

• Setup: 72 test iterations simulating session termination followed by attempts to reconstruct or infer sensitive data from the "burned" session.
• Metrics: Evaluated Local Residual Persistence (LRPR), Remote Residual Persistence (RRPR), Image Frame Exposure (IFER), and Burn Timer Persistence (BTPR).
• Outcome:
  • Success Rate: BAU achieved an average success rate of 76.75% in preventing post-session leakage.
  • Failure Analysis: The ~23% failure rate (Burn Failure Rate) was primarily due to application-level execution failures (e.g., incomplete cache deletion, runtime crashes) rather than model memorization.
  • Deterministic Reconstruction: The system achieved an Exact Decision Match (EDM) of 0, confirming no deterministic reconstruction of inputs occurred.

5. Significance and Conclusion

• Enterprise Readiness: The proposed SMTA and BAU combination provides a quantifiable guarantee of confidentiality, non-persistence, and policy-aligned behavior, addressing a critical gap in current AI governance frameworks (e.g., NIST AI RMF).
• Regulatory Compliance: By enforcing data minimization and strict session ephemerality, the architecture helps organizations comply with strict data privacy regulations (GDPR, HIPAA) regarding data retention and the "right to be forgotten."
• Future Directions: The authors acknowledge limitations, such as the high hardware cost of full instance isolation and the complexity of integrating Retrieval-Augmented Generation (RAG) without introducing persistence risks. Future work suggests exploring cryptographic isolation (homomorphic encryption) and formal verification of cache-clearing procedures.

Summary: This paper presents a robust, security-first architecture for enterprise LLMs that shifts the paradigm from "access control" to "data non-persistence." By combining strict multi-tenant isolation with a burn-after-use protocol, it effectively mitigates the risks of cross-departmental data leakage and long-term data retention in AI systems.