7月31日、AWSが「Balancing speed and safety: A control framework for AI coding agents」と題した記事を公開した。AIコーディングエージェントを安全に運用するための制御フレームワークを詳しく解説した内容で、AppSecチームが今すぐ参照できる実践的な構成要素が揃っている。

KiroやClaude Codeといったツールが普及し、自然言語の指示からコードを生成するAIコーディングエージェントは開発者のツールチェーンに定着しつつある。1つのエージェントが午後の数時間で数十のPRを開くことも珍しくない。ただし、その生産性には裏がある。エージェントはタスクの完了だけを最適化しており、組織のリスク感覚を持たない。

さらにModel Context Protocol（MCP）を通じてIDE外のAPI、データベース、インフラにも手が届くようになった今、AppSecチームが守るべき対象は拡大の一途だ。

AWSはこの課題に対し、「著者時（author-time）コントロール」と「ビルド時（build-time）コントロール」の2本柱からなるフレームワークを提示している。前者はコード生成の前後をIDE上で制御し、後者はCI/CDパイプライン上で本番到達前に検証・ゲートする構成だ。本記事では主にPillar 1（著者時コントロール）を中心に解説しているが、Pillar 2（ビルド時コントロール）についても7つのリスク対処の文脈で各種ゲートの位置づけが示されている。

7つのリスクと対処方針

フレームワークの前提として、エージェントに固有の7つのリスクが重要度順に整理されている。

最重要リスクはプロンプトインジェクション（R001）だ。エージェントはissueの説明文、Webページ、サードパーティのREADMEなどを読む。外部コンテンツにより、エージェントが秘密情報を漏洩したり、意図しないPRを開いたりする可能性がある。これはOWASP LLMアプリケーション トップ10においても最上位のリスクに位置づけられている。

対処の核心はアーキテクチャの分離だ。信頼された操作を担うエージェントと、信頼できないコンテンツに触れるエージェントを分け、後者には読み取り専用・最小権限のアクセスのみを与える。そして、取り消し不可能な操作には人間の承認を必須とする。

続くリスクは以下のとおりだ：

• R002（過剰な権限設定）: IAMのワイルドカードポリシーや平文での認証情報埋め込み。ステアリング文書とCheckov/cfn-nagによるポリシーas-codeスキャンで対処。
• R003（ゲートなしの本番デプロイ）: PRレビュー必須のブランチ保護、pre-commitフック、保護ブランチへの直接プッシュを禁じたサンドボックス実行。
• R004（サプライチェーンリスク）: ハルシネーションによる存在しないパッケージ名の推薦や、CVEを持つライブラリの参照。Amazon InspectorやDependabotによるSCAで対処。
• R005（外部アクセスの無制限化）: MCPサーバーを最小権限に絞り、ツール呼び出しを監査する。
• R006（ハルシネーションと誤ったコード）: SASTと単体テスト（決定論的）にLLMレビュー（非決定論的）を組み合わせる。
• R007（スコープクリープ）: バグ修正の指示に対してエージェントが周辺コードも勝手にリファクタリングするケース。仕様書で「変更してはいけない範囲」を明示する。

フレームワークの3分類：決定論的・非決定論的・人間

フレームワーク全体でコントロールは3種類に分類される。

• [D] 決定論的: SAST、シークレット検出、ポリシーas-codeなど、ルールに照らして毎回同じ結果を返す。既存のSDLCでも使われているもの。
• [ND] 非決定論的: ステアリング文書、LLM-as-judge、仕様への準拠確認など。ルールでは捉えられない「意図」の評価に使う。AIが生成したコードが決定論的チェックを全部通過しながら機能的に誤っているケースに対応するのが、この層の主な役割だ。
• [H] 人間レビュー: リスクに応じた判断が必要な箇所に限定する。すべての変更を人間に戻す「反射的なルーティング」は避けるべきとAWSは明記している。承認疲れ（consent fatigue）—レビュアーが反射的に承認するだけになる状態—が生じれば、コントロール自体が形骸化する。

Pillar 1：著者時コントロールの核心は「ステアリング文書」

著者時コントロールで最も実用的なのが、ステアリング文書（steering document）によるコンテキスト注入だ。

セキュリティチームが組織のポリシーを自然言語で記述し、開発者のIDE環境に配布する。エージェントはセッション開始時にこのファイルを読み込み、以降の生成における前提条件として扱う。記述例：

• IAMポリシーは最小権限原則に従うこと。ワイルドカードARNは禁止。
• ソースコードに認証情報をハードコードしない。シークレットマネージャーを使うこと。
• セキュリティグループは無制限のインバウンドアクセスを許可してはならない。

これはセキュリティ要件の「シフトレフト」だ。ただしステアリングは生成を正しい方向に偏らせるものであり、保証ではない。後続の決定論的ゲートとセットで使うことが前提だ。

効果的なルールの書き方として、AWSは「具体的かつテスト可能に書く」「スキャナーやレビューで出てきた実際の問題から反復的に育てる」ことを推奨している。

仕様書によるスコープ管理とMCPのアクセス制御

R007（スコープクリープ）への対処として、コード生成前に仕様書のレビューを義務付ける手法も紹介されている。仕様には「変更すべき挙動」と「変更してはならない挙動」を明示する。要件はEARS（Easy Approach to Requirements Syntax）記法（WHEN [条件] THE SYSTEM SHALL [動作]）のようなテスト可能な表現で書くことが推奨される。

MCPについては、各MCPサーバーを最小権限のツールセットに絞り、開発者自身のクレデンシャルではなく専用の絞り込んだ認証情報を渡すことが必要だ。KiroであればMCP設定ファイル（.kiro/settings/mcp.json）のenvブロックで供給する。**autoApprove: ["*"]の設定は、全ツール呼び出しで人間の承認プロンプトが消えるため、使ってはならない**とAWSは明示している。

AIコーディングエージェントのガバナンス設計は、今まさに各社が試行錯誤している段階だ。AWSが公式フレームワークとしてまとめた本記事は、組織のAppSec戦略にそのまま当てはめられる構成要素を揃えている。

詳細はBalancing speed and safety: A control framework for AI coding agentsを参照していただきたい。