境界型・検知型セキュリティの限界――AIエージェントに必要な「実行前の証拠検証」
AIエージェントが正しい権限を持ち、正規のAPIを呼び出そうとしている。それでも、その操作を今、実行してよいとは限らない。
例えば物流企業AのAIが、企業Bへの引き渡しに関する通知を送るとします。通信相手の認証は成功し、APIの利用権限も有効です。しかし、B側の受領条件が変更されていたらどうでしょうか。直前の通知が実行済みなのか不明なまま、別の企業Cへ切り替えようとしていたらどうでしょうか。
通信が「正規」であることと、その操作が業務上「実行可能」であることは別問題です。
この区別は、AIが回答するだけでなく、送金、公開、削除、設備操作、企業間システムの連携などを自律的に実行する時代に重要になります。
本稿では、NIST、英国NCSC、OWASP、日本のAISIの一次資料と、AgentDojo、CaMeL、AgentSpecなどの原著研究を読み解きながら、**境界型・検知型セキュリティを補完する「実行前の証拠検証」**を考えます。最後に、当社が公開した2つのサイバーアシュアランスPoCについて、確認できたことと確認できていないことを分けて紹介します。
!
先に結論：必要なのは「AIを信用しない」というスローガンではありません。重要な操作について、誰の命令か／操作権限があるか／今の業務条件を満たすか／その根拠を検証できるか／結果が確定したかを、AIの文章上の説明とは独立して扱う設計です。
▼関連するプレスリリース（サイバーアシュアランス）
1. 境界型・検知型は何を守ってきたのか
セキュリティの発展を、単純に「古い技術から新しい技術への置き換え」と理解するのは適切ではありません。それぞれ、守ろうとしている対象が異なります。
考え方 | 主に確認・制御すること | それだけでは残る問い |
境界型の防御 | ネットワークやシステムの内外、通信経路、アクセスの入口 | 正規の経路から来た具体的な操作が妥当か |
検知・防御（IDS/IPS、EDR等） | 攻撃の兆候、異常な挙動、既知の不正パターン等 | 異常に見えない操作が業務条件を満たすか |
ゼロトラスト | 主体・端末・サービス・対象リソース等に基づく動的な認証・認可 | 認可の設計が、操作時点の業務条件や結果不明状態まで十分に表現しているか |
実行前の証拠検証 | 個別操作、現在の条件、根拠、実行状態を照合して許可・保留・拒否 | 証拠そのものの真正性、現実との一致、実行経路の迂回をどう防ぐか |
NIST SP 800-207『Zero Trust Architecture』は、ネットワークの場所による暗黙の信頼を排し、主体やリソースに着目した認証・認可を設計する考え方を示しています[1]。つまり、ゼロトラストはすでに「正規のネットワークなら何でも通す」という発想を否定しているのです。
また、検知型も「事故が起きた後で知らせるだけ」ではありません。IDSは検知、IPSやEDR等は条件によって予防的な遮断も行います。NIST SP 800-94も、侵入検知と侵入防御を併せて扱っています[2]。
したがって本稿の主張は、境界防御・検知・ゼロトラストが不要になった、というものではありません。
それらが正常に機能していても、AIが提案した個別の業務操作について、必要条件と証拠の充足を別途確認すべき場面がある、という主張です。
2. 「認証された操作」が危険になり得る理由
2-1. AIは、外部データを指示として扱うことがある
AIエージェントは、メール、Webページ、文書、検索結果、他のツールの応答を読み、その内容を踏まえて次の操作を選びます。しかし、そこに攻撃者の指示が紛れ込む可能性があります。これが間接プロンプトインジェクションです。
NeurIPS 2024で発表されたAgentDojoは、外部ツールが返した内容を介した攻撃を調べるため、97の通常タスクと629のセキュリティテストケースを備えた評価環境を提示しました[3]。
さらに2026年の大規模な公開レッドチーミング研究では、464名が13モデルに対して約27万2,000件の攻撃試行を提出し、41シナリオの中で8,648件の成功例が報告されています[4]。研究では、攻撃の成功を利用者に悟らせないことも課題に含まれていました。
この数字は、世界中のAIエージェントが同じ割合で侵害されることを意味しません。特定の評価環境と攻撃シナリオにおける結果です。ただし、画面に表示された最終回答が自然だからといって、その背後の操作が適切だったとは限らないことを示す重要な実験結果です。
2-2. 「悪い命令」を発見するだけでは、被害の上限を決められない
英国NCSCは2025年12月、プロンプトインジェクションをSQLインジェクションと単純に同一視すべきではないと論じました[5]。
大切なのは、モデルが悪意ある入力に影響され得ることを前提に設計する点です。NCSCは、悪意ある内容がモデルに届くことを防ぐだけでなく、LLMではない決定論的な制御によって、システムが実行できる操作を制限することを推奨しています。
例えば、AIが取引先のメールを読んで「振込先の口座を変更して送金する」と提案した場合、「その文章は不審か」を分類するだけでは不十分です。支払先変更の承認記録、口座の登録状態、金額の上限などを独立して確認しなければなりません。
攻撃の文面を見破る確率を上げることと、許可されていない操作を実行できない構造にすることは別の防御です。
2-3. 実行後の検知では戻せない操作がある
誤ったファイル削除、対外公開、支払い、物理設備への指示、企業間の二重処理などは、事後検知だけでは完全に元に戻せない場合があります。
ここでいう「検知型の限界」は、検知技術が無力だという意味ではありません。検知から停止までに時間差が生じ得ること、そして業務条件違反が必ずしも不正通信や異常パターンとして現れないことです。
日本のAISIも2026年1月の『AIインシデントレスポンス・アプローチブック』で、自律的なAIエージェントには従来のインシデント対応だけで十分に対処することが難しいと整理しています[6]。同資料は発見的統制の重要性を強調しており、事前制御が事後監視を不要にするという話ではありません。
3. 国際的な議論は「実行の制御」に進んでいる
この問題設定は、単独の企業による主張ではありません。
OWASP『Top 10 for Agentic Applications 2026』は、ASI02：Tool Misuse and Exploitation（ツールの悪用）、ASI03：Identity & Privilege Abuse（識別情報・権限の悪用）、ASI08：Cascading Failures（連鎖的障害）などを主要リスクに挙げています[7]。AIが使える「正規のツール」そのものが、誤った操作の経路になり得るという整理です。
日本のAISIは2026年7月の『AIセーフティに関する評価観点ガイド 第1.20版』に、AIエージェント特有の「観測と制御」を追加しました。自律的な挙動と外部環境との相互作用を評価対象として明示しています[8]。
米国NISTの2026年5月の報告書も、AIエージェントには新たなセキュリティ上の脅威があり、既存のサイバーセキュリティ原則は引き続き重要である一方、適応が必要だという意見が広く寄せられたと整理しています[9]。なお、これは意見募集への回答を分析した報告であり、すべての論点をNISTが実験で証明したものではありません。
境界を守る、侵入を検知する、主体を認可する。その上で、実行内容と実行時点の条件を統治する。 現在の技術的な焦点は、この最後の問いにも広がっています。
4. 実行前の証拠検証とは何か
重要な操作については、AIの出力をそのまま業務システムへ流さず、独立した判定機構を通します。
この構造を考えるうえでは、次の5点が重要です。
主体と権限：AIまたはサービスは、当該操作に必要な権限を持つか。
業務条件：今の相手先、対象物、承認状態、制約条件は成立しているか。
証拠の検査：証拠は真正で、対象の操作と結び付いており、必要な時点の情報か。
実行への強制適用：判定を迂回して同じ操作を実行する経路がないか。判定後、実行直前に条件が変わらないか。
結果の確認：成功応答が失われたとき、「未実行」と推測して再送・切替えをしていないか。
考え方を簡単な式で表すと、設計上の目標は以下です。
Execute(a)⇒Admissible(a,p,e,s)Execute(a)⇒Admissible(a,p,e,s)
aa：提案された操作
pp：適用する権限・業務ポリシー
ee：検査に利用する証拠
ss：操作直前の状態
ここでの意味は「実行されたなら、所定の条件を満たしていた」という安全性の要件です。この式を書いただけで、実システムの安全が証明されるわけではありません。 判定機構をすべての実行経路に適用できること、条件を正しく定義できること、証拠が信頼できることなど、別の前提が必要です。
セキュリティ工学には、すべてのアクセスを仲介し、改ざんに耐え、検証可能であることを求める「Reference Monitor」という古典的な設計原則があります[10]。AIの実行制御でも、この考え方は重要です。
5. 「証拠がある」と「安全である」は違う
ここは最も誤解してはいけない点です。署名、ハッシュ、監査ログ、形式証明は、それぞれ異なる対象を確認します。
確認手段 | 確認できること | それだけでは確認できないこと |
電子署名 | 所定の公開鍵に対応する秘密鍵で署名され、署名対象が改変されていないか | 署名者の現実の身元や、署名した内容が真実か |
ハッシュ照合 | 所定の照合値と内容が一致するか | 誰が作ったデータか、照合値自体が信頼できるか |
業務条件の検証 | 定義された入力・状態が条件を満たすか | 条件の定義自体に抜けがないか |
形式検証 | モデルの前提の下で特定の性質が成立するか | 実装全体や現実世界に自動的に同じ性質が成立するか |
独立した検証器 | 開示された証拠が規則と整合するか | 証拠から省かれた出来事、鍵の侵害、未観測の現象 |
実行結果の照合 | 対象システムが報告した終端状態との対応 | 実際の物理作用の完了や外部世界の全状態 |
そのため、重要なシステムでは「検証に通った」という表示だけでなく、何を、どの前提で、どこまで確認したのかを公開可能な範囲で説明する必要があります。
6. 先行技術と比較して、何が違うのか
ここで重要なのは、「実行前に止める技術がなかった」という説明をしないことです。実行前の許可・拒否、時間と履歴に基づく制御、二重実行の防止、形式的な検証、第三者が照合できる証拠は、すでにそれぞれ先行研究や実装があります。
では、私たちの公開PoCは何を示すのでしょうか。答えは、**企業間の一つの業務操作を対象に、「許可判断で終わらず、結果不明、再送、相手先変更まで扱い、その処理を証拠と限定的な形式検証に結び付けたこと」**です。
6-1. 既存技術がすでに実現していること
観点 | 重要な先行技術・既存手法 | 当社PoCで確認した範囲 |
実行前の許可・拒否 | AgentSpecは実行時ルール適用を研究し、OWASP ACSはツール操作前後の制御インターフェースを定義している[12][15] | コールドチェーンでは受領権限、記録不足、上流の保留、条件変化に応じて模擬操作の呼出しを制御 |
過去の操作、時間条件、障害 | AWS Dogwoodは操作履歴と時間条件を扱い、Local Engineは並行実行・永続化・障害復帰も考慮している[18] | VPIでは、送信元・受信先の現在条件、通知の終端状態、応答消失、失効、再送、接続先切替えを模擬企業間の実通信で検査 |
重複作用と分散処理 | Amazonの冪等API設計やSagaパターンは、再送・部分障害・補償処理を扱う確立した手法である[19][20] | VPIでは、前の相手先での処理結果が不明なまま、別の相手先で同じ業務を進めないという企業間の安全条件を検査 |
検証可能な証拠 | AgentBoundは検証可能なガバナンス記録を提案し、ICME PreFlightはゼロ知識証明付きの操作判定を提供すると公表している[13][21] | VPIでは署名付きイベントと当事者間の処理の対応を、実行側のコードを取り込まないオフライン検証器で照合。ただしゼロ知識証明ではない |
形式的な安全条件 | Proof-Carrying Contractsは機械検査可能な証明を伴う操作制御を提案している[14] | コールドチェーンとVPIそれぞれの限定した抽象モデルでLeanによる安全性の検査を行い、具体入力や実装の一部との対応も検査 |
この表は、既存技術に当社PoCの機能が欠けているという「不在証明」ではありません。比較対象の設計目的と公開資料に対し、当社が何を具体的に作り、試したのかを整理したものです。
特にDogwoodを「履歴を扱えない実行制御」と比較するのは誤りです。また、AgentBoundの第三者検証可能な記録や、Proof-Carrying Contractsの形式的保証を無視して「当社が初めて実現した」と書くこともできません。
AgentBoundの論文は、ガバナンス記録を検証する枠組みを提示する一方、当該版では大規模な実測評価結果を今後報告するとしています[13]。これは論文の評価状況を示す違いであって、提案の技術的価値を否定するものではありません。
6-2. 決定的な論点は「返事がない＝実行していない」ではないこと
例えば、企業Aが企業Bに通知した後、通信が途切れた場面を考えてみます。Aが応答を受け取れなくても、B側の処理はすでに成立しているかもしれません。ここで「失敗したはずだ」と判断し、企業Cへ同じ業務を依頼すれば、通信がすべて正規でも二重処理が起こり得ます。
VPI PoCは、こうした**「結果が分からないこと」と「実行されていないこと」を混同しない**ための安全条件を検査しています。結果を確認できない間は次の相手先への処理を保留し、前の相手先で取消しが確定した場合は、次の相手先について改めて条件を確認するという振る舞いを、限定した模擬環境で試しました。
重要なのは、個々の通信が不正かどうかではなく、前の処理の状態が確かめられないまま、同じ業務を別の相手先で進めないことです。これは、異常な通信を見つける技術とは別の、業務上の整合性を守るための条件です。
VPIの公開Leanモデルでは、宛先BとCを持つ限定した状態遷移について、初期状態から任意の有限長の操作列をたどっても、両方が同時に committed にならないことを証明しています。趣旨を式で表すと、次の安全条件です。
∀τ∈Tracesmodel,¬(CommittedB(τ)∧CommittedC(τ))∀τ∈Tracesmodel,¬(CommittedB(τ)∧CommittedC(τ))
この命題が証明するのは公開抽象モデルの状態についてです。 実HTTP通信、SQLite、署名処理、現実の荷物の移動までLeanで一括証明したという意味ではありません。実装については、別に通信試験、入力照合、証拠の照合で対応を確認しています。
ここに今回の技術記事で伝えるべき論点があります。「何を実行してよいか」だけではなく、「すでに何が起きたか分からないとき、何を実行してはいけないか」も安全条件になるのです。
6-3. 私たちの差別化は「個々の機能」ではなく「対象を絞った検証の組立て」
実行前の制御、業務上の状態、処理結果、署名付きの記録、別実装による再照合、形式的な安全条件を、同じ業務シナリオに関連付けることがポイントです。
ただし、この組合せが世界で唯一である、すべての既存技術より優れている、あるいは本番環境で完成しているとは主張しません。公開資料から再実行・再検査できる範囲を、明確に示した参照実装として位置づけます。
7. 私たちの公開PoCは、実際に何を確認したのか
上記の構造について、当社は別々の対象と保証範囲を持つ2件のPoCを公開しています。両PoCを接続した統合製品や、実AIエージェントに対する攻撃遮断を実証したわけではありません。
7-1. Cold Chain Cyber Assurance — Public PoC 5.0
検証した問いは「品質が正常でも、その引き渡しを実行してよいとは限らない」です。
許可と停止：受領権限、証拠の充足、上流の保留、条件変化などを区別し、条件不成立時に模擬操作を呼ばないことを確認しました。記録を補完すれば正常に進める条件も扱います。
作用と成功確定の区別：操作が呼ばれた後に結果不一致が起こった場合、すでに発生した模擬作用をなかったことにはせず、成功確定から隔離します。
形式検証と実装照合：公開した7つの抽象条件と2つの状態に対するLean 4の37命題を検査しました。768組の具体入力・状態について、LeanモデルとPython・JavaScriptの出力対応を検査しています。
検出限界も開示：既存の50ケースの署名付き証拠には、署名と整合性が成立していても虚偽の観測値が通り得る負の対照を含みます。これは防御成功例として数えていません。
このPoCの強みは、単なる判定画面ではなく、**「通さない／補完後に通す／作用後の不一致は成功扱いしない／同一状態で再送しても重複作用を起こさない」**という一連の挙動と、公開抽象モデルでの安全性を検査できる点です。
一方、現実のWMS接続、温度センサーの真正性、プロセスをまたぐ永続的な一意実行、AI API連携は実証していません。37命題は37個の新発明を意味せず、768組の照合もPython・JavaScript全体の形式証明ではありません。
7-2. VPI Cyber Assurance v2.0.0-rc2
検証した問いは「企業間で前の結果が不明なとき、誤った切替えや二重処理をどう防ぐか」です。
模擬企業間の実通信：ローカル環境で模擬企業A・B・Cを別プロセスとして動かし、限定した通知操作 handoff.notice の受入れと相手先の切替えを、40のシナリオで検査しました。
実行条件の再確認：相手先の条件変更、権限の失効、期限切れや遅延した要求を含め、以前の許可をそのまま使い続けないことを検査しました。
結果不明時の保留：応答消失、処理停止、再送などが起きても、前の処理結果が確認できない状態で、別の相手先の処理を進めないことを確認しました。取消しが確定した場合の正常な切替えも試しています。
証拠の再検証：実行側の主要コードを取り込まない別プログラムで、公開された署名付き記録と処理結果の整合性を照合します。署名の確認だけで、業務上の正しさを証明したとは扱いません。
多層の確認：6,144の条件組合せ、38の整数境界、有限状態探索、Leanの抽象モデル検査を行い、対象コミット 7104afa の公開CIでは5ジョブの成功を確認できます。
VPI PoCで示したのは、「結果が分からなければ、同じ業務を別の相手先で進めない」という業務上の安全条件を、模擬企業間の通信試験、限定モデルでの形式検証、公開証拠の再照合という異なる手段から確認できることです。
ただし、各プロセスは同じPC上で動き、企業間の本当の運用独立性はありません。対象の作用はSQLite内の行であり、実貨物の移動やネットワーク経路変更ではありません。検証器が確認するのは開示された記録と所定規則との整合性です。情報が欠けたまま記録一式を作り直す攻撃、侵害された署名鍵、現実の事実との不一致を一律に排除することはできません。
7-3. 2件をどう位置づけるべきか
Cold Chain PoC | VPI PoC | |
中心的な問い | 引き渡しの実行条件と成功確定 | 企業間の結果不明・取消し・切替え |
検査する主な対象 | 公開抽象モデル上の操作呼出しと作用、既存署名付き証拠 | 模擬3社の通信・受信先DBの操作・署名付きイベント |
形式検証 | 37命題、768組のモデル・具体実装の照合 | 抽象状態遷移の安全条件、具体入力と実行側・検証側の照合 |
第三者が再検査できるもの | 抽象モデルとその計算、開示した証拠の署名・整合性 | 開示イベントの署名と処理順序・取消し・切替えの整合性 |
実証していないもの | 実WMS・実センサー・実AI接続・本番運用 | 実企業の独立環境・実物流・耐侵害性・本番AI接続 |
共通しているのは、「AIや利用者が何を要求したか」と「対象システムが実際に何を許し、どの結果を成功と認めるか」を別々に扱う設計です。これを公表している範囲のテスト・形式検証・証拠照合で示していることが、現段階での技術的な訴求点です。
最も重要なのは、証拠が不十分な操作を止めるだけでなく、結果不明の操作を勝手に失敗扱いして次へ進めないという点です。企業間で業務の主体が変わるほど、この違いは大きくなります。
8. 実運用で越えなければならない5つの課題
実行前の証拠検証は有力ですが、万能ではありません。実運用では少なくとも次の問題が残ります。
証拠の真実性：署名された虚偽データ、侵害された鍵、誤ったセンサー値をどう扱うか。
判定経路の完全性：管理者操作、別API、直接DB更新などでゲートを迂回できないか。
時間差と並行実行：判定と作用の間に条件が変わる問題や、複数操作の競合をどう防ぐか。
結果不明時の継続性：通信断で終端状態が分からないとき、二重作用を防ぎながらどう回復するか。
保証範囲の説明責任：モデル上の証明、テスト結果、実機の観測を混同せず、何が未確認かを示せるか。
「証拠があれば必ず安全」ではなく、確認できないものを確認できた扱いにしないことが、保証の信頼性を左右します。
おわりに：守る対象は「アクセス」から「実行の妥当性」にも広がる
ネットワークの入口を守ること。攻撃の兆候を見つけること。主体と権限を検証すること。これらは今後も不可欠です。
ただし、AIエージェントが現実の業務を動かす場面では、さらに一つの問いが必要になります。
その操作は、今この状態で、検証できる根拠に基づいて実行してよいのか。
ここに「境界型・検知型セキュリティの限界」を考える意味があります。既存のセキュリティを否定するためではなく、既存の防御だけでは判断しきれない、実行時点の業務上の正当性を扱うためです。
AIが何を提案するかだけでなく、どの操作を許し、どの操作を止め、どの結果を成功と認めるのか。その条件と根拠を、AIの説明から独立して検査可能にする。
特に重要なのは、操作の返信が失われても、実行がなかったと推測して次の相手へ進めないことです。正規の通信だけで起こり得る二重処理を、業務状態と証拠に基づいて防ぐ。この具体的な課題に対し、公開モデル・模擬企業間通信・再検証可能な証拠を組み合わせて検証していることが、現段階の当社PoCの訴求点です。
それが、AIエージェント時代のサイバーアシュアランスで追求すべき重要な方向だと考えています。
## 参考文献・一次資料（本文の番号に対応）
以下は、**公的機関の原文、原著研究、仕様の公開元、当社の公開実装**に限定した資料です。各文献について、本文で何を支えるかと、読み過ぎてはいけない点を併記しました（2026年11月2日時点）。
### 境界・検知・AIエージェントの脅威
**[1] NIST, _Zero Trust Architecture_, SP 800-207（2020年）**
ネットワーク境界による暗黙の信頼を排し、個々のリソースへの認証・認可を考えるための基礎文書。**ゼロトラストに実行前の認可がない、という主張は本資料と矛盾します。**
**[2] NIST, _Guide to Intrusion Detection and Prevention Systems_, SP 800-94（2007年）**
IDSとIPSの区別を含む原典。検知型が事後検知に限られないことを理解するために使用。古い刊行物のため、2026年の製品性能を比較する根拠にはしません。
**[3] Debenedettiほか, _AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents_, NeurIPS 2024**
ツール出力を通じたプロンプトインジェクションを評価する査読済み研究。97の通常タスク・629のセキュリティテストケースという評価基盤が重要です。
**[4] Dziemianほか, _How Vulnerable Are AI Agents to Indirect Prompt Injections? Insights from a Large-Scale Public Competition_（2026年、原著プレプリント）**
464名、約27万2,000件の攻撃試行、8,648件の成功例を報告。**実社会における一般的な侵害率ではなく、特定の競技・評価条件下の結果**です。
**[5] UK NCSC, _Prompt injection is not SQL injection (it may be worse)_（2025年12月8日）**
外部データをLLMが誤って指示として扱う危険と、非LLMの決定論的な実行制約の重要性を解説。今回の記事の設計上の中心的な根拠です。
**[6] 日本AISI, 『AIインシデントレスポンス・アプローチブック』（2026年1月9日）**
AI特有のインシデントと発見的統制の重要性を整理。**事前制御と、検知・対応を組み合わせる必要性**の根拠です。
**[7] OWASP GenAI Security Project, _Top 10 for Agentic Applications 2026_（2025年12月公開）**
ASI02のツール悪用、ASI03の権限悪用、ASI08の連鎖的障害などを示す専門家コミュニティのガイダンス。法令や適合認証ではありません。
**[8] 日本AISI, 『AIセーフティに関する評価観点ガイド 第1.20版』（2026年7月7日）**
AIエージェント特有の「観測と制御」、自律的な挙動、外部環境との相互作用を評価する国内の一次資料。
**[9] NIST, _Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents_（2026年5月18日）**
AIエージェント固有の新しい脅威と、既存セキュリティ原則の適応が必要という意見を整理した報告。**RFI回答の集約であり、NIST独自の攻撃実験ではありません。**
### 実行制御・検証可能性の先行研究
**[10] NIST CSRC, _Reference Monitor_（NIST SP 800-53 Rev.5由来の用語定義）**
すべてのアクセスを仲介し、改ざんに耐え、分析・検査可能であるという古典的な要件の確認先。AI実行保証の実装が自動的に同等の保証を得るわけではありません。
**[11] Debenedettiほか, _Defeating Prompt Injections by Design_（IEEE SaTML 2026）**
CaMeLによる制御フローとデータフローの分離、およびツール呼出し時の制約を示した査読済み研究。設計によってLLMの脆弱性の影響を抑える先行例です。
**[12] Wang, Poskitt, Sun, _AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents_（ICSE 2026）**
ルール言語と実行時の安全制約を扱う査読済み研究。報告された有効性は論文の各評価設定に基づきます。
**[13] Kaul, Lan, Gupta, _AgentBound: Verifiable Behavioral Governance for Autonomous AI Agents_（2026年6月、プレプリント）**
既存の認可と、個別操作の実行妥当性を区別する先行提案。ガバナンス判断の検証可能な記録を扱います。**論文自身が、実測評価結果は今後の公開としています。**
**[14] Ciliberto, Rudi, Tassi, _Proof-Carrying Contracts: Commitments AI Agents Cannot Break_（2026年10月、プレプリント）**
操作に先立って機械検査可能な証明を要求するProof-Carrying ContractsとAirlockを提案。実世界全体の無条件な安全性ではなく、形式化した制約と信頼前提を確認して読むべき資料です。
**[15] OWASP GenAI Security Project, _Agent Control Standard (ACS)_（2026年9月）**
AIエージェントの実行時フック、制御、追跡を共通化する公開仕様。公開リポジトリ：https://github.com/GenAI-Security-Project/agent-control-standard 。仕様と参照実装の成熟度は区別が必要です。
### 当社の公開PoC（上記の公的研究とは別区分）
**[16] 株式会社AIアシュアランス, _Cold Chain Cyber Assurance — Public PoC 5.0_（2026年）**
公開CI：https://github.com/GhostDriftTheory/verifiable-coldchain-cyber-assurance/actions/runs/41254070906
公開抽象モデルの形式検証、実装照合、署名付き既存証拠の検査を確認できる資料。実運用全体の保証や第三者認証ではありません。
**[17] 株式会社AIアシュアランス, _VPI Cyber Assurance v2.0.0-rc2_（2026年）**
公開CI：https://github.com/GhostDriftTheory/verifiable-physical-internet-cyber-assurance/actions/runs/41254040449
模擬企業間の通知操作・結果不明時の保留・切替え制御を検証する参照実装。実物流や本番ネットワークの安全性を直接証明するものではありません。
### 技術比較を補強する追加一次資料
**[18] AWS Open Source Blog, _Introducing Dogwood: runtime verification for AI agents_（2026年8月6日）／_Introducing the Dogwood Local Engine: temporal governance for agent actions_（2026年9月30日）**
履歴と時間に基づく操作判定、並行するイベントの扱い、再起動後に引き継ぐ状態について、開発元が具体的に説明している一次資料。**時系列・状態管理は既存研究にない、という主張を避けるために採用**。
**[19] Amazon Builders' Library, Malcolm Featonby, _Making retries safe with idempotent APIs_**
返信消失・再送・重複作用を防ぐための冪等API設計と、要求識別子を使った整合性維持の一次資料。**二重作用防止そのものは新規ではない**ことを理解するために採用。
**[20] AWS Prescriptive Guidance, _Saga patterns_**
複数システムにまたがる局所トランザクション、部分障害、補償処理の代表的な既存パターン。VPI PoCの実証対象を既存の分散処理技術と区別するために採用。
**[21] ICME Labs, _PreFlight — AI Agent Verification with Cryptographic Proof_（2026年公開の製品資料）**
実行前の検査とゼロ知識証明による独立照合を提供するとする、開発元の一次資料。**独立検証という着想の独占を主張しないための比較対象**。公開された製品側の自己説明であり、外部による網羅的な性能・安全性監査結果ではありません。
コメント