Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio
Certification scope
CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25, 18 pass, 1 na of 19 checks (U1 auth: stdio process boundary). Run by W-003 (Verity), suites/tripwire.py. Run 2 FAILED (T10: a within-batch duplicate event_id was stored twice and double-counted by the velocity detector) and run 1 PARTIAL cards retained append-only; the defect is fixed, the class closed (single validator call site, verified by source reading), and run 3 is the standing card. Novelty (NV) proven: verified actuation distinguishes Tripwire from logging/observability tools. Two detector evasions (signature-split loops, paced spawn fan-out) are documented SPEC NOTEs, unchanged by design.
What it does
- The enforcement half of the Eclipse money layer (Meter reports; Tripwire blocks — cluster law L3): four deterministic detectors — spend velocity, loop/retry-storm signature, spawn count, cap-approach trajectory — over recorded Meter/Wallet-shaped event streams
- Same stream + rule version replays to identical verdicts, actions, and evidence-pack hashes in separate processes (byte-identical, bench-proven)
- Rules are versioned and append-only, default to alert-only; auto-freeze fires only on rules the owner explicitly armed
- A freeze engages the sandbox Agent Wallet kill switch, then is verified by re-reading the Wallet: only a verified freeze records FROZEN_CONFIRMED; a lying backend yields FREEZE_UNCONFIRMED plus a critical owner page stating the agent is NOT confirmed stopped
- Every action carries a complete hash-bound evidence pack (rule version + triggering events + measured values) and writes a hash-chained receipt; the agent read surface exposes tripwire_status only, thresholds stripped
- v0 is sandbox-only: fixture streams, the sandbox Wallet, test USDC; live-rail freeze inherits the Wallet P3 gate wholesale
Tools
tripwire_wallet_bindtripwire_rule_settripwire_armtripwire_disarmtripwire_ingestfreeze_nowunfreezetripwire_eventstripwire_status
Problems it addresses
- An agent looped overnight and burned real money before anyone noticed — I need a breaker, not a report
- My spend monitor logs alerts but nothing ever actually stops the agent
- If a freeze is claimed, I want wallet-side proof the agent is stopped — not the tool's word for it
Not tested
- Live-rail freeze — v0 acts on the sandbox Agent Wallet only; freezing a live mandate inherits the Wallet P3 gate wholesale (spec 6.5)
- Live event streams — v0 consumes recorded fixture streams shaped as Meter cost records and Wallet events; no live Meter ingest exists (Meter itself is fixture-form at v0)
- External paging channels (SMS/push) — owner pages are notification records + receipts in v0; channel integrations are a later phase (spec 6.1)
- Cluster 1 Lineage feed for spawn counts — v0 spawn detection runs over declared spawn events in-stream; the Lineage join lands when Lineage is built
- Hosted/multi-tenant operation and auth beyond the stdio process boundary (bench U1 class)
Bench scorecard: test-bench/results/eclipse-tripwire-mcp-2026-10-25-3.json
Evaluation-intake listing
This listing records the tool's place in the Bazaar's evaluation
and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope,
and not-tested items included. It is not sold on this site, and its presence in the catalog
is not a claim beyond that evidence. The service behind every verdict is the bench:
what a bench run buys →