Writing a Japanese blog post on AI securityRan 4 searchesAnalyzing agent trust boundary failuresRan 3 searchesBrowsedsecurityboulevard.com/2026/08/researchers-document-instance-of-ai-agent-being-used-

2026年8月初旬、Pillar SecurityはGoogleのAgent Development Kit（ADK）Pythonリポジトリで、実運用環境における初の「agent-to-agent」特権昇格事例を公開した。低権限の公開向けエージェントがプロンプトインジェクションにより高権限のメンテナー向けエージェントを呼び出し、CIランナー上でのコード実行やトークン漏洩につながる経路が示された。 どこが甘くて何が起きうるか 問題の核心は、権限の異なるエージェントが「信頼できるトリガー」を共有していた点にある。公開のPRやIssueを処理する低権限エージェントは、未信頼のテキストを読む。攻撃者は貢献ガイドに沿った形で悪意ある指示を埋め込み、エージェントに「@gemini-cli」などの特定コメントを投稿させた。このコメントが、コラボレーター権限を持つボットアカウントから発せられたため、メンテナー専用ワークフローのゲートを通過した。結果として、issues/pull-requests書き込み権限付きのトークンが利用可能になり、偽のレビュー承認の捏造や、別の経路ではAntigravityエージェント経由のコマンド実行でPATやGCPサービスアカウント鍵の漏洩まで到達した。 従来の「人間対エージェント」の境界ではなく、「エージェント対エージェント」の暗黙の信頼が攻撃面になる。低権限側が処理した内容が高権限側の行動を決定するため、注入成功時の影響は供給チェーン全体に及び得る。サンドボックスやガードレールが存在しても、権限の合成とワークフロー間のシームが検証されていないと、これらは形骸化する。 現時点で有効な対策第一に、エージェントの権限を最小化する。人間アカウントや長期PATに紐づけず、短命かつスコープを絞ったトークンを使い、低権限エージェントから高権限ワークフローを直接起動できない設計にする。第二に、エージェント間のメッセージやコメントを「未信頼」とみなし、内容ベースではなく別の認証シグナル（署名付き要求や独立した人間ゲート）で制御する。第三に、ツール実行は許可リスト方式にし、git/ghのフックやエイリアスなど間接実行経路を遮断する。第四に、エージェント起動や相互呼び出しをログし、異常な連鎖を —

※本記事は Grok の応答をそのまま掲載しています。事実確認を行っていないので、参照する場合は原典 (末尾の「参考」節) を確認してください。