そのハーネス、本当に境界になっていますか？ AIエージェント時代の実行環境設計【MEGU-Meet #4】

AI Coding Agentは、もはや「チャットで回答を返す存在」ではなく、ファイル編集、shell実行、依存関係の追加、CI/CDやクラウド環境への操作まで行う“実行主体”になりつつあります。

本資料では、AIエージェントに外部能力を接続し、実行させるための制御層を「ハーネス」と定義し、そのハーネスを本当にセキュリティ境界として扱えているのかを考えます。

Prompt InjectionやTool Misuse、Sensitive Info Disclosureなどのリスクは、モデルの出力だけでなく、エージェントが何を実行できるかという権限・環境設計の問題でもあります。

許可プロンプトやルールだけに頼るのではなく、sandbox、filesystem isolation、network isolation、egress制御、最小権限、監査ログなどの強制制御を組み合わせ、AIエージェント時代の実行環境をどう設計すべきかを整理します。

MEGU-Meet #4「AI-Generated Vulnerabilities LT」での登壇資料です。

Transcript

1. MEGU-Meet #4 — AI-Generated Vulnerabilities LT そのハーネス、本当に境界になってい ますか？ AI Security Harness Engineering AIエージェント時代の「実行環境」をセキュリティ境界として見直す
2. 自己紹介 平木佳介 🕊️ X @k_hirasan ✍️ Zenn @khirasan 🏢 サイバーセキュリティクラウド ☁️ CloudFastener - Technical Account Manager 🤖 AI Coding Agent を業務で使い倒す日々 Claude Code AWS MCP Security
3. AI Coding Agentは「実行主体」になった 「このテストを直して」 → エージェントは… 📋 失敗ログを読む ✏️ ファイルを編集する 💻 shellを実行する 📦 依存関係を追加する ⚙️ CI/CDを変更する ☁️ クラウド環境にも触れる チャットではなく、開発環境に手を持った実行主体。
4. プロンプトからハーネスへ AIエージェント活用の関心はどこへ向かっているか 01 Prompt Engineering どう指示するか → 02 Context Engineering 何を渡すか → 03 Harness Engineering 何を実行させるか → 04 Loop Engineering どう継続的に回すか AIエージェント活用の論点は、出力品質から実行制御へ移っている。
5. 今日のハーネスの定義 AIエージェントに外部能力を接続 し、 実行させるための制御層。 🤖 AI Agent repo files shell MCP CI/CD secrets cloud 便利にするほど、攻撃面にもなる。
6. 危険なのは「入力」ではなく「実行」 INPUT ⚠️ Malicious Input / Prompt Injection → EXECUTION 🔑 secretを読む 📡 外部送信する 📦 依存関係を追加する ⚙️ CI設定を書き換える 🔴 terraform / kubectl を実行する OWASP LLM / Agentic Risks Prompt Injection Excessive Agency Tool Misuse Sensitive Info Disclosure Supply Chain Unexpected Code Execution Identity & Privilege Abuse モデルの出力リスクから、実行権限リスクへ。
7. 境界っぽいもの vs 本当の境界 方針・確認UI — Soft Controls 📝 CLAUDE.mdの注意書き 🙋 permission prompt 📋 allow / deny rules（粒度次第） 🪝 hooks（hook自体の信頼性も必要） 🤝 手元の慣習・レビュー頼み 強制制御 — Hard Controls 📦 sandbox / コンテナ 🗂️ filesystem isolation 🌐 network isolation 🔒 egress制御 🎫 scoped / short-lived credential 🚦 CI/CD approval gate 📋 audit log 許可プロンプトは境界ではない。強制制御で設計する必要がある。
8. レイヤーで考える 1 検知 Detection 危険な入力を見つける ATR secret scanning SAST CIスキャン 2 境界 Boundary 技術的に制限する sandbox 最小権限IAM network isolation filesystem isolation 3 監査 Audit 後から追えるようにする tool call log shell log MCP call log CI/CD audit log 4 運用 Operation 人間が判断する PR review 承認フロー permission prompt 例外管理 1つの仕組みで守るのではなく、レイヤーで境界を設計する。
9. 検知対象が変わった 従来の検知対象 ログ プロセス ネットワーク バイナリ クラウドイベント → AI Agent時代の検知対象 prompt tool definition MCP config SKILL.md agent instruction tool response LLM I/O
10. Agent Threat Rules はどこに効くか ATR AIエージェント固有の入力面を検知する試み MCP config SKILL.md tool response LLM input/output prompt injection tool poisoning context exfiltration zenn.dev/cscloud_blog/articles/agent-threat-rules-intro ✅ ATRでできること 危険な設定・入力に気づく ❌ ATRだけではできないこと shell実行・ネットワーク送信・シークレット 読み取りを止める ATRは境界ではなく検知。検知で気づき、境界で止める。
11. ハーネスを評価する5つの点検観点 👤 権限 エージェント専用の最小 権限になっているか ⚠ 開発者本人の強い権限 をそのまま使う 🔑 シークレット 読める場所に秘密情報が 置かれていないか ⚠ .env、AWS認証情報、 GitHub tokenを読める 💻 ツール実行 shellやMCPに実行制御 があるか ⚠ curl / npm install / terraform apply が広く 使える 📦 サプライチェーン 依存関係・MCP・ hooksを信頼できるか ⚠ 便利なMCPやnpm packageを無検証で追加 する 📋 監査 何を読んだか、何を実行 したか追えるか ⚠ 成果物だけ残り、実行 履歴が残らない まずは自分のハーネスの攻撃面を把握することから始める。
12. ハーネスを「境界」として設計する 01 AI Coding Agentのリスクは「出力」ではなく「実行」に移っている。 02 ハーネスは便利な接続層であると同時に、最大の攻撃面になる。 03 本当に境界と呼ぶなら、プロンプトではなく「分離・権限・監査」の強制制御で設計する。 " エージェントを便利に使うために、ハーネスを「信頼」ではなく「制御」で設計する。
13. ご清聴ありがとうございました！ MEGU-Meet #4 — AI-Generated Vulnerabilities LT