Imagine a franchise owner in Chicago asking an AI assistant for their total revenue from last week. The system returns a precise figure of $84,000. Moments later, a national brand manager asks the exact same question, and the system returns $9.2 million. In a multi-tenant environment, this divergence is not a bug—it is the primary requirement. For companies managing hundreds of distinct business entities, the ability to strictly partition data based on user identity is the difference between a powerful analytics tool and a catastrophic security breach. When a single software instance serves multiple clients, the risk of data leakage is constant, and the stakes are commercially existential.
The Three-Layer Deterministic Defense
PAR Technology, which supports over 300 restaurant businesses ranging from independent operators to massive franchises, has moved beyond simple access controls to implement a rigorous three-tier data isolation architecture. This system is designed to ensure that Row-Level Security (RLS) is enforced regardless of how a user phrases their request or how an AI model interprets it. The goal is to ensure that the data returned is governed by the user's identity, not the model's intuition.
The first layer of this defense is the request signing phase utilizing AWS SigV4. Every API request must be cryptographically signed and include three critical identifiers: the Tenant ID, the Business ID, and the Admin ID. This ensures that the identity of the requester is verified at the infrastructure level before any processing begins, preventing request forgery or identity spoofing.
The second layer operates within Amazon Bedrock, serving as a semantic validation gate. Before a query is ever executed, the system analyzes the intent of the model-generated query to ensure it aligns with the requester's authorized scope. This layer acts as a conceptual filter, blocking abnormal access attempts that might appear syntactically correct but are semantically unauthorized.
The final and most critical layer is the implementation of Split-Plane SQL. In this architecture, the generation of the SQL query is entirely decoupled from the application of security filters. While the LLM handles the complex task of translating natural language into a SQL query, the system intercepts that query before it reaches the database. It then programmatically injects the required permission filters based on the verified identifiers from the first layer. This ensures that the final data boundary is determined by the infrastructure, making the data extraction process deterministic rather than probabilistic.
The Failure of Probabilistic Security
This architectural rigor was born from the limitations of an earlier iteration. In the V1 version of their system, PAR Technology relied on a more direct pipeline: user questions were sent to Amazon Bedrock, where the `anthropic.claude-sonnet-4-20250514-v1:0` model interpreted the intent and generated SQL queries for a Databricks data warehouse. During the proof-of-concept phase, this approach was highly successful. The model demonstrated an impressive ability to select the correct tables and interpret complex analytical questions, proving that Text-to-SQL was a viable path for business intelligence.
However, the transition to a production environment revealed a fundamental flaw: the reliance on the model's generative capabilities for security. In a corporate multi-tenant environment, compliance is binary—it is either secure or it is not. The V1 approach relied on the model to remember and correctly apply business ID filters via prompting. This created a vulnerability rooted in the non-deterministic nature of Large Language Models.
An LLM is a probabilistic engine, meaning that the same input can produce different outputs across different sessions. In a security context, this is unacceptable. A model might correctly apply a business ID filter 10,000 times in a row, but the 10,001st query could omit the filter entirely. This risk is compounded by the model's inherent tendency to be helpful. When faced with an ambiguous user query, an LLM may attempt to expand the query range to find a more complete answer, inadvertently crossing the boundary into another client's data. By shifting to a Zero Trust model, PAR Technology removed the security burden from the model and placed it into the architecture, ensuring that no matter how the SQL is generated, the data boundary remains inviolable.
For any organization deploying enterprise LLM agents, the lesson is clear: prompt engineering is not a security strategy. To maintain true data governance, developers must implement a separation of concerns where the LLM generates the logic, but the infrastructure enforces the permission. This requires a strict adherence to the AWS Shared Responsibility Model, where the enterprise takes full ownership of the data isolation logic at the application layer. Furthermore, a robust audit logging system must be implemented to record the authenticated user ID, the request timestamp, and the final executed query. This creates a transparent trail of who accessed what data and under which authority, transforming the AI from a black box into a compliant enterprise tool.
The transition from trusting the model's intelligence to trusting the system's architecture is the only way to deploy generative AI in high-stakes B2B environments.
