Case 005 | AIコーディングエージェントにおける実行基盤の脆弱性
Update｜2026年8月24日
実行基盤の脆弱性が示す追加事例
2026年8月、AIコーディングエージェントを取り巻く実行環境について、モデルそのものではなく、その周辺にある実行基盤や権限管理が安全性を左右することを示す事例が報告された。
その一つが、Dockerを利用した開発環境に関する事例である。
AIコーディングエージェントでは、安全性を確保するため、危険性のあるコマンドを実行する前にユーザーへ承認を求める仕組みが利用されている。しかし、ユーザーが安全だと判断して承認した操作であっても、その後の実行環境や設定によっては、意図しないコマンド実行につながる可能性があることが示された。
これは、AIモデルが安全な回答を生成することだけでは、AIエージェント全体の安全性を保証できないことを意味する。
Case 005との関係
Case 005では、AIコーディングエージェントの安全性を、AIモデルだけではなく、モデルに接続された実行基盤、権限、設定、外部サービスを含むシステム全体として評価する必要があると整理した。
今回の事例は、この問題設定を補強するものである。
特に重要なのは、「人間による承認」が存在することと、「安全な実行」が保証されることは同じではないという点である。
人間が承認した操作であっても、その後に実行される処理や権限の範囲を十分に確認できなければ、Human-in-the-loopだけでは安全装置として不十分になる可能性がある。
FAL五原則から見た意味
この事例は、FAL五原則のうち、とくに次の三つに関係する。
観測可能性
AIエージェントが実際に何を実行しようとしているのかを、人間が確認できる必要がある。
監査可能性
承認された操作と、その後に実際に実行された処理を記録し、後から検証できる必要がある。
停止可能性
承認後であっても、想定外の処理が始まった場合には、実行を停止または遮断できる仕組みが必要である。
AIエージェントの安全性は、モデル単体の性能や安全対策だけでは成立しない。
モデル、実行基盤、権限管理、人間による承認、監査、停止機構を一つのシステムとして設計することが必要である。
Case 005は、AIコーディングエージェントの普及に伴い、この「モデルの外側にある安全設計」の重要性を継続して観察する。
出典・一次資料
[1] Docker, Mark Cavage, “https://www.docker.com/blog/ai-agent-security-systems-problem/17,600 Actions: Agent Security Is a Systems Problem,” August 18, 2026.
Original Case | 初稿 | 2026年8月9日
Confirmed Facts｜確認された事実
事案の概要
2026年8月に開催されたBlack Hat USA 2026において、Anthropic、Google、OpenAIなどが提供するAIコーディングエージェントおよび関連する実行環境について、複数のセキュリティ上の問題が報告された。
今回の問題で重要なのは、AIモデルが生成するコードそのものだけではない。
AIコーディングエージェントは、モデルに加えて、ファイルの読み書き、コマンド実行、外部サービスへの接続、認証情報の利用などを可能にする実行基盤と組み合わされて動作する。
そのため、モデルが安全に動作していても、その周辺に存在する権限管理、実行環境、設定ファイル、ワークフローなどに問題があれば、AIエージェントに与えられた能力や権限が攻撃者に利用される可能性がある。
モデルの外側に存在する攻撃面
AIコーディングエージェントは、単なる対話型AIとは異なり、開発環境の内部で実際の操作を行う。
例えば、
- ローカルファイルへのアクセス
- ソースコードの変更
- シェルコマンドの実行
- 外部サービスへのアクセス
- APIや認証情報の利用
- CI/CDなど開発ワークフローとの連携
といった機能を持つ場合がある。
このため、攻撃対象はAIモデルだけではなく、リポジトリ内のファイル、エージェントへの指示、ランタイム設定、拡張機能、認証情報、ネットワーク接続など、AIエージェントを構成する環境全体へ広がる。
権限境界そのものが攻撃対象になる
代表事例：Google ADKにおけるエージェント間の権限境界
Pillar Securityは、Googleのadk-pythonリポジトリにおいて、外部から提出されたPull RequestやIssueなどを処理する公開向けAIエージェントをプロンプトインジェクションで操作し、通常はメンバーやコラボレーターなどの信頼された利用者のみが起動できる高権限ワークフローへ処理を引き継がせる攻撃経路を実証した。
問題となった構成では、低権限のPRトリアージ用エージェントが、GitHub上でCollaborator権限を持つadk-botアカウントとしてコメントを投稿していた。
研究者は、Pull Requestに埋め込んだ細工された指示によって、このエージェントに@gemini-cliで始まるコメントを投稿させ、それを契機としてgemini-dispatchからgemini-invokeなどのより高い権限を持つワークフローを起動させることに成功した。
つまり攻撃者自身が高い権限を取得するのではなく、
Untrusted External Input
→ Low-Privilege Agent
→ Trusted Trigger
→ Privileged Agent / Workflow
→ Repository Operation
という経路を通じて、低い信頼レベルの外部入力から、より高い権限を持つ処理へ到達する経路が実証された。
Googleは報告を受けてadk-pythonリポジトリをハードニングし、その後、関連するIssue／PRトリアージおよび修正用エージェントワークフローを削除する修正も実施した。
今回報告された問題が示す重要な点の一つは、AIエージェントに与えられた権限そのものが新しい攻撃面になることである。
AIコーディングエージェントが実際の開発作業を行うためには、ファイル、リポジトリ、コマンド、外部サービスなどに一定のアクセス権限を与える必要がある。
しかし、外部から取り込まれた情報や信頼されていない指示がエージェントの判断に影響し、そのエージェントが広い権限を保持していた場合、本来は許可されるべきでない操作へつながる可能性がある。
したがって問題は、
「AIが危険なコードを生成するか」
だけではなく、
「信頼されていない入力が、AIエージェントに与えられた権限へ到達できるか」
というシステム上の信頼境界にも存在する。
認証情報と被害範囲
AIエージェントが利用できる認証情報が適切に分離されていない場合、脆弱性が発生した際の影響範囲はさらに大きくなる。
AIエージェントの能力とアクセス権限が拡大するにつれて、障害や侵害が発生した場合の潜在的な影響範囲、すなわち「blast radius」も拡大する。
Anthropicも、エージェントの能力向上とアクセス範囲の拡大に伴い、この潜在的な被害範囲をどのように制限するかが重要な工学的課題になっていると説明している。
したがって、認証情報の分離、最小権限、実行環境の隔離、ネットワーク制御などは、AIエージェントの安全性を構成する重要な要素となる。
Case 005で確認すべき境界
今回の事例群から、AIコーディングエージェントの安全性は、
評価チェーン：
Model → Agent Harness → Permission Management → Execution Environment → Credentials → Network Access → External Systems
という一連の経路全体で評価する必要がある。
このどこか一つでも信頼境界が破られれば、AIモデル自体を直接攻撃しなくても、AIエージェントが持つ能力や権限が攻撃者に利用される可能性がある。
AIモデルだけを守っても十分ではない
今回の問題が示す重要な点は、AIモデルの安全対策だけではAIエージェント全体の安全性を保証できないことである。
AIモデルが適切な安全制御を備えていたとしても、
評価チェーン：
Model → Agent Harness → Permission Management → Execution Environment → Credentials → Network Access → External Systems
という一連の経路のどこかに脆弱性が存在すれば、システム全体として安全性が失われる可能性がある。
実際、OpenAIも内部のコーディングエージェントについて、モデルの挙動だけではなく、実環境でエージェントがどのようにツールやシステムと相互作用するかを監視する仕組みを導入している。
FALの考察
Case 001〜004では、AIエージェントが与えられた目標を追求する過程で、人間が想定していなかった行動へ発展する問題を観測してきた。
Case 005では、問題の焦点がさらに外側へ広がる。
今回重要なのは、
「AIモデルが安全か」
だけではなく、
「そのAIモデルに、誰が、何を、どこまで実行させることができるのか」
という問題である。
AIコーディングエージェントは、モデル単体では存在しない。
その周囲には、
安全性を横断的に評価する要素：
Model
× Agent Harness
× Permission Management
× Execution Environment
× Credentials
× Network Access
× Software Supply Chain
という複数の構成要素が存在する。
このどこか一つでも信頼境界が破られれば、AIモデル自体を直接攻撃しなくても、エージェントが持つ能力や権限が攻撃者に利用される可能性がある。
FALの見解
Case 004では、FALはAIエージェントの安全性を、
AI Agent Execution Architecture
という観点から捉えた。
Case 005は、この考え方をさらに裏付ける事例である。
AIエージェントの安全性を評価する際には、モデル単体の安全性能だけでなく、
安全性を横断的に評価する要素：
Model Safety
× Runtime Security
× Identity & Credentials
× Least Privilege
× Network Control
× Supply Chain Security
× Continuous Monitoring
を一体として評価する必要がある。
特に重要なのは、AIに与える権限そのものをセキュリティ設計の対象とすることである。
高性能なAIエージェントほど、多くのファイル、ツール、認証情報、ネットワークへアクセスする必要が生じる。
能力の拡大とともに権限も拡大すれば、利便性と同時に潜在的な被害範囲も拡大する。
したがってFALは、AIエージェントに対して人間の開発者と同等、あるいはそれ以上に明確な、
「最小権限の原則（Principle of Least Privilege）」
を適用する必要があると考える。
AIエージェントの安全性は、モデルだけでは成立しない。
モデル、ハーネス、権限、認証情報、実行環境、ネットワーク、サプライチェーンを含むシステム全体が、安全性の評価単位でなければならない。
FALはCase 005を、AIモデルの脆弱性ではなく、AIエージェントを実世界へ接続する「境界領域のセキュリティ」の問題として位置付け、継続的に観測する。
Case 005 | Vulnerabilities in the Execution Infrastructure of AI Coding Agents
Update | August 24, 2026
Additional Case Highlighting Vulnerabilities in the Execution Environment
In August 2026, an additional case was reported involving the execution environments surrounding AI coding agents. The case demonstrated that security depends not only on the AI model itself, but also on the execution environment and permission management surrounding it.
One example involves a development environment using Docker.
AI coding agents may use mechanisms that require user approval before executing potentially dangerous commands. However, the case showed that even when a user judges an operation to be safe and approves it, the subsequent execution environment or configuration may still lead to unintended command execution.
This means that generating safe responses at the AI model level alone cannot guarantee the security of the AI agent as a whole.
Relationship to Case 005
Case 005 concluded that the security of AI coding agents must be evaluated not only at the AI model level, but as an entire system that includes the execution environment, permissions, configuration, and external services connected to the model.
The additional case reinforces this assessment.
Of particular importance is that the existence of human approval does not necessarily guarantee safe execution.
Even when an operation has been approved by a human, Human-in-the-loop alone may be insufficient as a safety mechanism if the human cannot adequately verify the processes subsequently executed or the scope of permissions involved.
Implications for the FAL Five Principles
This case is particularly relevant to three of the FAL Five Principles.
Observability
Humans must be able to determine what the AI agent is actually attempting to execute.
Auditability
Approved operations and the processes actually executed afterward must be recorded so that they can be reviewed and verified later.
Stoppability
Even after approval has been granted, mechanisms must exist to stop or block execution if unexpected processing begins.
The security of an AI agent cannot be established solely through the capabilities or safety measures of the model itself.
The model, execution environment, permission management, human approval, auditing, and stopping mechanisms must be designed as a single system.
Case 005 will continue to examine the importance of this “safety design outside the model” as AI coding agents become more widely deployed.
Source | Primary Source
[1] Docker, Mark Cavage, “17,600 Actions: Agent Security Is a Systems Problem,” August 18, 2026.
Original Case | August 9, 2026
Confirmed Facts
Overview of the Case
At Black Hat USA 2026, held in August 2026, multiple security issues were reported involving AI coding agents provided by Anthropic, Google, OpenAI, and related execution environments.
The important point is that the issue is not limited to the code generated by AI models themselves.
AI coding agents operate by combining models with execution infrastructure that enables them to read and write files, execute commands, connect to external services, and use credentials.
As a result, even when the model itself behaves safely, vulnerabilities in surrounding components—such as permission management, execution environments, configuration files, or workflows—may allow attackers to exploit the capabilities and privileges granted to the AI agent.
Attack Surfaces Outside the Model
Unlike conventional conversational AI systems, AI coding agents perform actual operations within development environments.
For example, they may have the ability to:
- access local files
- modify source code
- execute shell commands
- access external services
- use APIs and credentials
- interact with development workflows such as CI/CD
The attack surface therefore extends beyond the AI model itself to the entire environment surrounding the agent, including repository files, instructions provided to the agent, runtime configurations, extensions, credentials, and network connections.
Permission Boundaries Themselves Become an Attack Surface
Representative Example: Permission Boundaries Between Agents in Google ADK
Pillar Security demonstrated an attack path in Google’s adk-python repository in which a publicly accessible AI agent processing externally submitted Pull Requests and Issues could be manipulated through prompt injection to pass execution into higher-privilege workflows that would normally be triggered only by trusted users such as members or collaborators.
In the affected configuration, a low-privilege PR triage agent posted comments on GitHub using an adk-bot account with Collaborator permissions.
Researchers embedded carefully crafted instructions in a Pull Request that caused the agent to post a comment beginning with @gemini-cli. This comment then triggered higher-privilege workflows such as gemini-dispatch and gemini-invoke.
In other words, the attacker did not directly obtain higher privileges.
Instead, the demonstrated path was:
Untrusted External Input
→ Low-Privilege Agent
→ Trusted Trigger
→ Privileged Agent / Workflow
→ Repository Operation
Through this chain, input originating from a low-trust external source was able to reach processing with higher privileges.
Google hardened the adk-python repository after receiving the report and subsequently removed the related Issue/PR triage and remediation agent workflows.
One of the important lessons from this case is that the permissions granted to AI agents can themselves become a new attack surface.
AI coding agents require certain access privileges to files, repositories, commands, and external services in order to perform real development work.
However, when information or untrusted instructions introduced from outside influence an agent’s decisions while that agent retains broad privileges, the result may be operations that should never have been authorized.
The security question therefore is not only:
“Can AI generate dangerous code?”
It is also:
“Can untrusted input reach the privileges granted to an AI agent?”
This is fundamentally a question of trust boundaries within the system.
Credentials and Blast Radius
When credentials available to an AI agent are not properly separated, the potential impact of a vulnerability becomes significantly greater.
As the capabilities and access privileges of AI agents expand, so does the potential impact of a failure or compromise—the system’s blast radius.
Anthropic has similarly explained that limiting this potential blast radius is becoming an important engineering challenge as agents gain greater capabilities and broader access.
Credential separation, least privilege, execution-environment isolation, and network controls must therefore be treated as fundamental components of AI agent security.
Boundaries That Must Be Examined in Case 005
The cases examined here indicate that the security of AI coding agents must be evaluated across the entire chain:
Model → Agent Harness → Permission Management → Execution Environment → Credentials → Network Access → External Systems
If a trust boundary is broken at any point in this chain, attackers may be able to exploit the capabilities or privileges of the AI agent without directly attacking the AI model itself.
Protecting the AI Model Alone Is Not Enough
The central lesson from these incidents is that securing the AI model alone cannot guarantee the security of the AI agent as a whole.
Even if the AI model itself incorporates appropriate safety controls, a vulnerability anywhere along the chain—
Model → Agent Harness → Permission Management → Execution Environment → Credentials → Network Access → External Systems
—may compromise the security of the system as a whole.
OpenAI, for example, has also introduced mechanisms for its internal coding agents that monitor not only model behavior but also how agents interact with tools and systems in real execution environments.
FAL Analysis
In Cases 001–004, FAL observed problems in which AI agents, while pursuing assigned objectives, developed behaviors that humans had not anticipated.
In Case 005, the focus moves one layer further outward.
The critical question is no longer only:
“Is the AI model safe?”
It is also:
“Who can make that AI model execute what, and how far can that execution reach?”
AI coding agents do not exist as models in isolation.
They are surrounded by multiple components that must be evaluated together:
Model
× Agent Harness
× Permission Management
× Execution Environment
× Credentials
× Network Access
× Software Supply Chain
If a trust boundary is broken in any one of these components, an attacker may exploit the agent’s capabilities or privileges without directly compromising the AI model.
FAL Perspective
In Case 004, FAL viewed AI agent safety through the concept of:
AI Agent Execution Architecture
Case 005 provides further evidence supporting this perspective.
When evaluating the safety of AI agents, model-level safety capabilities alone are insufficient.
The following elements must be evaluated together:
Model Safety
× Runtime Security
× Identity & Credentials
× Least Privilege
× Network Control
× Supply Chain Security
× Continuous Monitoring
Of particular importance is treating the permissions granted to AI themselves as an explicit object of security design.
More capable AI agents require access to more files, tools, credentials, and networks.
If privileges expand together with capability, convenience increases—but so does the potential blast radius.
FAL therefore believes that AI agents should be subject to a clear:
Principle of Least Privilege
at least equivalent to, and potentially stricter than, that applied to human developers.
AI agent safety cannot be established at the model level alone.
The system as a whole—including the model, harness, permissions, credentials, execution environment, network, and software supply chain—must become the unit of safety evaluation.
FAL positions Case 005 not as a vulnerability of the AI model itself, but as a problem of “security at the boundary where AI agents connect to the real world.”
FAL will continue to monitor this boundary as AI agents gain greater autonomy, access, and operational capability.
Primary Sources
Pillar Securityhttps://www.pillar.security/blog/ill-just-call-you-agent-to-agent-privilege-boundary-failures-in-ci-cd-on-googles-adk-repository
Google — adk-pythonhttps://github.com/google/adk-python
Anthropic — How We Contain Claude Across Productshttps://www.anthropic.com/engineering/how-we-contain-claude
OpenAI — How We Monitor Internal Coding Agents for Misalignmenthttps://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/