CAIN-42 CAIN Studio
Sign inGet started
Menu

CAIN-42 · How it works

Moat 3: Trust Graph

Maps how every agent, person, tool and resource is connected.

Last reviewed 2026-10-01

Built in   The 7 moats · Moat

The question this moat answers: HOW IS EVERYTHING CONNECTED?

What it is

Connect principals, agents, authority, delegation, intent, policy, trust, decisions, tools, resources, execution, effects, evidence, causality, and incidents into a tenant-isolated historical relationship graph.

Where it fits

Part of How it works: The 7 moats, the live consensus cluster and the research lab. 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

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

2 test suites cover this moat in the CAIN-42 test manifest.

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.

Related

Full documentation

The complete reference, also at /docs/cain_7_moats.

CAIN 7-Moat Architecture#

Status: Canonical Version: 1.0 Last Updated: 2026-09-10

The CAIN Trust Fabric is organized into seven defensive moats. Each moat is an independent security layer that an attacker must defeat in sequence. No single moat grants authorization; every moat enforces its own boundaries.

MOAT #1: TRUST STATE#

Purpose: Determine the current evidence-backed trust state of every relevant principal/agent.

Core Question: "WHO DO WE TRUST RIGHT NOW?"

Key Components:

Evidence Sources:

Fail-Closed Principles:

MOAT #2: SECURITY-CONTEXT CONTINUITY#

Purpose: Preserve authenticated identity, authority, delegation, intent, policy, trust, constraints, and provenance across every system boundary.

Core Question: "DOES AUTHORITY AND SECURITY CONTEXT SURVIVE EVERY BOUNDARY?"

Key Components:

Continuity Verification:

MOAT #3: TRUST GRAPH#

Purpose: Connect principals, agents, authority, delegation, intent, policy, trust, decisions, tools, resources, execution, effects, evidence, causality, and incidents into a tenant-isolated historical relationship graph.

Core Question: "HOW IS EVERYTHING CONNECTED?"

Key Components:

Graph Analysis:

MOAT #4: EXECUTION PROVENANCE & ATTESTATION#

Purpose: Prove what actually executed, under whose authority, with which policy, trust state, security context, software components, tools, MCP servers, execution path, effect, and evidence.

Core Question: "CAN WE PROVE WHAT ACTUALLY HAPPENED?"

Key Components:

Database Tables:

Attack Detection:

MOAT #5: PREDICTIVE TRUST & BLAST RADIUS#

Purpose: Before consequential execution, determine what an actor could reach, affect, or cause, using trust, authority, graph, risk, impact, causal, and counterfactual analysis.

Core Question: "WHAT COULD HAPPEN BEFORE WE LET IT HAPPEN?"

Key Components:

Analysis Dimensions:

Uncertainty Classification:

Adversarial Resistance:

MOAT #6: ADVERSARIAL TRUST ENGINE#

Purpose: Continuously attack CAIN's own trust assumptions in controlled environments to discover authority escalation, context attacks, replay, graph poisoning, provenance failure, MCP/tool substitution, cross-tenant attacks, trust manipulation, and other failures.

Core Question: "CAN CAIN BREAK ITS OWN TRUST GUARANTEES, DETECT THE FAILURE, AND CONTAIN IT?"

Key Components:

Attack Categories: 1. IDENTITY - spoofing, substitution, credential misuse, context mismatch 2. AUTHORITY - privilege escalation, authority widening, unauthorized delegation 3. DELEGATION - escalation, transitive privilege, delegation replay 4. GRAPH - poisoning, false edges, hidden resources, cross-tenant traversal 5. TRAJECTORY - replay, manipulation, effect spoofing, gradual escalation 6. POLICY - bypass, stale policy, version substitution 7. TRUST - manipulation, state confusion, fake evidence 8. TOOL/MCP - substitution, identity spoofing, capability escalation 9. SECURITY_CONTEXT - mutation, substitution, widening, replay 10. PROVENANCE - substitution, evidence tampering, attestation replay 11. EXECUTION - stale authorization, effect mismatch, duplicate execution 12. MEMORY/EVIDENCE - poisoning, false provenance, signal injection 13. CROSS_TENANT - identity, authority, graph, evidence, trust traversal 14. COUNTERFACTUAL - manipulation, prediction poisoning

