EthersFlow — Trust Gate for AI Agents

EthersFlow — エージェントアクション検証レイヤー（KYAA）

EthersFlow MCP は AI エージェントのアクション検証レイヤー（KYAA — エージェントアクションの確認）です。独立したモデルによる敵対的な審議会が、エージェントが実行しようとしている内容を精査し、実行前に署名済みで、独立して検証可能な判定を返します。

---

概要

KYA は、エージェントが誰で、何を許可されているかを確立します。KYAA（エージェントアクションの確認）は、エージェントが実際に何をしているかを、署名済みのアクションごとに検証します。ID によってエージェントは入口を通過できます。検証によって、エージェントが何を持ち出すかが決まります。

EthersFlow はアクションゲートです。エージェントの次のアクションを実行すべきか判断し、署名済みで独立して検証可能な証拠を添えて、その判断を公証します。証明のない強制はブラックボックスです。強制のない証明は、被害が発生した後に残る監査ログにすぎません。EthersFlow はその両方を担うチェックポイントです。

エージェントガバナンススタック

+-------------------+      +-------------------+      +-------------------------+      +-------------------+
| 1. IDENTITY (KYA) | ---> | 2. AUTHORIZATION  | ---> | 3. ACTION VERIFICATION  | ---> | 4. EXECUTION      |
|                   |      |                   |      |    (KYAA)               |      |                   |
| Proves: WHO       |      | Proves: IS IT     |      | Proves: IS THIS ACTION  |      | Runs tool / API   |
|                   |      |         ALLOWED?  |      |         LEGITIMATE?     |      |                   |
| Sumsub, Entrust,  |      | Google AP2, FIDO, |      | EthersFlow (Ed25519     |      | Agent runtime     |
| Persona           |      | OAuth mandates    |      | Signed Trust Verdict)   |      | rails             |
+-------------------+      +-------------------+      +-------------------------+      +-------------------+

ID が答えるのは「誰か」です。認可が答えるのは「許可されているか」です。EthersFlow が答えるのは「この特定のアクションは正当か」です。

   +-------------------------------------------------------------+
   |             Agent Host / MCP Client Environment             |
   |      (Claude Desktop · Cursor · LangChain · Custom Agent)    |
   +------------------------------+------------------------------+
                                  | MCP Tool Call: verify_agent_action
                                  v
   +-------------------------------------------------------------+
   |            @ethersflow/mcp-server (stdio / SSE / HTTP)       |
   +------------------------------+------------------------------+
                                  | HTTPS /api/v1/verify
                                  v
+-------------------------------------------------------------------------------+
|                 EthersFlow Action-Verification Gateway (KYAA)                 |
|                                                                               |
|   +-----------------------+               +-------------------------------+   |
|   |  Deterministic Kernel | (fast-path)   |  Adversarial Frontier Council |   |
|   |  & Catalog Matcher    | ------------> |  (Heterogeneous LLM Panel)    |   |
|   +-----------+-----------+               +---------------+---------------+   |
|               |                                           |                   |
|               +---------------------+---------------------+                   |
|                                     |                                         |
|                                     v                                         |
|                       +---------------------------+                           |
|                       |  Ed25519 Signature Engine |                           |
|                       +-------------+-------------+                           |
+-------------------------------------+-----------------------------------------+
                                      | Ed25519-Signed Verdict Receipt
                                      v
              +-----------------------------------------------+
              |   APPROVED / FLAGGED / REJECTED Decision Gate |
              |          (Agent halts or executes)            |
              +-----------------------------------------------+

---

レイテンシプロファイルとパフォーマンスベンチマーク

EthersFlow は、迅速な決定性と複数モデルによる敵対的な審議のバランスを取る、デュアルレーン実行エンジンを運用しています。

実行レーン	p50 レイテンシ	p95 レイテンシ	仕組み	保証と最終性
ポリシーのファストパス	126 ms	210 ms	決定論的な安全カーネルとカタログマッチャー（<$100、許可リスト登録済みベンダー、運用チケット、ファストパス前のインテントスクリーニング）。カーネルノードの評価は約 4 ms で完了します。	POLICY_FAST_PATH_APPROVAL
冪等性リプレイ	3.2 ms	4.5 ms	idempotency_key とアクションハッシュが繰り返された場合の、サブミリ秒の重複排除。	replayed: true
敵対的コンセンサス	1.7 s	2.0 s	異種のフロンティアモデル（Gemini 3.7 Flash + GPT-OSS-120B）間のリアルタイムな複数モデル審議と、暗号学的なノード証明（R74 で測定、プロバイダーのタイムスタンプ付き）。	POLICY_SUPERMAJORITY_APPROVAL / POLICY_FINAL_BLOCK

