5.7 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AI Agent Command Safety | 2026-06-30 | 2026-07-01 | concept |
|
|
medium |
AI Agent Command Safety
AI agent command safety は、AI coding agent や computer-use agent が生成した shell command を、実際に実行される形で検査し、危険な動作を sandbox・承認・最小権限で抑える設計領域。ai-agent-identity-security が「どの権限で何にアクセスするか」を扱うのに対し、こちらは agent が出した具体的な command が shell や OS に解釈された後に何をするかを扱う。
GuardFall は、この領域が単なる blocklist では足りないことを示す事例である。The Hacker News の要約によると、Adversa AI は GuardFall を、bash が quote や省略表現を展開する前の平文 command だけを検査する guard の弱点として説明している。たとえば text matcher が rm を探しても、shell は r''m を rm として実行できる。つまり「モデルが出した文字列」と「bash が実行する argv」が一致しない限り、安全判定は抜け穴になる。^[raw/articles/guardfall-ai-coding-agent-shell-bypass-2026.md]
設計上の含意
- Shell-aware parsing: 危険語の文字列検索ではなく、shell と同じ解釈に近い tokenization / AST / argv レベルで検査する。記事では Continue が、bash が見る形で command を分解してから判定する設計で比較的耐えた例として挙げられている。
- Sandbox before policy: blocklist は補助であり、既定の network off、workspace 外書き込み制限、throwaway
$HOME、container / OS sandbox の方が基礎になる。これは Codex の approvals / sandboxing ドキュメントが示すread-only、workspace-write、network policy の考え方と接続する。 - No silent auto-exec on untrusted input: fork PR、booby-trapped repository、package の偽 documentation、config file など、untrusted text が agent の command へ変換される経路では、自動実行や
dangerously-skip-permissions型の設定を避ける。 - Command provenance: どの file / prompt / tool result が command 生成に影響したかを残さないと、ci-cd-runtime-security のような実行時証跡や loop-engineering の verification とつながらない。
Cursor の DuneSlide 事例は、sandbox があるだけでは足りず、「agent が書ける場所」をどう解釈するかがそのまま脱出経路になることを示した。The Hacker News の要約によると、CVE-2026-50548 は run_terminal_cmd の working_directory を非既定 path にすると Cursor がその path を書き込み許可に追加してしまい、攻撃者が sandbox helper や shell startup file を上書きできる問題だった。CVE-2026-50549 は symlink の実体確認に失敗したとき in-project path を信用する fallback を悪用し、同じく project 外の helper を上書きできた。どちらも MCP や web search のような untrusted source からの prompt injection が、承認なしで local shell control へ進む構図である。^[raw/articles/cursor-duneslide-sandbox-escape-2026.md]
Claude Desktop まわりの事例は、command safety が「生成された shell 文字列」だけではなく、設定同期、MCP/extension、personal preferences、偽 error message まで含む広い実行経路の問題であることを示す。The Register の Pentera Labs 記事では、攻撃者が Claude の account-wide personalization に base64 prompt を入れ、Desktop Commander など command-capable MCP があれば reverse shell、なければ Anthropic 風の偽エラーと install prompt でユーザーに実行させる流れが説明されている。Koi の PromptJacking 報告では、公式 Claude Desktop extensions が unsandboxed MCP server として動き、AppleScript への未 escape URL 補間から web prompt injection → local RCE へ進みうると説明されている。どちらも「agent が command を出す瞬間」より前に、信頼済み assistant の設定・connector・外部 web content が command path へ混ざるため、設定変更監視、extension allowlist、connector sandboxing が command guard と同じ層で必要になる。^[raw/articles/theregister-claude-desktop-double-agent-2026.md] ^[raw/articles/koi-promptjacking-claude-desktop-rce-2026.md]
なぜ重要か
Yuta の運用では、Hermes の scheduled job、Codex/Claude/OpenCode、local CLI、CI runner が同じ「agent が command を出す」面を共有する。便利な自走 loop ほど、guard を抜けた command が SSH key、cloud credential、wiki、repo、home directory へ届きやすい。したがって agent command safety は、個別 agent の機能ではなく、agent-oriented-cli-design、ai-agent-identity-security、ci-cd-runtime-security を横断する運用品質の条件として扱うべきである。
Open questions
- shell-aware guard を各 agent が個別実装するのか、共通の command policy engine として切り出すべきか。
- bash 以外の shell、PowerShell、Python one-liner、package manager script、Makefile などをどの粒度で同じ policy にかけるべきか。
- local developer UX を壊さずに、auto-run と human approval の境界をどう観測・調整するか。