はじめに
おつかれさまです。tyamonです。
AIエージェントの Kiro Crew を使っていると、Gitの main ブランチへの push やファイルのアップロードだけは、頼まない限り自動でやってくれないことに気づきます。これは不具合ではなく、Kiro Crew ガードレールと呼ばれる安全設計によるものです。この記事では、その2つの挙動を公式ドキュメントの記述を根拠にして整理します。
結論：取り消しにくい・共有システムに影響する操作は、ガードレールで意図的に止められています。
気づいたのは「アップロード」と「mainへのpush」の2つ
実際に使っていて止められたのは、次の2つの操作でした。
- ファイルを外部へアップロードしようとする操作
- Gitの
mainブランチへ push しようとする操作
どちらもエージェントが「やろうとして止まる」挙動で、エラーというより「ここは人間の判断を挟みます」という線引きに見えました。この2つがなぜ止まるのか、根拠を確認していきます。
根拠：公式ドキュメントの「Blocked commands」
Kiro Crew にはブロック対象をまとめた公式ドキュメント blocked-commands.md があり、冒頭でこう書かれています。
Kiro Crew gives an agent real tool access, so some commands are refused at the runtime boundary rather than by asking the model to behave.
つまり「モデルにお行儀よくさせる」のではなく、実行の境界で物理的に弾く設計です。モデルの気分や解釈に依存しない点がポイントです。
同ドキュメントの一覧表には、今回の2つに対応する項目がはっきり載っています。
| 分類 | 例 |
|---|---|
| Exfiltration shapes（情報持ち出しの形） | curl -d @file / --upload-file / wget --post-file |
| Destructive operations（破壊的操作） | rm -rf / / terraform destroy / aws … delete-* |
「アップロード」が止まる理由は、この Exfiltration shapes に添えられた一文が明快です。
Reading a local file into an outbound request body is indistinguishable from exfiltration, whatever the destination.
ローカルファイルを読んで外へ送るリクエストは、送り先がどこであっても「情報の持ち出し」と見分けがつかない、だから止める、という考え方です。S3 であろうと他のサービスであろうと、宛先では判断しないわけです。
mainへのpushが止まるのは「push先が確定できない」から
main への push については、私自身この記事を書く作業中に実際にブロックに遭遇しました。そのときホストから返ってきた診断がこれです。
rule=git-publish-target-unverifiable
shell substitution or expansion fuses text into the push target,
so the destination branch cannot be determined before the push runs.これは「push先のブランチ名が、実行してみるまで確定できない形になっている」という理由でのブロックでした。シェルの展開でpush先が変わりうる書き方は、main を守るために弾かれます。
Kiro Crew のガードレールは main / master / mainline といった保護ブランチへの直接 push を止めます。一方で、ブランチ名を明示したフィーチャーブランチへの push は許可されます。
# これは通る（ブランチ名を明示したフィーチャーブランチ）
git push origin feature/add-loginつまり「新しいブランチで作業して Pull Request を出す」流れは自動でこなせます。止まるのは
mainへの直接反映だけ、という線引きです。
止まるのは全部ではない：読み取り系は通る
誤解しやすいのですが、AWS 操作がまるごと禁止されているわけではありません。blocked-commands.md にも「Reading credential files is blocked. Running AWS CLI commands is not.」とある通りです。
- 通る：
describe/list/get/s3 ls/s3 cpなどの読み取り・コピー系 - 止まる：
delete/terminateのような破壊的操作、ローカルファイルを外へ送るアップロード系
破壊的操作は設定で解除可能ですが、認証情報の読み取りなど一部は解除できない（pinされている）とも書かれています。守りの固さに段階があるわけです。
まとめ
Kiro Crew が main への push とアップロードを自動でやらないのは、「取り消しにくい・共有システムに影響する・情報を外へ出す」操作を実行の境界で止める、意図的なガードレール設計でした。送り先では判断せず、push先が確定できない形も弾く、という徹底ぶりです。自律性を削るためというより、あなたのインフラとデータを壊さない・漏らさないための線引きだと理解すると腑に落ちます。
挙動を変えたい場合は、ダッシュボードの Settings → Security で個別ルールの無効化や独自ルールの追加ができます（認証情報まわりなど一部は解除不可）。
参考資料
- Kiro 公式サイト
- Kiro Crew 同梱ドキュメント
blocked-commands.md（Blocked commands and credential access）
この記事は tyamon（製造業の情シス）が実際に試した内容をもとに書いています。詳しくは運営者情報、ご質問はお問い合わせまで。
コメント