AIエージェントの一手は 誰も見ていない - Falco拡張OSS「Prempti」とeBPFで サーバーレス実行基盤を二層防御する

AIコーディングエージェントは、シェル実行やファイル操作、MCP呼び出しなど「破壊的なことも含めて何でもできる」状態のまま業務に入ってきています。現状のガードレールはシステムプロンプトやIDE設定など「お願いベース」で、実行時に何が起きるかを構造的に保証できていません。これがこのセッションの出発点にある課題です。

この課題を解く鍵として、クラウドネイティブの世界で実行時の脅威検知を担ってきたOSS「Falco」を紹介します。syscallをリアルタイムに監視し、YAMLルールに従って異常を検知するランタイムセキュリティエンジンで、CNCFプロジェクトとしてKubernetes環境の標準的な脅威検知手段になってきました。

セッション内では、AIエージェントに危険な操作を指示し、tool-call層でブロックされる様子と、tool-call層をすり抜けた操作がsyscall層で捕捉される様子の両方をライブデモでお見せします。

Transcript

1. sysdig SERVERLESSDAYS TOKYO 2026 ・ TRACK B ・ 9/19 AIエージェントの一手は 誰も見ていない Falco拡張OSS「Prempti」とeBPFで サーバーレス実行基盤を二層防御する 檜垣慶太（Keita Higaki） Sysdig, Inc. / Senior Customer Solutions Engineer
2. WHO AM I 自己紹介 檜垣慶太 / Sysdig, Inc. Senior Customer Solutions Engineer 今日話す立場 金融・エンタープライズ領域のクラウドネイティブセキュリティを技術支援。 Falco / eBPF を用いたランタイム検知の設計・運用を専門にしている。 ・Sysdig の製品説明ではない 近年は MCP ベースのシステムに対する Prompt Injection とその実行時検知をテーマに研究 ・falcosecurity/prempti という OSS を実際に運用して ・登壇。 Falco 解説書の執筆や OSS 開発を通じた発信も継続中。 いる立場から ・自分で踏んだ罠も含めて共有する tfdrift https://github.com/higakikeita/tfdrift-falco remedify https://glama.ai/mcp/servers/higakikeita/remedify ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 2
3. Sysdigとは? Wiresharkの共同開発者が創業 Wiresharkの共同開発者であるLoris Degioanniに より創業。クラウドネイティブ脅威検知の オープンソース標準であるFalcoを作成しました クラウドとコンテナの一貫した セキュリティを提供 開発環境から実行環境に至るまで、クラウドとコン テナの一貫したセキュリティを提供します。世界中 の多くの企業からの信頼を得ています Sysdigのミッション 本社：サンフランシスコ Sysdigのミッションは、あらゆるクラウド ネイティブ環境をセキュアで信頼できるものにす ることです Sysdig Inc. Proprietary Information 3
4. 3 出典：Falco Maintainers, KubeCon EU 2026
5. 強み OSS ECOSYSTEM OSSエコシステムを育て、そこから製品を生む Falcoを核に、Sysdigは10年にわたってOSSコミュニティに投資してきた。Sysdig SkillsやPremptiも同じ思想の上にある——作って終わりではなく、育て、そこか ら製品を生み出す。 CNCF Graduated Project 150M+ ダウンロード（ 2025年4月、Sysdig公表） 2016年のOSS化から10年 出典：https://www.cncf.io/projects/ OSSとして育てたものが、そのまま製品の基盤になる。 5
6. Sysdig 国内公開事例 出典：Sysdig.jp Sysdigが選ばれる理由 https://sysdig.jp/customers/
7. AGENDA 今日話すこと 今日話す 4つのこと 01 Falco Sysdigのコア技術・Falcoは何を解決するのか、まず土台を渡す 02 課題 AIコーディングエージェントは「何でもできる」状態で現場に来ている 03 二層防御 止まる場所が違う二つの防御層— tool-call層 と syscall層 04 実演・教訓 ブロックする層とすり抜けを捕まえる層を両方ライブで見せ、消えない前提を持ち帰る ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 7
8. PART I Falcoとは コア技術として、Falcoは何を解決するのか。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 8
9. 01 · Falco/Sysdig WHAT IS FALCO Falco — クラウドネイティブ・ランタイムセキュリティ 175M+ 8,600+ 1,600+ コンテナイメージ pull GitHub Stars コントリビューター 2026年1月時点 CNCF Graduated エコシステム全体 Falcoはカーネルイベントに、コンテナ／Kubernetesのメタデータを付与し、YAMLルールに従って異常をリアルタイ ムに検知するランタイムセキュリティエンジン。 Sysdigが開発し、2018年10月にCNCFへコントリビュート。以降 Graduated プロジェクトとして、Kubernetes環境の 標準的な脅威検知手段になってきた。 Falcoは防がない。起きたことを、確実に伝える。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 9
10. 01 · Falco/Sysdig READING A RULE Falcoルールを読んでみる — もっとも有名な例 falco_rules.yaml（Falco公式サンプル・簡略化） - rule: Terminal shell in container desc: A shell was spawned by a program inside a container condition: spawned_process and container and shell_procs output: Shell in container (user=%user.name shell=%proc.name) priority: NOTICE conditionは「コンテナの中でシェルが起動した」という状態を、syscallの組み合わせで表現している。攻撃コードを知らなくても、その状態自体が普段の運用ではま れ、という前提でルールが書かれている。 outputはSlackやSIEMにそのまま流せる自然文。priorityで重大度を分類する。 『何が起きたら異常か』を、先にルールとして言葉にしておく ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) — Premptiのルールも同じ発想。 sysdig 10
11. PART I ／ §4 技術の核： Falco / eBPF Falcoは2016年にSysdigが開発し2018年にCNCFへ寄贈、2024年2月にランタイムセキュリティ領域で初のCNCF Graduatedプロジェクトとなった。累計ダウン ロードは1.75億超。eBPFによりカーネルレベルでシステムコール等の挙動を監視するため、アプリケーションの変更は不要。 出典：①② Sysdig（Falco解説）、 CNCF ／ ③④ Sysdig内部アーキテクチャ資料（ Secureワークショップ） sysdig 11
12. PART I ／ §4-1 Falco / eBPFの内部構造 見る・分かる・止める、が同じホストの中で完結する 出典： Falco公式ドキュメント（ Kernel Events Architecture／ドライバの選択） sysdig 12
13. PART I ／ §4-3 Sysdigのアーキテクチャ： 1つの「ホスト」の中で完結する Sysdigは、eBPFで捕捉したsyscallをホスト内のルールエンジンで評価し、判定から対応（kill・隔離）までをホスト内で完結させる。 Sysdig（Falco）は、カーネル内のModern eBPFドライバがsyscallをlibscap経由でユーザー空間へリアルタイムに送り、同じホスト上のルールエンジンがそのイ ベントをその場で評価する。判定に必要な情報はホスト内で揃っているため、クラウド側の追加情報や外部システムとの相関を待たずに、ルールに一致した時点 でkill・隔離までを実行できる。 ※SysdigもSaaSと通信する（ポリシー配布・テレメトリ送信）。違いは、個々のイベント判定がその通信を待つかどうか。 出典：Falco公式ドキュメント（ドライバ構成）、 Sysdig（Falco, CNCF Graduated） ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 13
14. 前提 SYSTEM CALL syscall＝ユーザ空間とカーネルの唯一のゲート ファイルを開く・通信する・プロセスを生成する——アプリケーションは自分でハードウェアを直接操作せず、必ずカーネルにsyscallで『処理を依頼』する。逆に言えば、アプリの振る舞いは全てこの1 点を通る。 straceでcurlの動きを覗くと、ファイルを開いた・接続した・送受信した・出力した、という一つひとつの動作がsyscallの列としてそのまま見える。実装言語や中身が何であれ、この列は必ず現れ る。 出典： Sysdig技術記事「 AI時代の Runtime Security — なぜ SysdigはSyscallを見るのか」 アプリが世界に作用する瞬間は、必ずこの 1点を通る ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 14
15. 前提 THE ENGINE Falcoの真髄：観測点を syscallの境界に置いた 攻撃者がどんな入口（脆弱性・盗んだ鍵・サプライチェーン汚染）から侵入しても、実際に外界に作用した瞬間には必ずsyscallとして現れる。侵入経路を全て予測する必要はなく、この1点を押さえる ことで、攻撃の『動き』を逃さない。 OSの抽象化・特権の境界は、セキュリティ上もっとも意味のある観測点になる。ログを後から読むのではなく、境界そのもので、起きた瞬間に見る。 侵入経路を当てなくても、動いた瞬間には気づける ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 15
16. 前提 WHY IT WORKS だから、機械速度で検知でき、止められる 速い＝機械速度 正確＝事実そのもの カーネルイベントをその場でストリーム評価する。ログを集約してから調べる遅延がない。攻撃 実際に発行されたsyscallそのものを見る。難読化されていても、未知の言語で書かれていて が秒単位で動くなら、検知も秒単位で行える。（Sysdig 555 Benchmark: 5秒検知・5分調査・5 も、外界に作用した瞬間には必ず観測される。パターンが未知の脅威（ゼロデイ）でも、実際の 分対応が防御側の目安になっている） 挙動としてそのまま観測できる。ログは停止・改ざんが可能だが、この観測点は回避が難しい。 文脈がある 止められる 生のsyscallにコンテナ・Kubernetes・プロセスのメタデータを付与できる。『誰が・どのイメージの プロセス単位で特定できるため、kill・隔離・遮断まで自動で行える。検知点がそのまま対応点に ・何をしたか』まで記述できる。 なる。 ログ基盤は数分遅れて事後に気づくだけ。 syscallなら秒で見て、その場で止める ——機械速度の攻撃に、機械速度で対抗できる ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 16
17. PART II ／ §5 なぜ「未知の脅威」を検知できるのか シグネチャとの一致を前提にする検知は、一致するパターンが存在しないゼロデイを原理的に見逃す。 Sysdigは実際に起きているシステムコールの並び＝挙動そのものを見る。 検知方式 既知パターンの攻撃 未知パターンの攻撃（ゼロデイ） シグネチャ一致が前提の検知 検知できる 見逃す（一致するパターンが無い） システムコールの並び＝挙動そのものを観測 検知できる 検知できる（挙動そのものを見ている） パターンの有無に関係なく検知できることが、シグネチャ方式との違い この違いの意味 シグネチャ一致に頼る検知は、一致するパターンが存在しないゼロデイを原理的に見逃す。挙動そのものを見る検知は、シグネチャの有無に関係なく異常を捉えられる。 やるべきこと 既知パターン一致の検知に加えて、システムコールの並び＝実際の挙動を監視する層を持つ。 出典： Sysdig（MITRE ATT&CKマッピング解説） ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 17
18. 01 · Falco/Sysdig THE SERVERLESS FOUNDATION サーバーレスの上でも、 eBPFは効くのか A B C コンテナ型（Fargate） コンテナ型（Cloud Run） FaaS型（Lambda等） ノード管理は手放すが、実行は Linuxカーネルの上で起き gen2ではgVisorサンドボックスを使う構成がある。 syscall MicroVM単位の隔離。 eBPFの適用範囲はさらに狭く、本 ている。eBPFセンサーの計装実績があり、今日の実演 可視性は検証中で、今回のスコープには含めていない。 セッションのスコープ外として扱う。 基盤に選んだ。 「サーバーレスなら何でもeBPFで見える」わけではない。基盤ごとにカーネルへの距離が違う。 Lambdaの扱いは検証中である。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 18
19. PART II 今の世の中の課題 AIが普及したことで、セキュリティ的な脅威の質が変わってきた。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 19
20. PART I ／ §1 脆弱性武器化スピードの推移 2018年 2023年 2025年末 約1年 8日 数時間 脆弱性公開から実戦投入まで 脆弱性公開から実戦投入まで React2Shell公開直後に実戦投入 この数字の意味 公開後にパッチ・スキャンで対応する運用は、対応が完了する前に攻撃が終わ る時間軸に入った。PoCの有無すら、もはや速度の壁にならない。 2026年：CVE-2026-39987は、参考にできる攻撃コード （PoC）が一切無い状態 からでも、公開から 10時間 未満で実戦投入された。同じ時間軸の「どれが一番早いか」ではなく、「ゼロから作ってもこの速さに達す る」という別の脅威。 やるべきこと 検知の基準を「公開後の対応速度」から「実行された瞬間の検知」に置き直す。 出典： Sysdig 2026 Cloud-Native Security and Usage Report ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 20
21. PART I ／ §2 AIが変えた攻撃側の生産性 AI攻撃コード自動生成 CVE公開 → スキャン開始 AIエージェント攻撃（JADEPUFFER） 10〜15分・約1ドル 15分 31秒 2025〜2026年の複数調査 Unit 42調査 ログイン失敗から手法を変えて成功まで（人手を介さず） 2026年に確認されたJADEPUFFERは、脆弱なLangflowから侵入して資格情報を収集し、MySQLとNacosを暗号化。LLM生成の脅迫文とビットコインアドレスで 恐喝した。ログイン失敗時は自ら診断し、31秒で修正コードを再送信して攻撃を継続した——人手を介さず。 出典： The Hacker News（Langflow事例）、 Unit 42調査、 Sysdig 2026レポート 背景：AI関連パッケージは前年比 25倍、クラウド ID全体で人間の割合はわずか 2.8%（Sysdig 2026 Cloud-Native Security and Usage Report） 攻撃側はすでに「機械速度」に到達している ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 21
22. PART I ／ §3 自律型AIエージェントが本番侵入まで完遂した初の公開事例 侵入経路 攻撃規模 対応の教訓 0 17,000+ GLM-5.2 人の指示なし ——攻撃全体を自律型 AIエージェントが実行 記録された攻撃アクション（ログ解析による） 商用APIはガードレールで拒否、 OSSモデルを自社基盤で解析 2026年7月、Hugging Faceは本番環境への侵入を検知。OpenAIのモデル評価中に、自律型AIエージェントがデータセット処理の2つのコード実行経路を悪用し てワーカーを乗っ取り、資格情報を収集して複数クラスターへ横展開した。攻撃の開始から終了まで、人が意思決定に介在した痕跡は確認されていない。 出典： Hugging Face公式ブログ「 Security incident disclosure — July 2026」 教訓：フォレンジック分析も商用 APIはガードレールで実行不能 ——自社基盤の OSSモデルで対応。防御側も AI活用が前提になる。 攻撃側だけでなく、防御側も AIで機械速度に対応する時代に入った ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 22
23. PART I ／ §4 TRTの成果 2026年の主要な脅威調査 — 一覧 調査対象 確認された内容 時期 JADEPUFFER 自律型ランサムウェアによるデータベース恐喝 2026年 marimo (CVE-2026-39987) 4ピボット・1時間未満で侵入から窃取まで完遂 2026年5月 コンテナエスケープ エージェント駆動でオーケストレーション層まで到達 2026年 LLMjackingの進化 abliteratedモデルを使った攻撃ツールの自律構築 2026年 CTFジェイルブレイク CTFを装いLLMの安全フィルタを回避、実動エクスプロイトを生成 2026年6月 いずれもSysdig TRTが実際の環境で観測した事象であり、予測や仮説ではない。詳細な技術解説は sysdig.com/threat-research で公開されている。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 23
24. 02 · 課題 THE AUTONOMY TRADE-OFF 開発者の自由を制限すると、生産性が上がらない だからといって、 AIエージェントは使いたい。便利さそのものが、自由に任せていることの裏返しになっている。 01 02 03 締めすぎると、使われなくなる 緩めすぎると、今日話した事故になる 本当に必要なのは二択ではない 許可リストを厳しくしすぎると、エージェントが頻繁に止ま 「何でもできる」状態のまま任せると、 Hugging Faceの事 止める／通すの二値ではなく、状況に応じて allow / り、開発者は結局ガードレールを迂回する経路を探してし 例のような侵入まで一直線になる。 deny / ask を分けられる粒度。 まう。 『自由を削る』ではなく、『どこで、どう判断するか』を設計する話に変える。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 24
25. 02 · 課題 NO SHARED STANDARD YET ガードレールを引くための「規格」がまだ整っていない MCPのようなエージェント間のプロトコル自体、まだ生まれて数年。「どこまでの権限を、どう表現するか」の共通言語は、業界全体でもまだ収束していない。 OWASPが「Agentic Top 10」を出したのも 2025年12月——つい最近のこと。参照すべき標準そのものが、今まさに作られている最中にある。 MCP → 仕様は発展途上 権限モデル → ベンダーごとに違う 標準が固まるのを待っていたら、機械速度の攻撃には追いつけない。だから今日話す二層は「規格」ではなく 「実行時の観測」で境界を引く。 だからこそ、 AIエージェントのガードレールを考える上での物差しの一つが必要になる ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) — 次の OWASPがその一つ。 sysdig 25
26. 02 · 課題 WHAT IS OWASP OWASPとは、そしてなぜこの Top 10なのか AIエージェントのガードレールを考える上で、物差しの一つになるのがOWASP。特定の企業や製品に依存しない、非営利のオープンコミュニティが出し 続けている無償・公開のガイドラインだ。 最も知られているのが「OWASP Top 10」シリーズ。Webアプリ、API、そしてLLMアプリケーション向けの「LLM Top 10」は、業界の共通言語としてセキュ リティ要件やベンダーの主張を評価する基準に使われている。 OWASP Top 10 (Web) → API Top 10 → LLM Top 10 (2025) → Agentic Top 10 (2026) 従来のLLM Top10は「一回のモデル応答」が持つリスクを扱う。だが今日のエージェントは、自律的に計画し、複数ステップにわたってツールを呼び出す。そこに は専用のリスク分類が必要になった。 この後の話は、その最新版 — Agentic Top 10 — に沿って進める。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 26
27. 02 · 課題 AGENTIC TOP 10 OWASP Top 10 for Agentic Applications 2026とは 2025年12月公開（OWASP GenAI Security Project）。AIエージェントが自律的に計画・判断し、複数ステップでツールを呼び出すことに特有の 10種のリスクを、 ASI01〜ASI10として定義している。 ASI01 ASI02 ASI03 ASI04 ASI05 目標乗っ取り ツール誤用 ID・権限濫用 サプライチェーン 予期しないコード実行 ASI06 ASI07 ASI08 ASI09 ASI10 メモリ汚染 エージェント間通信 連鎖的障害 人間の信頼濫用 暴走エージェント この物差しに、今日話す二層（ Prempti/Falco）がどこまで応えられるかは、実演のあとで正直に振り返る。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 27
28. 02 · 課題 THE VIEW YOU HAVE TODAY 今見えているダッシュボードは、全部 green Hugging Faceが侵入に気づくまでの間も、外から見えるダッシュボードはこう見えていたはずだ。 1.8s 4,210 100% 0.0% P95 レイテンシ トークン数 / リクエスト ツール呼び出し成功率 エラー率 正常 正常 正常 正常 普段見ている指標は、すべてアプリケーション層のもの。呼び出しが成功したか／トークン数／秒数 ——今日あなたが見ているダッシュボードと同じ種類の数字 だ。 ツールが実際に何をしたか — ファイルを読んだのか、どこに接続したのか— は、このどのダイヤルにも乗っていない。 「動いている」ことと「安全に動いている」ことは、別の観測が必要になる。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 28
29. PART III 二層防御という発想 止まる場所が違う、二つの防御層をここで初めて重ねる。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 29
30. 03 · 二層防御 補足 · APPROACH アプローチの違い ―― 「何が置かれているか」と「今何をしているか」 クラウドセキュリティには、大きく2つの見方がある。 配置を見るアプローチ 今の挙動を見るアプローチ（ Sysdig） クラウド上の設定・資産・権限の関係を定期的に読み取り、「外部公開されていて、 サーバーの中で実際に起きている一つひとつの動きをその場で見張り、想定外 かつ強い権限を持っている」といった危険な配置を洗い出す。実行時の信号を取り の動きをした瞬間に検知・ブロックする。設定が正しくても、動いているコード自 入れる場合も、その信号は最終的にこの「配置図」に重ねて意味づけされることが 体が変な振る舞いをした瞬間に気づける。 多い。 建物の中に立って、実際の様子を見ている警備員 設計図と鍵の配布状況を確認する担当 『配置の点検』と『今の挙動を見る仕組み』を重ねることで、まだ誰も知らない弱点にも気づける範囲が広がる。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 30
31. 03 · 二層防御 THE TWO LAYERS 止まる場所が違う、二つの防御層 USER SPACE Tool-call層 — Prempti 実行前に止める。協調的な設計— containment ではない。 モデル依存 モデルの判断（保証できない） 拒否するかどうかはモデルの性質。持てる制御ではない。 KERNEL Syscall層 — Falco / eBPF 越えた瞬間そのものを見る。実運用で発火する。 上の二つは止められれば止める。下は起きたことを伝える。どちらも代わりにはならない。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 31
32. PART IV tool-call層で止める — Prempti ここから実演を交えて、今日いちばん時間を使う区間に入る。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 32
33. 04 · Prempti WHAT IS PREMPTI Premptiとは — tool-call層の最初の一手 3 6 Preview 判定の種類 デフォルトルール数 ステータス allow / deny / ask セクション Falco Ecosystem・2026年5月 Premptiは、コーディングエージェントのツール呼び出し（シェル実行・ファイル読み書き・ Web取得・MCP呼び出し）を実行前に横取りし、Falcoルールで評価して allow / deny / ask を返す。 すべての呼び出しに構造化された監査証跡が残る。falcosecurity organization 配下の公開プロジェクト。 Falcoは起きたことを伝える。 Premptiは起きる前に止めようとする。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 33
35. 04 · Prempti WHAT THE RULES TARGET モデルの判断ではなく、観測可能な振る舞いを狙う ▸ 信頼できないホストからのインストール npx / pip install / claude skills install + IOCドメイン ▸ /tmp からの MCPサーバー起動 --stdio / --sse + /tmp, /dev/shm, /var/tmp ▸ MCP設定内の IOCドメイン .mcp.json の server url ▸ 難読化された起動コマンド obfuscated launch command ▸ エージェントの自己登録 claude mcp add / plugin install — 自らスコープを広げる ▸ skillファイル内の pipe-to-shell curl | sh 相当 5番目は「エージェントの自己登録」 — Excessive Agency をtool-call境界で捉える例。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 35
36. 04 · Prempti HOW IT WORKS 判定フロー — 実行前にどう横取りするか コーディングエージェント Prempti Falcoルールエンジン tool_call() を発行 ルールとして評価 verdict: allow / deny / ask denyなら理由も添えて返す allowの場合、エージェントは遅延をほとんど感じない。 denyの場合だけ、構造化された理由とともに押し戻される。 判定に必要な情報はホスト内で揃っており、外部システムとの相関を待たずに判定できる。 判定はホストの中で完結する。外部呼び出しを待たない。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 36
37. 04 · Prempti LIVE DEMO ① tool-call層で止まる様子を見る 1本のスクリプトの中で、 ALLOW / DENY / ASKの判定が すべて実際に返る 実機収録の最終行："That's the tool-call layer. Now watch it hand off to the syscall layer." ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 37
38. 04 · Prempti WHAT JUST HAPPENED デモで起きたこと、そして次の問い tool_call('cat /etc/shadow') は、実行される前に denyされた。 01 02 結果 — エージェントは行動を変えた 問い — 経由しなければ？ エージェントは denyの理由を読み、別の方法を提案した。 tool-call層は、たしかに実行 では、エージェントがこのフックを経由せず、直接シェルを叩いたらどうなるか。 前に止まっている。 Premptiは協調的な仕組み。フックを経由しない実行は、この層からは見えない。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 38
39. 05 · 限界 WHAT PREMPTI DOES NOT DO Premptiは、自らの限界を書いている “It is not a sandbox … It does not contain a determined adversarial agent.” — falcosecurity/prempti README 協調的なポリシー層はcontainmentではない。ホスト側で、実行前に動き、エージェントがフィードバックに従うことを前提にしている。 そして、そのすべてはツール呼び出しがフックを通過することに依存する。 だから、すり抜けたものを捕まえる別の層が要る。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 39
40. 05 · 限界 WHAT THE KERNEL SEES すり抜けても、カーネルには必ず現れる コーディングエージェント Tool-call層（Prempti） OS / カーネル（Falco / eBPF） （今回は経由しない） フックを経由せず直接実行 → syscallとして必ず現れる Tool-call層をすり抜けた操作も、実際に実行されればカーネルのsyscallとして必ず現れる。 アプリ層には記録する理由がない— 呼び出し自体は成功しており、正常に見えるからだ。 検知は、モデルが漏らすと決めたかどうかに依存しない。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 40
41. 06 · Falco/eBPF LIVE DEMO ② すり抜けを syscall層で捕まえる tool-callは正常終了として返る。越えた「読み取り範囲」をsyscall層のFalcoルールが検知する。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 41
42. 06 · Falco/eBPF TWO LAYERS 二層防御、それぞれ止まる場所が違う 01 02 03 Tool-callレイヤー（Prempti） モデル判定レイヤー Syscallレイヤー（Falco/eBPF） 実行前に止める。協調的な仕組みであり、 containmentで 意味の理解で拒否する。モデル依存 — ツール説明への 境界を越える動きそのものを見る。実際の本番環境でも はない。 攻撃で複数モデルが影響を受けた例がある。 発火実績がある。 Tool-call層は行動制御（ prevention）。Syscall層は実行監視（ detection）。この二つは別物で、 AIエージェントのガバナンスにはどちらも要る。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 42
43. 06 · Falco/eBPF WHERE WE STAND 先ほどの物差し（ OWASP Top 10）に、この二層はどこまで応えるか 強く対応 部分的に対応 対象外 実演した内容がそのまま実例 止められる範囲に条件がある 別の防御と組み合わせが必要 ASI02 ツール誤用・濫用 デモ②が実例。越えた読み取り範囲をsyscallで検知。 ASI03 ID・権限濫用 認証情報窃取・reverse shell・IMDSアクセスをdeny。 ASI04 サプライチェーン IOCホスト・tmp/shm起動・不正MCP設定をdeny。 ASI01 目標乗っ取り 乗っ取り自体は防げないが、結果の行動は止める。 ASI05 予期しないコード実行 shell経由は拾えるが、in-process evalは漏れる。 ASI08 連鎖的障害 検知は早期シグナルになるが、遮断機構は別途必要。 ASI10 ASI06 メモリ汚染 RAG／ベクトルDBの汚染は範囲外。 ASI07 エージェント間通信 プロトコルの暗号・認証は範囲外。 ASI09 人間の信頼濫用 人間側のUI・心理設計の話。 暴走エージェント 自己拡張(mcp add等)はASKで捕まえる。完全な逸脱検知では ない。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 43
44. 07 · まとめ TAKEAWAYS モデルが賢くなっても、消えない前提 1 ツールは権限でスコープする タスクの都合ではなく — タスクより広いツールは攻撃面そのもの 2 協調的なポリシー層は containmentではない tool-call層は前提であって保証ではない 3 境界を越えた瞬間は syscall層で検知する アプリ層には記録する理由がない 4 Alignmentは制御ではない 監査できず、固定できず、更新のたびに変わる 5 「発火しなかった」と「問題がなかった」を区別する ネガティブコントロールを仕込む None of these go away as the models get smarter. — 消えない前提から始める。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 44
45. SUMMARY “ 止める層と、 見る層。 LLMの行動制御（ prevention）と、カーネルでの実行監視（ detection）は別物。 Falco / eBPFのような検知層が、 AIエージェントのガバナンスにも欠かせない。 falcosecurity/prempti ・ Falco / eBPF — 両方公開されている。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 45
46. 07 · まとめ EVERYTHING IS OPEN SOURCE 踏んだ罠および検証の結果 01 02 03 falcosecurity/prempti https://github.com/higakikeita/will-b e-prompt-injected RUNBOOK.md カーネル選定・ distrolessの罠・鳴らないルール — 踏んだ tool-call境界のポリシー層（ upstream） エージェント／ MCPサーバー／ Falcoルール／Fargate構 罠の記録 成 同じ罠にあなたも当たるはずなので、公開してある。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) Clone して、違う壊し方をして、教えてほしい。 sysdig 46
47. SUMMARY 見つけて、直して、検証する。 その積み重ねが、未来をつくる。 falcosecurity/prempti と Falco / eBPF は、すべて公開されています。 技術コミュニティの手で、次の一手へ。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 47
48. THANK YOU Q&A ご質問をどうぞ 檜垣慶太（ Keita Higaki） 参考 Sysdig, Inc. / Senior Customer Solutions Engineer @keitah0322 github.com/falcosecurity/prempti #ServerlessDaysTokyo falco.org 個人の研究プロジェクトです。見解は個人のものであり、Sysdigの製品・立場を代表するものではありません。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) Appendixにルール例・参考文献あり sysdig 48
49. APPENDIX A3 REFERENCES 参考文献・リンク [1] falcosecurity/prempti — GitHub github.com/falcosecurity/prempti [2] Falco — CNCF Graduated project falco.org [3] ClawHavoc — 341 malicious skills campaign （詳細はセッション本編スライド 33を参照） [4] ServerlessDays Tokyo 2026 セッションページ tokyo.serverlessdays.io/#session-keita-higaki [5] 本トーク関連： OWASP New Zealand Day 2026 登壇資料 （Prompt Injection 研究の詳細版） [6] Falcoの10年史・OSSエコシステム Falco Maintainers, KubeCon EU 2026 / cncf.io/projects ※ 本資料は個人の研究プロジェクトの発表であり、 Sysdigの製品・立場を代表するものではない。 ServerlessDays Tokyo 2026 ｜ 檜垣慶太 (Sysdig) sysdig 49