Cyan Eclipse Muzzle

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• A PASS verdict is scan evidence, not a guarantee of safety or non-defamation.
• Classes scanned by this release: PII and secrets. Classes outside those two are not scanned, and a PASS is not evidence about them.
• This release does not scan for defamation-risk: defamation-risk detection is excluded from the certified scope of this version, and a PASS verdict is not evidence about defamation.
• Secrets detection (on seeded fixtures): private-key headers, AWS, GitHub and prefixed tokens, bearer and JWT tokens, keyword assignments including JSON and compound key names, Authorization headers in any scheme, URL userinfo passwords, standalone 32-char hex tokens, and high-entropy tokens — 100% recall and 100% precision on seeded fixtures (fresh bench corpus, rates computed from signed receipts).
• PII detection (on seeded fixtures): email addresses; Social Security numbers in dashed, dotted, spaced, and contiguous forms (SSA-validity gated); payment cards in grouped and contiguous forms (Luhn-gated); and phone numbers in domestic formats and E.164 international formats — 100% recall and 100% precision on seeded fixtures (spec thresholds ≥95% recall / ≥90% precision).
• Phone scope: international phone detection covers E.164 (`+`-prefixed) forms, grouped or contiguous. A foreign number dialled with a `00` prefix, or written in national format without a leading `+`, is not detected as an international number; however, if its trailing digits happen to form a US/Canada (NANP) number pattern, the domestic phone detector will flag that trailing pattern. National-format foreign numbers whose digits do not form a NANP pattern are not detected.
• Hex scope: standalone hex detection is capped at 32 chars — a standalone 32-char hex token is flagged; a hex string of 40 or more chars is detected only with assignment or header context, and standalone 40+ hex is not flagged.
• Every verdict is a Herald-signed receipt bound to the content hash: any one-byte change to the content fails offline verification at step 1, and a receipt signed under any keys other than the pinned Herald/scanner keys fails at step 2. Detected secrets and PII appear in receipts, exports, and persisted artifacts by span and hash only — never as raw values. Unverifiable artifacts export only as UNVERIFIED_EXPORT.

Tools

Problems it addresses

• I'm about to publish agent- or human-drafted text — I need it scanned for secrets and PII first, with the verdict bound to the exact content hash so the thing that was checked is the thing that ships
• A downstream publisher needs proof a scan passed — I need a Herald-signed receipt it can verify offline, where any one-byte change to the content fails verification at step 1
• A scan found something — I need the findings recorded by span and hash only, never the raw secret or PII value, in every receipt, export, and persisted artifact

Not tested

• Defamation-risk detection — not included in v0.1: Defamation detection is not included in v0.1 — parked for a v0.2 redesign; a PASS verdict is not evidence about defamation
• Any class outside PII and secrets — not scanned by this release, and a PASS is not evidence about them
• Live, publisher, or production scope — local/fixture only: no live publisher integration, hosted endpoint, network egress, or production content is certified by this ruling
• Detection rates beyond the seeded-fixture rates stated in the authorised claim block — measured on seeded shapes in a fresh fixture corpus only
• Production signing custody — fixture Herald/scanner RS256 keys are local-only in keys/ (gitignored, private keys mode 600, never committed); the v0.1.0 shipped fixture keys were burned and receipts signed under them fail verification at step 2