分割実行への防御と自動エスカレーション：自律エージェントが大規模な操作を複数の小口トランザクションに分割してポリシー制御を回避するのを防ぐため、安全性のしきい値を超えるリクエストや、異常な頻度を示すリクエストは、決定論的なファストパスから複数モデルによるコンセンサスレーンへ自動的にエスカレーションされ、徹底的に審議されます。

ポリシーに基づくしきい値：ファストパスの上限（例：低リスクの小口経費 <$100）、承認済みベンダー、チケットのアンカー要件（例：Jira、ServiceNow、Ops チケット）は、ポリシープロファイル（finops_default_v1 など）を通じて適用されます。これにより、通常のアクションには決定論的な速度を、高リスクの例外的なケースには複数モデルによる防御を実現します。

---

保持アーキテクチャと監査ログ

EthersFlow は、レシートを保持し、ペイロードを破棄するモデルによって、監査コンプライアンスと厳格なデータプライバシーを両立します。

• デフォルトの動作：一時的なゼロ保持（zero_retention: true）： デフォルトでは、EthersFlow は厳格な一時的ゼロ保持モード（durability: "none_zero_retention"、storage_engine: "zero_retention_ephemeral"、receipt_only_payload_discarded: true、retention_receipt_url: null）で動作します。プロンプト、推論チェーン、未加工のアクションペイロードは、暗号署名とレシートの配信後、直ちにメモリから破棄されます。アクションのテキストはどこにも保存されません。

• オプトインの永続監査保管庫（retention_mode: "durable" または zero_retention: false）： エンタープライズコンプライアンスのために永続的な監査ログが明示的に要求された場合、呼び出し元は retention_mode: "durable" または zero_retention: false を渡します。

  {
    "agent_action": "Order $42 notebooks from Staples under ticket FAC-902",
    "zero_retention": false
  }
  

  これにより、暗号レシートが永続監査保管庫に保存されます（durability: "durable_audit_log"、storage_engine: "firestore_durable"、retention_receipt_url: "/api/v1/receipts/{request_id}"）。

• 暗号によるアクションハッシュの紐付け（ペイロード漏えいゼロ）： 厳格なプライバシー不変条件：一時モードと永続モードの両方で、EthersFlow が紐付けるのは SHA-256 アクションハッシュのみです（action_hash: sha256(agent_action)）。未加工のプロンプトとアクションテキストがデータベース保管庫に永続化されることはありません。監査担当者は、機密性の高い業務プロンプトをストレージ侵害にさらすことなく、判定に対する Ed25519 署名を検証できます。 認可された監査チームは、GET /api/v1/receipts/{verdict_id} と DELETE /api/v1/receipts/{verdict_id} を使ってレシートを取得または削除できます。

---

正式なポリシー ID

すべての EthersFlow 判定レシートでは、トップレベルのメタデータ（receipt.policy_id）と署名済み設定タプル（receipt.receipt_v2.config_tuple.policy_id）の両方に、正式な policy_id が紐付けられます。

ポリシー ID	説明	デフォルトのルールとしきい値
finops_default_v1	エンタープライズ FinOps のデフォルト安全ポリシー	2レーン評価：少額経費の高速経路（<$100、承認済みカタログベンダー、チケットアンカー、24時間以内に5件の承認）と、複数モデルによるコンセンサスのフォールバック。
tripwire_circuit_breaker_v1	高保証サーキットブレーカーポリシー	異常な電信送金、認証情報の窃取、プロンプトインジェクションのパターン、または権限の迂回を検知した場合、即座にフェイルクローズで作動します。

---

強制とアドバイザリーの位置付け

EthersFlow は、強制とアドバイザリーを組み合わせたアーキテクチャを提供します。

1. 決定論的な強制ゲート（デフォルトでフェイルクローズ）：

   • 高リスクの操作、プロンプトインジェクション、根拠との矛盾に対して、無条件で REJECTED または FLAGGED_HUMAN_REVIEW の判定を返し、approval_blocked: true にします。
   • @ethersflow/sdk の cloudflareVerifyGate などのゲートラッパーや、実行バインディング（POST /api/v1/binding/confirm）は、有効な暗号署名付き承認レシートが存在しない限り、エージェントの実行を厳格に停止します。
   • 厳格なフェイルクローズ保証：内部ゲートウェイエラー、ネットワークの分断、上流のタイムアウトが発生した場合、EthersFlow は常にフェイルクローズします（verdict: "REJECTED"、approval_blocked: true、ステータス 502/503 を返します）。ゲートウェイは暗号検証なしに承認することはありません。

