LLM（大規模言語モデル）を使ったAIエージェントに、複数のシステムを横断した操作を任せる設計を検討している開発者やアーキテクトに向けた内容です。エージェントが「本来やってはいけない操作」を実行しようとしたとき、実際に何がそれを止めるのかを整理します。
AIエージェントとは、LLMを使って計画・判断・実行を自律的に行うソフトウェアの仕組みです。人間が一手ごとに承認するチャットボットとは違い、複数ステップの操作を人の介入なしに完結させます。この自律性こそが企業にとっての価値ですが、同時に新しいリスクの入り口にもなります。
何が起きるか：権限のすり抜けという事象
エージェントが本番環境で動くとき、想定していない操作を実行してしまうケースがあります。
たとえば、顧客対応エージェントに「注文状況の確認」権限だけを与えたつもりが、connected toolやAPI経由で在庫データベースの更新まで実行できてしまう、といった構成です。
この問題が厄介なのは、エージェント自体のロジックは正しく動いていることです。プロンプトの指示通りに動き、ツールを正しく呼び出しています。問題は「呼び出せてしまうツールの範囲」がアプリケーション層で管理しきれていない点にあります。
影響範囲は単一のバグとは異なります。エージェントは複数システムをまたいで動くため、一つの権限設計ミスが、顧客データベース・決済システム・社内ドキュメントなど複数箇所に波及する可能性があります。
なぜ起きるか：権限管理をアプリ層に置いてしまう構造
従来型のWebアプリケーションでは、認可（authorization、何をしてよいかの判定）はアプリケーションコードやミドルウェアに書かれてきました。ログイン画面の裏でロール（役割）ごとにボタンの表示・非表示を切り替える、といったやり方です。
この設計は、人間がUIを操作する前提では機能します。人間はボタンがなければ押せません。
ところがAIエージェントは、UIを介さずAPIやツール呼び出しを直接組み立てます。プロンプトインジェクション（悪意ある入力でLLMの指示を書き換える攻撃）や、意図しない推論の結果、アプリ層のガード条件をすり抜けるルートを見つけてしまうことがあります。
さらに根本的な問題として、複数のエージェントやマイクロサービスが同じデータに触れる構成では、認可ロジックがアプリごとにバラバラに実装されます。あるサービスではチェックしていた条件を、別のサービスでは実装し忘れる、という状態が生まれやすくなります。
この構造的な弱点への対応として注目されているのが、認可のロジックを「データ層」に移す考え方です。データベースやデータアクセスの経路そのものに、行レベル・列レベルのアクセス制御を組み込み、どのアプリケーションやエージェント経由でアクセスしても同じルールが適用されるようにする設計です。PostgreSQL（オープンソースのリレーショナルデータベース）で言えば、Row Level Security（行単位のアクセス制御機能）はこの考え方に近い実装の一つです。
自分のプロジェクトが該当するか確認する
以下の観点で、現在の構成を棚卸ししてみてください。
- エージェントやLLMが呼び出すツール・API・DB接続の一覧を、コードベース全体から洗い出せるか
- 認可判定が「アプリケーションのif文」だけで完結していないか（DB側にも同等のガードがあるか）
- 同じデータベースに複数のサービス・エージェントが接続する構成になっていないか
- LLMへの入力（外部ドキュメント・ユーザー入力）がツール呼び出しの引数に直接反映される経路がないか
コードベースでの確認方法として、まずエージェントフレームワーク（LangChain・LlamaIndex・独自実装など）のツール定義を検索します。
grep -rn "def.*tool\|@tool\|Tool(" ./srcこれで洗い出したツール関数それぞれについて、「引数として渡ってくる値がどこまで信頼できるか」「実行結果としてどのテーブル・カラムに書き込みうるか」を一つずつ確認します。数が多い場合は、ツール一覧をスプレッドシートに書き出し、対象テーブル・必要権限・現在のチェック方式を列にして棚卸しすると抜け漏れが見えやすくなります。
データベース側では、PostgreSQLならRow Level Securityが有効になっているか確認できます。
SELECT relname, relrowsecurity FROM pg_class WHERE relkind = 'r';relrowsecurity が f（false）のテーブルは、行レベルの制御がかかっておらず、アプリ層の判定だけに依存している状態です。
対策の手順
1. まずエージェントが到達しうる全ツール・全APIエンドポイントの棚卸しを完了させます。ここが漏れていると、以降の対策も穴だらけになります。
2. 各データベーステーブルについて、行レベル・列レベルのアクセス制御を検討します。PostgreSQLならRow Level Securityでポリシーを定義し、「どのロールがどの行に触れるか」をDB側で強制します。
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY agent_read_only ON orders
FOR SELECT USING (agent_role() = 'support_readonly');3. エージェントに付与するDB接続やAPIキーは、最小権限（least privilege）の原則で発行し直します。読み取り専用が十分な業務には、書き込み権限を持つ接続を使い回さないことが基本です。
4. プロンプトインジェクション対策として、外部入力（Web検索結果・アップロードされたドキュメントなど）とシステム指示を明確に分離し、ツール呼び出しの引数バリデーションを別レイヤーで行います。エージェントの出力をそのままSQLやシェルコマンドに埋め込む実装は避けます。
5. 監査ログをアプリ層とデータ層の両方で取得し、「誰が・どのエージェント経由で・何にアクセスしたか」を後から追跡できるようにします。異常なアクセスパターンの検知にも使えます。
まとめ
AIエージェントの自律性が高まるほど、認可ロジックをアプリケーションコードだけに頼る設計はリスクが大きくなります。
手を動かす第一歩としては、エージェントが呼び出せるツール・API・DB接続を一覧化するところから始めてみてください。
そのうえで、PostgreSQLのRow Level Securityのような仕組みを使い、データそのものにアクセス制御を持たせる方向へ段階的に移行することが、エージェント経由の想定外操作を防ぐ現実的な選択肢になります。
棚卸しと権限の見直しは地味な作業ですが、本番でエージェントを動かす前に一度は通しておきたい工程です。