Aletheia Runtime Safety & Scope Creep Filter

Aletheia MCP サーバー 🛡️

ミリ秒未満で動作するランタイムフィルターです。AI エージェントが実行する前に、スコープ逸脱やプロンプトインジェクションを伴うツール呼び出しをブロックします。

Aletheia MCP は、Claude Code、Claude Desktop、およびその他のMCP互換エージェントからのツール呼び出しを、実行される前にインターセプトし、破壊的な呼び出しをブロックします。オーバーヘッドは**ミリ秒未満（約25 µs）**で、処理のクリティカルパスにLLMは介在しません。

これは、Aletheiaの研究論文で分類されている9つの行動シグネチャを動機としています。これらは、モデルが環境に働きかけるインターフェース（出力／現実、入力／信頼、タスク／スコープなど）に基づいて導かれた、ID付きの反復的なLLM失敗パターンです。このサーバーは、そのうち2つを対象とします。

• S3（権限の範囲を超えたスコープ逸脱）：エージェントが実際に与えられたタスクの範囲外で行動します。ワークスペース外のファイルを書き込んだり、無関係なシステムに手を出したり、指示された作業の範囲をひそかに広げたりします。
• S2b（論文での命名によるジェイルブレイク脆弱性）：このサーバーには、ツールの結果、ファイルの内容、取得したデータに紛れ込ませた敵対的な指示という関連問題に対する、実用的なパターンベースのヒューリスティックが含まれています。これはS2bに着想を得たエンジニアリング上のヒューリスティックであり、論文独自の実証的なS2bの知見を実装したものではありません。論文では、より安定した攻撃分類が整うまで、S2bの評価を明確に先送りしています（「定義済みの次のステップとして位置付ける」）。また、このサーバーのキーワード／パターン照合は、その評価で測定されるものとは異なる、より限定的なものです。

論文では、3つの独立したコーパスに含まれる2,571件の事例を用いて、これら9つのシグネチャを検証しています。内訳は、AI Incident Database（AIIDと人手で精選した補足データ、n=1,134）、AVID AI Vulnerability Database（n=767）、MIT AI Risk Repository（n=670）です。モデルごとの検出率は、その手法とともに論文で報告されています。これらの数値は、これらのシグネチャが重要である理由を示す参考情報として扱い、このコードベースを独立監査したベンチマークとはみなさないでください。

---

セキュリティモデル：サンドボックスではなく、高速な事前フィルター

Aletheia MCP は、決定論的なパターンベースの字句・構造フィルターです。検査対象となるシェル、SQL、ファイルシステム、ネットワークの各領域に対して、敵対的なレッドチームテストを何度も繰り返し、反復的に強化してきました。テストを重ねるたびに実際の見落としが見つかり、その都度修正して再検証しています。このプロセスは現在も続いており、完了することはありません。これは Bash と SQL に対する誠実なヒューリスティックなパターンマッチングであり、正式なパーサーでも、完全性の証明でもありません。

重要

これが何であり、何ではないか：

• Aletheia は高速な第一段階の実行前フィルターです。オーバーヘッドは数マイクロ秒から数十マイクロ秒程度で、決定論的に動作し、処理の主要経路に LLM は使いません。既知の破壊的な操作、データ流出、SSRF、権限昇格のパターンを幅広く検出し、実行前に阻止します。検出対象は継続的に拡大しています。
• Aletheia はサンドボックスでも、正式な保証でも、それらの代替でもありません。最小権限の認証情報、非 root のシステムユーザー、スコープを限定したデータベース権限、コンテナーまたは VM レベルの隔離（Docker、gVisor、Firecracker）の代わりにはなりません。シェルや SQL のテキストを解析して両言語を完全に理解するのではなく、既知の危険なパターンを認識する仕組みのため、十分に新規性の高い、または難読化された構文は、原理上、現在のパターンセットではまだ対応できていないものが必ず見つかる可能性があります。これはチューリング完全なシェルに対するパターンベースのフィルタリングに固有の性質であり、将来のパッチで完全に解消できる不具合ではありません。
• Aletheia は DNS の名前解決を行いません。そのため、攻撃者が管理するドメイン名がプライベート IP やクラウドのメタデータエンドポイントを指していても、文字列ベースのフィルターではこの層で検出できません。その対策には DNS を認識する送信トラフィック制御が必要です（SECURITY.md を参照）。
• 適切な運用方法は、Aletheia を、よくある簡単な失敗を低コストで防ぐ一つの層として扱い、実際のセキュリティ境界となる OS／ネットワークレベルのサンドボックスと組み合わせて使うことです。サンドボックスの代わりに使うものではありません。

