コンテンツにスキップ
ファウンダー価格 — 早期顧客向けに固定今すぐ始める →

AIエージェントのマルチテナンシー：クレデンシャル分離、ネームスペース分離、SOC 2

AIエージェントのマルチテナンシーとは、エージェントプラットフォームの建築的特性であり、各テナントのクレデンシャル、メモリ、実行コンテキスト、監査記録を他のすべてのテナントから分離するものです。これは開発者の慣例やエージェントの指示追従ではなく、インフラストラクチャ層で適用されます。Webアプリのマルチテナンシーとは異なり、エージェントはライブAPIキーを保持し、リクエスト間で永続的なメモリを蓄積し、認証されたツール呼び出しを実行します。これらはデータ行の分離を超えた3つの次元であり、OWASP LLM06とSOC 2 CC6.1を満たすためにテナントごとに分割する必要があります。

AIエージェントのマルチテナンシーとは、エージェントプラットフォームの建築的特性であり、異なるテナントを提供するエージェントが互いのクレデンシャル、メモリ、実行コンテキスト、監査記録にアクセスできないことを保証するものです。これはテナント別クレデンシャルVaultスコープ、ブラックボードネームスペースACL、コンテナ化された実行分離、分割された監査ログにより、インフラストラクチャ層で適用されます。これにより、プラットフォーム上に構築されたB2B SaaS製品は、テナント分離を開発者の責任ではなく構造的保証として継承できます。

エージェントのマルチテナンシーがWebアプリより難しい理由

従来のWebアプリのマルチテナンシーは1つのことを分離します：データ行です。tenant_id列を追加し、すべてのクエリをフィルタリングすれば完了です。エージェントのマルチテナンシーは、Webアプリが対処する必要がなかった3つの追加次元を分離する必要があります。これらのいずれかの失敗は、OWASP LLM06 Sensitive Information Disclosureの下でテナント間のデータ漏洩イベントを構成します。

Webアプリが持っていなかった3つの分離次元

クレデンシャル分離：Webアプリはセッショントークンでユーザーを識別します。セッションは外部サービスへの永続的なアクセスを持ちません。エージェントにはテナントにスコープされた実際のAPIキーが必要です。テナントAのエージェントとテナントBのエージェントが1つのOpenAIキーを共有する場合、テナントAの大量使用がテナントBのレート制限余裕を低下させます。テナントAの請求にテナントBのトークン消費が含まれます。テナントAの侵害後にキーを失効させると、テナントBも中断されます。SOC 2 CC6.1の論理アクセス要件に違反します。

メモリ分離：エージェントは作業メモリ（コンテキストウィンドウ）、セマンティックメモリ（ベクトルストアの埋め込み）、調整状態（ブラックボードエントリ）をインタラクション間で蓄積します。これらのメモリストアのいずれかがテナントごとに分割されていない場合、あるタスク中にエージェントコンテキストに取得されたテナントAのドキュメントが、意味的に類似したタスク中にテナントBのエージェントコンテキストに現れる可能性があります。これがOWASP LLM06 v1.1のテナント間漏洩の典型的なシナリオです。

監査ログ分離：テナントAとテナントBのツール呼び出しが混在した共有監査ログは、テナントBの記録を公開せずにテナントAのコンプライアンスチームにエクスポートできません。SOC 2 CC6.1は各テナントの監査者が自分の記録のみを閲覧できることを要求します。

Shared-Nothing vs Pool vs Bridge：3つのマルチテナンシーモデル

サイロモデル（Shared-Nothing）：各テナントは完全に専用のインフラストラクチャを持ちます。テナントあたりのコストが最も高い最大分離。厳格なデータ居住要件を持つエンタープライズテナント、規制業界に適しています。

プールモデル：すべてのテナントがインフラストラクチャを共有し、tenant_idパラメータフィルタリングによるアプリケーション層でのみ分離が適用されます。最低コスト、最弱分離。

ブリッジモデル：コントロールプレーンで分離が適用された共有コンピューティングインフラストラクチャ。各テナントはインフラストラクチャACLによって適用された専用クレデンシャルVaultスコープとメモリネームスペースを取得します。これがB2B SaaSの推奨デフォルトです。OpenLegionのプロジェクトスコープ型アーキテクチャはブリッジモデルの実装です。

