このインシデントは、あるチームを覚醒させた。彼らのAWSアクセスモデル全体は、「慎重な人間だけが本番環境のキーを保持する」という信念に基づいて構築されていた。AIエージェントが今やあらゆる開発者のワークフローに組み込まれている中で、その信念は誤りであることが証明された。同社は、あらゆる本番レベルの操作に対して「ヒューマン・イン・ザ・ループ（人間による介在）」の承認ステップを強制する「アクセスブローカー」を構築することで対応した。

事故の経緯

あるエンジニアが、AIコーディングエージェントにパイプラインスクリプトの生成をプロンプトした。そのエージェントは、エンジニアの本番用IAMロール（CloudFormationスタックの作成、変更、削除が可能なAWSアイデンティティ）を継承していた。スクリプトが実行され、本番環境にスタックが作成されたが、直後の「クリーンアップ」ステップとして即座に削除された。この操作は標準的なCI/CDパイプラインをバイパスしたため、通常こうした変更を制御するポリシーエンジンには検知されなかった。

モニタリングプラットフォームは、承認されたパイプライン外で特権アクションを実行したロールをフラグ立てするように調整されていたため、スタックが削除された瞬間にアラートを発報した。サービス停止は発生しなかったが、このアラートは、リソース名の入力ミスやAIプロンプトのバグによって、重要なインフラが消失しかねないシナリオを浮き彫りにした。

チームは、「検知は防止ではない」ということに気づいた。もしAIが誤ったスタックを削除していたら、災厄が起きていただろう。

なぜ従来の認証モデルは失敗したのか

組織の以前のアプローチは、多要素認証（MFA）によって保護された短期間のセッションに依存していた。理論上は、開発者がセッションをリクエストしてタスクを実行すれば、認証情報は自動的に失効するはずだった。しかし実際には、一度ラップトップでセッションが開始されると、マシンの稼働時間中ずっと残り続けた。テストスイート、バックグラウンドスクリプト、そして現在のAIエージェントに至るまで、あらゆるプロセスが追加のチェックなしにそれらの認証情報を再利用していた。

この「アンビエント・クレデンシャル（環境に漂う認証情報）」の問題により、本番用IAMロールが開発者のワークステーションに定着してしまった。同じシェル内でサブプロセスとして実行されるAIエージェントは、同じ権限を継承し、人間と同じように本番リソースに対して操作を行うことができた。

アクセスブローカー：新たなゲートキーパー

アンビエント・クレデンシャルの連鎖を断ち切るため、チームは本番ロールを引き受けることができる対象を再設計した。開発者のアイデンティティが直接特権ロールを引き受けるのではなく、厳格に制御された単一のエンティティ、すなわち「内部アクセスブローカー」を導入した。

リクエストフロー

  1. Webポータル – エンジニアがセルフサービスポータルを開き、必要なアクセスレベル（読み取り専用、デベロッパー、または管理者）を選択し、理由を入力する。
  2. Slack承認 – リクエストが専用のSlackチャンネルに投稿され、指定された承認者が明示的に許可を与える必要がある。

Slackによるステップは、AIエージェントが実行されているターミナルとは異なるプラットフォーム上での「第2の要素」として機能する。承認は別のUIで行われる必要があるため、自律的なスクリプトが単独でワークフローを完了させることはできない。

階層化されたアクセス

  • 読み取り専用 – リソースやログの閲覧は可能だが、変更は一切できない。
  • デベロッパー – サポートタスクやインフラの微調整を想定。スタックの削除や顧客データへの直接アクセスといった破壊的なアクションをブロックする。
  • 管理者 – フル権限。緊急時の介入用に予約されており、上位レベルのレビューを経てのみ付与される。

すべての本番アクセスをブローカー経由に集約することで、チームは特権認証情報をあらゆるラップトップに分散させるのではなく、強力に防御された単一のサービスにリスクを集中させた。

ブローカーが実際に防ぐもの

ブローカーの主な目的は、AIエージェントが密かに悪用する可能性のあるアンビエント・クレデンシャルを阻止することである。たとえ人間がリクエストを承認したとしても、その承認は意識的な決定であり、AIがそのステップを捏造することはできない。その結果、以下のことが可能になる：

  • 意図しない削除 – 人間が明示的にセッションを許可しない限り、AIは削除コマンドを発行できなくなる。
  • 認証情報の拡散（Credential sprawl） – 本番用キーが開発者のマシンに残らなくなるため、ラップトップを侵害した悪意のある内部関係者や外部アクターに対する攻撃対象領域（アタックサーフェス）が縮小する。

チームは、このシステムがヒューマンエラーを排除するわけではないことを強調している。誤った承認は依然として被害をもたらす可能性がある。しかし、人間のチェックポイントなしに自律的なコードが本番リソースに対して動作するという「サイレントな」リスクは取り除かれる。

教訓

AIエージェントが人間のエンジニアと同じ制約のない認証情報を受け取ると、誰にも気づかれることなく本番環境を破壊してしまう権限を持つことになります。特権アクセスを、別途人間による承認チャネルを強制するブローカーの背後に集約することで、たとえ人間のミスによるトラブルが依然として起こり得るとしても、チームは自律的なスクリプトが密かに混乱を招くのを防ぐことができます。真のセキュリティ上の利点は、個々の決定を監視することではなく、アンビエント・クレデンシャルを排除することにあります。