CAIN-42 · Prove it to anyone

CAIN Compliance

Keeps a running check of your agents against the EU AI Act, NIST AI RMF and ISO 42001.

Last reviewed 2026-10-01

Live   Core platform · governance

What it is

Continuous compliance with EU AI Act, NIST AI RMF, ISO/IEC 42001, and custom frameworks.

Where it fits

Part of Prove it to anyone: Signed records your auditor, regulator or customer can check without trusting us. Every CAIN-42 product runs behind the same rule: an AI agent's action is checked before it runs (identity, authority, policy, risk), decided as allow, hold for a human, or block, and recorded as signed evidence. Unknown or error never becomes allow.

Use it

• Open it https://cainstudio.online/conformance
• Documentation https://cainstudio.online/docs/conformance
• API endpoint: https://cainstudio.online/fabric/compliance/summary — needs your API key (get a free key)

Recorded status: PRODUCTION. "Live" on this page means its link answered when the catalog was last checked (2026-10-01T18:22 UTC).

Live now

Checked from your browser when this page opened, not from a cached list.

Fire a real decision

Send an action through the live CAIN-42 pipeline from this page, with no account, and watch every stage decide. This is the same pipeline every product here sits behind; it runs for a throwaway demo tenant and is rate limited.

For AI engineers

Every product sits behind one decision path: your agent proposes an action with the exact arguments, CAIN runs it through identity, authority, policy, risk, trust and quorum consensus, and answers ALLOW, REQUIRE_APPROVAL or DENY with an Ed25519-signed record. A timeout, outage or unknown verdict never becomes ALLOW. A brand-new agent has no trust history, so its first actions usually come back REQUIRE_APPROVAL.

Python (zero dependencies)

pip install https://cainstudio.online/cainstudio-0.3.0-py3-none-any.whl
export CAIN_API_KEY=...   # free key: https://cainstudio.online/signup

import cainstudio

@cainstudio.guard()
def transfer(amount_usd: float, to: str) -> str:
    ...  # runs only if CAIN allows this call, with these arguments

try:
    transfer(5000, "acme")
except cainstudio.ApprovalRequired as e:
    print("held for a human:", e.approval_id)
except cainstudio.ActionBlocked as e:
    print("refused:", e.decision.reasons)
except cainstudio.CainUnavailable:
    print("CAIN unreachable: not run")   # fail-closed

See a real decision with no account

cainstudio try          # live pipeline, stage by stage
cainstudio try --list   # the other attack scenarios

MCP clients (Claude Code, Cursor)

claude mcp add --transport http cain https://cainstudio.online/mcp

More: Python SDK · TypeScript SDK · framework integrations · AI quickstart · decision signing key

Tested guarantees in this area

Every rule in these niches has its own page with its recorded result.

• Evidence, receipts & proofs: 928 tested invariants — Signed records that prove what happened, checkable by anyone.
• Consensus & distributed systems: 64 tested invariants — Many machines agreeing on one answer, even when some fail or lie.

Related

• CAIN Proof — Turns every decision into a signed receipt anyone can check.
• Decision signing key — The public key that lets anyone check a CAIN decision was really signed by CAIN.
• Enterprise Trust Center — Security, privacy and policy answers for your procurement team.
• EU AI Act Pre-Conformity Portal — Work through EU AI Act readiness for your AI system, step by step.
• Offline verifiers — Small standalone programs that check CAIN's evidence on your own machine, without trusting our sites.
• QuorumSeal — A signed, versioned audit trail of group decisions and votes.
• Verification Lab — Hands-on labs for checking CAIN evidence yourself.
• Verify CAIN-42 — Check CAIN-42's own claims yourself, in your browser.

Full documentation

The complete reference, also at /docs/conformance.

CAIN conformance#

cain test

Runs two suites: conformance (does the fabric behave the way the contract says?) and red team (attempt the attack; pass only if it was refused).

The suite can fail#

That is the requirement it was built against. A suite that cannot fail is marketing. On a fresh or partly-configured deployment cain test typically reports several failures, and those failures are real.

A skip is not a pass#

If a conformance check cannot run, it returns SKIP, and any skip downgrades the overall result to INCOMPLETE:

INCOMPLETE is not PASSED. Silently counting "could not test" as "fine" is exactly how a green suite comes to mean nothing.

**A deployment must not be described as CAIN-conformant unless cain test reports PASSED.**

What is checked#

Conformance

Red team -- each one performs the attack:

• unauthenticated decision is refused
• forged credential is refused
• tenant cannot be set by X-Tenant, X-Tenant-Id, X-Customer-Id, X-CAIN-Tenant, X-Principal, X-Forwarded-User
• operator-only paths refuse a customer key (privilege escalation)
• internal service namespaces are not exposed through the public edge
• prompt injection / tool poisoning payloads
• decision replay
• SSRF (reported SKIP from the client side -- the decision endpoint does not fetch URLs, so this needs testing against the service that does)

Selecting suites#

cain test --suite redteam
cain test --suite isolation --verbose
cain test --json | jq '.conformance, .critical_failures'

Exit code 0 only when the result is PASSED.

Interpreting an injection failure#

If a payload is not flagged, the suite says the risk stage "ran and did not flag it -- treat the risk stage as unproven, not as a prompt-injection defence." That wording is deliberate. The blocklist behind that stage is populated by fuzzing campaigns against a deployment; an empty blocklist matches nothing, and cain doctor reports patterns_loaded alongside enforcing so the two are never confused.