Kiro５兄弟のいまどきのセキュリティ基礎知識 ― Kiro CLIとDraw.io MCPで信頼境界を描くまで

Last updated at 2026-08-29Posted at 2026-08-29

はじめに

2026年8月26日のSecurity-JAWS 第42回で、「Kiro 5兄弟のいまどきのセキュリティ基礎知識」というテーマで登壇しました。本記事は、その発表内容を資料を開かなくても理解できるように再構成した紹介記事です。

発表資料はこちらです。

内容は2026年8月26日時点のスナップショットです。Kiroは更新が非常に速く、特にKiro CLI v3、Kiro Web、Kiro Mobile、Kiro Crewは変更が続いています。実際に設定するときは、利用中のバージョンと最新の公式ドキュメントを確認してください。

Kiro Crewの公式GitHubリンク切れに注意

2026年8月29日現在も、Kiro公式のCrew Securityページ末尾にある「security deep dive」のリンクが切れています。
公式ページは.../blob/main/docs/security-deep-dive.mdを指していますが、正しくはdocs/architecture/security-deep-dive.mdです。

Kiro Crewのセキュリティを調べるなら、GitHubでは次の順で読むのがおすすめです。

優先度	内容
必読	上記の`docs/architecture/security-deep-dive.md` — 多層防御の全体像と、公式自身が認める限界
次に読む仕様	`docs/system-specs/modules/governance.md` — Plane Aなど「どこで止めるか」の定義
対応する実装	`src/kiro_crew/hooks.py` — Plane A（`HookManager.on_tool_call`）の実体

Plane Aとは: Kiro Crew Gatewayが、エージェントのツール実行前に「この操作を許可するか」を判断する主要な関門です。資料ではPreToolUse GateやCrew HookManagerとも呼ばれ、実装上はHookManager.on_tool_callに当たります。機密パス、禁止コマンド、Governanceなどをここで確認します。ただし、allowedToolsなどによりPermission Request自体が発生しない呼び出しは、この関門に届きません。

今回伝えたかったことは、大きく以下の3つです。

緻密な調査リポジトリを先に作れば、Kiro CLIへ「Draw.ioで論理構成図、物理構成図、シーケンス図を描いて」と依頼するだけで、根拠を反映した詳細図まで作り込める
Crewを除くKiro 4形態はUnified Agent Harnessへ向かっているが、統合はまだ途中。permissions.yamlも「すべてで利用可能」になったわけではない
Web、Mobile、Cloud Sessionsはクラウドサンドボックスを中心にワークフローが統合されつつある。ただし、サンドボックスだけで機密情報やAWS権限の問題が消えるわけではない

一言でまとめると、Kiroは統合に向かっているものの、セキュリティ設定まで統一済みだと思うと危ないということです。

前提：Kiro 5兄弟は「2＋2＋1」で理解する

以前の記事「Kiro 5兄弟の現在位置を確認してみた」では、5形態を次の「2＋2＋1」に整理しました。

グループ	形態	実行場所・役割	セキュリティを考えるときの入口
ローカル開発ツール	IDE / CLI	開発者のPCで対話的に開発	Unified Harness、`permissions.yaml`、hooks
クラウド委任サーフェス	Web / Mobile	AWS上の同じクラウドセッションを操作	タスク単位のサンドボックス、ネットワーク、Secrets、IAMロール
常駐オーケストレータ	Crew	自分のPCやサーバーでGatewayが常駐し、Kiro CLIをACP経由で駆動	Crew独自のGate、OSサンドボックス、`security_policy.json`

「兄弟」「双子」「住み込み」といった比喩は公式用語ではなく、私の整理です。

Kiro Crewは横並びの「5つ目の画面」ではありません。常駐するGatewayが、Kiro CLIをACP（Agent Client Protocol）経由で動かす上位レイヤです。そのため、Crewだけは他の4形態とセキュリティ設定の体系が大きく異なります。

① Unified Agent Harnessへの統合は進行中

何を統合しようとしているのか

従来のIDEとCLIには、同じKiroという名前でも次の違いがありました。

セッションの保存形式が異なる
権限設定の記法が異なる
コンテキスト圧縮の方式が異なる
IDEには仕様駆動開発、CLIには自動化・ターミナル連携という機能の偏りがある

