AWS で構築した行レベルセキュリティを備えたマルチテナント LLM アナリティクスとセキュアエージェントの仕組み

At PAR Technology Corporation, we build technology for the restaurant industry, supporting over 300 restaurant businesses, from independent operators to large, multi-brand franchise groups. Across this diverse customer base, we help organizations make better decisions by unlocking the value of their data.

When we set out to build a natural language text-to-SQL agent for self-serve analytics, the objective was clear: enable business users, regardless of technical background, to ask a business question in plain English and receive a reliable, data-backed answer in seconds. However, delivering on that promise required solving a more complex challenge beneath the surface.

In this post, we show you how PAR built a production-ready multi-tenant LLM analytics system that enforces row-level security through a three-layer architecture: cryptographic request signing with AWS SigV4, semantic validation on Amazon Bedrock, and programmatic data isolation via Split-Plane SQL.

We demonstrate how each layer operates independently to reduce the risk of cross-tenant data exposure, even when the LLM itself is compromised or manipulated.

The core problem sits at the intersection of data access, correctness, and security at scale. Our system must simultaneously support thousands of users, each tied to different businesses, datasets, and permission boundaries. Every query generated by the agent must not only be accurate, but also strictly scoped to the data that user is authorized to access. In other words, the challenge isn’t only generating SQL. It’s generating the right SQL, for the right user, against the right slice of data, every single time.

The data boundary problem

Consider two users who open our analytics agent on the same morning and ask the exact same question: “What were total sales last week?”

The first user is a franchise owner. They operate two locations in Chicago. The correct answer for them is $84,000, the combined sales of their two stores.

The second user is a brand manager at the corporate level. They oversee the entire chain, 200 locations across the country. The correct answer for them is $9.2 million.

Same question. Same database. Completely different numbers, and both are correct. Showing the franchise owner the national figure isn’t only a data governance failure, it potentially exposes commercially sensitive information about other operators on the system. And showing the brand manager only two locations’ worth of data means they’re making national decisions on incomplete information.

This is the row-level security problem, and it plays out across thousands of queries every day on our system. Every query has to return the right number for that specific user, not the global number, not another tenant’s number.

Why you can’t rely on the LLM to enforce this

Our initial instinct, like many teams building LLM-powered applications, was to instruct the model to apply the right filters. Include the user’s business ID in the prompt, tell the model to consistently scope queries accordingly, and trust it to comply. The problem is that LLMs are non-deterministic by nature. They are powerful reasoning engines, but they are probabilistic generators rather than deterministic policy engines. A model that correctly applies a business ID filter ten thousand times in a row may silently omit it on the ten thousand and first. It might hallucinate a filter value. It might misinterpret an ambiguous prompt and broaden the scope of a query in ways that expose data it shouldn’t touch.

In a consumer application, non-determinism is an inconvenience. In a multi-tenant analytics system handling sensitive business data, it is insufficient as a security boundary. You cannot build a compliance posture on top of a system that might behave differently every time.

Our goal

We needed to build a self-serve analytics solution that was powerful enough for business users to trust and designed with security controls that our engineering and compliance teams could stand behind one where data boundaries were enforced deterministically, at the architecture level, regardless of what the model did or didn’t do. This post shares the engineering approach we took to get there.

Solution overview

Our production architecture grew out of the limitations of a simpler first version, so it helps to start there.

Where we started

Our first version of the analytics agent was conceptually straightforward. A user typed a question in plain English. The system passed that question to a large language model on Amazon Bedrock (using Anthropic’s Claude Sonnet 4, model ID anthropic.claude-sonnet-4-20250514-v1:0), which interpreted the intent and generated a SQL query against our Databricks data warehouse. The query ran, and the result came back as a plain-language response. For a proof of concept, it worked well. The model correctly interpreted most questions, selected reasonable tables, and produced accurate SQL.

But when we started preparing for production where real customer data would be at stake, across hundreds of businesses and thousands of users, we asked ourselves a harder set of questions. What happens when a user asks something vague and the model makes a broad assumption about scope? What happens when a session is compromised? What happens when a user deliberately crafts a prompt to request data they are not authorized to see? What happens when the model forgets to apply the right filter?

In a basic text-to-SQL setup, the model is the only thing standing between the user and the database. And as we have already established, LLMs are non-deterministic. They are not reliable security enforcers. Our v1 was analytically promising but architecturally vulnerable, not ready for an enterprise, multi-tenant environment where data boundaries are a compliance requirement, not a nice-to-have.