既知の制限事項（網羅的ではありません。判明次第更新）

• 検出対象は、既知の危険な関数、フラグ、構文パターン（特定の SQL 関数、特定のシェル難読化の慣用表現など）を列挙したものです。パターンセットにまだ追加されていない類似の変種や新しい変種は、発見されて追加されるまで検出されません。
• DNS の名前解決は行いません。SSRF 対策の対象はリクエストテキスト内のリテラル IP アドレス／ホスト名に限られ、ドメイン名が実際に解決される先は対象外です。
• S2b（プロンプトインジェクション）の検出はキーワードとパターンに基づいています。意味を分類するものではなく、十分に新規性の高い表現で回避できる可能性があります。
• これは単一の実装であり、現在も積極的に反復改善されています。このリポジトリのコミット履歴に記録された反復的な自己テスト以外に、独立した第三者による敵対的レビューはまだ受けていません。

---

エージェントランタイムにおける問題：スコープクリープ（S3）

自律型エージェントにツールの実行権限（Bash、SQL、ファイルシステムの変更、API 呼び出し）が与えられた場合、主な失敗モードは権限範囲を超えた行動です。

• 破壊的なシェル操作：「git diff を調査して」と頼まれたエージェントが、競合を解決するために git reset --hard や rm -rf * を実行します。
• 認証情報の収集：コードを読み取るエージェントが、接続エラーを解決するために ~/.ssh/id_rsa、.env、AWS の認証情報を探ります。
• 無制限のデータベース書き込み：エージェントが、WHERE 条件を付けずに（または恒真となる WHERE 1=1 を付けて）DELETE FROM accounts; や UPDATE users SET role='admin'; を実行します。
• インタープリターの抜け道：エージェントが、python3 -c "os.system('...')" や node -e "fs.rmSync('/')" のように、シェルコマンドをラップして実行します。
• SSRF とクラウドメタデータの漏えい：ネットワークのエンドポイントを調査するエージェントが、169.254.169.254（AWS メタデータ）や内部の RFC1918 サブネットにリクエストを送信します。
• 権限の自己拡大：プロンプトインジェクションを受けた、または振る舞いが逸脱したエージェントが、自身の安全ポリシーを書き換えようとします。

既存の防御策は LLM-as-a-judge による評価に依存しており、ツール呼び出しごとに 1,500～3,000 ms の遅延が発生します。Aletheia MCP は、単桁マイクロ秒で確定的な多段階の字句・構造フィルタリングを実行します。

---

主な機能

以下のリストは、網羅的な分類体系として最初から設計されたものではなく、反復的な敵対的テストを通じて構築された、現在のパターンセットで検出できる内容を示しています。検出対象ではないもの（DNS のケースでは、現時点でも今後も対象外となるもの）については、上記の既知の制限をご覧ください。