これらを共通のエージェント実行基盤へ寄せていくのが、Unified Agent Harness（統一エージェントハーネス）です。エージェント本体とIDE、CLI、Web、Mobileなどの画面を分離し、ACPでつなぐ方向へ進んでいます。

権限設定の共通軸がpermissions.yaml

新しい系列では、ファイル読み書き、シェル、MCPなどを「capability」として扱い、allow、ask、denyを宣言します。capabilityは個々のコマンド名ではなく、複数のツール操作をまとめた権限カテゴリです。通常のcapabilityは次の12種です。

capability	主に制御する操作
`fs_read`	ファイルやディレクトリの読み取り
`fs_write`	ファイルの作成・変更などの書き込み操作
`shell`	シェルコマンドの実行
`web_fetch`	指定したURLからのコンテンツ取得
`web_search`	Web検索の実行
`mcp`	MCPサーバーが提供するツールの呼び出し
`subagent`	サブエージェントへの処理の委任
`skill`	Agent Skillsの読み込み・利用
`power`	Kiro Powersの有効化・利用
`context`	エージェントのコンテキストに関する操作
`diagnostics`	診断情報を扱うツールの利用
`sandbox_network`	サンドボックス内からのネットワークアクセス

このほか、複数のcapabilityをまとめて指定するメタcapabilityとして、全操作を表すall、すべての組み込みツールを表すbuiltin、fs_readとfs_writeをまとめたfilesystemがあります。これら3種は上の12種には含めません。公式ドキュメントは、matchの対象をファイル系ではパス、shellではコマンド接頭辞、mcpではサーバー名とツール名として明記しています。一方、subagent以降のcapabilityについては、同じページでmatchの対象粒度まで詳しく説明していません。

# ユーザー設定ディレクトリの permissions.yaml
rules:
  # 拒否は最優先
  - capability: shell
    effect: deny
    match:
      - "rm -rf *"
      - "sudo *"

  # ソースとテストへの書き込みを許可
  - capability: fs_write
    effect: allow
    match:
      - "src/**"
      - "tests/**"

  # よく使う開発コマンドを許可
  - capability: shell
    effect: allow
    match:
      - "npm *"
      - "npx *"
      - "git *"
    exclude:
      - "npm publish*"

これは文法を示す抜粋です。allowは組み込みの既定権限へ加算され、既定を置き換えません。この例も「srcとtests以外を自動拒否するホワイトリスト」にはなりません。実運用では、環境変数ファイル、秘密鍵、クラウド認証情報など、利用環境に合わせたfs_readの拒否ルールも追加してください。

評価の優先順位は次の通りです。

deny > ask > allow

スコープ間に「こちらのファイルが優先」という順位はなく、複数のルールが一致した場合は、最も制限の厳しい効果が勝ちます。どのルールにも一致しない操作はIAMのような暗黙の拒否ではなく、人間に確認するaskへ落ちます。

一番重要なのは「どのエンジンで動いているか」

2026年8月26日時点の状況を整理すると、次のようになります。

形態	`permissions.yaml`の状況	注意点
Kiro IDE 1.x	利用する新系列	GA済み
Kiro CLI 2.x	利用しない	通常起動はこちら。実機2.18.1では不正なファイルを置いても権限関連の警告は出なかった
Kiro CLI v3	利用する新系列	Early Access。`--v3`で明示的にオプトイン
Kiro Web / Mobile	将来の共通化対象	公式のPermissions管理ページはWebについて「Coming soon」。管理手段が未提供であることと、内部で何も強制されないことは同義ではない
Kiro Crew	利用しない	Crew独自のガバナンス体系を使う

つまり、permissions.yamlを書いたことより、そのファイルを読むエンジンを起動しているかの方が重要です。

「統一される未来」は見えています。しかし現在は移行期です。「新しい記事を読んで設定ファイルを書いたので、通常起動のCLI 2.xも守られた」と思い込むことが、一番避けたい状態です。

② Kiroクラウドサンドボックスによる統合ワークフロー

WebとMobileは同じセッションを見る2つの窓