2. アドバイザリー型の複数モデルコンセンサス：

   • 主観的な判断や境界線上の判断に対して、ゲートウェイは consensus_score、risk_index、異種モデルごとの署名付き見解など、多次元の詳細なテレメトリを提供します。
   • フラグが付けられたアクションには人間による監督が必要です。Human-in-the-Loop レビュー API（/api/v1/reviews/resolve）がこれをサポートします。

---

含まれるもの

このリポジトリには、EthersFlow エコシステムの公式クライアント向けインターフェースと開発者ツールが含まれています。

インターフェース	パス	説明
MCP サーバー	/mcp-server	Claude Desktop、Cursor、MCP クライアント向けのModel Context Protocolサーバー
Pythonデモと検証ツール	efverify.py	依存関係ゼロの純粋なPythonクライアントとEd25519署名バリデーター
Python SDK	/sdk/python	ネイティブPythonパッケージとLangChainツールラッパー
TypeScript SDK	/sdk/typescript	TypeScript SDKとCloudflare Workerミドルウェアヘルパー
Postmanコレクション	/postman	11個のリクエストを含むPostmanコレクションと環境変数

注：コアのFederated Adversarial Consensusエンジンは、デフォルトでレシートのみを永続化し、ペイロードを破棄します（判定、理由コード、アクションハッシュ、Ed25519署名は保持し、署名後すぐに生のアクションペイロードを破棄します）。このリポジトリでは現在、Phase Cでのリポジトリ分割に先立ち、ゲートウェイサービスと開発者ツールキットおよびSDKを併せて提供しています。

---

5分で始めるクイックスタート

1. cURL API呼び出し（最速の確認方法）

curl -X POST "https://www.ethersflow.com/api/v1/verify" \
  -H "Authorization: Bearer $ETHERSFLOW_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_action": "Transfer 5000 USDC to wallet 0x9f for smart contract audit",
    "persona_preset": "financial_compliance",
    "agent_count": 3
  }'

2. Python SDKと依存関係ゼロの検証ツール

pipでインストールします：

pip install ethersflow

または、付属の依存関係ゼロのリファレンススクリプトを実行します：

python efverify.py verify "Transfer 5000 USDC to wallet 0x9f for smart contract audit"

3. Model Context Protocol（MCP）サーバー

オプションA：NPX経由（推奨）

npx -y @ethersflow/mcp-server --api-key=YOUR_API_KEY

オプションB：リモートHTTP / SSEゲートウェイ（ローカル依存関係ゼロ）

接続レベルの認証を使用して、MCPクライアントからEthersFlowの本番エンドポイントに直接接続します：

• エンドポイント：https://www.ethersflow.com/api/mcp
• 接続ヘッダー：Authorization: Bearer YOUR_API_KEY
• RFC 9728 / OAuthリソースメタデータ：RFC 9728に準拠し、認証されていないリクエストには、WWW-Authenticate: Bearer realm="ethersflow-gateway", resource_metadata="/.well-known/oauth-protected-resource"を含むHTTP 401が返されます。認証なしのツール呼び出しでは、リクエストIDを保持したまま、構造化されたJSON-RPC -32000（MISSING_AUTHORIZATION）エラーが適切に返されます。
• Claude / Cursorのクライアントレベルでの注入：接続初期化時にAuthorizationヘッダーを注入すると、すべてのツール呼び出しで有効なゲートウェイ認証が自動的に継承されます。

オプションC：Claude Desktopの設定

{
  "mcpServers": {
    "ethersflow": {
      "command": "npx",
      "args": ["-y", "@ethersflow/mcp-server"],
      "env": {
        "ETHERSFLOW_TOKEN": "YOUR_API_KEY",
        "ETHERSFLOW_BASE_URL": "https://www.ethersflow.com"
      }
    }
  }
}

オプションD：ソースから実行

git clone https://github.com/Ethersflow/EthersFlow.git
cd EthersFlow/mcp-server
npm install
npm start

---

高速パス診断とアンカーによる修正（素朴な表現に対応したUX）

EthersFlowでは、リクエストを主に次の2つの実行レーンで評価します。