OWASP LLM06：テナント間の機密情報開示

OWASP LLM Top 10 v1.1はテナント間データ漏洩をLLM06: Sensitive Information Disclosureとして高い深刻度で分類しています。

テナント間漏洩の攻撃ベクター

  1. テナントAのエージェントがカスタマーサポートリクエストを処理します。テナントAの内部製品ドキュメントと顧客記録をコンテキストウィンドウに取得し、関連する段落を共有ベクトルストアに埋め込み保存します。
  2. テナントBのエージェントが意味的に類似したリクエストを処理します。共有ベクトルストアをクエリすると、テナント分割インデックスがないためテナントAの埋め込み段落がTop-K最近傍として返されます。
  3. テナントAの内部顧客記録がテナントBのエージェントコンテキストに現れます。

敵対的な入力は不要です。漏洩はアーキテクチャの失敗です。

プロンプトインジェクション（LLM01）を含む完全なフレームワークについてはAIエージェントセキュリティとOWASP LLM Top 10脅威モデルを参照してください。

メモリ漏洩：作業メモリ、ベクトルストア、ブラックボード状態

3つのエージェントメモリタイプにはそれぞれ個別のテナント分離処理が必要です：

作業メモリ（コンテキストウィンドウ）：エージェントの現在のコンテキストウィンドウをテナントリクエスト間で共有してはなりません。

セマンティックメモリ（ベクトルストア）：共有ベクトルストアを使用する場合、すべての書き込みにtenant_idを必須メタデータフィールドとして含める必要があり、すべてのクエリにストレージクライアント層で注入されるメタデータフィルター{tenant_id: current_tenant_id}を含める必要があります。

