AWS: 行レベルセキュリティとSplit-Plane SQLの暗号化データ境界を持つマルチテナントAIエージェント

PAR Technology — レストランチェーン管理のSaaS企業 — は共有システム上で300以上のレストランブランド向けのAI分析エージェントを構築しました。要件は決定論的です：フランチャイズオーナーは自分の売上データのみを見ます（例：2店舗で84,000ドル）、ブランドマネージャーは全国合計（920万ドル）を見ます — 同一のクエリ、同一のデータベース、まったく異なる結果。AWS ML Blogはこのシステムのアーキテクチャをコンセプト実証ではなくプロダクションソリューションとして説明しています。

3層の保護：署名から暗号化境界まで

マルチテナント（複数テナント）環境とは、複数のクライアントが同じデータベースインフラを共有することを意味します。行レベルセキュリティ（ユーザーに基づいてデータベースの行をフィルタリングするメカニズム）はLLMエージェントでは古典的にプロンプト命令によって実装されてきましたが、このアプローチはモデルによって無視されたりプロンプトインジェクション攻撃によって回避されたりする可能性があります。

AWSアーキテクチャは3つの決定論的な層を導入しています。第1層はAWS Signature Version 4（SigV4）を使用します：各APIコールにTenant ID、Business ID、Admin IDを紐づける暗号署名で、ペイロードの変更があれば直ちに署名が無効になります。第2層はAmazon BedrockをセマンティックバリデーターとしてSQLジェネレーターに到達する前にユーザーの質問が明確でサポートされているかを確認します；「すべて見せて」のような不特定のリクエストは拒否されます。第3層がSplit-Plane SQLです。

Split-Plane SQLとは何か、なぜプロンプト保護では不十分なのか？

Split-Plane SQL（SQL生成の二重プラン）はクエリ生成を2つの独立したフローに分割します。セキュリティフローはデータベーステーブルを認可された行のみに事前フィルタリングするSQL Common Table Expressions（CTE）を生成します。その後のみ、Amazon Bedrockはそれらの一時的でフィルタリングされたビューのスキーマを受け取ります — 基礎となるテーブルのスキーマではありません。LLMは生成されたSQLの内容に関わらず、物理的にサンドボックス外のデータを参照することができません。古典的なアプローチとの違いは構造的です：プロンプト命令はモデルに何ができるかを伝えますが、Split-Plane SQLはその境界をアーキテクチャのレベルで暗号的に強制します。

PAR Technology：クロステナント公開インシデントなしに50,000クエリ

プロダクション実装はクライアント間のデータ漏洩インシデントなしに50,000以上のクエリを処理しました。インフラにはネットワーク分離を持つDatabricksクラスター、TLS 1.3、自動キーローテーションを持つAWS KMS暗号化、および異常検出を持つCloudTrail監査ログが含まれています。AWSはアーキテクチャの基本原則を次のように要約しています：「LLMはアーキテクチャの上ではなく、中に座る。」