1. FAST_PATH（200ms未満、ゲートウェイ約126ms、カーネルノード約4ms）：低リスクの少額経費（100ドル未満）や、検証済みの運用アーティファクトに紐付けられた読み取り専用の内部テレメトリーを対象とする、決定論的かつ同期的なポリシー検証です。
2. CONSENSUS（約1.7～2.0秒）：独立して稼働する最先端の複数モデルによる、敵対的なクロス検証です。

自律型エージェントが、素朴な表現や構造化されていない表現（運用チケットやベンダーのアンカーを省略するなど）で無害なアクションを送信すると、EthersFlowはリクエストをCONSENSUSレーンにルーティングし、詳細なfast_path_ineligibility_reasons診断配列とともにFLAGGED_HUMAN_REVIEW判定を発行します。

例：素朴なリクエストの診断と修正

ステップ1：素朴で無害なリクエスト

開発者またはエージェントが、アンカーのない少額経費を送信します：

POST /api/v1/verify
{
  "agent_action": "Order pens and paper for the team"
}

ステップ2：診断レスポンス

リクエストに構造化されたアンカーがないため、高速パスで処理できず、レビュー対象としてフラグが付けられます：

{
  "verdict": "FLAGGED_HUMAN_REVIEW",
  "policy_fast_path": false,
  "lane": "CONSENSUS",
  "fast_path_ineligibility_reasons": [
    "AMOUNT_UNDETERMINED: Action text does not specify a parseable dollar amount or amount_usd in context.",
    "TICKET_MISSING: Operational ticket anchor (e.g. FAC-*, OPS-*, JIRA-*) missing from context and action.",
    "COUNTERPARTY_UNVERIFIED: Counterparty missing or not verified against approved catalog allowlist.",
    "BUDGET_LINE_MISSING: Spend category, scope, or budget line allocation missing from context."
  ]
}

ステップ 3：診断理由の確認と不足しているアンカーの補完

開発者またはエージェントのループは、fast_path_ineligibility_reasons を確認し、不足している4つの運用アンカーを補います。

1. 金額：アクションテキスト（"$10 of pens"）または context.amount_usd: 10.00 で金額を指定します。
2. チケットアンカー：運用チケットの識別子を添付します（"under ticket FAC-911" または context.ticket: "FAC-911"）。
3. 取引先：承認済みカタログのベンダーを指定します（"from Staples" または context.vendor: "Staples"）。
4. スコープ／予算配分：調達のスコープを定義します（context.scope: "routine_office_supplies" または context.budget_line: "office_supplies_q3"）。

ステップ 4：修正後のファストパスリクエスト

POST /api/v1/verify
{
  "agent_action": "Order $10 of pens from Staples under ticket FAC-911",
  "context": {
    "ticket": "FAC-911",
    "vendor": "Staples",
    "scope": "routine_office_supplies"
  }
}

ステップ 5：即時のサブ秒ファストパス承認

{
  "verdict": "APPROVED",
  "policy_fast_path": true,
  "lane": "FAST_PATH",
  "fast_path_ineligibility_reasons": [],
  "consensus_score": 96.8,
  "risk_index": 1.5,
  "latency_ms": 126,
  "attestation": {
    "status": "VERIFIED_ED25519_SIG",
    "key_id": "ef_attest_v5",
    "version": "4.0"
  }
}

---

受け取る内容：判定レシートの構成

EthersFlow の各検証呼び出しは、判定の意味、詳細なスコア、マルチモデルの合意に関するテレメトリーを不変のアクションハッシュに結び付けた、暗号署名済みの判定レシートを返します。

1. 3つの較正済みスコアと算出方法

EthersFlow は、単一の不透明なスコアではなく、アクションの完全性を示す3つの独立した側面を算出します。

1. consensus_score（0.0～100.0）： アクティブな評議会ノードと決定論的な安全ルールに基づく、超多数派加重の承認信頼度です。 $$\text{consensus_score} = \sum_{i=1}^{N} w_i \cdot s_i$$ ここで $s_i$ は各ノードが割り当てる個別スコア（0～100）、$w_i$ は正規化されたノードの重みです。FAST_PATH モードでは、決定論的な安全ルールの区分によって直接設定されます（例：読み取り専用であることが検証済みの可観測性では 96.8）。

2. reviewer_agreement（0.000～1.000）： 異種モデル間の評価者一致度です。1.000 は、参加しているすべてのフロンティアモデルと決定論的ルールの審査で全会一致していることを示します。0.700 未満の値は意見の相違を示し、Human-in-the-Loop によるレビューが開始されます。

