LLM analytics needs hard data boundaries

AWS, together with PAR Technology, describes a production architecture for multi-tenant LLM analytics. The important element is not the text-to-SQL agent itself, but a clear security boundary: the model may formulate queries, but it must not be responsible for tenant isolation.

For enterprises, this matters because natural-language self-service analytics quickly touches sensitive data. A question such as “What were sales last week?” can mean a store figure, a brand figure or a group-wide number depending on the user’s role. If the agent is only prompted to respect that boundary, governance becomes probabilistic.

What AWS and PAR show

According to AWS, PAR uses a three-layer architecture: cryptographically signed requests with AWS SigV4, semantic validation with Amazon Bedrock, and programmatic data isolation through Split-Plane SQL. Each layer is meant to independently prevent a generated query from reading another tenant’s data.

That is the key point: the LLM is not treated as the policy engine. AWS explicitly notes that a model may apply a filter correctly ten thousand times and still omit or misinterpret it the next time. For multi-tenant systems that handle business or customer data, this non-determinism is not a sufficient control boundary.

Why this matters in DACH projects

OWASP lists Prompt Injection, Sensitive Information Disclosure, Improper Output Handling and Excessive Agency among the Gen AI Top 10. These risks become practical as soon as an agent generates database queries, executes tools or forwards results without robust validation.

For CIOs and CFOs, the decisive question is therefore not the demo, but the architecture: where is binding data authorization enforced? In the database, in a gateway, in a policy layer or only in the prompt? Amazon Redshift documents row-level security as a database mechanism that makes rows visible according to policies. Such hard boundaries are more reliable for AI analytics than model instructions.

What to do now

Do not start natural-language analytics with a broad data catalog. Start with a bounded dataset, define roles, tenant IDs, allowed metrics and test cases for boundary violations. Only then should an LLM be allowed to generate SQL.

The guiding question is: “Can the agent generate a wrong query without seeing wrong data?” If the answer is no, the security architecture is not finished yet.