書き換え可能なデータベースログは証拠にならない——書き込み権限を持つ者なら誰でも改変でき、編集後もテーブルは編集前とまったく同じように信頼できるように見える。改ざん不能な監査証跡はこれとは異なる。ハッシュチェーンで連結され、独立して検証可能な台帳であり、各イベントが直前のイベントにリンクしているため、改ざんは単に抑止されるのではなく検知可能になる。ここでは、それが技術的に何を意味するのか、そしてそれがAIエージェントに具体的にどう当てはまるのかを説明する。
AIエージェントのための改ざん不能な監査証跡とは、追記専用でハッシュチェーンによって連結されたイベントログであり、各エントリの暗号学的ハッシュが直前のエントリのハッシュを組み込んでいるものである。そのため、シーケンスのどこかで変更、削除、挿入が行われると、チェーンは壊れ、独立して数学的に検知可能になる。これは、単にポリシーによって編集から保護されているだけのデータベースではない——改ざんがそれ自体の避けられない証拠を残す構造である。
本番システムにはすでにログが存在する。アプリケーションログ、リクエストトレース、occurred_at列とその発生元エージェントへの外部キーを持つPostgresテーブルなど。問題はこれらが存在しないことではなく、それ自体の完全性について何も証明できないことである。
そのいずれにも悪意は必要ない——通常の運用上のデータベースアクセスがあれば十分である。書き換え可能なログは一つの主張にすぎない——これが起きたことです、信じてください、というものだ。メール送信、送金、顧客データへのアクセスといった実際の行動を取る自律型エージェントにとって、いずれ誰かが「このエージェントは実際に何をしたのか、その記録が正確だとどうやって分かるのか」と尋ねたとき、単なる主張では不十分である。
その仕組みは見た目より単純である。台帳の各イベントにはcontent_hashがあり——そのイベントの内容の暗号学的ハッシュであり——イベント自身のデータと、直前のエントリを指すprevious_event_hashを計算に組み込む。つまり、各イベントのハッシュは、その時点までのチェーン全体の履歴に依存しており、イベント自体だけには依存していない。
新しいイベントはチェーンの末尾に追記される。この設計には更新や削除の操作は存在しない——台帳は増え続けるだけである。
イベントNのハッシュはイベントN−1のハッシュを組み込んでいる。イベントN−1について後からでも何かを変更すると、イベントNが直前のエントリとして記録したものとは異なるハッシュが生成される。
検証パスはすべてのエントリを走査し、内容と記録された直前のエントリから期待されるハッシュを再計算して、保存されている値と一致するかを確認する。どこか一箇所でも不一致があれば、その時点以降のチェーン全体が壊れる。
これはブロックチェーンやGitのコミット履歴の背後にあるのと同じ構造的発想——コンテンツアドレス方式で連結された参照——を、通貨台帳やコードベースではなく監査ログに適用したものである。
VeriSwarm Vaultは追記専用でハッシュチェーンによって連結された台帳であり、Maxプランで利用できる。スイートを通じて処理されるあらゆるイベント——トラスト判定、Guardスキャンの検出結果、Passport検証、エージェントのライフサイクル変更——は、別途ロギング呼び出しを行うことなく自動的にそこへ書き込まれる。各台帳エントリには次が記録される：
event_id, actor_type / actor_id, subject_type / subject_idevent_type, source, occurred_at, ingested_atcontent_hash — このイベントの暗号学的ハッシュprevious_event_hash — 直前のエントリのハッシュ整合性は、GET /v1/suite/vault/verifyオンデマンドで確認できる。このエンドポイントはチェーンを走査し、確認済みエントリ数とともに整合性が保たれているかどうかを返す。検証失敗はデータ品質の問題ではなくセキュリティインシデントとして扱われる——チェーンが壊れているということは、まさに台帳が証明すべきことを証明できなくなっていることを意味するからである。台帳データはエクスポートすることもでき（JSONまたはCSV、イベントタイプ・アクター・エージェントでフィルタ可能）、オフライン検証用のチェックサムも付与される。フィールドレベルの完全な詳細はVaultのドキュメント.
現時点で最も明確な具体的適用例はEU AI Actである。第12条は、高リスクAIシステムに対し、リスク状況を特定でき、第26条の6か月保持期間を耐え抜ける形式でイベントをその存続期間全体にわたって自動的に記録することを義務付けている。ハッシュチェーンによって連結された台帳こそが、「ログはあります」を、規制当局や監査人が実際に信頼できる証拠へと変える。その要件、そしてVaultがそれにどう対応するかについては、AIエージェントのためのEU AI Act第12条ロギングで解説している。改ざん不能な監査証跡は一般的なメカニズムであり、第12条はそれを持つべき具体的かつ現在執行可能な理由の一つにすぎない。
改ざん不能とは、ストレージ層が物理的に書き込みを防ぐという意味ではない——ほとんどのデータベースは、十分なアクセス権を持つ者であれば技術的に編集できる。改ざん不能とは、改ざんが検知可能であるという意味である。ハッシュチェーンで連結された台帳では、各イベントのコンテンツハッシュが直前のイベントのハッシュを組み込んでおり、そのため各エントリは暗号学的に直前のエントリとリンクしている。チェーンのどこかでレコードを変更、削除、挿入すると、それ以降に計算されるすべてのハッシュが一致しなくなる——改ざんは見えないまま残るのではなく、検証時に即座に表面化する。
通常のログ——アプリケーションログ、Postgresの監査テーブル、CloudWatchのエントリ——は、イベントが発生したことを記録する。しかし、その記録がその後改変されていないことは証明しない。そのテーブルへの書き込み権限を持つ者（エンジニア、侵害されたクレデンシャル、自動化されたクリーンアップスクリプト）は誰でも行を編集または削除でき、テーブルは以前とまったく同じように信頼できるように見える。ハッシュチェーンで連結された台帳はこのギャップを埋める：整合性は主張されるものではなく、チェーン検証によって数学的に確認できるものになる。
検証は最初のイベントから台帳を順に走査し、各エントリの内容と記録された直前のエントリのハッシュから期待されるハッシュを再計算し、保存されている値と一致するかを確認する。VeriSwarm Vaultはこれを GET /v1/suite/vault/verify として公開しており、確認済みエントリ数とともに ok: true または false を返す。false という結果は、通常の運用の外でレコードが変更、削除、または挿入されたことを意味する——VeriSwarmのガイダンスでは、これをデータ品質のバグではなくセキュリティインシデントとして扱うべきとしている。
VeriSwarm Vaultでは、スイートを通じて記録されるあらゆるイベント——トラスト判定（allow/review/deny）、Guardのセキュリティスキャン検出結果、Passportのアイデンティティ検証、エージェントのライフサイクル変更（kill switch、委任の付与）——が、Vaultが有効化されると自動的に書き込まれる。各エントリにはアクター、サブジェクト、イベントタイプ、タイムスタンプ、ペイロード、そしてチェーン連結用のハッシュが記録される。別途ロギング呼び出しは不要であり、これはエージェントがプラットフォームを通じて通常どおり動作することの副産物である。
規制はそれを望む理由の一つであり——EU AI Act第12条の記録保持義務はその直接的な例である——しかし根底にあるニーズはもっと広い。意味のある自律性（ツールへのアクセス、顧客対応の行動、金融やPIIの取り扱い）を持つエージェントは、いずれ誰かが「このエージェントは実際に何をしたのか、その記録を信頼できるのか」と尋ねる瞬間を生み出す。書き換え可能なログはそれに対して主張で答える。改ざん不能で独立して検証可能なログは、それに証拠で答える。
いいえ——ハッシュチェーンによって連結された台帳とチェーン検証エンドポイントを含むVaultはMaxプランの機能である。Gateの無料プランはトラストスコアリングとイベント取り込みをカバーするが、改ざん不能な監査台帳そのものは有料機能である。現在のプラン詳細は/pricingを参照してほしい。
VaultはMaxプランの機能である——ハッシュチェーンによる台帳、チェーン検証、エクスポートは無料プランには含まれない。完全な技術リファレンスを読むか、特定の規制にどう対応するかを確認してほしい。