• ⚡ ミリ秒未満（p99 で約 25 µs）のオーバーヘッド：毎秒 100,000 回以上の評価を実行します。エージェントのループで体感できる遅延はありません。
• 🛡️ 権限の単調なエスカレーションを防止：自律型エージェントが書き込み、破壊的操作、ネットワークの権限を自ら付与するのを防ぎます。権限は自発的に強化できますが、緩和するには operatorSecret が必要です。
• 🎯 回避耐性を強化したエンジン：
  • データベースの OS およびファイルシステムプリミティブ：PostgreSQL の COPY ... PROGRAM、pg_read_file()、lo_import()、MySQL の LOAD DATA INFILE、INTO OUTFILE、SQLite の ATTACH DATABASE、SQL Server の xp_cmdshell をブロックします。
  • スキームなし・不正な URL に対する SSRF 防御：プロトコル相対およびスキームなしのエンドポイント（169.254.169.254/latest）を正規化し、無効な URL を厳格なフェイルクローズ方式で拒否します。また、オフライン権限のもとではクラウドメタデータへの直接アクセスを拒否します。
  • シェルからのメタデータへの直接アクセスとネットワークツールの無効化：URL スキームなしで curl／wget に指定された直接の IP 参照をスキャンし、socat による生ソケット経由のデータ流出チャネルをブロックします。
  • ワイルドカード認証情報と機密ディレクトリの境界：すべての .env.* 形式（.env.secrets、.env.staging、.env.test）および機密設定のルート（~/.kube/、~/.docker/、~/.gnupg/、.git-credentials）に対して、ワイルドカード保護を適用します。
  • 線形 O(N) 正規化：トークンベースの非バックトラッキング式ブレース展開と、有界なパラメーター解決により、100KB 以上のペイロードでもミリ秒未満の実行時間を実現します。
  • Bash ソケット擬似デバイスのインターセプト：/dev/tcp/HOST/PORT および /dev/udp/HOST/PORT へのリダイレクトを検査し、シェル入力の段階でクラウドメタデータへの SSRF や隠れたデータ流出チャネルを直接遮断します。
  • SQL CTE と手続き型ブロックのインターセプト：共通テーブル式（WITH ... DELETE）および PL/pgSQL の匿名ブロック（DO $$ ... $$）に対して、制限のない変更を防止します。
  • 動的リンカー乗っ取りの防御：LD_PRELOAD、DYLD_INSERT_LIBRARIES、および実行時の環境変数の乗っ取りを無効化します。
  • 引用符とバックスラッシュの除去：トークン分割による回避（r'm' -rf /、r\m -rf /）を防ぎます。
  • 変数の間接参照とデフォルト値へのフォールバック：シェル変数の置換（X=rm; $X -rf /）とデフォルト値を使ったパラメーター展開（${X:-rm} -rf /）を解決します。
  • 位置パラメーターと IFS の正規化：$IFS$9 による単語分割を無効化します。
  • 二重表現による SQL 分析：インラインコメントを使った回避（DROP/**/TABLE、DR/**/OP、および # MySQL comment）を防ぎます。
  • インタープリターのエスケープをインターセプト：文字列の連結（'r'+'m'）を再帰的に正規化し、動的インポート（import("node:fs")）を検査します。また、python、node、ruby、perl、php、sh で -c／-e／-r フラグに渡されるコードを解析します。
  • 16 進数と Base64 の自動デコード：16 進数（bytes.fromhex(...)）および Base64 でエンコードされたコマンドペイロードを自動的に抽出、デコードし、再帰的に評価します。
  • Unicode NFKC とゼロ幅文字のサニタイズ：プロンプトインジェクション（S2b）に含まれる不可視文字（\u200B、\u200C、\uFEFF）や、紛らわしい全角文字・数学用ボールド体による脱獄表現を無効化します。
  • IPv4 マップ IPv6 の SSRF 変換：圧縮形式の 16 進数 IPv6 表記（[::ffff:a9fe:a9fe]）を正規形式のドット区切り 10 進数バイト列（169.254.169.254）に変換します。
  • パーセントエンコードされたパストラバーサル：複数回の URL デコードにより、%2e%2e%2f.env や ..%2f.ssh%2fid_rsa を検出します。
  • 汎用フォークボム：任意の関数識別子にまたがる、再帰的にパイプされたバックグラウンドプロセスを検出します。
  • SetUID による権限昇格：chmod u+s、chmod 4755、および権限の改ざんを阻止します。
  • 恒真 SQL 述語：WHERE 1=1、WHERE true、および恒真式を、制限のない変更として検出します。
  • 多相引数の検査：ネイティブツールと認識されていないサードパーティ製ツールの両方で、文字列、配列、オブジェクトを安全に検査し、フェイルクローズ方式で処理します。
