MCPGate · enforcement boundary
Your agents' tool calls run only when authorized
MCPGate is the gate in front of your tools and APIs. CAIN-42 decides whether an agent's action is allowed; MCPGate makes sure only allowed calls get through. Everything else is refused, with signed proof. Where it stands today: running live on real servers, still pre-production, not yet independently audited.
Three steps, every time
- 1
Agent proposes
Your AI agent wants to do something: call a tool, write to a database, send money. It can only ask.
- 2
CAIN-42 decides
CAIN-42 checks who is asking, whether they have the authority right now, and how risky it is. No authority means no action.
- 3
Gate enforces, proof is kept
The gate lets only the approved action through. The decision and what happened are saved as signed proof anyone can check.
Why teams use CAIN-42
It is not the agent
CAIN-42 does not replace your model and does not decide what your agent wants. The agent proposes; CAIN-42 only decides whether that action has valid authority.
Stops actions without authority
An action runs only while its authority is valid. Expired, revoked, forged or out-of-scope authority stops it, before it happens, not after.
Proves every decision
Every yes and every no is signed, so you can show exactly what happened and why. Works with any agent that calls tools over HTTP or MCP.
Protect your agents in minutes
Free to start. Protection is on by default.
Under the hood
The technical detail
Everything below is for engineers and security reviewers. Each claim links to evidence you can check yourself.
Technology
Built for the execution channel, not just the prompt
Prompt filters inspect text. CAIN-42 governs what agents actually do: tool calls, shell, databases, APIs, money. The rule it is built on: an agent may learn, remember, plan, delegate and discover tools, but none of that creates authority. Only a decision the CAIN-42 cluster has committed does, and it is re-checked before every action.
Decision pipeline
Identity, intent, policy, authorization, risk, trust, consensus, enforcement and evidence, in that order. Each stage reports its verdict and whether it enforces.
live stage status →Byzantine consensus authorization
PBFT with n=4 and f=1 on two live clusters: cain-mr-01 (Atlanta, Los Angeles, Miami), which certifies every hosted decision, and cain-mr-02 (Atlanta, Los Angeles, Miami, Silicon Valley), which survives losing any one host. A decision counts only with a quorum certificate of 3 Ed25519 signatures.
watch it live →Enforcement boundary (MCPGate)
Sits in front of MCP servers, APIs and tools. A call runs only if that exact call was authorized; anything else gets a signed denial.
5 ran, 12 attacks blocked →Signed evidence
An Ed25519-signed, hash-chained record per decision, with the key kept outside the database. Standalone verifiers re-check everything offline.
Verification Center →Default-deny SDK
The Python guard and MCP proxy hold any action you did not declare. Allow tools explicitly with guard(allow=[...]); opting out is recorded on every decision.
quickstart →Agent hypervisor (ZoD)
Agent code runs confined: Linux namespaces, cgroup v2 and a kernel syscall filter (seccomp-BPF) that refused all 15 escape calls in a live run. Its authority is committed by the live cluster and re-checked before every action: expiry, trust, identity, tool schema, context, trajectory, revocation, evidence, parent authority, policy changes and risk budgets. Today it is a library the operator runs, not yet a hosted service.
kernel filter, verified live →Send one action through the live pipeline
No account. Each button posts a fixed scenario to /fabric/try on this site (the hosted pipeline makes the decision; MCPGate enforces decisions, it does not make them) and shows the real decision, stage by stage, including whether each stage was enforcing. The demo forces enforcement on for its own throwaway tenant; the response says so.
For developers
One request. A signed decision back.
Try it with no account: send a prompt-injection attempt through the live pipeline. You get back the verdict, which stage blocked it, and the consensus certificate your gateway verified.
$ curl -X POST "https://cainstudio.online/fabric/try?scenario=prompt-injection"
{
"verdict": "BLOCKED",
"blocked_by": ["trust"],
"consensus": {
"cluster_id": "cain-mr-01",
"certificate_verified_by_gateway": {
"verified": true,
"signers": ["cain-mr-node-1", "cain-mr-node-2", "cain-mr-node-3"],
"quorum": 3
}
},
"evidence": { ... }
}Architecture
Where CAIN-42 sits
The enforcement boundary is the third box. The dashed PBFT layer above it is how MCPGate enforces consensus.
Proof, not promises
Check what is live right now
Your browser loads each row below from its source as the page opens. A source that does not answer shows as NOT LIVE.
What CAIN-42 is not, yet
What CAIN-42 is, and is not
What it is
A trust and execution-control runtime for AI-agent actions. An action is proposed, a pipeline evaluates it (identity, intent, policy, authorization, risk, trust, verification, approval), a boundary applies the verdict before the tool runs, and the decision is recorded as evidence. Every hosted decision is ordered and signed by a 4-replica PBFT cluster (3 of 4 signatures), and agent authority in the CAIN-45 hypervisor is committed by the same live cluster.
Is it an "agent hypervisor"?
Partly. The hosted gateway mediates the tool calls routed through it and cannot see a call that bypasses it. Separately, the CAIN-45 agent hypervisor (ZoD) confines agent code with Linux namespaces and cgroups, takes its authority from the live cluster, and re-checks that authority before every action. It is a library the operator runs today. It has a kernel syscall filter (seccomp-BPF, classic BPF, not eBPF), but no egress allowlist (egress is deny-all) and no hardware attestation yet. It is not a VM hypervisor.
What it is not, today
Not certified by anyone. Not independently reviewed. Consensus runs live on 4 replicas across 3 hosts in 3 regions, but one operator and one provider run all of them, and losing the two-replica Los Angeles host halts progress. Not every hosted stage enforces: since 2026-09-27 every tenant is in enforce mode by default, and identity, authorization, PBFT consensus, MCPGate and execution block; policy, risk, intent, verification, ActionProof and approval verdicts are recorded but do not block. An agent's authority lapses on a policy change and on risk or blast-radius budgets (tripped on the live cluster); a cluster epoch or membership change is enforced too, but was tested only with an injected change, not by re-keying the live cluster. The roadmap's next evolution (a unified trust kernel, eBPF kernel enforcement, swarm governance, cluster federation) is a plan, not built. No customer traffic is claimed.
The enforcement boundary in detail
Consensus-bound authorization
A tool call runs only with a PBFT-committed authorization bound to the exact action, scope, identity, security context, expiry and single use. Replay, action substitution, capability escalation, identity substitution, context drift, forged certificates, and missing or expired authorizations are refused with signed denial proofs.
Fail-closed where it is wired
A stage that cannot answer is reported as unavailable, never as allow. Identity revocation, entitlement and the tenant kill switch stop calls even in shadow mode.
Self-hosted proxy: default-deny
The self-hosted SDK and MCP proxy (cain/guard.py) hold any undeclared action for approval, and a failed quarantine lookup fails closed. The 5 dangerous calls a 2026-09-26 internal audit got through (shell pipe to bash, reading /etc/shadow, writing authorized_keys, exfiltration) are now refused, with regression tests. Operators declare authorized tools with guard(allow=[...]) or CAIN_ALLOWED_ACTIONS. Opting out is explicit and recorded on every decision.
Self-hosted
MCPGate is designed to run inside your network, so traffic and evidence stay on your infrastructure. A Helm chart exists in the CAIN-42 repository. No public self-hosted installer is published today: /install.sh returns 410.
8 ways to verify CAIN-42 yourself
Verify CAIN-42 yourself
Every step uses a real endpoint or a published, signed file. The verifiers import none of CAIN-42's code; the implementation itself is not published.
1 · Live multi-region PBFT cluster
4 replicas in Atlanta, Los Angeles and Miami, running now. Your browser fetches each decision from all four replicas and verifies every Ed25519 vote. It can audit the whole history continuously, and a tamper lab lets you try to get a modified certificate accepted. Fault-injection run: 336 certificates, 49/49 checks.
2 · Current state
The generated snapshot: commit, process start, enforcement flags, live mode, known limitations.
3 · The signed claims registry
Every public CAIN-42 claim with its status, evidence level, artifact digests and limits. Your browser checks the Ed25519 signature.
4 · Agent hypervisor on the live cluster
Agent authority committed by cain-mr-01, then broken 17 ways: 14 tripped for real (expiry, trust, identity, tool schema, context, trajectory, revocation, deleted evidence, revoked parent, policy change, unreadable policy, risk budget, blast-radius budget, a delegate spending its parent's budget) and 3 injected (epoch, membership). Every next action was refused and the tool never ran. One command each, no CAIN code: 48/48 and 60/60 checks. The syscall-filter run is a third bundle (8/8).
5 · MCPGate enforcing consensus
Tool calls ran only with a PBFT-committed authorization; nine attack classes were refused with signed denials. Disposable cluster.
6 · Live sandbox cluster
Crash up to two of four sandbox nodes and watch commits stop at the quorum boundary; signed node state checked in your browser.
7 · Soak on the live multi-region cluster
Continuous writes; every 20 minutes a random replica is killed on its own host and restarted; hourly hash-chained checkpoints signed with the evidence-root key, each with a fresh MCPGate-enforced authorization and its refused replay.
Soak: checking…
8 · Earlier 72-hour soak: failed, and why
The first soak ran on a single-host twin. At hour 11 its commits stalled at height 4094: two replicas in view 39, two in view 40. That was a real liveness bug, fixed in e1cf69c and running live since. The harness then ran out of memory at hour 24. The verifier marks the stalled checkpoints invalid.
Three sites, one system
cainstudio.online · CAIN Studio
The hosted CAIN-42 control plane: the decision pipeline, API keys, the evidence store, the public Lab and the Verification Center.
mcpgate.online · MCPGate
The enforcement boundary: the component in the agent's call path that lets a tool call run or stops it. Self-hosted by design.
clawx.click · CLAWX
The agent-facing layer: agent identity, channels and approvals, and the public evidence log. Most CLAWX integrations are not built yet; each is labelled.
All three names resolve to one host today. They are three views of one system, not three independently operated deployments.
History
Latest change, 2026-09-28: AI agents now get their permission from the live server cluster, and that permission is re-checked before every action. We broke it 14 real ways (time ran out, trust dropped, the agent's model was swapped, a tool changed, a policy changed, a budget ran out, and more) and it stopped the agent every time. Agent code also runs behind a kernel filter that blocked every escape attempt. Anyone can re-check the proof. Earlier generations (CAIN 1–41) stay published as history, not as the current system; the previous homepage is kept as it was on 2026-09-25, marked superseded, and the now page takes precedence over it.