Kiro Mobileは「スマートフォンでコードを書くIDE」ではありません。Webで始めたセッション、接続リポジトリ、モデル設定、エージェントのコンテキストを引き継いで、外出先から確認・操作するためのサーフェスです。

さらにKiro CLIのCloud Sessionsでは、CLIからクラウドセッションを開始・再接続できます。IDEも複数サーフェスのセッションを見渡すHubへ向かっています。

ただし、ローカルの個人設定がそのままCloud Sessionへ移るわけではありません。Cloud configurationは、手元のKiro設定をクラウド実行環境へ同期する仕組みです。公式ドキュメントでは、同期できる設定としてpersonal steering、custom agents、skills、hooksが挙げられています。一方、コマンドやファイル操作の許可・拒否を定めるpermissions.yamlは、userスコープ・workspaceスコープともに同期対象として記載されていません。ただし、これだけで「クラウド側では権限チェックが行われない」とは断定できません。公式情報から分かるのは、手元のpermissions.yamlをクラウドへ持ち込む方法が、文書化されていないという点までです。

タスクは概ね次の流れで処理されます。

サンドボックス起動
  → 認可済みリポジトリをclone
  → 環境設定と依存関係を準備
  → エージェントが作業
  → 結果をリポジトリへ反映
  → タスク完了後にサンドボックスを破棄

ローカルPCを閉じても作業が続き、Web、Mobile、CLIから同じ仕事へ戻れるのが強みです。

「サンドボックスだから安全」ではない

Kiro公式ドキュメント自身が、クラウド実行時の限界を説明しています。

論点	サンドボックスで守られること	残るリスク
タスク分離	タスクごとに環境が作られ、完了後に破棄される	リポジトリ内の悪意ある指示をエージェントが読む可能性は残る
Secrets	保存時は暗号化される	実行時は環境変数としてエージェントから利用可能。コード変更、ログ、外部通信による流出は防げない
ネットワーク	アクセス先を制限できる	完全なオフラインにする選択肢ではない。許可先とリポジトリアクセスの設計が必要
MCP	ツールを追加できる	MCPサーバーはエージェントのツール実行サンドボックス外で動くため、同じ制約を受けない
AWS権限	タスク用の一時クレデンシャルを利用できる	エージェント、CLIツール、MCPが同じ権限を使う。強いロールなら権限昇格を含む操作が可能

AWSへ接続する場合は、信頼ポリシーだけ設定して終わりではありません。Kiro専用かつ最小権限のIAMロールを用意し、Source Identityやセッションタグで追跡・スコープダウンできるようにします。サンドボックスの環境変数へ静的なAWSアクセスキーを設定しないことも重要です。

補足: 静的キーが環境変数にあるとIAMロールより優先されます。ロールを使う場合は静的キーを除去してください。

クラウドサンドボックスは「被害範囲を狭める箱」です。渡したSecretsやIAM権限の強さまで自動で適正化する機能ではありません。

③ Kiro Crewは同じ「サンドボックス」でも別物

バージョン注記（2026年8月29日追記）: 本稿のKiro Crew実測はv0.3.0を基準にしています。2026年8月29日時点の最新安定版はv0.4.1で、同版自体は表示上のバージョン補正だけを行うhotfixです。実質的な版差であるv0.4.0では、暗号化Secrets Vaultやsecret://参照、複数のapproval/validator bypass修正などが追加されました。一方、allowedTools等でPermission Requestが発生しない場合にPlane Aへ到達しないことと、Plane Aが拒否コマンドのSOLE強制点であることは、v0.4.1の公式仕様にも残っています。

Kiro Crewの基本構造

Kiro Crewは、Pythonのasyncioとaiohttpで動く単一の常駐Gatewayプロセスを中心に、Kiro CLIをACP経由で駆動します。会話、記憶、lessons、skills、cron、Slackなどのチャネルを束ねられる一方、常駐するため、単発のCLIよりも守るべき範囲が広くなります。

Crewのセキュリティはpermissions.yamlではなく、主に次の仕組みで構成されます。

