読み取り専用だけでは不十分：AIエージェントのためのガードレール
シニアエンジニアは、AIエージェントの安全性を確保するために、よくある一つの助言をします。それは「読み取り専用のアクセス権を与えること」です。
それは安全に聞こえます。エージェントは、何も壊すことなく、低速なクエリの調査やスキーマの要約を行うことができます。
しかし、読み取り専用は安全モデルではありません。それは単なる制限です。
エージェントが有用な作業を行う必要が生じた瞬間、読み取り専用がその動きを止めます。もしエージェントが不適切なインデックスや破損した行を見つけたとしても、それを修正することはできません。結局、火事を指差すことはできても、ホースを手に取ることができないアシスタントになってしまうのです。
チームはしばしば諦めて、エージェントに書き込み権限を与えてしまいます。本当の危険が始まるのは、その時です。
真の問題は「エージェントが書き込むべきか」ではありません。真の問題は「それらの書き込みをどのように統制（ガバナンス）するか」です。
指示によって書き込みを統制しようとしないでください。システムプロンプトに「テーブルをドロップしてはいけない」といったルールを書き込まないでください。
プロンプトインジェクションによって、これらのルールは無効化されます。攻撃者はデータの一行やコメントを利用して、エージェントにルールを無視させるよう仕向けることができます。ガードレールがエージェントと同じウィンドウ内に存在する場合、エージェントは論理を組み立ててそのルールを回避できてしまいます。
「統制されていない書き込み」と「仲介された書き込み」を区別する必要があります。
• 統制されていない書き込み：エージェントがコマンドの実行を決定し、データベースがそれを実行します。唯一の制御手段は、エージェント自身の判断のみです。 • 仲介された書き込み：コマンドがエージェントの外部にあるチェックポイントを通過します。このチェックポイントは、エージェントとデータベースの間のデータパスに位置します。
仲介された書き込みは、次のように機能します：
- エージェントがステートメントを提案します。
- プロキシまたはコントロールプレーンがそのステートメントを解析します。
- プロキシがリスクを分類します。
- プロキシが、それを許可するか、あるいは人間に承認を求めるかを決定します。
このアプローチは、プロンプトインジェクションからあなたを守ります。悪意のある指示によってエージェントが DROP TABLE コマンドを書き込むよう騙されることはあっても、プロキシを騙すことはできません。プロキシはエージェントの意図を読み取るのではなく、実際のSQLコマンドのみを確認するからです。
安全を確保するために、この構造を採用してください：
- 安全な読み取りは自動許可する。作業を迅速に進めるため、エージェントが自由に
SELECTクエリを実行できるようにします。 - リスクのある書き込みを制限する。
DELETE、UPDATE、またはスキーマの変更には人間の承認を必須にします。 - すべてをログに記録する。誰が変更を提案し、誰がそれを承認したかについて、不変の記録を保持します。
安全性のためにリードレプリカに頼らないでください。レプリカは調査には役立ちますが、修正を適用することはできません。本番環境の問題を解決するには、プライマリデータベースに書き込む必要があります。
仲介（Mediation）によって、データを安全に保ちながら、エージェントに有用な役割を果たさせることができます。
Optional learning community: https://t.me/GyaanSetuAi