• 🛡️ 2 つの動作モード：
  1. 直接ガードツール：スタンドアロンツール（aletheia_set_mandate、aletheia_intercept、aletheia_safe_bash、aletheia_safe_sql）。
  2. フェイルクローズ型の透過プロキシ：任意の下流 MCP サーバー（Postgres、Filesystem、Bash）をラップするミドルウェアです。単一の tools/call と JSON-RPC 2.0 のバッチ配列の両方をインターセプトし、厳格なフェイルクローズ境界を適用します。
• 📊 リアルタイムの可観測性リソース：aletheia://telemetry/summary を介して、監査ログ、ブロック率、レイテンシ分布をリアルタイムで公開します。
• 🔒 外部 API 呼び出しゼロ：実行のホットパスで、LLM を判定役とする処理による遅延は発生しません。

---

パフォーマンスベンチマーク

10,000 回連続で複数ドメインを評価して測定しました（Bash の難読化解除、SQL パターン検証、パス検証、SSRF チェック、プロンプトインジェクション）。以下の数値は代表的なローカル実行での結果です。p50 は実行ごとに安定していますが、p99 はシステム負荷によって変動します（観測範囲は約 24～70 µs）。マイクロ秒単位では GC の一時停止に敏感なためです。それでも、どちらもミリ秒未満という目標を十分に達成しています。

指標	測定値	目標
p50（中央値）	約 0.0085 ms（8.5 µs）	< 0.500 ms
p95 レイテンシ	約 0.0180 ms（18 µs）	< 0.800 ms
p99 レイテンシ	約 0.024～0.070 ms（24～70 µs）	< 1.000 ms
スループット	100,000+ 回の評価 / 秒	> 10,000 / 秒
ホットパスの外部 API	0（決定論的なローカルエンジン）	0

ローカルで npm run benchmark を実行してください。 結果はマシンによって異なります。具体的なマイクロ秒単位の数値は、厳密な SLA ではなく「余裕をもってミリ秒未満」であることを示す例として捉えてください。

マイクロ秒レベルのオーバーヘッドを実現する仕組み

これを実現する単一の秘訣があるわけではありません。処理を遅くする要因がないことに加え、実装上の工夫をいくつか取り入れています。

1. ホットパスに LLM は一切ありません。 判定はすべて、プロセス内で同期的に実行される JavaScript によって行われます。ネットワークの往復も、モデルの推論もありません。これが最大の要因です。LLM を判定役として使うと、リモート推論リクエストのため 1.5～3 秒かかりますが、こちらはローカルでの文字列照合なのでマイクロ秒単位で済みます。
2. 正規表現パターンはモジュールの読み込み時に一度だけ事前コンパイルされ、呼び出しごとに再構築されることはありません。 各パターンリスト（DESTRUCTIVE_SIGNATURES、SENSITIVE_PATH_PATTERNS、OBFUSCATION_PATTERNS など）は、サーバーの起動時に構築された RegExp オブジェクトで、プロセスの稼働中は再利用されます。V8 は正規表現の内部表現を一度だけコンパイルするため、リクエストごとの再コンパイルコストは発生しません。
3. 入力は短く、処理は線形です。 シェルコマンド、SQL クエリ、パス、URL は通常、数十～数百文字です。その程度の文字列に対して正規表現を十数回順番に適用する処理は、本質的に数マイクロ秒で完了します。（この前提が一度だけ崩れたことがあります。通常の入力では問題なかった O(n²) の正規化処理が、敵対的な 100KB のペイロードに対して 18 秒かかりました。これはコミット履歴に記録され、修正済みです。既知の制限を参照してください。）
4. ディスパッチで行う処理は上限があり、すべてを網羅するものではありません。 評価器はまず、ツール名の安価な部分文字列チェックによって、ツール呼び出しがどのドメイン（bash、SQL、ファイルシステム、ネットワーク）に属するかを特定します。その後、そのドメインのチェックだけを実行し、呼び出しごとに全ドメインのすべてのチェックを実行することはありません。
5. 固定サイズの記録領域。 監査ログとレイテンシ履歴のバッファーにはそれぞれ 500 件、2,000 件という上限があり、償却 O(1) の操作で管理されます。そのため、サーバーの稼働時間が長くなっても、呼び出しごとのオーバーヘッドは増えません。これは仮定ではなく、直接検証済みです。300 万回の連続評価を行っても、処理性能は約 154,000 回／秒で一定し、低下傾向は見られませんでした。

