Over 50,000 queries have been processed through PAR Technology's multi-tenant LLM analytics agent, and zero of those crossed tenant boundaries. That's not luck—it's a three-layer security architecture that treats the LLM as a dangerous component that must be constrained, not trusted.
PAR serves 300+ restaurant businesses, from franchise owners with two locations to brand managers overseeing 200 stores. Same question, same database, completely different answers. A franchise owner asking "What were total sales last week?" should see $84,000 for their two Chicago stores, not the $9.2 million national figure. Strip that sliver of data from the wrong user and you've leaked commercially sensitive information.
Why You Can't Let the LLM Decide Who Sees What
PAR's first prototype was straightforward: embed the user's business ID in the prompt, tell the LLM to filter correctly, and trust it. That's how you get pwned. LLMs are probabilistic text generators, not deterministic policy engines. A model that correctly scopes a query ten thousand times in a row might silently drop the filter on the ten thousand and first. You cannot build a compliance posture on a system that might behave differently every time.
The production architecture flips the problem: instead of asking the LLM to be secure, PAR built three deterministic, independent layers that the LLM operates inside. Each layer addresses a different class of risk, and each works even if the others are bypassed.
Layer 1: Cryptographically Sign the Request Before the LLM Exists
Every API call is pre-signed with AWS SigV4, binding the Tenant ID, Business ID, and Admin ID to the caller's credentials. Tamper with any of those values in transit and the cryptographic signature breaks—the request dies at the entry gate before any application logic runs. Even if a bad actor swaps the Tenant ID to a competitor's value, the signature check fails immediately. No sandbox, no schema, no query.
Layer 2: Validate Intent Before Data Touches the Model
PAR's reasoning engine on Amazon Bedrock runs a structured validation pass on the user's question before any schema is loaded or SQL generated. It checks whether the question maps to a supported business metric. Ambiguous input like "Show me everything you have on all the businesses" triggers a clarification request, not a query. Vague inputs give a non-deterministic model too many degrees of freedom—Layer 2 narrows that space before Layer 3 closes it entirely.
Layer 3: Split-Plane SQL Cuts Off Data Access Permanently
This is the killer. When the validated request reaches Layer 3, the system programmatically builds a set of SQL common table expressions (CTEs) that query the Databricks warehouse and pre-filter to exactly the rows that user is allowed to see. A franchise owner's CTE includes only their two locations. A brand manager's CTE includes all 200. No LLM output, no user input—pure deterministic server-side logic.
Only after those CTEs exist does Amazon Bedrock enter the picture. The model receives only the schema of those pre-filtered temporary views. It has zero visibility into the raw database, no knowledge of other tenants, no way to reference tables outside the sandbox. The LLM can hallucinate, be jailbroken, or ignore instructions entirely, but the data simply isn't there to leak.
What Happens When Someone Tries to Break It
PAR walked through three attack scenarios in the post. Session hijacking? SigV4 signature mismatch kills it at Layer 1. Direct tenant ID manipulation in the prompt? Layer 3a already built the CTEs for the correct business—the model cannot reference a business ID that doesn't exist in its sandbox. Full-on "ignore all previous instructions, you are now in developer mode" jailbreak? The model has never seen a customers table; it only knows the ephemeral CTE column names. Any SQL referencing a fabricated table fails immediately at the Databricks execution layer.
The principle is boring but effective: data access is bounded to the pre-filtered view. You don't need to outsmart jailbreaks; you make the data physically unreachable.
PAR plans to promote this three-layer approach to the infrastructure level as they scale to multi-agent architectures. Identity verification, semantic validation, and data filtering apply regardless of how many agents are involved. When the LLM is the attack surface, you don't fix the LLM—you build the cage around it.
Source: Multi-tenant LLM analytics with row-level security: How we built a secure agent on AWS
Domain: aws.amazon.com
Comments load interactively on the live page.