Cyan Eclipse Promptseal

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism (SPEC §2.1, verbatim) — production system prompts are sealed and versioned; every runtime incident can be traced to the exact prompt version and its approver.
• Sealed versions, hash-chained — prompt_seal seals a fixture prompt body: prompt_hash=sha256(body bytes) is the version identity; version records are hash-chained per lineage (gapless seq, prev_hash) and author-signed; re-sealing identical bytes returns the existing record (idempotent, no second metering event); a version without a valid Herald approval is labelled UNAPPROVED on every surface and can never be bound to a deployment
• Approval bound to the exact hash — approval_attach verifies a Herald-signed approval record against the pinned fixture Herald key (record-supplied keys never used) and requires approved_version_hash to equal the version record hash; approving a label approves exactly one byte-sequence — a one-character edit is a new hash with no approval (APPROVAL_SIGNATURE_INVALID / APPROVAL_HASH_MISMATCH are named, non-mutating refusals)
• Fixture deployment binding + incident links — deployment_bind binds an approved version to a fixture deployment descriptor, optionally citing a Kitseal-style config seal by ref+hash (cited, never backfilled; absence stated on receipt face); incident_link reads the binding in force — a caller-asserted version is refused as an input and stored nowhere; trace receipts name incident, deployment, version record hash, prompt hash, Herald approval hash, and the approver read from the Herald record itself, signed and counter-signed against the chain head; broken/invalid/absent approval yields only an unsigned DOWNGRADED_EXPORT (receipt_grade:false), never upgraded
• Offline verification (SPEC §6.4) — trace_verify walks a presented pack alone (chain + body hash recompute, Herald signature + binding, binding citation, link citation, receipt signatures) as a pure function of pack + pinned fixture keys; decisive fixture F-PS13 passes in a fresh process with no Promptseal state; any step failing returns PROMPTSEAL_VERIFY_FAIL:<step>, no partial trace
• Stored-serve hardening (bench conditions C1–C6, all CLOSED at v0.1.3) — incident_link idempotent path runs lineage defect check before echo (C1); lineage identity bound end-to-end to store key and pack (C2); idempotent re-link checks paired deployment_ref (DEPLOYMENT_REF_MISMATCH, C3); chain records carry exact per-type field sets — injected counter_signature/unknown fields are defects (C4); serialized pack aux binding/incident_link copies, top-level config_seal, approval_records set and every prompt_bodies entry are bound exactly to chain copies (C5); whole store (structure, every lineage chain, metering) validated at load on every path — garbage siblings yield named CHAIN_BROKEN refusal/downgrade with zero writes (C6)
• Runtime limit (SPEC §11.2, on every receipt face) — the chain proves which prompt version was sealed and who approved it, and that a fixture deployment's binding named it; it does not prove the sealed prompt is what actually ran in any live process

Tools

Problems it addresses

• System prompts are edited in a console, config file, or chat with no version, no approver, and no way after an incident to answer which prompt was live and who approved it
• An approval for one prompt text must not drift onto edited text — approval has to bind the exact byte-sequence hash, so a one-character edit is a new, unapproved version
• After a runtime incident I need a recomputable trace — incident → link → binding → sealed version hash → Herald approver — from records alone, not a reconstruction from memory or deploy logs

Not tested

• Production prompts, real deployments, or runtime attestation — SPEC §11.2 fence: the chain proves which prompt version was sealed and who approved it, and that a fixture deployment's binding named it; it does not prove the sealed prompt is what actually ran in any live process. Runtime attestation is an integration claim, never a v0.1 claim, and no runtime integration exists in v0.1.3
• Sealing real production prompts (prompt bodies may carry trade-secret/confidential material), binding to real deployments, any runtime-attestation integration, or use of a trace receipt in an employment, contractual, or regulatory dispute — the SPEC §10.1 counsel gate is UNBUILT by design, named, with no dormant live mode: each live phase is a separate, counsel-cleared, re-benched build. v0.1.3 has no production-prompt ingest path, no deployment connector, and no runtime hook
• Production signing / Herald authority — fixture Herald key is a test double (pinned herald-fixture, local fixture key in keys/, gitignored, mode 600, never committed) and confers no Herald authority; Promptseal verifies and cites Herald-signed approval records, issues none, and holds no real Herald key. A fresh clone generates its own fixture keys to run the full suite
• Hosted or live operation — local stdio only; metering points only per SPEC §9 (exactly 1 promptseal_lineage_month_active event per lineage; seals, approvals, binds, links, traces and refusals add none; no charge path built, no live Meter ingest), the $49/mo shape is a book reference with no charge path built