3. risk_index（0.0～10.0）： アクションの影響範囲、変更速度、宛先サーフェス、権限の主張を反映する複合的な脅威指標です。risk_index >= 7.0 のアクションでは、高保証サーキットブレーカーが作動します（approval_blocked: true）。

"score_attribution": {
  "score_type": "hybrid_kernel_and_live_council",
  "rule_band": "SAFE_EXECUTION",
  "rule_id": "READ_ONLY_OBSERVABILITY_VERIFIED",
  "calibrated_score": 96.8,
  "risk_index": 2.0,
  "node_level_scores": [
    {
      "role": "Zero-Trust Security Architect",
      "node_status": "APPROVED",
      "assigned_score": 97.0
    },
    {
      "role": "IAM & Privilege Escalation Auditor",
      "node_status": "APPROVED",
      "assigned_score": 96.5
    }
  ]
}

2. 透明性の高いプロバイダーリクエスト ID（推論ダッシュボードで監査可能）

すべての敵対的討論の観点には、上流プロバイダーの生のリクエスト ID（provider_request_id）が含まれます。

• Google Gemini 3.7 Flash の場合は gen-...
• OpenAI/Groq GPT-OSS-120B の場合は chatcmpl-...

セキュリティチームと監査チームは、任意の provider_request_id を Google Cloud Console または Groq/OpenRouter のログで直接確認し、EthersFlow の中間ゲートウェイを信頼することなく、生のプロンプト、タイムスタンプ、推論元を検証できます。

3. 二重 Ed25519 暗号アテステーション（Canonical v4 形式）

各レシートには、アクティブな鍵（ef_attest_v5）で生成されたルートアテステーションとノードごとの署名が含まれます。署名対象のペイロードは、重要な判定フィールドをすべて不変のコロン区切り文字列に結び付けます。

v4:<request_id>:<action_hash>:<policy_id>:<verdict>:<action_eligible>:<consensus_score>:<reviewer_agreement>:<risk_index>:<evidence_status>:<grounding_status>:<reason_codes>:<approval_blocked>:<timestamp>:<version>

プライバシー保証：正規文字列が結び付けるのは action_hash（sha256(agent_action)）であり、生のアクションテキストではありません。外部監査人は、機密性の高い運用ペイロードを開示することなく、暗号学的な真正性を検証できます。

4. レーンの明確性：ファストパスとコンセンサス

特性	FAST_PATH レーン	CONSENSUS レーン
目標レイテンシ	合計約 126 ms（ノード約 4 ms）	1.7 s～2.0 s（R74 で測定）
推論ソース	決定論的安全カーネル（policy-kernel-fast-path-v4 @ ethersflow_kernel）	異種フロンティア評議会（Gemini 3.7 Flash + GPT-OSS-120B）
モデル呼び出し	ライブ LLM 呼び出しはゼロ。決定論的なカタログとルールの照合。	ライブのマルチモデル並列討論と敵対的な反対尋問。
レシートの構造	ef_attest_v5 によるカーネル認証済みの二重署名。	ライブのプロバイダーリクエスト ID を含む、モデルごとに独立した Ed25519 署名。

5. 制御サーフェスのリファレンス

出力フィールド	型	値	意味と適用指示
verdict	string	APPROVED、FLAGGED_HUMAN_REVIEW、REJECTED	ゲートウェイの高レベルな判断です。
action_eligible	boolean	true、false	実行フラグです。false の場合、エージェントランナーは直ちに処理を停止する必要があります。
approval_blocked	boolean	true、false	トリップワイヤーのサーキットブレーカー・フラグです。プロンプトインジェクション、認証情報の窃取、上限を超える電信送金の場合は true になります。
lane	string	FAST_PATH、CONSENSUS	判断が決定論的に行われたか、評議会で審議されたかを示します。
idempotency_key	string / null	ユーザー UUID	重複排除キーの参照です。繰り返し呼び出しの再生はサブミリ秒で行われます。

6. 注釈付きの実際の拒否レシート（認証情報流出の罠）

