Security

Threat model

The trust boundaries, the adversaries we model, what each control does and does not stop, and the residual risk we accept.

Last reviewed 31 August 2026

Formal Threat Model — CAIN Trust Fabric / CAIN Studio / MCPGate

Version 1.0 · 2026-08-16 · Classification: shareable under NDA

This model was produced by reading the running code and probing the live system, not by populating

a template. Every control marked *implemented* names the file or endpoint that implements it and,

where one exists, the test that proves it. Every gap is stated as a gap.

Standing assumption for the whole document: the platform is a single-node deployment on a

shared VM. That is a material fact for availability and blast-radius analysis and is not hidden

below.

1. System decomposition and trust boundaries

 ┌──────────────────────────────────────────────────── TB-1 · public internet ──┐
 │  Agent runtime (customer-controlled, UNTRUSTED)                              │
 │  LangChain / LangGraph / CrewAI / OpenAI / custom loop                       │
 └───────────────────────────┬──────────────────────────────────────────────────┘
                             │ HTTPS + X-API-Key, or MCP (streamable HTTP)
 ┌───────────────────────────▼───────────────────── TB-2 · enforcement boundary ┐
 │  k3s / Traefik ingress → platform-gateway (4 uvicorn workers)                │
 │  entitlement · rate limit · containment · OPA · Fabric decision · metering   │
 │  /internal/* namespace block                                                 │
 └───────────────────────────┬──────────────────────────────────────────────────┘
                             │ cain-net Docker bridge (TRUSTED-ISH, see R-7)
 ┌───────────────────────────▼───────────────────── TB-3 · service mesh ────────┐
 │  99 product services · OPA · adversarial-fuzzer · actionproof · agent-id     │
 │  billing-service (money) · cainaccounts (humans) · blizzard-governance       │
 └───────────────────────────┬──────────────────────────────────────────────────┘
                             │
 ┌───────────────────────────▼───────────────────── TB-4 · state ───────────────┐
 │  gateway.db (decisions, principals, containment) · billing db (money)        │
 │  Docker volumes · Stripe (external, PCI-delegated)                           │
 └──────────────────────────────────────────────────────────────────────────────┘

Trusted: the gateway process, the cain-net bridge, the state volumes, Stripe.

Untrusted: every agent runtime, every payload, every header the caller controls (including

X-CAIN-Chain-Id and X-CAIN-Chain-Depth), every upstream tool *response*.

Semi-trusted: the 99 product services — they are ours, but several assume /internal/* is

unreachable from outside, which is why the gateway blocks that namespace centrally rather than

trusting each service to defend itself.

2. STRIDE

3. LINDDUN (privacy)

Pseudonymisation and rehydration (named in the brief): the platform does not implement a

pseudonymisation/rehydration pipeline. pii-redactor performs one-way redaction with no

rehydration key. This is a gap, not a control, and any claim to the contrary would be false.

4. MITRE ATT&CK mapping

Enterprise techniques relevant to an agent-execution boundary:

Not applicable / not claimed: persistence, lateral movement and exfiltration techniques

targeting the host OS are outside what this platform controls. There is no EDR, no host IDS, and

none is claimed.

5. Attack trees — catastrophic scenarios

AT-1: Unauthorised real-world action executed with evidence showing it was authorised

GOAL: cause an unauthorised action AND make the record say it was fine
├── 1. Bypass the boundary entirely
│   ├── 1.1 Call the upstream service directly ......... blocked: services expose no host ports;
│   │                                                     gateway is the only published entry
│   ├── 1.2 Reach /internal/* through the proxy ........ blocked centrally at the gateway
│   └── 1.3 Compromise the cain-net bridge ............. REQUIRES host compromise (R-7, residual)
├── 2. Pass the boundary with forged authority
│   ├── 2.1 Forge a tenant id ......................... blocked: tenant derives from billing, not input
│   ├── 2.2 Steal an API key .......................... POSSIBLE (T1078) → mitigations: rotation,
│   │                                                     per-agent budgets, revocation, evidence
│   └── 2.3 Escalate from an agent sub-key ............ blocked: agent keys cannot mint/revoke
├── 3. Make the decision say yes
│   ├── 3.1 Exploit fail-open on a dependency ......... blocked: unavailable ≠ allow; entitlement
│   │                                                     fails closed; containment fails closed
│   ├── 3.2 Exploit "no profile" as permission ........ NOT a denial by design, and enforcement is
│   │                                                     opt-in — this is the honest weak point:
│   │                                                     a tenant with no ActionProof profile gets
│   │                                                     no plan-level protection
│   └── 3.3 Race the budget check .................... FIXED (E-2); was exploitable
└── 4. Corrupt the record afterwards
    ├── 4.1 Edit the decision store ................... POSSIBLE with host/db access (T-1) —
    │                                                     store is not tamper-evident
    └── 4.2 Change policy and deny it ................. blocked: content-addressed policy version

Residual for AT-1: a stolen root API key plus a tenant that has authored no ActionProof profile

and left enforcement in shadow mode. Every layer then records faithfully and blocks nothing. The

compensating controls are per-agent budgets, revocation, and the fact that the evidence trail makes

the action attributable after the fact.

AT-2: Financial exhaustion of a customer

GOAL: run up unbounded cost on a victim tenant
├── 1. Runaway loop .................................. contained (depth/chain/velocity)
├── 2. Parallel budget bypass ........................ FIXED (atomic reservation)
├── 3. Chain-id rotation ............................. falls through to tenant velocity breaker
├── 4. Many agent keys under one tenant .............. PARTIAL: keys share the tenant velocity
│                                                       ceiling, but each carries its own budget
└── 5. Expensive-service targeting ................... bounded by budget, not by call count

Worst case with production defaults: $10 per tenant-minute, then a 60s cooldown. See

ECONOMIC_SAFETY.md.

AT-3: Cross-tenant compromise

GOAL: read or affect another tenant
├── 1. Guess another tenant's decision/principal id ... blocked: every query filters on caller tenant
├── 2. Trip another tenant's breaker .................. blocked: containment is tenant-scoped
├── 3. Exhaust shared capacity ........................ POSSIBLE: single node, shared workers (D-2/D-3)
└── 4. Cross-tenant read via a product service ........ OUT OF SCOPE of the fabric — each of the 99
                                                        services owns its own tenancy; the fabric
                                                        does not retrofit isolation onto them

AT-3.4 is the most important residual in this document. The Fabric enforces tenancy at the

boundary and in its own stores. It does not guarantee that every downstream service is internally

multi-tenant-safe.

6. Red-team simulation vectors

Runnable now (assurance/stress_fabric.py, tests/test_economic_safety.py):

Not yet built (named as gaps): prompt-injection corpus replay against the live decision path;

malicious upstream-response handling; MCP protocol fuzzing against the hosted MCP server;

dependency-confusion and supply-chain simulation.

7. Residual risk register

8. What this document deliberately does not claim

• No certification of any kind is held (SOC 2, ISO 27001, FedRAMP, HIPAA). See AUDIT_READINESS.md

for control-by-control readiness rather than a compliance claim.

• No penetration test by an external party has been performed on this system.
• No formal guarantee beyond what each individual verification service proves within its own

documented scope.

• This model covers the Trust Fabric boundary and its own stores. It is not a threat model of

all 99 downstream product services individually.

Back to security & disclosure →