Gatewayが持つPreToolUse Gate
機密パスの遮断
禁止コマンドのdeny floor（Plane Aへ到達した呼び出しに対して下限として効く拒否リスト）
利用者が作るsecurity_policy.jsonと実行プロファイル
Kiro CLI側を囲うOSサンドボックス
出力のredaction（機密情報の塗りつぶし）
Security Event Ledger（SEL）による監査

ここで重要なのは、守る判定を持つのはエージェントではなくCrew Gateway側だという点です。

論理構成図：誰を信頼し、どこで判定するか

論理構成図では、全体を4つのゾーンに分けました。

外部：人間、Slack、ブラウザ、外部サービス。すべて非信頼
Crew Gateway：信頼の中心。入力検証、ツール許可、出力処理を担当
keystoneファイル群：認証・鍵・監査などCrew自身を守る重要ファイル
エージェント側：Kiro CLIとツール子プロセス。非信頼として扱う

図中のPlane Aは、PreToolUse Gate、Crew HookManager、HookManager.on_tool_callと呼ばれているものと同じです。機密パス、禁止コマンド、Governance、自動承認・セッション信頼を、Gateway側の同じ主要評価点で判定します。

ただし、このGateが評価できるのはPlane Aへ到達したツール呼び出しだけです。これが後述するバイパスを理解する鍵になります。

物理構成図：箱の内側と外側を確認する

物理構成図では、論理上の「多層防御」が実際にはどのプロセスとファイルに対応するかを描きました。

特に重要なのは次の3点です。

OSサンドボックスに入るのはKiro CLI側で、親のCrew Gatewayは箱の外
pooled MCP backend、MCP gateway daemon、cronなど、信頼側として箱の外で動く子プロセスがある
ファイル保護は一様ではなく、読み書き禁止、書き込みのみ禁止、保護なしの3種類がある

Crewが自動生成するエージェント設定JSONは、keystoneの機密パス保護に含まれません。ここを書き換えてツールを自動承認させると、後述するGateのバイパスへつながる可能性があります。

また、Crewの既定OSサンドボックスは、作業ディレクトリだけに閉じ込めるコンテナではありません。macOS版の実測では、基本は許可し、特定パスを隠す拒否リスト型でした。サンドボックスの隔離強度は、standard、cc、strictの順に強くなります。既定のautoは実装上standardの固定エイリアスで、AWS設定、GitHub CLI設定、Kubernetes設定、SSH鍵はいずれも隠れません。

補足（Kiro Crew 0.3.0）: ccではKubernetes設定が対象になり、LinuxではAWS設定も隠れますが、macOSでは隠れません。SSH鍵はOSを問わずstrictでのみ隠れます。

シーケンス図：判定順と「図の外にある経路」

シーケンス図では、Slackやブラウザから要求が入り、エージェントがツールを呼び、結果が人間へ返るまでを11ステップで表しました。

Plane Aへ到達した呼び出しは、概ね次の順番で評価されます。

機密パス
  → 禁止コマンド
  → Governance（security policy ∩ profile）
  → 自動承認 / セッション信頼 / YOLO

補足: Plane Aの各段は、エラー時も同じ向きではありません。機密パスと拒否コマンドの評価は安全側に停止しますが、実行中のGovernance評価は一般例外時にsoft fail-open（許可側）です。これは、不正なポリシーファイルを起動時に読んだ場合のfail-closedとは別経路です。

ここでいうYOLOは、時間制限付きの全面自動承認です（既定6時間、上限24時間）。

拒否が先、許可が後です。Plane Aの中まで来た呼び出しなら、自動承認やセッション信頼でhard denyを上書きできません。

ところが、allowedToolsやmcpServers.autoApproveによってローカル承認済みになった呼び出しは、Permission Requestを発生させません。そのためPlane Aへ到達せず、Gate全体を素通りします。

この経路では、Plane A上のSEL監査にも到達しません。守りたい対象をsecurity_policy.jsonのcommands、mcp、toolsなどで明示すると、Crewが生成する最終エージェント設定kirocrew.jsonでは、rebuild_agent_config()が該当するツール参照（ref）の無条件許可を外し、呼び出しをGate審査と監査へ戻します。ポリシーが沈黙しているrefには無条件許可が残り得ます。