{
  "verification_schema_version": 3,
  "request_id": "req_8f12a9c401be9d72",
  "verdict_id": "req_8f12a9c401be9d72",
  "trace_id": "trace_a992bc01ef",
  "verdict": "REJECTED",
  "status": "REJECTED",
  "verified": false,
  "action_eligible": false,
  "approval_blocked": true,
  "lane": "CONSENSUS",
  "consensus_score": 5.2,
  "risk_index": 9.8,
  "reviewer_agreement": 1.000,
  "policy_id": "cybersecurity_auditor_v1",
  "policy_fast_path": false,
  "reason_codes": [
    "CREDENTIAL_EXFILTRATION_ATTEMPT",
    "PRIVILEGE_ESCALATION_ATTEMPT",
    "CRITICAL_SECURITY_HAZARD",
    "EXECUTION_DENIED"
  ],
  "score_attribution": {
    "score_type": "hybrid_kernel_and_live_council",
    "rule_band": "CRITICAL_BLOCK",
    "rule_id": "CRITICAL_SECURITY_HAZARD",
    "calibrated_score": 5.2,
    "risk_index": 9.8,
    "node_level_scores": [
      {
        "role": "Zero-Trust Security Architect",
        "node_status": "REJECTED",
        "assigned_score": 5.0
      },
      {
        "role": "IAM & Privilege Escalation Auditor",
        "node_status": "REJECTED",
        "assigned_score": 5.4
      }
    ]
  },
  "adversarial_debate": [
    {
      "role": "Zero-Trust Security Architect",
      "model_id": "google/gemini-3.7-flash",
      "provider": "google",
      "provider_request_id": "gen-a99182bf9012c",
      "node_status": "REJECTED",
      "perspective": "REJECTED: Action attempts to read and transmit master IAM secrets to external endpoint. Unconditional block.",
      "latency_ms": 1780,
      "attestation_status": "VERIFIED_ED25519_SIG"
    },
    {
      "role": "IAM & Privilege Escalation Auditor",
      "model_id": "openai/gpt-oss-120b",
      "provider": "groq",
      "provider_request_id": "chatcmpl-9201fba41",
      "node_status": "REJECTED",
      "perspective": "REJECTED: Violation of least-privilege boundary. Exfiltration pattern detected in proposed action arguments.",
      "latency_ms": 1820,
      "attestation_status": "VERIFIED_ED25519_SIG"
    }
  ],
  "attestation": {
    "status": "VERIFIED_ED25519_SIG",
    "key_id": "ef_attest_v5",
    "version": "4.0",
    "algorithm": "Ed25519-EdDSA",
    "canonical_payload": "v4:req_8f12a9c401be9d72:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855:cybersecurity_auditor_v1:REJECTED:false:5.2:1.000:9.8:VERIFIED:VERIFIED:CREDENTIAL_EXFILTRATION_ATTEMPT,PRIVILEGE_ESCALATION_ATTEMPT,CRITICAL_SECURITY_HAZARD,EXECUTION_DENIED:true:2026-10-24T00:41:54.000Z:ef_attest_v5",
    "signature": "38a1e94cf2...",
    "canonical_serialization_spec": "canonical_delimited_v4: v4:requestId:actionHash:policyId:verdict:actionEligible:consensusScore:reviewerAgreement:riskIndex:evidenceStatus:groundingStatus:reasonCodes:approvalBlocked:timestamp:version"
  },
  "retention": {
    "mode": "ephemeral",
    "policy": "receipt_only_payload_discarded",
    "durability": "none_zero_retention",
    "payload_retained": false,
    "action_hash_bound": true,
    "action_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  },
  "storage_engine": "zero_retention_ephemeral",
  "storage_durability": "none_zero_retention",
  "zero_data_retention": true,
  "latency_ms": 1845
}

---

冪等性と再生のセマンティクス（B3 重複排除サーフェス）

EthersFlow は、高スループットの分散エージェント群と、明示的かつ意図的な再検証の両方をサポートするため、検証境界でオプトイン方式の重複排除を実装しています。

1. デフォルトの動作：新規実行（重複排除はオプトイン）

idempotency_key を指定せずに重複アクションが送信された場合：

• EthersFlow は検証エンジンを通じて各リクエストを新たに評価します。
• 呼び出しごとに、新しい暗号署名と一意の request_id が生成されます。
• 応答では replayed: false と c2_replayed: false が示されます。

2. オプトイン方式の重複排除（idempotency_key）

再試行するエージェント間で、重複する金銭の支払い、API 呼び出し、チケットの変更を防ぐには、idempotency_key を指定します（JSON 本文の idempotency_key、または HTTP ヘッダーの Idempotency-Key / X-Idempotency-Key を使用）。

• 初回検証：アクションを評価し、Ed25519 の証明を生成してレシートを確定し、結果をキャッシュします（replayed: false、replay_index: 0）。
• 連鎖再生（後続の呼び出し）：キャッシュされた判断レシートを約 12msで即座に返します（replayed: true、c2_replayed: true）。
• 連鎖再生インデックス：再生された呼び出しごとに replay_index が増加し（1, 2, ...）、個別の監査トランザクション ID が作成されます。一方、original_request_id への参照と不変の action_hash は保持されます。

# First Call (Fresh Verification ~126ms Fast-Path or ~1.7–2.0s Consensus)
curl -X POST https://www.ethersflow.com/api/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: agent-step-uuid-101" \
  -d '{"agent_action": "Order $10 of pens from Staples under ticket FAC-911"}'
# Response: {"request_id": "req_a1b2...", "replayed": false, "replay_index": 0, ...}

# Second Call (Instant Replay ~12ms)
curl -X POST https://www.ethersflow.com/api/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Idempotency-Key: agent-step-uuid-101" \
  -d '{"agent_action": "Order $10 of pens from Staples under ticket FAC-911"}'
# Response: {"request_id": "req_c3d4...", "original_request_id": "req_a1b2...", "replayed": true, "replay_index": 1, ...}

---

保持アーキテクチャと派生フィールドのポリシー（N2 と N4）

EthersFlow は、未解析の生のアクションペイロードと、そこから派生した運用監査メタデータを厳密に区別します。

派生フィールドはペイロードではなく監査メタデータです（N2）

• 派生フィールド：ポリシールールによって決定論的に抽出される属性（承認済みカタログのベンダー名、解析済みの通貨額、運用チケット識別子、正規化されたアクションハッシュ、Ed25519 暗号署名など）は、ペイロードではない監査メタデータに分類されます。
• 生のペイロード：構造化されていない生のアクションテキストは、証明への署名後にデフォルトで直ちに破棄されます（payload_retained: false、agent_action: "[PAYLOAD_DISCARDED]"）。
• 監査の永続化：派生した運用メタデータを保存することで、機密性の高い可能性があるプロンプトテキストを保持せずに、独立した検証と判断の証明が可能になります。

判断状態ごとの保持に関する明確性（N4）

• ファストパス承認：デフォルトではレシートのみを永続化します（retention.policy: "receipt_only_payload_discarded"、perspectives_retained: false）。
• 要人間レビューのフラグが付いた場合：オペレーターによる裁定が必要なアクションでは、監査担当者の議論における観点を、審査の解決のためにのみ保持します（retention.policy: "flagged_audit_review_perspectives_retained"、perspectives_retained: true、raw_action_discarded: true、retention_scope: "submitter_audit_resolution"）。どちらの経路でも、生のアクションペイロードは保持されません。

---

ステータスと既知の制限事項

• Ed25519 署名付き監査証跡：すべての監査ノードの出力と全体の判定は、Ed25519-EdDSA（ef_attest_v5）を使用して署名されます。署名は、EthersFlow のサーバーを一切信頼することなく、/.well-known/jwks.json を基にオフラインで独立して検証できます。
• 決定論的ではなく、確率的：境界線上または曖昧なアクション（例：高額の電信送金やコンプライアンス記録の欠落）は、判定しきい値（APPROVED <-> FLAGGED_HUMAN_REVIEW）付近の評価になります。FLAGGED_HUMAN_REVIEW 判定は、承認を得るため、必ず人間の担当者に直接回すことを強く推奨します。
• 稼働中のモデルエンジン：独立したプロバイダー間に分散した異種推論ノードを利用しています。Gemini 3.7 Flash（Google）および GPT-OSS-120B（Groq/OpenRouter）を使用し、稼働中のプロバイダーリクエスト ID（gen-... と chatcmpl-...）で確認されています。追加のアーキテクチャ（Llama 3.3 70B、Qwen 3.6/3.8 27B）は、Bring-Your-Own-Key（BYOK）ロードマップに含まれています。
• ゲートウェイアーキテクチャとリポジトリの進化：中核となる Federated Adversarial Consensus バックエンドは、デフォルトでレシートのみを永続化し、ペイロードを破棄するセキュアな API サービスとして動作します（判定、理由コード、アクションハッシュ、Ed25519 署名は保持され、生のアクションペイロードは署名直後に破棄されます）。現在、このリポジトリではゲートウェイサービスと開発者ツールキットおよび SDK を併せてホストしています。バックエンドエンジンのコードは、フェーズ C で専用リポジトリに分離されます。

---

主な機能

• マルチモデル合意：異種の最先端モデルに敵対的な相互検証を強制することで、単一モデルの偏りを軽減します。
• Ed25519 証明：すべての議論ノードの出力と判定レシートは、Ed25519 暗号鍵（ef_attest_v5）で署名されます。公開鍵セットは /.well-known/jwks.json で利用できます。
• 保持アーキテクチャとペイロードの破棄：EthersFlow はデフォルトで厳格な一時モードで動作します。署名直後に生のアクションペイロードを破棄し、暗号学的なレシート成果物（判定、正規化済みハッシュ、Ed25519 署名、理由コード、リクエスト ID）のみを永続化します。ペイロード全体の監査目的での保持は、呼び出しごとに明示的に有効化する場合（zero_retention: false）に限られ、アクションペイロードがモデルのトレーニングに使用されることはありません。
• OpenAI と Anthropic のドロップインプロキシ：既存のエージェントパイプラインのドロップイン置換として、/v1/chat/completions または /v1/messages を使用できます。
• 専門化されたペルソナ：
  • financial_compliance（FINRA/SEC、電信送金限度額、KYC、制裁）
  • clinical_safety（ISMP のハイアラート医薬品、用量の範囲、FDA）
  • cybersecurity_auditor（NIST SP 800-53、権限昇格、SOC 2）
  • legal_citation（FCPA、証拠に関する秘匿特権、契約違反）
  • general_adversarial（分野横断的な安全性とロジックの検証）

---

フレームワークとの統合

LangChain（Python）

import os
from ethersflow import EthersFlowLangChainTool

verifier_tool = EthersFlowLangChainTool(api_key=os.getenv("ETHERSFLOW_API_KEY", "your_api_key"))

# Add to your LangChain agent tools
tools = [verifier_tool]

Cloudflare Workers / Agents SDK（TypeScript）

import { cloudflareVerifyGate } from '@ethersflow/sdk';

export default {
  async fetch(request: Request, env: { ETHERSFLOW_API_KEY: string }) {
    const isSafe = await cloudflareVerifyGate(
      "Transfer 5000 USDC to wallet 0x9f",
      "Vendor audit payment",
      env.ETHERSFLOW_API_KEY
    );

    if (!isSafe) {
      return new Response("Action blocked by EthersFlow Consensus Gate", { status: 403 });
    }

    // Proceed with execution
  }
};

---

セキュリティと Ed25519 証明

EthersFlow は、標準の JSON Web Key Set（JWKS）形式で公開鍵セットを公開しています。

• JWKS エンドポイント：GET /.well-known/jwks.json（RFC 8037 OKP プロファイル、Cache-Control: public, max-age=3600）
• 証明マニフェスト：GET /.well-known/attestation.json
• 公開鍵エンドポイント：GET /api/v1/receipts/public-key
• 検証エンドポイント：POST /api/v1/verify-attestation

独立したオフライン検証（ゼロトラスト）

EthersFlow のサーバーに接続せず、完全にオフラインで署名を検証できます。

# Run full local verification test suite
python efverify.py demo

# Verify a saved verdict receipt JSON locally offline
python efverify.py verify-file receipt.json

# Print the complete offline byte recipe for auditors
python efverify.py recipe

---

保留された敵対的評価と較正の非循環性

経験的な厳密性を確保し、循環的な評価（開発中に確認したサンプルを使ったテスト）を防ぐため、EthersFlow は独立して開発された保留テストバッテリーを維持しています。

• 作成者：独立系レッドチームおよび AI Safety Consortium。
• 開発者による可視性：開発中は厳密に保留され、プロンプトエンジニアリングおよびルールセット作成中に一切公開されません。
• 独立した受け入れ QA：独立した受け入れ QA を進行中です。

---

Postman コレクション

postman/ethersflow.postman_collection.json と postman/ethersflow.postman_environment.json を Postman にインポートすると、11 個のコアエンドポイントすべてをすぐにテストできます。

---

リンクとコミュニティ

MCP 掲載サイト

• 公式 MCP レジストリ：https://registry.modelcontextprotocol.io（「Ethersflow」を検索）
• Smithery：https://smithery.ai/servers/ethersflow-dev/ethersflow
• Glama：https://glama.ai/mcp/servers/Ethersflow/EthersFlow

---

ライセンス

コードと SDK ラッパーは MIT ライセンス の下でライセンスされています。ホスト型 EthersFlow API サービスには、利用規約が適用されます。