CAIN-42 CAIN StudioVerification
What the evidence proves. What it does not.
A CAIN-42 deliverable is a signed, hash-chained record with a standalone verifier. It is designed so a reader who does not trust us can check it. That is a narrower claim than "secure", and we keep the difference visible.
Verify a bundle
For the $500 assessment, run this inside the unzipped evidence.zip. The current signing key is published at cainstudio.online/keystone/public-key; compare it with the key we give you on the call.
python3 verify_keystone.py --pinned-pub b6hfA2rpAdV29FOdhNXGkk4t91mCV0AnfFYwq0HO0R8=
It prints ALL RECORDS VALID and exits 0, or TAMPERED OR INVALID and exits 1. Other engagements, such as an MCPGate delivery, ship a different verifier:
python3 verify.py ./bundle python3 verify.py ./bundle --pinned-pub <sha256-of-issuer-public-key.pem>
| Output | Exit | Meaning |
|---|---|---|
INTACT | 0 | Every signature verifies, the chain is unbroken, the manifest matches the last record, and any included bodies match their digests. |
FAILED | 1 | At least one check failed. The output lists each problem. Do not accept the artifact. |
EMPTY | 1 | The ledger has no decisions. No evidence is not a pass. |
MISSING / TOOLING_MISSING | 1 / 2 | Required files absent, or the verifier's own dependencies are unavailable. |
Pin the key fingerprint out of band. A bundle that carries its own key can be forged self-consistently by anyone who controls the bundle; the pin is what makes it evidence of our issuance.
What it proves
Integrity
The records were not altered after signing. Any edit to a decision, a body, the manifest or the head breaks verification.
Provenance
The record was signed by the key you pinned, and the report and findings are bound to that signed record.
Ordering
Each entry commits to the previous one, so a deletion or reordering is detectable.
Enforcement observation
In an MCPGate delivery, the downstream tool's own call log shows which calls arrived. A denied call that does not appear there is evidence it did not execute on that host.
What it does not prove
- It does not prove the system is secure. It proves a decision was recorded and not altered.
- It does not prove the action was a good idea. Authorization is not correctness.
- It is not an independent audit. The verifier shares no code with the producer, but it is written by the same company. No third party has reviewed it.
- It does not cover a bypass. A caller with direct network access to the tool server is outside the gate. The harness demonstrates this rather than hiding it.
- It does not prove the truth of the report. A person wrote the findings; the signature binds them to the record, not to reality.
- No certification. There is no SOC 2, ISO 27001, EU AI Act conformity assessment or legal opinion behind this.
Evidence you can ask for
| Artifact | Path | What it shows |
|---|---|---|
| MCPGate harness report | artifacts/evolution43/mcpgate-verification/verification-report.json | 19 cases, expected vs observed, and the downstream call log. |
| Evidence bundle | artifacts/evolution43/mcpgate-verification/mcpgate-evidence-bundle.zip | Signed decisions with the standalone verifier. |
| Package tests | deploy/mcpgate-standalone/tests | 22 tests over config, policy, evidence and the edge. |
| Claims registry | platform-gateway/frontend/proof/bundle/claims/CAIN42_FINAL_PUBLIC_CLAIMS.json | 70 registered claims, 0 independently verified. The registry says so. |
Our source repository is private. Ask and we will send these report files before you pay. If we cannot produce one, treat that claim as unavailable.
Ask for the bundle before you pay the balance
Any engagement can be structured so you verify a sample artifact first. If a vendor will not let you run a verifier on a sample, that is the finding.
Start an engagement