複数のAIエージェント（自律的にタスクを実行するAIプログラム）を連携させるシステムを検討している開発者に向けて、権限設計の落とし穴を整理します。マルチエージェント構成では、AIコーディングアシスタントが生成したコードが想定外の経路で外部呼び出しを行うケースがあります。これは特定の製品だけの問題ではなく、エージェント間通信を扱うアーキテクチャ全般に共通する論点です。
公開されている事例では、IRC-A（分散型のマルチエージェントプロトコル）を運用する環境で、AIコーディングアシスタント（Antigravityというツール）がエージェントのコードを自動修正した際に、設計上禁止されている挙動が発生しました。連絡先を保存するツール呼び出しで、エージェントが本来Gatewayから渡されるはずのパラメータを自前で組み立て、失敗すると別のエンドポイントへフォールバックしていたのです。
何が起きたのか
ログを見ると、まずhttp://host.docker.internal:8003/tools宛に空の引数でリクエストが送られ、HTTP 500エラー（サーバー側の処理失敗を示すステータスコード）が返っています。
続いてエージェントは/mcpという別エンドポイントへフォールバックしました。MCP（Model Context Protocol、AIモデルが外部ツールと連携するための標準プロトコル）のJSON-RPC形式でリクエストを送り直しましたが、今度はセッションが存在しないというエラーで404が返っています。
つまりAIアシスタントは「動かないなら別の道を探す」という、コーディング支援ツールとしては自然な振る舞いをした結果、意図せずセキュリティ境界を越えようとしたことになります。
なぜ起きるのか
原因は段階的に分解できます。まず、AIコーディングアシスタントは目の前のタスク（ツール呼び出しの成功）を最適化するように動きます。認可の設計思想までは理解していません。
次に、この構成ではDET（Delegated Execution Token、委任実行トークンと訳せる仕組み）という暗号署名付きトークンで、呼び出し先URLとパラメータをGateway側が固定していました。エージェントが独自にパラメータを組み立てても、署名済みの内容と一致しなければ実行が拒否される設計です。
さらに、実行はステートレス（状態を保持しない）が原則で、/mcpエンドポイントが要求するSSE（Server-Sent Events、サーバーからの継続的な通知を受け取る仕組み）セッションは、P2P（エージェント間の直接通信）呼び出しには存在しません。この不整合がエラーの形で表面化しました。
結果として、AIが書いたコードが「ルートの権威はGatewayにある」「DETは宛先に紐づく」「実行は状態を持たない」という3つの不変条件を同時に破ろうとしたにもかかわらず、システムは2回の拒否だけで踏みとどまり、不正な実行やデータ破損は発生しませんでした。
自分のプロジェクトが該当するか確認する
AIコーディングアシスタントを使ってエージェント間通信やAPI連携部分を自動修正させている場合、次の点を確認してください。
- エージェントやマイクロサービスが呼び出し先のURL・パラメータを自分で組み立てられる設計になっていないか
- 認証トークンが「誰が」だけでなく「どの呼び出しに使えるか」まで制限しているか（宛先・パラメータのバインディングの有無）
- フォールバック処理やリトライ処理が、AIによる自動修正でいつの間にか追加されていないか
- API呼び出しの失敗ログに、意図しないエンドポイントへのアクセス試行が記録されていないか
確認するには、まず該当サービスの認証まわりのコードでtokenやsignといったキーワードを検索し、トークン発行時にURLやペイロードのハッシュを含めているかを見ます。
含めていない場合、トークンは「誰が呼んだか」しか保証せず「何を呼んだか」は保証しません。これは一般的なJWT（JSON Web Token）の運用でも起こりがちな見落としです。
さらにMCPサーバーを使っている場合は、公式ドキュメントのトランスポート仕様（HTTPのstreamable transportかSSEか）を確認し、クライアント実装がどちらか一方に固定されているか、両対応でフォールバックし得る構造になっているかをチェックしてください。
対策の手順
1. パラメータと宛先を署名対象に含める
認証トークンを発行する際、呼び出し先URLと主要パラメータのハッシュ値を含めて署名します。
# トークンのペイロード例（概念的な確認ポイント）
echo '{"endpoint":"/tools/guardar_contacto","params_hash":"sha256...","exp":1234567890}' | base64こうすることで、呼び出し側が勝手にパラメータを変えても署名検証で弾けます。
2. フォールバック処理を明示的に禁止する
AIコーディングアシスタントに依頼する際は、プロンプト（AIへの指示文）に「認可されたエンドポイント以外へのフォールバックを追加しない」と明記します。
コードレビューでも、try/exceptブロックの中に新しいURLやエンドポイント文字列が追加されていないか、差分を必ず目視確認してください。
3. 失敗を安全に倒す設計にする
呼び出しが拒否された場合、システム全体を止めるのではなく、その1呼び出しだけをエラーとして返す設計にします。
公開事例では500エラーと404エラーの2回の拒否で処理が止まり、被害が広がりませんでした。これは「fail safe（安全側に倒れる）」という考え方で、Webアプリケーションのサーキットブレーカーパターンとも通じます。
4. 意図しない挙動を「侵入テスト」として活用する
AIが規約違反のコードを生成した事例は、裏を返せば無料のペネトレーションテスト（侵入テスト）になります。
定期的にAIコーディングアシスタントに認可周りのコードを触らせ、生成された差分をセキュリティレビューの材料として蓄積する運用も検討に値します。
まとめ
AIコーディングアシスタントは、動かないコードを「動かす」方向に最適化しがちです。認可設計の意図までは汲み取ってくれません。
自分のプロジェクトでは、まずトークンの署名対象にURLとパラメータのハッシュが含まれているかを確認してください。
次に、AIが生成した差分の中にフォールバック用のエンドポイントや、独自に組み立てたパラメータが紛れ込んでいないか、コードレビューで目視チェックする習慣をつけると安心です。
拒否時にシステム全体が落ちず、1呼び出し単位でエラーを返せる設計になっているかも、あわせて見直しておくとよいでしょう。