Powered by Cyan Eclipse Technologies — https://cetech.ai
Eclipse Cluster — the container substrate of the Constellation family: signed images, governed runtimes, orchestrated workloads, every action receipted.
v0.1.0 implements phase K0 only (spec: eclipse-cluster-container-spec-20261025.md §8): the signed-image verification gate. Before any image is allowed near a runtime, this server checks it against a written policy — registry allowlist, digest resolution, cosign-style signature, signer identity, DSSE/in-toto provenance — and returns a verdict that is PASS/FAIL per check, in the shape of a CertBridge result card.
It is deliberately usable before any container runtime exists: the host this was built on has no Docker, and none is required. Runtime, image-pipeline, and orchestration phases (K1–K3) are later work and are not in this build — no tool here can start, stop, or deploy anything.
Related MCP server: contextboundary-gw
An unreachable registry, a missing signature, a valid signature from the wrong signer, a signature made for a different digest, a registry that isn't allowlisted — each is a FAIL with a reason. There is no PASS-by-default path. Every verdict, pass or fail, is appended to a hash-chained receipt ledger.
Checks, in order:
Check | Question it answers |
| Is this registry named in the policy? (No contact is made if not.) |
| Does the reference resolve to a concrete digest — and if the reference pinned a digest, does it match? |
| Is there a cosign-layout signature object ( |
| Does the signature cryptographically verify under a key in the local trust bundle? |
| Is the key that verified the one the policy names? (A valid signature from the wrong signer fails here.) |
| Does the signed payload name this image's digest? (Catches signatures transplanted from another image.) |
| Does the signed payload name this repository? |
| If the policy requires provenance: does a DSSE attestation exist, verify under a policy signer, name this digest, and carry an allowed predicate type (e.g. SLSA provenance)? If the policy doesn't require it, these report |
Registry access is read-only (registry.py, stdlib urllib): manifest resolution by tag or digest (one level of manifest-list/index selection), blob fetches with digest self-check, and the anonymous bearer-token flow Docker Hub / GHCR use. The client has no write path. HTTPS everywhere except loopback (so local dev registries and tests work).
Signature layout follows cosign: the signature object at tag sha256-<digest>.sig carries the base64 signature in the dev.cosignproject.cosign/signature annotation and the signed simple-signing payload as a layer; attestations live at sha256-<digest>.att as a DSSE envelope layer. The OCI Referrers API is tried as a fallback. [Verify per registry: GHCR supports referrers; Docker Hub coverage has historically been partial — the tag layout is tried first for that reason. Signature-annotation placement also varies slightly across cosign versions; both manifest-level and layer-level annotations are read.]
Cryptography is pure Python stdlib (sigverify.py): ECDSA over NIST P-256, Ed25519, and RSA PKCS#1 v1.5, plus SubjectPublicKeyInfo parsing and DSSE pre-auth-encoding. No cryptography package, no cosign binary, no dependencies.
Out of scope in v0.1: keyless/Fulcio signatures. A signature object that carries only a certificate chain fails signer_matches_policy with that reason stated — key-based trust bundles are the K0 trust model, matching the spec's owner-custodied signing-key decision (§8.2).
Tool | What it does |
| Run the gate on an image reference ( |
| The loaded policies, the trust bundle's public keys (fingerprints only), and config paths — the written scope the gate enforces. |
| The append-only, hash-chained receipt ledger of past verifications, with chain validation. |
python3 server.py # MCP over stdio, stdlib only, no dependenciesCLI mirror:
python3 server.py verify ghcr.io/your-org/your-image:v1 --policy default
python3 server.py policies
python3 server.py receipts --limit 20(verify exits 0 on PASS, 1 on FAIL.)
Env var | Default | Purpose |
|
| Directory of policy JSON files (see |
|
| Trust bundle: the public keys the gate trusts at all. Start from |
|
| Append-only receipt ledger (hash-chained). |
A policy names: policy_id, allowed_registries, signers (by trust-bundle key_id), and required_provenance (required + allowed predicate_types). A signature can verify cryptographically yet still fail the gate if its signer isn't named by the policy — that separation is the point.
python3 -m unittest discover -s tests -v # 12 offline tests, local stub registry
python3 smoke_test.py # MCP-over-stdio end-to-end, offlineThe suite builds cosign-layout fixture images signed with the system openssl binary (an external signer, as in production) and serves them from a local stub registry implementing token auth, manifests, and blobs. Covered: signed+attested PASS (ECDSA), Ed25519 PASS, wrong signer FAIL, in-bundle-but-not-in-policy signer FAIL, payload-for-a-different-digest FAIL, unsigned FAIL, missing-provenance FAIL, non-allowlisted registry FAIL (with proof the gate made no registry contact), unreachable registry FAIL, receipt-chain integrity, unknown-policy FAIL. One opt-in live test (ECLIPSE_CLUSTER_LIVE=1) checks a real public image fails the gate with reasons rather than erroring.
v0.1.0 reference implementation — K0 gate only; orchestration is later phases. Local tests pass (see above); Test Bench run pending — no certification is claimed. Per spec §7, Cluster does not list as a runtime product until something real runs under it; this gate is the first real thing.
MIT (see LICENSE). A Cyan Eclipse Technologies product. The "Powered by Cyan Eclipse Technologies" attribution travels with it.
Show the loaded verification policies, the trust bundle's public keys (fingerprints only), and config paths. The written scope the gate enforces.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It usefully discloses a behavioral trait — that public keys are shown as fingerprints only (privacy posture) — and that config paths are included. However, it does not explicitly state read-only/no side effects or describe output format, leaving gaps a no-annotation tool should fill.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the resources. The trailing fragment 'The written scope the gate enforces' is slightly terse but adds framing rather than waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A zero-param read tool with no output schema and no annotations; the description sufficiently enumerates the returned content categories so an agent knows what to expect. Only the read-only nature and rough return structure remain implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. No parameter documentation is needed, and the description appropriately focuses on what is returned rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (Show) and enumerates the concrete resources returned: verification policies, trust bundle public keys, and config paths. It is distinguishable from siblings like verify_image (an action) and receipt_list (receipt listing), though it doesn't explicitly reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'The written scope the gate enforces' hints at context but gives no explicit when-to-use guidance, no exclusions, and no comparison to alternatives. An agent must infer that this is the introspection tool for inspecting the active policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The append-only, hash-chained receipt ledger of past verifications — passes and failures alike.
| Name | Required | Description | Default |
|---|---|---|---|
| image | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does contribute real behavioral context — the ledger is append-only and hash-chained, and includes failures as well as passes — which tells an agent entries are immutable and auditable. It omits that this is a non-mutating read, says nothing about ordering, pagination, default/maximum limit, or whether the list is scoped to the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no waste, and the most distinctive property (append-only, hash-chained) is front-loaded. However it is an appositive fragment rather than an actionable statement, so brevity here reflects under-specification rather than economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema mean the description must supply both behavioral and structural detail, and it supplies only a one-line characterization. An agent still cannot tell entry ordering, pagination behavior, or what the undocumented 'image' parameter filters on before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions neither parameter. 'limit' is largely self-evident, but 'image' on a ledger-listing tool is genuinely ambiguous — a filter by image? by hash? — and the description does nothing to disambiguate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name plus the phrase 'receipt ledger of past verifications — passes and failures alike' tells an agent the resource is a log of prior verification results, and implicitly contrasts with verify_image (which performs a verification). But the description is a noun phrase with no verb, so it never states that the tool lists or returns entries, and it says nothing about policy_show.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance at all — nothing about when to call this versus re-running verify_image, and no mention of prerequisites. The only faint signal is 'past verifications', which an agent must infer means this is read-after-verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a container image against policy BEFORE it is allowed anywhere near a runtime: registry allowlist, digest resolution, cosign-style signature validity, signer named by policy, payload binding, and DSSE provenance. Returns a per-check PASS/FAIL verdict and appends a receipt. Fails closed on every error.
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| policy | No | ||
| policy_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the fail-closed error policy, the per-check PASS/FAIL return shape, and the side effect of appending a receipt — that receipt append is important behavioral information an agent would otherwise miss. It stops short of stating auth requirements, whether verification is cached/expensive, or idempotency of repeated calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence covers scope, all checks, return shape, side effect, and failure mode, with the admission-control constraint front-loaded. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The return shape and side effect are described adequately despite there being no output schema, and no annotations exist to lean on. However, for a tool with a nested object parameter and zero schema documentation, the missing explanation of policy contents and policy/policy_id selection leaves a real gap before an agent can call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters, including a nested 'policy' object, so the description must compensate and largely does not. It never explains the 'image' format (tag vs digest), what the nested policy object must contain, or — most importantly — the precedence/relationship between 'policy' and 'policy_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify a container image') and enumerates the exact checks performed: registry allowlist, digest resolution, signature validity, signer identity, payload binding, and DSSE provenance. It is clearly distinct from the sibling tools policy_show and receipt_list, which read policy/receipt data rather than performing verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'BEFORE it is allowed anywhere near a runtime' gives a clear gating/admission-control context for when to call it. It doesn't explicitly name when-not to use it or point at alternatives, but the siblings are obviously unrelated read tools, so the practical guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0policy_showreceipt_listverify_imageScored across 3 tools
Each tool targets a distinct object and action: verifying an image, inspecting loaded policies, and listing the receipt ledger. There is no plausible way to confuse them, and the descriptions reinforce the boundaries (action vs. configuration vs. audit trail).
All three names are snake_case and readable, but the ordering convention is mixed: verify_image is verb_noun while policy_show and receipt_list are noun_verb. It is consistent enough to predict, but not a single uniform pattern.
Three tools is on the lean side but fits the narrow scope of a verification gate: verify, inspect policy, read ledger. Each tool clearly earns its place with no filler.
The core lifecycle — gate on verify, inspect the policy being enforced, audit past verdicts — is fully covered with a fail-closed design. Minor gaps exist, such as fetching a single receipt by ID or a policy reload/validation operation, but agents can work around them via receipt_list and policy_show.
Fail-closed policy guardrails for AI agents running kubectl, terraform, helm, and argocd.
Governance runtime for compliance: verified, human-approved writes to a tamper-evident record.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
Governed MCP: agent audit, provenance, deterministic checks, and receipt-backed FragGate execution.
