EthersFlow — Trust Gate for AI Agents

What EthersFlow — Trust Gate for AI Agents does

EthersFlow — Trust Gate for AI Agents adds an action-verification step between an agent runtime and the tool or API call the agent intends to make. It is designed for KYAA, or “Know Your Agent’s Action”: identity establishes who an agent is, authorization establishes what it may do, and EthersFlow evaluates whether a particular action is legitimate.

The MCP server exposes the verify_agent_action tool. A client submits a proposed action to the EthersFlow action-verification gateway, which returns a decision gate of APPROVED, FLAGGED, or REJECTED. The response includes a signed receipt that can be checked independently using Ed25519 signatures and the published public keys.

How it works

Requests are evaluated through two lanes. A deterministic safety kernel and catalog matcher can handle eligible fast-path requests, including the documented conditions around low-value purchases, approved vendors, operational tickets, and intent screening. Other requests, or requests that exceed the fast-path allowance, can go through an adversarial consensus lane using heterogeneous models such as Qwen, Llama, and Gemini.

The gateway signs the resulting verdict and binds it to the action through a SHA-256 action hash. Repeated requests can be recognized through an idempotency key and action hash. The documented fast path has lower latency than live multi-model deliberation, while the consensus lane is intended for escalation and broader semantic review.

By default, the service follows a receipt-only retention model. It stores the verification artifact, including the verdict, hashes, reason codes, request ID, and signature, while discarding the raw action payload. Clients can explicitly set zero_retention to false when full payload retention is required for an audit record; the provided example shows this as a per-call choice.

Setup and configuration

The repository identifies the MCP package as @ethersflow/mcp-server and documents stdio, SSE, and HTTP transport modes. The server forwards verification requests over HTTPS to the EthersFlow /api/v1/verify endpoint.

The service exposes receipt retrieval at GET /api/v1/receipts/{request_id}. In receipt-only mode, retrieved metadata indicates that the payload was not retained. Ed25519 public keys are available through the service’s JWKS endpoint for signature verification.

Tools and capabilities

EthersFlow — Trust Gate for AI Agents provides the documented verify_agent_action MCP tool for submitting an action for review. Its supported capabilities include:

• Deterministic policy and catalog matching for eligible requests
• Escalation to multi-model adversarial consensus
• APPROVED, FLAGGED, and REJECTED decision outcomes
• Ed25519-signed, independently checkable verdict receipts
• Idempotent replay handling through request identity and action hashes
• Receipt-only storage with optional full-payload retention

Limitations and notes

Verification is an additional control before execution; it does not execute the approved tool or API action itself. Fast-path approval is conditional rather than universal. The documented operational-ticket allowance is five fast-path approvals in 24 hours with a stated $500 cap, after which requests fall back to live consensus. Latency also varies by lane: the provided benchmarks list sub-second median timing for the policy path and substantially higher median timing for adversarial consensus.

Receipt-only persistence protects stored action text but still leaves cryptographic metadata and normalized hashes in the receipt. Setting zero_retention to false changes the retention behavior and allows authorized operators to retrieve the recorded payload.