Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio — local v0.1 build over a local state file; no network transport
Certification scope
CERTIFIED(local) — Eclipse Bazaar Test Bench 2026-10-25: 23 pass, 1 na of 24 checks (U1 na), 0 fail — 23/23 scored checks, single bench, no fix round. CEILING — read exactly: CERTIFIED(local) over FIXTURE subjects only, and the fixture boundary is enforced by the product, not by convention: v0 refuses any non-fixture subject by name (SUBJECT_NOT_FIXTURE) and every subject in the package is synthetic. Real-subject personal-data processing is NOT built and is held at gate G-COUNSEL (spec §17); jurisdiction packs (state privacy / AI-law vocabulary variants) are NOT built (G-COUNSEL per pack) — the versioned-vocabulary mechanism they would ride on ships in v0 as data. Consumer-facing grant UX is NOT built (G-OWNER); v0 has no consumer surface at all, and no hosted or network form exists. Consent records consent; it does not manufacture it, and no output certifies any party.
What it does
- A check-gate, not a registry: a processor agent presents a consent receipt id at action time and gets ALLOW/DENY + reason + record id synchronously — a revocation is effective at the very next check, for every processor, with no sync step and no consent copies held by processors
- Lineage law: every grant names subject, grantor, grantee, purpose, data classes, capture method, capture evidence ref, captured_at and expiry — a record without lineage is void, refused at grant time and denied at check time
- Separation of duties by name: the grantee can never write its own consent (CONSENT_SELF_ASSERTED); grants issue only from the subject or a recorded delegate; revocation is subject/delegate only
- Append-only, hash-chained records; revocation is a new record that supersedes at check time, and consent_dependents returns the propagation map — exactly the processors who presented a receipt — with the revocation notices issued to them
- Purposes, data classes, capture methods and revocation sources are versioned vocabularies shipped as data (vocabularies.json), not code; consent_bulk_import / consent_extend / consent_check_skip do not exist and refuse -32602 at the transport; family T3 is empty — no enforcement verb at any tier
Tools
consent_grantconsent_checkconsent_revokeconsent_historyconsent_dependents
Problems it addresses
- Agents process personal data on my behalf — I need consent I can revoke once and have it bind every processor at the very next action, not after a sync
- A consent record without who captured it, how, and for what purpose is worthless when it is challenged — provenance cannot be reconstructed later
- The agent holding the data must never be the one asserting the consent
Not tested
- Real-subject personal data — NOT built, held (G-COUNSEL, spec §17); v0 refuses any non-fixture subject by name (SUBJECT_NOT_FIXTURE)
- Jurisdiction packs (state privacy / AI-law vocabulary variants) — NOT built (G-COUNSEL per pack)
- Consumer-facing grant UX — NOT built (G-OWNER); v0 has no consumer surface at all
- Hosted / live registry service form and any network transport — NOT built; v0 is a local stdio server over a local state file
Bench scorecard: test-bench/results/eclipse-consent-mcp-2026-10-25.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 →