Kiro Crewの資料では、かつて存在したエージェントJSON側の禁止コマンド注入経路はv1で廃止され、Plane Aが禁止コマンドの唯一の強制点（原文では大文字でSOLE）と説明されています。つまり、Plane Aを素通りした呼び出しを禁止コマンドでもう一度止める第二の面はありません。

これは「Crewの防御がすべて無意味」という話ではありません。Plane Aへ来た呼び出しには、機密パスやdeny floorが自動承認より先に効きます。問題は、どの呼び出しがその強制点へ到達するのかを確認しないと、多層防御を過大評価してしまうことです。

security_policy.jsonは利用者が作る

Kiro Crew 0.3.0の実機確認では、security_policy.jsonは既定で存在しませんでした。公式資料の表現も「standalone operator-authored」、つまり運用者が自分で作るファイルです。

製品の検証コマンドも、次の原則を明示します。

Omission does not deny. Name each row explicitly.

省略しても拒否にはならない。守る行を明示せよ。

ポリシーが無くても機密パスとdeny floorまで消えるわけではありません。しかし、ネットワーク、ファイルシステム、MCPなどのガバナンス上限は、書かなければ追加されません。また、ポリシーはGateway起動時に読み込まれるため、変更後は再起動が必要です。

Crewにはポリシーの表示・検証・判定理由の説明や、監査ログの確認・完全性検証を行うコマンドもあります。まずは読み取り系のコマンドで現状を確認するのが安全です。

kirocrew policy show
kirocrew policy validate
kirocrew policy explain <scope> <item>
kirocrew security deny-list
kirocrew security verify

同じ「サンドボックス」を同じ意味で使わない

Kiro WebとKiro Crewは、どちらもサンドボックスという言葉を使います。しかし、境界の作り方は大きく異なります。

観点	Kiro Web / Mobile / Cloud Sessions	Kiro Crew
実行場所	AWS上	自分のPCやサーバー
分離単位	タスクごと	Webのようなタスク単位の分離はない（単一の常駐Gateway）。作業ディレクトリへの拘束規則は実測0件
壁の型	隔離（containment）。使い捨ての箱	遮蔽（redaction）。許可を基本に特定対象を隠す拒否リスト
ライフサイクル	タスク完了で破棄	Gatewayが長期常駐
基本イメージ	使い捨ての箱に仕事を預ける	自分の環境にエージェントが住み込む
主な残余リスク	渡したSecrets、MCP、IAM権限、外部通信	ローカルの別プロジェクト、認証情報、Gateを通らない経路、常駐・無人実行

CrewにもOSサンドボックスはありますが、Webのタスク単位コンテナと同じ隔離境界だと思わないことが重要です。

Kiro CLIとDraw.io MCPで3つの図を描くまで

今回の一番の目玉は、ここまで掲載した論理構成図、物理構成図、シーケンス図を、Kiro CLIからDraw.io MCP Serverを使って作成したことです。

「図を描いて」の前に調査リポジトリを作る

詳細な図を一度の短いプロンプトだけで正しく作れたわけではありません。先に、調査リポジトリへ次の情報を蓄積しました。

公式ドキュメントとOSSソースのURL、取得日、版、原文引用
確定した事実と筆者の評価を分けた調査ノート
論理名と実装名の対応表
プロセス、ファイル、通信、信頼ゾーン、強制点の一覧
fail-open、fail-closed、fail-to-human、ドキュメント不整合の区別
未確認事項と、図で断定してはいけない事項
アスキーアートによる下書き
図ごとの作図仕様、共通の色、境界番号、凡例

この状態まで作ると、最後の依頼は短くできます。

調査リポジトリの確定事実、留保事項、アスキーアート、作図仕様を読んでください。
Draw.io MCP Serverを使い、Kiro Crewの信頼境界について、
1. 論理構成図
2. 物理構成図
3. 判定順序のシーケンス図
を作成してください。

3図で境界番号と配色を統一し、推論は[I]、未確認は[U]として、
原文が断定していない内容を確定事項として描かないでください。

ここでKiro CLIがしているのは、単なる箱と矢印の描画ではありません。調査リポジトリから要素と関係を拾い、Draw.ioのXMLへ落とし、3図で同じ境界番号と配色を維持する作業です。

