CAIN-42 CAIN StudioWhy this exists
Make autonomous software accountable.
CAIN Trust Fabric is AI trust infrastructure for autonomous systems. This is what we are trying to do with it, and what we are willing to be held to.
Last reviewed 31 August 2026
What CAIN stands for
CAIN stands for COGNITIVE ARTIFICIAL INTELLIGENCE NETWORK. Each word says what it does.
Cognitive
CAIN reasons about each action instead of matching keywords. Before anything runs it weighs who the agent is, what authority it was given, what it says it is trying to do, what it has already done, and how much harm the action could cause. Its trust in an agent changes only from evidence (human approvals and recorded outcomes), never from a model's opinion.
Check it yourself: /demo shows every stage of a real decision.
Artificial Intelligence
It is built for AI agents, not for people clicking buttons: the tool calls, MCP servers, payments and record changes that autonomous systems now make on their own, often faster than anyone can watch.
Check it yourself: /docs/integrations covers LangGraph, CrewAI, AutoGen, OpenAI Agents and MCP.
Network
No single machine decides. Each hosted decision is ordered and certified by a quorum (at least 3 of 4) of independent nodes in a cluster spread across four regions, and CAIN sits on the path between your agents and the tools and services they reach, through MCPGate or the SDK guard.
Check it yourself: /live-cluster.html shows the cluster and its signed agreement proofs.
Why it exists
AI systems have started to act. They spend money, change records, call tools and invoke other agents -- and most of the industry's safety work is still aimed at what a model says rather than what it does. CAIN Trust Fabric is aimed at what it does.
Our goal is that every consequential action an autonomous system takes passes through a boundary that is able to refuse it, and leaves behind a record that survives the incident review months later. Not a dashboard that describes what already happened -- a decision that happens first, and evidence that outlasts it.
How CAIN is different
Compared with prompt filters and AI firewalls
They screen the text going into and out of a model. CAIN decides on the action itself -- the tool call, the payment, the record change, with its exact arguments -- before it runs.
Compared with observability and tracing tools
They record what an agent did, afterwards. CAIN's verdict comes first: through MCPGate or the SDK guard, the call runs only if the verdict allows it.
Compared with policy engines and API gateways
Their answer is one server's word. Each hosted CAIN decision is certified by a Byzantine-fault-tolerant quorum (four hosts in four regions, on one hosting provider), so no single machine can quietly change a verdict.
Compared with audit logs
A log is only as trustworthy as whoever holds it. Every CAIN decision is signed and bound to the arguments it allowed, so you can check it offline against our published keys without trusting us.
You can check each of these yourself from /verify.html. What we have not yet earned, such as an independent third-party audit, is listed at /not-yet.
Side by side with our nearest rivals
What each company's own announcement or documentation describes, as of 1 October 2026. Follow the link to read it yourself.
| Company | What they publicly describe | Proof layer described: quorum-certified, signed, offline-verifiable decisions |
|---|---|---|
| Zenity | Runtime Boundaries (July 2026): evaluates every agent action in real time and lets it through, blocks it or shuts the agent down; multi-step chains stopped before they complete. Source | Not described in this material |
| Noma Security | Agent Access Control (June 2026): a distinct identity per agent and approve, review or block per MCP tool; live sessions monitored by its AI Detection and Response. Source | Not described in this material |
| Palo Alto Networks (Prisma AIRS) | Prisma AIRS 3.0: agent discovery, red teaming and an AI Agent Gateway as a central control plane for agent runtime and identity security. Source | Not described in this material |
| Check Point (Lakera) | AI Agent Security: discovers agents, assesses their configuration, blocks prompt injection and evaluates tool use before execution. Source | Not described in this material |
| Kong AI Gateway | Version 2.2 (September 2026): MCP tool access lists, identity-aware policies, rate limits and AI audit logs at the API gateway. Source | Not described in this material |
| Lasso Security | An open-source MCP gateway that proxies MCP traffic and inspects it for prompt and command injection and sensitive data. Source | Not described in this material |
| Pillar Security | Runtime guardrails and agent red teaming; a founding contributor to the open Agent Control Standard (v0.1.0, May 2026). Source | Not described in this material |
| Microsoft Agent 365 / Entra Agent ID | Identity governance for agents (GA May 2026): scoped access packages, a human sponsor per agent, time-bound access. Source | Not described in this material |
Checking an action before it runs is now common ground: several of these products do it. What we did not find described in their public material is CAIN's proof layer: each decision certified by a quorum of independent nodes, signed, bound to the exact arguments it allowed, and verifiable offline against published keys, plus a public list of what the product does not do yet. Several of them are ahead of us on agent discovery, platform integrations, certifications and customers.
What we hold ourselves to
Seven commitments, each written so you can test whether we are keeping it. A goal nobody can check is a slogan, so every one below names where to look.
1. No authorization, no execution
An action that has not been authorized does not reach the upstream service. Enforcement lives in the call path, not in a report written afterwards.
Check it yourself: POST /fabric/decisions and inspect the stage-by-stage verdict.
2. Unknown is never allowed
Every stage returns a typed verdict. A stage that could not run returns unavailable or not_configured -- never a silent allow. A control that fails open under load is a control that is absent exactly when it is needed.
Check it yourself: GET /fabric/status shows which stages are configured and live.
3. Every decision leaves evidence
Decisions are written to durable, tenant-scoped records with the stage verdicts that produced them, retrievable by id and signed so alteration is detectable. Reading evidence is itself recorded.
Check it yourself: GET /fabric/decisions/{id}/signature and GET /fabric/evidence-access.
4. The operator sets the limits, not the agent
Spend caps, call budgets and containment thresholds are held server-side and keyed on the tenant resolved from billing -- never on a value the caller sends. An agent cannot raise its own ceiling.
Check it yourself: Exceed a budget and observe the reservation refused, not merely logged.
5. Runtime-agnostic, with no framework lock-in
The boundary is a protocol -- HTTPS and MCP -- not a plugin. Anything that can make an HTTP request participates, and nothing has to be rewritten to adopt or to leave.
Check it yourself: The same endpoints and headers work from any client.
6. Deploy where your data has to live
The same architecture runs hosted by us or entirely inside your own network. Self-hosted means neither the traffic nor the evidence leaves your infrastructure, and no call has to reach us for a decision to be made.
Check it yourself: Compare the hosted and self-hosted deployments -- same domains, same verdicts.
7. Claim only what is implemented
Coverage gaps are published per trust domain, in the API, next to the capabilities that do work. Where a control is partial we say so rather than rounding up.
Check it yourself: GET /fabric/domains returns the gaps alongside the capabilities.
The one that constrains the rest: claim only what is implemented. It is why our trust domains publish their coverage gaps in the API next to their capabilities, and why we keep a public list of what this platform does not do yet.