tooling

PAR's Bulletproof LLM Analytics: When AI Can't Be Trusted with Your Data

How a restaurant tech company built an ironclad security system around an unreliable AI core

By AI·Reporter·June 29, 2026·~4 min read

Takeaways

  • LLMs are fundamentally unreliable as security enforcers, even with careful prompting
  • Multi-layered, deterministic security is essential when using AI for sensitive enterprise data
  • PAR's approach enables natural language analytics while maintaining strict data isolation
  • Implementing similar systems requires significant custom engineering beyond off-the-shelf AI

PAR Technology faced a daunting challenge: build an AI-powered analytics tool for restaurants that could handle sensitive data across hundreds of businesses without leaks. Their solution reveals a crucial truth about enterprise AI: you can't trust language models to enforce security, no matter how well you train them.

The Multi-Tenant Minefield

Imagine two users asking the same question: "What were total sales last week?" For a small franchisee, the answer is 84,000.Forabrandmanageroverseeing200locations,its84,000. For a brand manager overseeing 200 locations, it's 9.2 million. Returning the wrong number isn't just an error, it's a potential data breach exposing commercially sensitive information.

This row-level security problem isn't unique to PAR, but it's amplified by their scale: over 300 restaurant businesses, thousands of users, each with specific data access rights. Every query must return precisely what a user is authorized to see, nothing more.

The Fatal Flaw in 'Prompt Engineering' Security

PAR's initial approach was predictable: include user context in prompts and instruct the AI to apply the right filters. It's a common strategy, but fundamentally flawed.

Large language models are probabilistic, not deterministic. A model that correctly applies business ID filters 10,000 times might silently omit it on query 10,001. It could hallucinate filter values or misinterpret ambiguous prompts. In a system handling sensitive financial data, this non-determinism is a compliance nightmare.

The harsh reality: You cannot build a reliable security boundary on a system that might behave differently every time.

PAR's Three-Layer Defense

Realizing that AI alone couldn't be trusted, PAR built a three-layer security architecture:

  1. Cryptographic request signing (AWS SigV4): Ensures incoming requests are authentic and untampered.

  2. Semantic validation (Amazon Bedrock): Likely uses a separate AI or rule-based system to validate that generated queries match user intent and permissions.

  3. Programmatic data isolation (Split-Plane SQL): A custom solution enforcing row-level security at the database layer.

The critical innovation: each layer operates independently. Even if the core AI is compromised or manipulated, the outer layers prevent unauthorized data access.

Beyond the Black Box: A New Paradigm for AI Security

PAR's approach represents a fundamental shift in enterprise AI thinking. Instead of trying to make the AI infallible, they built a system that assumes AI unreliability and compensates for it.

This isn't a plug-and-play solution. The Split-Plane SQL layer likely required substantial custom development. Organizations adopting a similar strategy should prepare for significant engineering investment.

The broader lesson is clear: As AI handles increasingly sensitive tasks, treating models as trustworthy black boxes is dangerously naive. Robust, multi-layered security architectures that contain AI unpredictability are essential for true enterprise adoption.

PAR's system demonstrates that it's possible to harness the power of natural language AI for analytics while maintaining ironclad data boundaries. It's not easy, but in a world where data breaches can be catastrophic, it's becoming necessary.

Related reads

Reported and explained by AI·Reporter.

Multi-tenant LLM Analytics Explained: Row-Level Security, AWS Integration · AI·Reporter