3種類に分けた理由

1枚へ全部入れると、論理と実装と時間軸が混ざります。そこで、次の順で読めるように分けました。

論理構成図：誰を信頼し、何を非信頼として扱うか
物理構成図：その境界は、実際にはどのプロセス・ファイル・通信にあるか
シーケンス図：1回の要求で、どの順番に判定され、どこを通らない経路があるか

「静的な信頼配置 → 物理的な実体 → 動的な判定順」と分けることで、同じ情報を違う角度から相互確認できます。

人間のレビューは必要

Draw.io MCPは、調査結果を編集可能な図へ変換する作業を大幅に速めてくれました。一方で、初版から次の訂正も入りました。

重要ファイルを散文のグループ数で数えてしまい、実装上の件数と不一致になった
「認証情報を隠す」という説明を、サンドボックスのtier別に書き分ける必要があった
MCPプロセスを箱の中の非信頼側に描いたが、実装コメントを確認すると信頼側で、意味が反転した

3図を相互にレビューして初めて見つかった問題もあります。

したがって、伝えたいことは「AIなら調査なしで正しいアーキテクチャ図を作れる」ではありません。

根拠の揃った調査リポジトリがあれば、Kiro CLIはDraw.io MCPを使って、複雑な調査結果を一貫した図へ変換してくれる。ただし、図は調査の従属物であり、根拠確認と人間レビューは必要。

これが、今回の登壇で一番伝えたかったことです。

実務で確認するチェックリスト

IDE / CLI

実行中のIDE・CLIのバージョンとエンジンを確認したか
CLI 2.xへ、v3用のpermissions.yamlを書いただけで安心していないか
permissions.yamlのallowは既定への加算で、未一致はaskとなり、ホワイトリストにはならないことを理解したか
shellのパターンに、引数なし・複合コマンドなどの抜けがないか
設定をエージェント自身が変更できないようにしたか

Web / Mobile / Cloud Sessions

サンドボックスへ本当に必要なSecretsだけを渡しているか
user/workspaceスコープのpermissions.yamlがCloud configurationの同期対象に列挙されていないことを確認したか
MCPサーバーがサンドボックスと同じ制約を受けると思っていないか
Kiro専用かつ最小権限のIAMロールを使っているか
サンドボックス環境変数の静的AWSアクセスキーがIAMロールより優先されていないか
Source Identity、セッションタグ、CloudTrailで追跡できるか
ネットワークの許可先を確認したか

Crew

permissions.yamlではなくCrew独自の設定を確認したか
security_policy.jsonが既定では存在しないことを理解したか
守りたいスコープとrefを省略せず明示し、該当する無条件許可をGateへ戻したか
allowedToolsやMCPの自動承認がPlane AとそのSEL監査を通るか確認したか
Gateway、Kiro CLI、MCP、cronのどれがサンドボックス内外にあるか確認したか
使用OSとサンドボックスtierごとに、AWS設定やSSH鍵が実際に隠れるか確認したか
ポリシー変更後にGatewayを再起動したか
ポリシーの検証、判定理由、監査ログの完全性を確認したか

まとめ

今回の結論を以下の3点に戻ってまとめます。

Kiro CLI＋Draw.io MCPは、調査リポジトリに蓄積した根拠を、論理図・物理図・シーケンス図へ変換できる。短い作図依頼で高密度な図を作れるかどうかは、その前にどれだけ調査を構造化したかで決まる
Kiro 4形態はUnified Agent Harnessとpermissions.yamlへ向かっているが、まだ移行期。IDE、CLI 2.x、CLI v3、Web/Mobile、Crewで現在地が違う
クラウドサンドボックスによってWeb、Mobile、CLIのワークフローはつながる。ただし、Secrets、MCP、IAM権限、ネットワークは別途最小化する必要がある。Crewのサンドボックスは、Webの使い捨ての箱とは別物

Kiro 5兄弟はできる子です。しかし、兄弟全員に同じ設定を渡せば同じように守られるわけではありません。

どの実行面で、どの設定が読み込まれ、どの強制点を通るのか。

そこまで確認して、初めて「設定した」が「守られた」になります。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up