Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio (two capability records via ENVOY_SURFACE; hosted split at E1)
Certification scope
CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25, 17 pass, 1 na of 18 checks (U1 auth: stdio process boundary). Run by W-003 (Verity), suites/envoy.py. Runs 1-2 PARTIAL cards retained append-only (bench-suite defects); run 3 is the standing card.
What it does
- One owner-approved identity source generates a signed corporate Agent Card (Eclipse Herald machinery, consumed by import — never forked): capabilities program-general behind a publication lint, VOSB carried as verifiable references, SAM status stated exactly as 'renewal submitted, activation pending'
- Counterparty vetting into risk tiers R0-R3: JWS verified against the domain's JWKS, domain anchoring, certification posture hash-matched to the presented card; typosquats get their own record + similarity flags and never touch the honest org's tier or disclosure history
- Disclosure Engine renders facts per tier (T-public; T-vetted rate-card SHAPE with no numbers; T-NDA behind an owner-entered NDA record whose ID every render must cite; T-mandate) with a per-fact disclosure log and one identical no-oracle refusal shape
- Engagements bind only by the three-key rule — owner approval record + Wallet-shaped mandate reference + Herald delegation reference; no tool on either surface signs, commits, or moves funds
- All inbound content quarantined as data under Herald Security Law #1; signed, replay-protected, room-isolated envelopes; kill switches and an attention budget — no counterparty action can directly create owner work
Tools
identity_getinquiry_opencapability_exchangefact_requestscope_draft_openscope_draft_revisescope_draft_getproposal_submitproposal_statusroom_sendroom_historyattestation_submitcounterparty_registercounterparty_listcounterparty_getdisclosure_log_querytier_setnda_record_createwaiver_createrecognized_bench_addengagement_inboxproposal_pack_getproposal_decideengagement_attach_mandateengagement_attach_delegationbinding_checkmandate_fact_addroom_getengagement_closeoutkill_switch_counterpartykill_switch_globalkill_switch_reinstateidentity_publishidentity_rotate_keyidentity_retire_keyaudit_review
Problems it addresses
- Other companies' agents are coming, and my company has no signed front door — no vetting, no disclosure tiers, no record of what we told them
- I need to prove exactly what my company disclosed to a counterparty's agent, and when — without ever letting their agent bind us
Not tested
- Any live counterparty or hosted endpoint — E0 is fully offline against local fixtures (.example domains, fixture keys); E1 is owner-gated (hosting go, trademark screen, Herald root-key backup, cetech.ai flip).
- Card fetch from a counterparty's real well-known URL — E0's harness presents the card + the domain's JWKS as local files; the verification checks are the production checks, the fetch is the fixture seam.
- Herald gateway execution against real desk agents — E0 records Herald delegation REFERENCES for the three-key rule; live gateway delegation is Herald's own certified scope.
- Real Wallet mandate issuance — E0 records operator-entered Wallet-shaped mandate references; Envoy never mints mandates.
- Operator-channel authentication beyond process ownership (the standing U1 note) — E1 build decision with attributable-principal receipts required by spec 11.2.
- T-NDA fact contents are labeled E0 fixture placeholders; real T-NDA facts are human-authored into the identity source at E1.
Bench scorecard: test-bench/results/eclipse-envoy-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 →