Decoupling LLM Generation from Data Access: A Three-Layer Security Architecture for Text-to-SQL Agents

As enterprises deploy text-to-SQL agents, preventing cross-tenant data leaks requires decoupling natural language generation from data access enforcement. According to a recent AWS Machine Learning Blog post, PAR Technology has implemented a three-layer security architecture to isolate data boundaries, providing a blueprint for mitigating prompt injection risks in multi-tenant environments.

The Multi-Tenant Data Boundary Problem

PAR Technology, which provides technology solutions for over 300 restaurant businesses ranging from independent operators to large multi-brand franchise groups, faced a critical challenge when building a self-serve text-to-SQL agent. The goal was to allow non-technical business users to query their data using natural language. However, ensuring that identical queries from different users yield strictly scoped results is a complex security problem. For instance, a franchise owner asking for total sales last week must only see data for their specific locations, while a corporate executive asking the same question should see aggregate data across the entire brand.

Relying on the LLM to generate the correct SQL WHERE clauses based on user context is inherently risky. If an LLM is responsible for appending tenant IDs to a query, a simple prompt injection attack-such as a user instructing the model to ignore previous instructions and return all records-could easily bypass these constraints, resulting in a catastrophic cross-tenant data leak. The core problem sits at the intersection of data access, correctness, and security at scale, requiring a system that generates the right SQL for the right user against the right slice of data.

A Three-Layer Defense-in-Depth Architecture

To address this vulnerability, PAR engineered a system that explicitly does not trust the LLM with data access enforcement. Instead, they implemented a three-layer architecture designed to isolate data boundaries even if the LLM is compromised. The first layer utilizes cryptographic request signing with AWS SigV4, ensuring that every request to the analytics engine is strictly authenticated and tied to a verified user identity before any SQL is executed.

The second layer involves semantic validation using Amazon Bedrock. Rather than blindly executing the generated SQL, this layer uses an LLM to evaluate the intent and structure of the query, checking for malicious patterns or unauthorized analytical requests. Finally, the third and most critical layer is programmatic data isolation via a technique PAR refers to as Split-Plane SQL. By decoupling the SQL generation from the execution context, this architecture ensures that the underlying data boundaries remain intact. The LLM generates the core analytical query, but the infrastructure programmatically wraps or modifies that query to enforce row-level security (RLS) at the database level, completely independent of the model's output.

Implications for Enterprise LLM Agents

This architecture highlights a necessary shift in how enterprises must design LLM-driven analytics. Early text-to-SQL implementations often attempted to solve the multi-tenancy problem by passing user identity and permission matrices as context to the LLM, hoping the model would accurately append the necessary filters. PAR's approach demonstrates that production-grade systems must treat the LLM as an untrusted query generator.

By enforcing RLS programmatically outside the LLM's control, organizations can mitigate the risks of SQL injection and cross-tenant data exposure. This defense-in-depth strategy is likely to become the standard for B2B SaaS platforms integrating generative AI analytics. As more organizations move away from static dashboards toward conversational interfaces, the attack surface for data exfiltration expands. Traditional role-based access control (RBAC) is insufficient when a single natural language prompt can generate complex, multi-join SQL queries. By adopting a Split-Plane architecture, engineering teams can maintain the agility of generative AI while adhering to strict compliance frameworks like SOC 2 or GDPR. This separation of concerns-where the LLM handles the semantic translation and the database engine handles the authorization-provides a scalable blueprint for the next generation of enterprise software. It proves that the viability of enterprise AI agents depends less on the reasoning capabilities of the underlying foundation models and more on the deterministic security wrappers built around them. For engineering teams, the mandate is clear: security boundaries must live in the infrastructure, not in the system prompt.

Limitations and Open Questions

While the architectural blueprint presented by PAR Technology is sound, the AWS blog post leaves several technical specifics unaddressed. The exact mechanics of Split-Plane SQL and how it programmatically isolates data at the database level are not fully detailed. It remains unclear whether this involves dynamic view creation, query rewriting via an Abstract Syntax Tree (AST) parser, or leveraging native PostgreSQL or database RLS features.

Furthermore, the post does not specify which foundational models hosted on Amazon Bedrock were selected for the semantic validation layer. Different models offer varying trade-offs between reasoning capability and speed, which is critical for a validation step. Additionally, the operational cost of running a secondary LLM solely for semantic validation at scale is omitted. For platforms processing thousands of concurrent queries, the financial implications of this defense-in-depth strategy must be weighed against the risk of data exposure. Most importantly, the source does not quantify the performance overhead or latency introduced by this three-step validation and signing process. For real-time self-serve analytics, the latency cost of multiple validation hops-especially those involving secondary LLM calls for semantic checks-could be a significant adoption friction point for end users expecting instant results.

Synthesis

Securing text-to-SQL agents in multi-tenant environments requires moving security boundaries out of the prompt and into the deterministic infrastructure. PAR Technology's implementation proves that while LLMs are highly capable of translating natural language to SQL, they cannot be trusted to enforce data access policies on their own. As enterprise adoption of generative analytics accelerates, architectures that enforce programmatic data isolation independent of the LLM will be critical for maintaining trust and compliance. The transition from experimental AI features to production-grade enterprise tools will be defined by these robust, multi-layered security paradigms.

Key Takeaways

• Multi-tenant text-to-SQL agents must decouple natural language generation from data access enforcement to prevent cross-tenant data leaks.
• PAR Technology utilizes a three-layer architecture consisting of AWS SigV4, Amazon Bedrock semantic validation, and Split-Plane SQL.
• Relying on LLMs to generate security constraints like SQL WHERE clauses is a critical vulnerability; row-level security must be enforced programmatically.
• The latency impact and specific model choices for this defense-in-depth approach remain open questions for enterprise adoption.