# 共有AIメモリのテナント分離 CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-515-ai CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-515-URL-EB4A047DF155, EVD-EA-515-URL-753402E46EED, EVD-EA-515-URL-14A4DFCF1FD2, EA-515-CURRENT-APPROVAL, EA-515-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-515-UNKNOWN-01 OPS_IDS: none ## Summary 共有AIメモリでは、利用者・チーム・顧客の識別子を保存するだけでは分離が成立しません。認証された主体から許可する範囲を決定し、読取、書込、更新、削除、要約、検索、キャッシュ、復元まで同じ範囲を適用する必要があります。検索だけにフィルタを付けても、別の経路で他テナントの記憶が更新・合成されれば分離は破れます。本項は共有メモリの権限伝播と運用検証を扱い、削除はEA-512、訂正収束はEA-514に接続します。 ## Current judgment Qdrantのmultitenancy文書は、共有collectionのtenant fieldへ条件を付けて対象のデータを検索する構成を示します。is_tenantは配置・索引最適化の情報であり、それだけで認証主体に応じた権限判定が成立するとは読み取れません。tiered構成では小さいtenantがshared shardに同居し、大きいtenantをdedicated shardへ分けるため、配置の単位と業務の権限範囲も別です[S1]。 ## Scope 共有AIメモリのテナント分離 ## Confirmed - Qdrantのmultitenancy文書は、共有collectionのtenant fieldへ条件を付けて対象のデータを検索する構成を示します。is_tenantは配置・索引最適化の情報であり、それだけで認証主体に応じた権限判定が成立するとは読み取れません。tiered構成では小さいtenantがshared shardに同居し、大きいtenantをdedicated shardへ分けるため、配置の単位と業務の権限範囲も別です[S1]。 QdrantのSecurity文書が説明するgranular JWTはcollection単位のread/write権限を持ちます。同じcollectionへのアクセス許可を、その中の任意のtenantを読めるという業務上の許可と混同しません[S2]。一方、Weaviateはmulti-tenancyによりtenantごとにデータを分離し、tenantを指定して操作する構成を提供します[S3]。この機構を利用しても、アプリケーションが認証主体に対して誤ったtenantを選択しないことは別に検証する必要があります。 ## UNKNOWN - EA-515-UNKNOWN-01: 各組織のtenant定義、役割、共有規則、全APIと背景job、製品版、JWT構成、backup選択復元、権限撤回の伝播時間、実機負例試験、独立した本番漏えい事故の因果確認は未確認です。旧研究にあった製品CVEは今回再確認していないため、現行版の欠陥として転載していません。 ## Evidence - EVD-EA-515-URL-EB4A047DF155 (RESEARCH): [S1] Qdrant Multitenancy、tenant fieldとtiered構成: — https://qdrant.tech/documentation/manage-data/multitenancy/ - EVD-EA-515-URL-753402E46EED (RESEARCH): [S2] Qdrant Security、Granular Access API Keys / JWT Configuration: — https://qdrant.tech/documentation/security/ - EVD-EA-515-URL-14A4DFCF1FD2 (RESEARCH): [S3] Weaviate Multi-tenancy operations、tenantを指定するデータ操作: — https://docs.weaviate.io/weaviate/manage-collections/multi-tenancy - EA-515-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-515-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits DB側のtenant分離やcollection権限は有効な防御層です。ただし、アプリケーション側の誤ったtenant選択、権限の広い運用者、外部cache、要約の混合までは自動解決しません。逆にcollection共有だけを理由に、適切に制御されたすべての構成を不適合と断定することもできません。リスクに応じてDB・鍵・network・backupの分離単位を選び、実際の経路を検証します。 ## Failure / limits 実行主体やtenantが不明、共通鍵で任意tenantを選択できる、保護されない操作経路がある、派生物の共有範囲が不明な場合は分離完了を宣言しません。 ## PUBLIC_CLAIM 共有AIメモリでは、利用者・チーム・顧客の識別子を保存するだけでは分離が成立しません。認証された主体から許可する範囲を決定し、読取、書込、更新、削除、要約、検索、キャッシュ、復元まで同じ範囲を適用する必要があります。検索だけにフィルタを付けても、別の経路で他テナントの記憶が更新・合成されれば分離は破れます。本項は共有メモリの権限伝播と運用検証を扱い、削除はEA-512、訂正収束はEA-514に接続します。 ## ESTABLISHED Qdrantのmultitenancy文書は、共有collectionのtenant fieldへ条件を付けて対象のデータを検索する構成を示します。is_tenantは配置・索引最適化の情報であり、それだけで認証主体に応じた権限判定が成立するとは読み取れません。tiered構成では小さいtenantがshared shardに同居し、大きいtenantをdedicated shardへ分けるため、配置の単位と業務の権限範囲も別です[S1]。 QdrantのSecurity文書が説明するgranular JWTはcollection単位のread/write権限を持ちます。同じcollectionへのアクセス許可を、その中の任意のtenantを読めるという業務上の許可と混同しません[S2]。一方、Weaviateはmulti-tenancyによりtenantごとにデータを分離し、tenantを指定して操作する構成を提供します[S3]。この機構を利用しても、アプリケーションが認証主体に対して誤ったtenantを選択しないことは別に検証する必要があります。 ## CROSS_STAGE_CONTROLS 以下は製品機能を横断して適用する設計提案です。すべての製品が自動で実装する保証ではありません。 | 経路 | 適用する境界 | 主な失敗 | | --- | --- | --- | | 書込・更新・削除 | 現在の主体、tenant、対象ID、操作権限 | 他tenantのIDを受け付ける、tenant属性を変更できる | | 検索・ID取得 | 許可範囲を必須条件にし、結果の所属も照合 | 検索だけ保護しID取得が無保護 | | 要約・統合 | 全入力の許可と出力の共有範囲を計算 | 複数tenantの入力を一つの要約に混合 | | cache・profile | keyにtenantと許可範囲の版を含める | 同じ質問やuser名を共通keyにする | | export・backup・restore | 保存物全体の範囲と復元権限を確認 | live検索の分離をbackupの分離と誤認 | | job・subagent | 明示した実行主体と限定scopeを引き継ぐ | 背景処理が管理者の広い権限へ戻る | tenantの条件を付ける共通関数があっても、迂回できる管理APIやバッチ経路が残れば十分ではありません。許可範囲のない呼出しを拒否し、対象IDを直接渡す操作にも同じ検査を適用します。共通データを参照する正当な業務は、明示された共有領域として扱い、tenant条件の欠落による暗黙の共有にしません。 ## DERIVED_MEMORY_AND_RESTORE 要約は入力データのコピーを含み得るため、保存先と権限の追跡対象です。出力には元artifact、入力版、入力時の許可scope、生成時刻、適用する共有規則を結び付けます。権限撤回やtenant離脱後は原文だけでなく、関連する要約、profile、cache、評価コピーにも失効判断を及ぼします。データの内容が匿名に見えることだけで他tenantへ移してはいけません。 共有collectionやshared shardのbackupがtenant単位に分割されているとは仮定しません。復元物の対象、復元先、実行主体、旧権限の再導入、削除・訂正義務の再適用を確認してから提供を再開します。checksum一致は保存物の完全性の証拠であり、その保存物を誰が読んでよいかの証拠ではありません。今回、製品別の選択復元機能や復元後の全派生物分離は実機確認していません。 ## VERIFICATION_PROFILE 架空のtenant A/Bを用意し、異なる識別用データを格納します。Aの認証主体による検索、ID取得、書込、更新、削除、要約、cache、exportの各経路でBへ影響しないことを確認します。tenant指定なし、改変された指定、権限撤回直後、背景job、復元後を別の負例にします。許可した共有領域へのアクセスは正例として残し、単に全操作を拒否しているだけの試験にしません。 本RUNでは実DB、実顧客データ、実認証基盤に対する試験を行っていません。上記は検証計画であり、実施結果や認証済みの安全性を意味しません。監査ログはactor、tenant、対象、操作、policy版、判定、結果へ結び付け、機密本文を不用意に複製しないようにします。 ## COUNTEREVIDENCE_AND_LIMITATIONS DB側のtenant分離やcollection権限は有効な防御層です。ただし、アプリケーション側の誤ったtenant選択、権限の広い運用者、外部cache、要約の混合までは自動解決しません。逆にcollection共有だけを理由に、適切に制御されたすべての構成を不適合と断定することもできません。リスクに応じてDB・鍵・network・backupの分離単位を選び、実際の経路を検証します。 ## OPEN_UNKNOWN 各組織のtenant定義、役割、共有規則、全APIと背景job、製品版、JWT構成、backup選択復元、権限撤回の伝播時間、実機負例試験、独立した本番漏えい事故の因果確認は未確認です。旧研究にあった製品CVEは今回再確認していないため、現行版の欠陥として転載していません。 ## SAFE_WORDING 「指定した主体・tenant・操作経路について、権限と保存範囲を検証した」とします。「tenant_idがあるため安全」「検索フィルタがあるため完全分離」は使用しません。 ## 運用上の停止・確認条件 実行主体やtenantが不明、共通鍵で任意tenantを選択できる、保護されない操作経路がある、派生物の共有範囲が不明な場合は分離完了を宣言しません。 ## SOURCES_AND_PROVENANCE 既存EA-515-R1-20261012および継続Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewUのEA-515節を継承。2026-10-18に下記一次資料を確認。製品仕様、そこからの推論、提案制御、未実施試験を分離しました。 - [S1] Qdrant Multitenancy、tenant fieldとtiered構成: https://qdrant.tech/documentation/manage-data/multitenancy/ - [S2] Qdrant Security、Granular Access API Keys / JWT Configuration: https://qdrant.tech/documentation/security/ - [S3] Weaviate Multi-tenancy operations、tenantを指定するデータ操作: https://docs.weaviate.io/weaviate/manage-collections/multi-tenancy NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.