To meet our Zero Trust security requirements, we had to go back to the architecture and design security in from the ground up.

How our customers are structured

To understand the scale of the challenge, it helps to understand how we structure our customers. We serve over 300 restaurant businesses on our system. These businesses are organized into tenants, think of a tenant as a brand or an umbrella organization. A large restaurant group that owns several different chains, for example, would be a single tenant, with each chain being a separate business underneath it. Within each business, there are multiple admins, the people who log in and use our analytics agent day to day.

The hierarchy looks like this:

• A tenant is the top-level organization (a brand group or franchisor).

• A business sits within a tenant (typically a specific restaurant chain or concept).

• An admin is an individual user within a business (a brand manager, a franchise owner, a regional director).

A brand manager admin might have access to the full 200 locations in their business. A franchise owner admin might have access to only the two locations they operate. Both are valid users of the same system, querying the same underlying database, but the rows of data they are authorized to see are completely different. This is what makes row-level security not only a feature, but a foundational engineering requirement.

Every API request to our agent carries three identifying values: a Tenant ID, a Business ID, and an Admin ID, and every query result must be scoped to exactly what that combination is authorized to see. Nothing more.

Our security architecture follows the AWS shared responsibility model. AWS is responsible for security of the cloud. AWS protects the infrastructure that runs Amazon Bedrock and other AWS services. PAR is responsible for security in the cloud, implementing the three-layer security architecture, managing identity and access controls, and enforcing data isolation at the application and database layers.

Sensitive data is designed to be encrypted both at rest and in transit. Our Databricks data warehouse uses encryption at rest for stored data, and API communications use TLS 1.3 encryption. Encryption keys are managed using AWS Key Management Service (AWS KMS) with automatic rotation policies. Comprehensive audit logging captures data access operations, including authenticated user identity, timestamps, and query details, enabling security monitoring and compliance verification.

AWS service integrations use AWS Identity and Access Management (AWS IAM) roles with temporary credentials exclusively. No long-term access keys are used in the system. The Amazon Bedrock integration uses IAM roles for authentication, and the Databricks service principal obtains temporary credentials through AWS IAM role assumption.

System architecture

Our production text-to-SQL agent is a conversational analytics solution built on AWS. A user types a question in plain English. The solution validates that question, identifies the relevant data schemas, generates a SQL query against a pre-authorized data sandbox, executes it on our Databricks cluster, and returns both the result and a plain-language analysis. Under the hood, the solution is composed of several key components:

• Reasoning engine — powered by Amazon Bedrock with AWS IAM role-based access controls and Amazon CloudWatch logging enabled, this component interprets the user’s intent and validates whether the question maps to a supported, well-defined metric before anything else happens. If the question is ambiguous or unsupported, the system stops and asks for clarification rather than proceeding to SQL generation.

• Schema router — also running on Amazon Bedrock, this determines which database schemas are relevant to the user’s validated question.

• SQL generator — generates Databricks-compatible SQL against the authorized data schemas.

• Databricks cluster — stores and serves the underlying restaurant data and executes the final SQL query. The Databricks deployment uses network isolation, encryption at rest for stored data, and service principal authentication with restricted access controls.

• Flask API layer — Handles request routing, session management, and orchestration between components.

The three-layer security architecture

The gap between our v1 and our production architecture is a three-layer security architecture where each layer operates at a different point in the request pipeline, addressing a different class of risk. Each layer is independent and deterministic. The LLM sits inside this architecture, not above it. It operates within boundaries it cannot cross, regardless of what it generates.

The three layers are:

• Layer 1 — Integrity-protected requests (API entry point): Every API call is cryptographically signed, verifying who is asking before anything else runs.

• Layer 2 — Semantic input validation (after authentication, before data access): The reasoning engine validates what is being asked before data is touched.

• Layer 3 — Programmatic data isolation (SQL generation phase): A Split-Plane SQL architecture controls what data the model is allowed to see, enforcing strict row-level security at the database layer.

The request flows through these layers in strict sequence: Layer 1 authenticates at API entry, Layer 2 validates intent after authentication, and Layer 3 enforces data boundaries at SQL generation. Each layer operates independently. Layer 3 still enforces row-level security even if Layer 1 or 2 were somehow bypassed.

Solution walkthrough

We walk through how each security layer operates in practice, using real bad actor scenarios to demonstrate how the architecture responds. Each layer description includes a “Resilience in practice” section showing what happens when a bad actor attempts to bypass that specific control.