正確な数値について指摘された場合の率直な注記： 約 25µs という数値は、プロセス内の評価関数そのものの処理コストです。高解像度の単調時計を使い、その関数呼び出しの直前と直後を直接計測しています。実際の MCP セッションにおける JSON-RPC のシリアライズや標準入出力パイプの I/O は含まれておらず、これらの分だけオーバーヘッドが加わります。裏付けられる主張は「ホットパスに LLM がなく、エンドツーエンドで余裕をもってミリ秒未満」であり、「測定方法にかかわらず、正確に 25 マイクロ秒」ではありません。

---

本番環境への対応状況とスケールテスト

ユニットテストスイートに加え、これらは合成的なプロセス内ループではなく、実際に起動したプロセスと実際の下流 MCP サーバー（@modelcontextprotocol/server-filesystem）に対する、再現可能なテストです。npm run test:scale:concurrent と npm run test:scale:isolation で実行できます（ソース：test/scale-*.mjs）。

テスト	確認内容	結果
継続負荷（評価 300 万回、単一インスタンス）	長時間実行におけるメモリ増加／スループット低下。定期的な権限設定の変更とテレメトリの読み取りも混在	初期の約 50 万回の評価によるウォームアップ後、ヒープは約 8.3MB で横ばい。全実行を通じて、劣化傾向はなく、毎秒約 154,000 回の評価を継続
複数インスタンスの同時実行（シミュレーション上の顧客 30 社、実際に起動したプロセス）	独立した Aletheia と下流サーバーのペアを多数同時に実行した際の正確性と分離	合計 4,800 件の操作で、タイムアウト 0 件、正確性の失敗 0 件 — 同時に行われた敵対的なパストラバーサルの試行 1,200 件はすべてブロックされ、問題のない書き込みと読み戻しはすべて正しく一致し、相互汚染もありませんでした
顧客間の分離（対象を絞ったテスト）	ラップ対象のサーバーではなく、Aletheia 自身の --allowed-paths 境界によって、あるインスタンスが別のインスタンスのデータを実際に読み取れないようにできるか	下流サーバーに両方のディレクトリへのアクセスを意図的に許可していた場合でも、顧客 A は顧客 B の通常の（「機密」ではない）ファイルを読み取れませんでした。コンテンツ漏えいは 0 件
現実的な誤検知の確認（114 個のコマンド：git、npm/yarn/pnpm、python/pip/poetry、docker/kubectl、make/cargo/maven/gradle、ファイル操作、実際の API への curl、一般的な SQL）	一般的な開発者のワークフローが誤ってブロックされないか	推奨される --allow-write --allow-network 設定で、誤検知 0 件（0.00%）
下流サーバーのクラッシュ処理	ラップ対象のサーバーがセッション中に予期せずクラッシュした場合の動作	約 4ms で検出し、終了コードを正しく伝播。ハングや孤立プロセスのないクリーンなシャットダウン（Aletheia はクラッシュした下流サーバーを自動再起動しません。stdio MCP サーバーのペアと同様に、併せて終了します）
Node の最小バージョン	engines: >=18.0.0 という宣言が実際に正しいか	テストスイート全体（155/155）と、server-filesystem に対する実際のプロキシセッションが、開発マシンのより新しいバージョンだけでなく、Node 18.20.8 でもパスすることを確認

