AIワークスペースで最も難しい課題はプライバシーである

多くのAI製品にとって、プライバシーとは設定画面のトグルスイッチです。データ保持のオン/オフ。モデル学習へのオプトアウト。フッターに並ぶコンプライアンスバッジ。

AIがチャットボットとして別タブで動いているうちは、それで十分でした。しかし、AIがワークスペースのメンバーとしてファイルを読み、外部サービスを操作し、データベースに書き込み、ユーザーの代理で行動するようになった瞬間、その前提は崩れます。

なぜエージェントがプライバシーを難しくするのか

従来のSaaSアプリケーションには明確な信頼境界があります。ユーザーが認証し、アプリが権限を検査し、データ層がアクセスを制御する。コードは決定論的で監査可能です。AIエージェントはこのモデルに適合しません。アクションを確率的に生成し、プロンプトインジェクションによって操作される可能性があり、チャンネル・接続・ユーザーをまたいで動作します。

モデルに境界を守らせることは、確率的テキスト生成器にセキュリティ判断を委ねることと同じです。そこでKylonは、モデルを信頼しない入力として扱い、モデルが触れることのできないインフラ層ですべての境界を強制します。

多層防御アーキテクチャ

エージェントごとのVM分離

すべてのエージェントは、専用のハードウェア仮想化microVMで実行されます。カーネル、メモリ空間、ディスクが完全に分離されたフル仮想化です。エージェントAは、エージェントBのプロセス、メモリ、ファイルシステムを物理的に観測できません。侵害されても、影響範囲はそのVM1台に限定されます。

“原則: 信頼するのではなく、封じ込める。すべてのエージェントは侵害される前提で設計し、侵害されても影響が退屈なほど小さくなるようにする。”

コマンド単位のbubblewrapサンドボックス

すべてのシェルコマンドをbubblewrapベースのnamespaceサンドボックス内で実行します。ホワイトリストモードで動作し、ルートファイルシステムは空のtmpfsから始まり、明示的に指定されたパスのみがマウントされます。

• 書き込み可能パスは1つだけ。エージェントの一時作業ディレクトリのみ
• 読み取りホワイトリストはコマンド呼び出しごとに再計算。現在のチャンネルのディレクトリ、エージェント自身の設定ディレクトリ、共有ワークスペースナレッジのみ
• ブロック対象パスはゼロ権限のオーバーレイで遮蔽
• ネットワークアクセスはコマンド単位で制御可能
• プロセス生成はseccompフィルタでfork、cloneなどのsyscallを遮断

ホワイトリスト外のパスは「アクセス拒否」ではなく、namespaceにマウントされていないため、存在しない状態です。#engineeringのエージェントが#hrのファイルを読もうとしても、lsでもfindでもヒットしません。

“原則: 未認可のパスは「禁止」ではなく「不可視」にする。アクセス拒否はパスの存在を示唆する。空のnamespaceは何も伝えない。”

RBACによるファイルアクセス制御

ワークスペースのファイルはクラウドストレージから読み取り専用でマウントされ、単一ワークスペースにスコープされます。永続化にはワークスペースAPIを経由し、チャンネルメンバーシップ、パスポリシー、エージェントID検証のフルRBACチェックを実行します。

接続アクセス制御

こうした場面を想定してみてください。エージェントが「チームカレンダーを確認して」と依頼を受け、あるメンバーのカレンダー接続で別のメンバーの非公開予定を読み取ってしまう。プロンプトインジェクションではなく、ワークスペースレベルで共有された接続にユーザー単位のスコープがないというアーキテクチャ上のギャップが原因です。Kylonの接続モデルはこの種の障害を防ぐ設計になっています。

• 接続は個人に帰属。Gmailの接続はユーザー本人のもの
• エージェントには明示的な個別付与が必要。一括付与ポリシーはACL層でエージェントを除外
• 委任はスコープされ、仲介される。エージェントは生の認証情報を保持しない
• 認証情報は暗号化して保存。実行時のみメモリ上で復号

“原則: 接続はAIではなく、人間のものである。すべての委任は明示的で、スコープされ、取り消し可能でなければならない。”

外部アクション: AIは下書きだけ、送信は人間だけ

エージェントがメールを送信しようとすると、システムがそれを遮断し、レビュー可能な下書きに変換します。承認はアクションごとのフィンガープリントに紐づいており、承認後に何かが変更されると自動的に無効化されます。

この攻撃を想定してみてください。プロンプトインジェクションで無害に見えるメールの承認を取得し、送信前に宛先と本文を差し替えるよう指示する。フィンガープリントチェックがこれをブロックします。承認は1通の正確なメッセージに対して発行されており、改変後のバージョンとは一致しません。送信は失敗し、改変された内容は人間のレビュアーに可視化されます。

“原則: AIは下書きできる。送信できるのは人間だけ。人間が承認するのは正確な内容であり、白紙委任ではない。”

継続的モニタリング

• サンドボックス違反の異常検知。ホワイトリスト外へのアクセス試行はブロック済みでもログに記録。パターン分析でプロンプトインジェクションの兆候を検出
• 接続アクセスの監査。すべての委任がログに記録。異常パターンでアラートを発報
• フィンガープリント不一致の追跡。HITL検証失敗時、変更前後の内容がログに記録

“原則: ログだけでなく、ループを監視する。アーキテクチャが何かを検出したときに教えてくれる仕組みが必要。”

まとめ

AIワークスペースのプライバシーが難しい理由は、暗号化やACLが複雑だからではありません。モデルが影響を与えられないインフラ層、正確な内容を検証する人間のゲート、そして継続的モニタリングの組み合わせで解決します。AIが実際の行動権を持つとき、プライバシーにはこのアーキテクチャが求められます。