Attack Outcomes:

Feedback Loop:

ATTACK → DETECT → VERIFY → CONTAIN → EVIDENCE → TRUST UPDATE → RE-EVALUATE → PROVE

Anti-Gaming:

MOAT #7: AUTONOMOUS TRUST CONTROL LOOP#

Purpose: Connect verified evidence, trust state, prediction, decisions, enforcement, execution, outcomes, adversarial results, and future trust into a governed continuous feedback loop.

Core Question: "CAN VERIFIED EXPERIENCE CONTINUOUSLY CHANGE FUTURE TRUST AND DECISIONS?"

Key Components:

Control Loop:

DRIFT → DETECT → IMPACT → SENTINEL → CONTROL → ENFORCEMENT → RECOVERY → RE-VERIFICATION → EVIDENCE

Subsystem Integration:

Trust State Machine:

Response Actions:

Fail-Closed Principles:

Moat Dependencies#

┌─────────────────────────────────────────────────────────────────┐
│ MOAT #7: AUTONOMOUS CONTROL LOOP                                 │
│   Consumes outputs from all other moats                          │
└─────────────────────────────────────────────────────────────────┘
         ▲
         │
┌────────┴────────────────────────────────────────────────────────┐
│ MOAT #6: ADVERSARIAL ENGINE                                     │
│   Tests all other moats; emits trust signals                    │
└─────────────────────────────────────────────────────────────────┘
         ▲
         │
┌────────┴────────────────────────────────────────────────────────┐
│ MOAT #5: PREDICTIVE TRUST + BLAST RADIUS                       │
│   Pre-execution analysis; causal + counterfactual                │
└─────────────────────────────────────────────────────────────────┘
         ▲
         │
┌────────┴────────────────────────────────────────────────────────┐
│ MOAT #4: EXECUTION PROVENANCE + ATTESTATION                    │
│   Binds decision → execution → effect                           │
└─────────────────────────────────────────────────────────────────┘
         ▲
         │
┌────────┴────────────────────────────────────────────────────────┐
│ MOAT #3: TRUST GRAPH                                           │
│   Reachability, blast radius, graph relationships               │
└─────────────────────────────────────────────────────────────────┘
         ▲
         │
┌────────┴────────────────────────────────────────────────────────┐
│ MOAT #2: SECURITY-CONTEXT CONTINUITY                           │
│   Preserves identity, authority, context across boundaries     │
└─────────────────────────────────────────────────────────────────┘
         ▲
         │
┌────────┴────────────────────────────────────────────────────────┐
│ MOAT #1: TRUST STATE                                           │
│   Evidence-derived trust computation                            │
└─────────────────────────────────────────────────────────────────┘

Testing Requirements#

Every moat requires: 1. Acceptance tests - Core functionality works 2. Security tests - Attack vectors blocked 3. Tenant isolation tests - Cross-tenant access prevented 4. Stale-state tests - Expired data handled correctly 5. Graph integrity tests - Poisoning detected 6. Non-execution tests - Counterfactuals don't execute real actions

Evidence References#

Each moat produces durable, tenant-scoped evidence containing:

Evidence is never deleted, only superseded with new versions.

Governance#

All seven moats are governed by CAIN Policy. Policy changes require: 1. Proposed via governance mechanism 2. Approved by authorized actors 3. Applied atomically across all moats 4. Version tracked for rollback

No moat can be bypassed by policy. Policy governs the moats, but cannot disable them.

Try CAIN-42 on your own agents

Create a free account and every new account starts with a 7-day trial of the full platform. Or try the sandbox first, with no account at all.

Create a free account →  ·  Try the sandbox  ·  See the whole ecosystem