これらの結果は、長期にわたる予測不可能な実際の使用に代わるものではありません。ツールにバグがないことを証明するのではなく、初期の実使用で深刻な問題となる特定の障害要因（誤った Node バージョン、メモリリーク、高い誤検知率、インスタンス間の干渉）を排除するものです。

---

クイックスタート

ヒント

Aletheia はデフォルトで完全にロックダウンされた状態（読み取り専用、ネットワークなし、ループバックなし）で起動し、意図的にその状態を維持します。 エージェントにファイルの書き込みやネットワーク呼び出しが必要な場合は、以下に示すように、起動時に --allow-write／--allow-network／--allow-loopback で許可し（書き込み先は --allowed-paths でディレクトリに限定し）、事前に権限を付与してください。これらのフラグはサーバー起動時の初期権限設定を行うものであり、operatorSecret による制限を受けません。この制限が適用されるのは、実行中のセッションの権限設定を途中で変更する場合のみです（たとえば、エージェントが aletheia_set_mandate を呼び出して自分の権限を緩和しようとする場合です。これは意図的にブロックされます）。ほとんどのユーザーに必要なのは、operatorSecret ではなく以下の起動フラグです。

1. Claude Code CLI

# Read-only (safe default; can inspect but not modify anything):
claude mcp add aletheia -- npx -y aletheia-mcp

# Practical default for a coding agent that needs to edit files in your project:
claude mcp add aletheia -- npx -y aletheia-mcp --allow-write --allowed-paths /path/to/your/project

2. Claude Desktop

claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "aletheia": {
      "command": "npx",
      "args": ["-y", "aletheia-mcp", "--allow-write", "--allowed-paths", "/path/to/your/project"]
    }
  }
}

3. 透過プロキシモード

既存の下流 MCP サーバーを Aletheia でラップし、安全性フィルタリングを適用します。

{
  "mcpServers": {
    "secure-filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "aletheia-mcp",
        "--allow-write",
        "--proxy",
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/allowed/dir"
      ]
    }
  }
}

---

ツールリファレンス

ツール	モード	注釈	説明
aletheia_set_mandate	状態	readOnlyHint: false	運用上の安全範囲を設定または厳格化します。緩和するには operatorSecret が必要です。
aletheia_get_mandate	可観測性	readOnlyHint: true	有効なマンデート、許可されたパス、リスク許容度を取得します。
aletheia_intercept	ゲートキーパー	readOnlyHint: true	ツール呼び出し候補を事前確認します。違反の詳細とともに ALLOW または BLOCK を返します。
aletheia_safe_bash	実行	readOnlyHint: false	検証済みのシェル実行ツールです。実行前に rm -rf、フォーク爆弾、データ流出をブロックします。
aletheia_safe_sql	監査	readOnlyHint: true	DROP、TRUNCATE、および範囲を限定しない DELETE／UPDATE（WHERE 1=1 を含む）に対して SQL を検証します。
aletheia_get_telemetry	可観測性	readOnlyHint: true	評価件数、ブロック率（%）、マイクロ秒単位のレイテンシパーセンタイルを出力します。

---

リソースとプロンプトのリファレンス

リソース（resources/read）

クライアントは、標準の MCP resources/read を使用して、必要に応じてサーバーの状態を確認できます。

• aletheia://telemetry/summary：リアルタイムの評価カウンター、ブロック率（%）、マイクロ秒単位のレイテンシ分布。
• aletheia://telemetry/audit-log：直近50件のツール許可リクエストについて、入力、判定、違反シグネチャ、タイムスタンプを記録したローリングログ。
• aletheia://mandate/current：アクティブなセッションのマンデートパラメーター、許可されたツールリスト、パスの境界、権限切り替え設定。
• aletheia://signatures/s3：Signature S3（スコープの拡大）に関する仕様、リスク分類、ベンチマーク失敗率データ。