Layer 1: Integrity-protected request signing

Security begins before a request reaches our application logic. Every API call to our analytics agent is pre-signed using AWS Signature Version 4 (SigV4), cryptographically binding the request payload: including the Tenant ID, Business ID, and Admin ID, to the caller’s AWS credentials. Attempts to modify these values in transit invalidate the signature immediately, and the request is rejected before it touches our application layer.

Once the signature is verified, the three IDs are concatenated into a composite session key: a unique identifier that anchors every downstream operation to a specific, verified user context. Subsequent processing happens entirely within this isolated session. Sessions do not bleed into one another.

Resilience in practice: session hijacking attempt

The threat: A user intercepts a valid API request and swaps out the Tenant ID with a competitor’s known value, hoping to access their data.

What the system does: The SigV4 signature check fails immediately. The payload has been modified after signing, so the cryptographic signature no longer matches. The request is rejected before it reaches the application layer. Even if the bad actor bypassed this, the composite key validation would catch the mismatch, the Tenant ID, Business ID, and Admin ID must resolve together as a legitimate, pre-registered combination.

Why it fails: The malicious event is dead on arrival. There is no sandbox created, no schema passed to the model, and no query generated. The request is rejected at the authentication layer.

Layer 2: Semantic input validation via the reasoning engine

Once a request has been verified and a session established, the next question is: do we actually understand what the user is asking, well enough to act on it safely?

This is where our reasoning engine on Amazon Bedrock steps in, and it does so before data is touched, before schema is loaded, and before SQL is generated.

The reasoning engine performs a structured validation pass on the user’s question. It checks whether the question maps to a supported, well-defined business metric on our system. If the question is clear and supported, the engine passes it forward. If the question is ambiguous, for example, the user asks for “total sales” when the system distinguishes between sales amount and sales count, the engine stops and asks a clarifying question before proceeding. If the question references a metric the system does not support, the engine responds with the list of supported metrics and asks the user to refine their question.

This layer serves two purposes. The first is quality: it validates that the SQL generator only ever operates on a well-scoped, unambiguous input, which dramatically improves query accuracy. The second is security: by intercepting vague or unsupported inputs before they reach the SQL generation stage, we help prevent a class of failures where an underspecified question leads the model to make assumptions about scope, assumptions that could inadvertently broaden data access beyond what was intended.

A non-deterministic model asked to answer a vague question has more degrees of freedom. A non-deterministic model asked to answer a precise, validated question has far fewer. Layer 2 narrows that space before Layer 3 closes it entirely.

Resilience in practice: vague or out-of-scope question

The threat: A user submits a deliberately vague question: “Show me everything you have on all the businesses.”

What the system does: The reasoning engine evaluates the question against the system’s supported metrics. The question does not map to any supported metric and is far too broad to be safely interpreted. Rather than passing it to the SQL generator, where a non-deterministic model might interpret “everything” in unexpected ways, the engine returns a response asking the user to specify which metric they are interested in, from a defined list.

Why it fails: The question does not reach the SQL generator. There is no opportunity for the model to make a broad or incorrect assumption about scope. The system only moves forward when it has a validated, well-defined question to work with.

Layer 3: Programmatic data isolation via Split-Plane SQL architecture

With a verified identity from Layer 1 and a validated, well-scoped question from Layer 2, the system is now ready to retrieve data. Layer 3 is where the row-level security problem is solved definitively, not through the model, but around it.

Layer 3a — The security layer

When the validated request arrives at this stage, our system uses the composite session key to programmatically generate a set of SQL common table expressions (CTEs). These CTEs query the Databricks data warehouse and pre-filter the underlying tables to include only the rows the authenticated user is permitted to see: scoped by their Tenant ID, Business ID, and the specific locations their Admin ID is authorized to access.

To make this concrete: a brand manager’s CTE is built to include the 200 locations in their business. A franchise owner’s CTE is built to include only the two locations they operate. Both users are querying the same underlying Databricks tables, but the authorized window into that data is completely different for each of them, and that window is defined entirely by the server-side validated identity payload, not by anything the user typed or anything the model decided.

This filtering is applied before the model is invoked. No user input influences it. No LLM output influences it. It is a deterministic, programmatic operation that produces a temporary, in-memory data sandbox containing exactly the data this user is allowed to see, nothing more.

CTE generated without LLM:

WITH accessible_locations AS (

-- Admin 7042 maps to just 2 locations under this tenant

SELECT DISTINCT location_id