【kiro-cli】サブエージェントのShell実行を特定コマンドのみに制限する（allowedCommands設定）
はじめに (TL;DR)
- kiro-cliでサブエージェントを作る際、Shell実行権限を渡すとrm -rfなどの誤実行が怖くて本番導入しづらい
- ドキュメントには明記されていないが、toolsSettingsを使うことでコマンド単位のホワイトリスト制御が可能であることが判明
- これを使えば、「調査（ls/grep）はできるが、破壊（rm）はできない」安全なコードレビュー担当エージェントが爆誕する
背景・課題
最近、開発フローにAIエージェント（kiro-cli）を組み込んで、コードレビューや簡単な調査を自動化しようと試みています。
特に作りたかったのが、Tech Lead Agentです。
メインのエージェントから呼び出され、Terraformの構成やPythonコードの品質をチェックする専門職ですが、ここで一つ大きな課題にぶつかりました。
「エージェントにShellアクセス権限を与えるのが怖すぎる」
コードの中身を確認してもらうには、ls や cat、grep といったコマンドが必要です。しかし、単に allowedTools:["shell"] を許可してしまうと、AIがハルシネーション（誤作動）を起こして、誤ってファイルを削除したり、意図しない書き込みを行うリスクが排除できません。
公式ドキュメントやIssueを読み漁りましたが、「ツールの有効化/無効化」については記述があるものの、「コマンドレベルの制御」については明確な情報が見当たりませんでした。
試行錯誤の末、特定のコマンドのみを正規表現で許可する設定を見つけ出したので、その設定方法を共有します。
アプローチ・解決策
メインエージェントは何でもできる「司令塔」とし、実作業を行うサブエージェント（Tech Lead Agent）にはRead Onlyに近いShell権限のみを付与する設計にします。
通常の設定ファイルには記述が少ないですが、toolsSettings オブジェクト内の shellプロパティに allowedCommands を配列で渡すことで、実行可能なコマンドを正規表現で制限できることがわかりました。
実装・コード
以下が、実際に稼働させているTech Lead Agentの設定ファイル（tech-lead.json）の完全な構成例です。
ここでは、プロジェクト内のファイル調査は自由に行えるが、システムへの変更はレビュー結果の出力のみに限定するという安全な構成を実現しています。
{
"name": "senior-reviewer-agent",
"description": "技術アーキテクチャ・コードレビュー専門エージェント。Terraform/Lambdaコードのレビュー、セキュリティチェックを担当。",
"prompt": "file://./prompts/aws-expert.md",
"resources": [
"file://GUIDELINES.md",
"file://terraform/**/*.tf",
"file://src/**/*.py"
],
"tools": [
"read",
"write",
"shell"
],
"allowedTools": [
"read"
],
"toolsSettings": {
"write": {
"allowedPaths": [
"/workspaces/my-project/review_result.md",
"/workspaces/my-project/docs/audit_log.md"
]
},
"shell": {
"allowedCommands": [
"ls.*",
"find.*",
"grep.*",
"cat.*"
]
}
}
}
解説：ここがポイント
- toolsSettings.shell.allowedCommands
ここが今回の肝です。正規表現が使えるため、厳密な完全一致だけでなく柔軟な指定が可能です。
ls.*:lsコマンド単体や、ls -la,ls src/などを幅広く許可します。
grep.*: コード検索には必須です。
逆に、ここに記述されていないコマンド（例：rm,curl,pythonなど）をエージェントが実行しようとすると、ynで実行可否を聞かれます。 -
toolsSettings.write.allowedPaths
Shellだけでなく、ファイル書き込み（writeツール）に関してもパス制限をかけています。
これにより、エージェントが勝手にsrc/main.pyを書き換える事故を防ぎ、指定したレポートファイル（review_result.md）への出力のみを許可しています。
ハマりポイントと解決策
- 正規表現の記述ミスでコマンドが通らない
allowedCommands は正規表現として評価されるため、記述が厳密すぎるとオプション引数つきの実行で弾かれます。
NG: "ls"
理由:ls -laと打たれた瞬間にマッチしなくなる。
OK: "ls.*"
理由:lsから始まる文字列なら何でもOKにする（多少緩いが、読み取り系コマンドならリスクは低い）。
おわりに・今後の展望
ドキュメント化されていない toolsSettings を活用することで、セキュリティリスクを最小限に抑えつつ、強力なCLI操作能力をエージェントに付与することができました。
これで、「ちょっとこのディレクトリのコード構造見ておいて」と安心して丸投げできるTech Leadエージェントの完成です。
次にやりたいこと：
次は terraform planコマンド自体を allowedCommands に追加し、プラン実行からリスク評価まで自律的に行うエージェントへ進化させてみたいと思います。