プロンプト（prompts/get）

• aletheia_mandate_enforcer：運用上の安全境界を設定し、実行前にリスクの高いアクションを Aletheia に通すようエージェントに指示するシステムプロンプトのディレクティブです。task_description（必須）、workspace_root（任意）、allow_write（任意）を受け取ります。

---

アーキテクチャ

                    ┌───────────────────────────────────────────────┐
                    │          Claude / Agent Host Runtime          │
                    └───────┬───────────────────────────────┬───────┘
                            │                               │
                  Mode 1: Guard Tools              Mode 2: Transparent Proxy
                  (aletheia_intercept,             (Intercepts tools/call
                   aletheia_safe_bash)              to downstream MCPs)
                            │                               │
                            ▼                               ▼
            ┌───────────────────────────────────────────────────────────────┐
            │                      Aletheia MCP Server                      │
            │                                                               │
            │  ┌─────────────────────────────────────────────────────────┐  │
            │  │              S3 Scope Creep Engine (<10µs)              │  │
            │  │  ├─ Multi-stage Token Unquoting & De-obfuscation        │  │
            │  │  ├─ Variable Indirection Resolver                       │  │
            │  │  ├─ Positional IFS & Brace Expansion Normalizer         │  │
            │  │  ├─ Dual-Representation SQL Comment Analyzer            │  │
            │  │  ├─ Interpreter Escape Filter (python -c, node -e)      │  │
            │  │  ├─ Destructive Filter (rm -rf, fork bombs, find -del)  │  │
            │  │  ├─ SetUID / Privilege Escalation Guard                 │  │
            │  │  ├─ Credential & Sensitive File Access Guard            │  │
            │  │  ├─ SSRF & Cloud Metadata Validator                     │  │
            │  │  ├─ SQL DDL & Tautological Predicate Guard (WHERE 1=1)  │  │
            │  │  ├─ Monotonic Mandate Escalation Guard (operatorSecret) │  │
            │  │  └─ S2b Adversarial Prompt Injection Filter             │  │
            │  └─────────────────────────────────────────────────────────┘  │
            │                                                               │
            │  ┌─────────────────────────────────────────────────────────┐  │
            │  │ Telemetry & Audit Stream (aletheia://telemetry/summary) │  │
            │  └─────────────────────────────────────────────────────────┘  │
            └───────────────────────────────┬───────────────────────────────┘
                                            │
                              [ALLOW]       │       [BLOCK]
                    ┌───────────────────────┴───────────────────────┐
                    ▼                                               ▼
          Execute Tool Safely                         Emit Structured Policy Breach
                                                      (Explains boundary violation)

---

研究への謝辞と実証コーパス

Aletheia MCP は、より広範な Aletheia AI Safety Research Core の一環として、Vikas Shivpuriya が開発しています。基盤となる動作上の失敗シグネチャは、AI Incident Database（AIID）、AVID AI Vulnerability Database、MIT AI Risk Repository に記録されたインシデントに基づいています。最先端システム（Claude Sonnet 4.6、GPT-4o、Gemini 2.5 Flash）に関して言及されているモデル別の検出率は、その論文の評価ハーネスによるものです。これらは Signature S3 が重要である理由を示す参考情報として扱い、このコードベースの検証済みベンチマークとは見なさないでください。特に Signature S2b は、まだこの実証評価の対象になっていません。論文では今後の課題として先送りされているため、このサーバーの S2b フィルターは、論文の調査結果によって検証された実装ではなく、分類体系に基づく独立した実用的なヒューリスティックとして捉えてください。

このリポジトリで独立して検証できるものは、テストスイート（npm test）、レイテンシベンチマーク（npm run benchmark）、および敵対的テストの各ラウンドと、それによって実施された修正を記録したコミット履歴です。

• 研究論文と分類体系：github.com/vikasny30/aletheia-paper
• ライセンス：Apache 2.0