調整状態（ブラックボード）：エージェント間で共有されるキーバリュー状態は、テナントスコープのキープレフィックスを使用する必要があります。例：projects/{tenant_id}/*。

クレデンシャル分離：テナント別Vaultスコーピング

テナント別クレデンシャルスコーピング：共有APIキーが失敗する理由

最も一般的なマルチテナンシークレデンシャルの誤りは、すべてのテナントに1つのLLM APIキーを使用することです。これは4つの異なる方法で失敗します：レート制限共有、コスト帰属不能、失効の爆発半径、監査分離の破壊。

正しいパターン：各テナントは自分のAPIキーを取得します。完全なVaultアーキテクチャについてはクレデンシャル管理とテナント別Vaultスコーピングパターンを参照してください。

JWTアンチパターン：失効なしのトークンスコープ

3つの軽減策が必要です（すべて同時に必要）：

  1. 短命トークン：エージェントツール呼び出しトークンのTTLを300秒（5分）以下に。
  2. アクティブ失効レジストリ：テナントごとの有効なトークンIDのテーブル。
  3. タスク別トークンローテーション：各エージェントタスクに新しいトークンを発行。

実行分離：KubernetesネームスペースとリソースクォータURL

テナント別ネームスペース：RBAC、NetworkPolicy、ResourceQuota

4つのコンポーネントが必要です：

テナント別ネームスペース：各テナントのエージェントポッドは専用のKubernetesネームスペースで実行されます。

ネームスペーススコープのServiceAccountsを持つRBAC：各テナントは自分のネームスペースにスコープされたRoleBindingsを持つ専用のServiceAccountを取得します。

デフォルト拒否のNetworkPolicy：デフォルトですべてのテナントネームスペースにすべてのイングレスとエグレスを拒否するポリシーを適用。

LimitRangeを持つResourceQuota：ResourceQuotaによるネームスペース別のCPU、メモリ、ポッド数の制限。

プロセスレベルのサンドボックスコントロールについてはAIエージェントサンドボックスとプロセスレベルの実行分離を参照してください。

マルチテナントエージェントプラットフォームのSOC 2コンプライアンス

CC6.1：データ分類別論理アクセスコントロール

CC6.1コンプライアンスには3つの具体的なコントロールが必要です：テナント別クレデンシャルVaultスコープ、テナント別メモリネームスペース、テナント別監査ログパーティション。

SOC 2監査者はテナント間で使用される共有APIキーをCC6.1の欠陥として指摘します。完全なコントロールマッピングについてはAIエージェントガバナンスとSOC 2コンプライアンスフレームワークを参照してください。

CC6.6：昇格権限エージェントへの特権アクセス制限

CC6.6コンプライアンスには以下が必要です：テナント間の昇格権限エージェント呼び出しの構造的防止、監査可能な特権エージェント権限定義、特権アクションの呼び出し別監査記録。

テナント別監査ログパーティショニング

ストレージキーパターン：audit/{tenant_id}/{year}/{month}/{day}/{agent_id}/{tool_call_id}.json

テナント別S3バケットポリシー：テナント別に独立したバケットプレフィックスとリソースポリシー。

OTLPリソース属性：各OpenTelemetryログレコードにtenant_idをリソース属性として含める。

テナント別SIEMワークスペース：共有SIEMデプロイメントではテナント別インデックスまたはワークスペースを設定。

完全な監査ログ設計についてはAIエージェント監査ログとテナント別コンプライアンス記録を参照してください。

アンチパターン：やってはいけないこと

アンチパターン1：インフラストラクチャではなくエージェントプロンプトにテナントID

エージェントのシステムプロンプトにtenant_idを注入し、エージェントが自分のテナント境界を適用することに依存することは、最も一般的で最も危険なマルチテナンシーアンチパターンです。プロンプトインジェクションバイパス、幻覚ドリフト、インフラストラクチャ適用なしで失敗します。

アンチパターン2：テナントフィルターなしの共有ベクトルストア

これはOWASP LLM06の主要な漏洩ベクターです。修正には各書き込みに必須メタデータフィールドtenant_idと各クエリでストレージクライアント層で注入されるメタデータフィルターが必要です。

アンチパターン3：プロンプトにテナントクレームがある共有LLM APIキー

このアンチパターンはCC6.1で失敗します：レート制限共有、コスト帰属失敗、失効の爆発半径、テナント別に分割できないプロバイダー監査記録。

OpenLegionの見解：慣例ではなくアーキテクチャによる分離

OpenLegionはエージェントコードがバイパスできない3つのインフラストラクチャ層メカニズムでテナント分離を適用します：プロジェクト別クレデンシャルVaultスコーピング、ブラックボードネームスペースACL、デフォルトでブロックされたクロスプロジェクトエージェントメッセージング。

分離コントロールOpenLegionLangChain / LangGraphCrewAIAutoGenOpenAI Agents SDK
テナント別クレデンシャルVaultスコープインフラストラクチャ適用開発者慣例開発者慣例開発者慣例開発者慣例
ブラックボードネームスペースACLインフラストラクチャ適用利用不可利用不可利用不可利用不可
クロスプロジェクトエージェントメッセージングブロックデフォルトブロック利用不可利用不可利用不可利用不可
テナント別予算上限（Zone 2）インフラストラクチャ適用開発者慣例開発者慣例開発者慣例開発者慣例
テナント別監査パーティション（WORM）インフラストラクチャ適用開発者慣例開発者慣例開発者慣例開発者慣例
Kubernetesネームスペース + ResourceQuotaプラットフォーム管理セルフ管理セルフ管理セルフ管理セルフ管理

ホスト型インフラストラクチャ層についてはテナント分離保証を持つマネージドAIエージェントプラットフォームを参照してください。

よくある質問

AIエージェントのマルチテナンシーとは何ですか？

AIエージェントのマルチテナンシーとは、エージェントプラットフォームの建築的特性であり、異なるテナントを提供するエージェントが互いのクレデンシャル、メモリ、実行コンテキスト、監査記録にアクセスできないことを保証するものです。これは開発者の慣例ではなくインフラストラクチャ層で適用されます。従来のWebアプリのマルチテナンシーとは、テナント別クレデンシャルVaultスコーピング、テナント別メモリ分割（ベクトルストアとブラックボード）、テナント別監査ログ分割という3つの追加の分離次元を必要とする点で異なります。

OWASP LLM06とは何で、マルチテナントエージェントシステムにどう影響しますか？

OWASP LLM Top 10 v1.1 LLM06 Sensitive Information Disclosureはテナント間データ漏洩を高い深刻度として分類しています。これはエージェントがテナントAのデータを処理し、テナント分割なしで共有メモリ層に取得したドキュメントを保存し、その後テナントBの応答に表示するシナリオです。攻撃に敵対的な入力は不要です。軽減にはストレージクライアント層でのテナント別メモリ分割、テナント別クレデンシャルスコーピング、テナント別監査ログパーティションが必要です。

SOC 2 CC6.1とCC6.6はマルチテナントエージェントプラットフォームにどのように適用されますか？

SOC 2 Type II CC6.1はデータ分類に基づいて論理アクセスを制限することを要求します。マルチテナントエージェントシステムでは、テナント境界が主要な分類境界です。CC6.6はデータベース書き込みや外部API呼び出しなどの昇格ツール権限を持つエージェントに適用されます。テナント間で使用される共有APIキーは通常CC6.1の欠陥として指摘されます。

マルチテナントエージェントシステムにおけるJWTトークンTTLの脆弱性とは何ですか？

エージェントツール呼び出しのテナントコンテキストに使用されるJWTアクセストークンは通常3,600秒（1時間）後に期限切れになります。テナントAに発行されたトークンが不正にキャッシュされたり、インフラストラクチャのバグで共有されたり、デバッグログに記録されたりした場合、TTL期間全体にわたってテナントAに帰属する認証済み呼び出しに使用される可能性があります。軽減には3つのコントロールが必要です：TTL 300秒以下の短命トークン、アクティブなテナント別トークン失効レジストリ、タスク別トークンローテーション。

マルチテナントエージェントのKubernetesネームスペース分離はどのように機能しますか？

Kubernetesネームスペース分離は4つのコンポーネントによる実行分離を提供します：テナント別専用ネームスペース、テナント別ServiceAccountsとネームスペーススコープのRoleBindingsを持つRBAC、デフォルト拒否と必要な外部エンドポイントのみの明示的許可リストを持つNetworkPolicy、ネームスペース別コンピューティング制限を持つResourceQuota。ネームスペース分離はマルチテナンシーのコンピューティング次元を解決し、テナント別クレデンシャルスコーピングとメモリ分割と組み合わせる必要があります。

マルチテナントエージェントシステムにおける共有ベクトルストアのアンチパターンとは何ですか？

ストレージクライアント層で注入されるクエリ別テナントフィルターなしで共有ベクトルストアを使用することは、OWASP LLM06の主要な漏洩ベクターです。正しい実装には各書き込みにtenant_idメタデータフィールドと各クエリでベクトルストアクライアント層で注入されるメタデータフィルターが必要です。厳格なコンプライアンス要件にはテナント別ネームスペースまたは独立したインデックスがストレージアドレス層での境界を適用します。

OpenLegionはどのようにテナント分離を適用しますか？

OpenLegionは3つのインフラストラクチャ層メカニズムでテナント分離を適用します：プロジェクト別クレデンシャルVaultスコーピング（Zone 2はエージェント提供パラメータではなくメッシュセッションの認証されたプロジェクトコンテキストを使用して$CRED{}ハンドルを解決します；クロスプロジェクトクレデンシャル解決はアーキテクチャ的に不可能です）、ブラックボードネームスペースACL（エージェントはメッシュスーパーバイザーによって適用されるプロジェクトのキープレフィックスに対してのみ読み書き権限を持ちます）、デフォルトでブロックされたクロスプロジェクトエージェントメッセージング。

エージェントプラットフォームの3つのマルチテナンシーアーキテクチャモデルは何ですか？

3つのマルチテナンシーモデルはそれぞれ異なる分離保証とコストプロファイルを持ちます：サイロモデル（Shared-Nothing）は各テナントに完全に専用のインフラストラクチャを提供します。プールモデルはすべてのインフラストラクチャを共有し、アプリケーション層でのみ分離を適用します。ブリッジモデルはコンピューティングインフラストラクチャを共有しながら、テナント別クレデンシャルVaultスコープとメモリネームスペースACLによりコントロールプレーンで分離を適用します。ブリッジモデルはB2B SaaSの推奨デフォルトです。