Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年10月1日に Loris Degioanni が投稿したブログ (https://www.sysdig.com/blog/with-ai-agents-runtime-is-the-only-place-truth-lives) を元に日本語に翻訳・再構成した内容となっております。
最近、セキュリティとAI分野で影響力のある人々が、フロンティアAIモデルをどれほどの速さで開発すべきかをめぐって公の場で議論を交わしています。これは非常に重要で、実際に大きな影響を伴う議論ですが、セキュリティチームが今日向き合わなければならない課題を形づくっているのは、この議論だけではありません。
今、私たちの組織にとって重要なAIエージェントは、すでにデプロイされているか、デプロイの途上にあります。エージェントは実際のインフラストラクチャー上で稼働し、認証情報を保持し、本番アプリケーションにアクセスしています。ビジネスはすでにエージェントに依存しており、次に何が起こるかというペースの議論が決着するのを待ってはくれません。
そこで、その議論ではなく、より具体的な点を掘り下げたいと思います。この1年で、私たちのセキュリティプログラムの足元で実際に何が変わったのか、そして技術的な観点から、先手を打つには何が必要なのかです。
エージェント型AIを守ることの難しさ
私のキャリアの大半において、サイバーセキュリティとは人と組織を守ることを意味し、そのために、アプリケーション、データ、インフラストラクチャーといったソフトウェア資産を保護してきました。
ソフトウェア資産は決定論的です。実行する前に、そのソフトウェアが何をできるのかを正確に把握できます。この性質こそが、セキュリティチームが構築してきたほぼすべての制御の土台であり、ポリシーを事前に記述できる理由でもあります。許可リストが機能し、ベースラインが意味を持つのもそのためです。
その裏側には人がいて、人にはアイデンティティがあります。問題が起きたときには、そこに名前が紐づきます。アカウントがあり、セッションがあり、上長がいて、責任の連鎖があります。
エージェントは、従来のソフトウェア資産でも人でもありません。人間並みの能力とアクセス権限を持って動作し、自らステップを選びながら仕事をこなすソフトウェアです。計画は実行中に書かれ、同じリクエストであっても、次回は異なる計画になる可能性があります。そのため、人とソフトウェアに対する制御を支えてきた2つの前提がどちらも崩れます。振る舞いを事前に列挙することはできず、システムに対して動作しているアイデンティティが、その責任を負うアイデンティティとは限らないのです。
これは、環境の中で動作する、まったく新しい種類の存在です。新しい課題を突きつけており、それに見合った解決策が求められます。
エージェントは人が手作業でレビューできる速度を超えて動く
AIエージェントは、数秒のうちに行動し、失敗し、自らを修正します。7月、私たちの脅威リサーチチームは、JADEPUFFER と名付けたオペレーターを発見しました。これは、エンドツーエンドで実行されたエージェント型ランサムウェアキャンペーンとして初めて記録された事例です。攻撃者は自らのAIにCVEを指し示したあと、キーボードから手を離し、キャンペーン全体をエージェントが単独で実行しました。
私にとって、JADEPUFFER で最も印象的だった点は、AIエージェントがログインの失敗を31秒でトリアージし、修正したことです。エージェントは自らのミスを診断し、アプローチを変更して、1分足らずで機能する修正を実行しました。
JADEPUFFER は攻撃者のエージェントでしたが、この速度は外部の脅威に限ったものではありません。組織がデプロイするAIエージェントも、与えられたアクセス権限の範囲で、同じペースで計画し、失敗し、再試行します。
これらの調査結果を持ち出したのは、危機感をあおるためではなく、セキュリティチームの運用上の前提が何を意味するのかを考えてほしいからです。私が見てきたすべてのセキュリティプログラムには、レビュー、承認、エスカレーションを担う人間がどこかに介在しています。31秒というペースでは、人がレビューしながら先回りし続けることはできません。別のAI支援型侵入が管理者アクセスに到達するまでにかかった8分という時間も同様です。
これは、セキュリティから人間を排除するという意味ではありません。人間の速度を補強し、脅威とリアルタイムの対応との間に人間が障害として立ちはだからないようにする、という意味です。防御は、事後に行うステップであってはなりません。アクションが発生したその瞬間に、それをブロックまたは停止するものでなければなりません。
エージェントによる自身の行動の説明は、信頼できるアリバイではない
7月下旬、OpenAI は、隔離された評価環境内のエージェントが、未知の脆弱性と漏えいした認証情報を連鎖させて、他社の本番システムに到達したことを公表しました。これを受けて Anthropic は、自社のモデルがインターネットにアクセスできた可能性のある141,006件の評価実行をレビューし、モデルが実際のシステムに触れた3件のインシデントを確認しました。
AIがサンドボックスを脱出するという話が多くのニュースを賑わせましたが、より重要なのは、モデルが自身の置かれた状況についてどう結論づけたかという点でしょう。あるエージェントは、侵入した環境が本物であると認識しながら、攻撃を続けました。別のエージェントは、推論を重ねた末に、やはりまだシミュレーションの中にいるはずだと判断しました。自分がどこにいるかを理解した時点で停止したモデルは、1つだけでした。
エージェントが自身の状況をどう理解しているかは、制御の手段にはなりません。その理解が信頼できない場合、あるいはガードレールが悪意ある行動を止められない場合、エージェント自身による自らの行動の説明は、間違いなく信頼できません。
現在のAIセキュリティツールの多くは、エージェントのログだけに依存しています。つまり、受け取ったプロンプト、実行したと申告するツール呼び出し、実行したと申告するアクションです。エージェントが何をしようとしていたと言っているのかを確認できる場所は、ここしかないため、このデータには価値があります。しかし、最も重要な瞬間、つまり何かがおかしくなったときには、これらのログは有効性を失います。乗っ取られたソフトウェアや、無謀に動作しているソフトウェアは、自らの行動の記録を偽造したり消去したりできるからです。
コンテキストとして扱うなら、エージェント自身の説明は非常に貴重です。しかし、証拠として扱えば、リスクになります。エージェントが侵害されれば、その説明も侵害されているのです。
エージェント型AIのランタイム防御に欠かせない4つの特性
かつてランタイムは、関係者だけが使う言葉でした。本番環境で稼働するコンテナのようなユーザーやソフトウェア資産を、検知とアラートの間に遅延を生じさせることなく、リアルタイムに保護することを意味していました。
今やランタイムは議論の中心にあります。AIエージェントのような高度で予測不能な存在が何をするのかを理解する唯一の方法であり、同時に、それらをガバナンスする最も効果的な方法でもあることが明らかになりつつあります。ただし、エージェントにおいては、ランタイムはこれまで以上の意味を持たなければなりません。
真のランタイムには、4つの欠かせない特性が必要です。エージェントの下層で観測すること、エージェントの内部で観測すること、その両者を相関させること、そして実行の瞬間に対処することです。
- 下層で観測する。カーネルレベルでは、実行されているプロセス、開かれているファイル、確立されている接続を実際に確認できます。エージェントはツール呼び出しを誤って報告することがあっても、たった今発行したシステムコールを書き換えることはできません。そのため、カーネルのデータは真実のソースとなりますが、意味の面では乏しいデータでもあります。システムコールからは、プロセスが接続を開いたことは分かっても、なぜ、誰のために開いたのかは分かりません。
- エージェントの内部で観測する。Claude Code や Codex などのコーディングエージェントは、フック、設定ファイル、セッションデータ、APIなどの仕組みを通じて、自らのアクティビティを公開しています。カーネルでは見えないものが、ここで見えるようになります。アクションの背後にあるプロンプト、エージェントが呼び出した MCP サーバー、実行したWeb検索などです。これらは、エージェントが制御するレイヤーであるため、それ単体では証拠になりません。しかし、意味は豊富です。これがなければ、カーネルのビューは、意図もコンテキストもないアクションの一覧にすぎません。
- 収集するだけでなく、相関させて情報を補強する。価値は両方のビューを組み合わせることで生まれ、その働きは2つの方向にあります。1つ目は、内部のビューがカーネルのビューを補強することです。匿名のプロセスからのネットワーク接続は、企業のアカウントではなく個人アカウントで動作し、非公開の顧客データを分析しているセッション内のエージェントからの接続になります。システムコールは同じでも、リスクはまったく異なります。2つ目は、カーネルのビューが内部のビューを検証することです。エージェントが実行したと報告した内容と、マシンが実際に行った内容が食い違った場合、その食い違いこそが検知そのものです。何かがおかしくなっていることを示す、最も信頼できる唯一のシグナルであり、両方のビューを同時に比較できなければ、見ることはできません。
- 実行の瞬間に判断し、対処する。エージェントの計画は実行時に書かれるため、アクションを事前に列挙することはできません。同じアクションでも、その背後にある認証情報が現時点で何に到達できるかによって、取るに足らないものにも、壊滅的なものにもなります。テストハーネスでキーを読み取ることはノイズですが、本番環境を管理するキーを読み取ることはインシデントです。しかも、それらのキーや環境は常に変化しています。この2つをその場で区別できるのは、相関と補強を経たビューだけであり、そのビューは、不正または悪意があると判断したアクションを、その瞬間にブロックまたは停止できなければなりません。
Sysdig は10年にわたり、この問題の一つの形に取り組み、動き続けるソフトウェアをどこで動いていても追跡してきました。この10年から得た教訓は、カーネルだけでは決して十分ではなかったということです。システムコールが役に立つようになったのは、コンテナ、Kubernetes、クラウドのコンテキストと結びついたときでした。プロセスが行った接続が、本番環境で稼働する決済サービスが行った接続になったのです。エージェントハーネスは、そのコンテキストの最新かつ最も豊富なソースです。新しいのは、ワークフォースの形です。AIエージェントはどこにいるのか、何ができるのか、実際に何をしたのか、そしてどの人間がそれに責任を負うのか。
規制当局も同じ方向に動いています。たとえば EU AI Act は、高リスクAIシステムに対し、その稼働期間全体にわたってイベントを自動的にログ記録することを求めます。場合によっては、どの担当者が結果を検証したかまで記録する必要があります。こうしたログは、エージェントが報告した内容だけでなく、実際に起きたことに基づいていてはじめて、持つ価値があります。
AIエージェントはエンドポイントで始まりますが、ブラスト半径(影響範囲)はクラウドにあります。そして、インシデントが発生したあとでエンドポイントのビューとクラウドのビューをつなぎ合わせるやり方では、いずれも機能しません。エージェントをリアルタイムで追跡する、単一のビューでなければなりません。
常に何が起きているかを見ていないガバナンスは、理論上のガバナンスにすぎません。そして、エージェントが実行したと言っている内容しか見られないランタイムは、名ばかりのランタイムです。