CAIRN sits between an AI agent and anything it can affect: verifying, recording, and, where warranted, refusing. Every decision it makes is written to a hash-chained ledger that a reviewer can check without installing CAIRN, and without taking our word for any of it.
Enterprises are deploying AI agents faster than anyone can verify what they are allowed to do. Most answer with a policy document or a demo.
Governance defines what an AI is allowed to do. CAIRN proves it did only that. A runtime enforcement layer between an AI agent and anything it can affect: verifying, recording and, where warranted, refusing.
From what an agent asks to do, down to the evidence. The Gate: every tool call is checked before it reaches a tool. Policy and Governance Engine: signed policy, autonomy ceilings, egress allow-listing. Isolated Execution: Docker with no network and a read-only filesystem, or Windows Sandbox. Cryptographic Evidence Ledger: tamper-evident SHA-256 decision records, exported as JSONL.
Every action gets a decision. Read a project file: allowed, within policy, recorded to the ledger. Send outside the declared scope: refused; egress is allow-listed, and it is recorded either way. A tool CAIRN cannot classify: refused; default-deny, what cannot be verified does not run. 0.22–0.28 ms median per decision that runs no code, CAIRN 2.10.13, measured on an idle machine.
Every decision, hash-chained: four records, allowed, refused, refused, allowed. The second is altered from refused to allowed, and it and every record after it are flagged. Alter a record and the chain says so. Your auditor verifies the exported bundle with openssl, without installing CAIRN and without taking our word for any of it.
CAIRN Trust Fabric. The runtime enforcement layer for enterprise AI. Verified, recorded, and refused where warranted. cairnetp.com. Request a pilot.
Every security and compliance review of an AI agent platform eventually asks the same question: does this platform actually enforce what the vendor says it enforces? Most answer with a policy document or a demo. Neither is something a reviewer can independently check.
Guidelines written in PDF governance packs. Code execution runs unchecked on host machines, and violations are discovered post-hoc in security audits or incident reviews.
Every tool invocation that enters the registry is authorised before it runs: one choke point, and a denied tool never reaches the executor. If gate arguments error or schemas fail, the system fails closed into refusal. What cannot be verified simply does not run.
THE 4-TIER CAIRN SYSTEM
The stacked cairn symbol represents the physical architecture: from user intent down to cryptographic evidence. From what an agent asks to do, down to the evidence of what was decided.
A tool call is classified and checked (its arguments, any code it carries, the policy it falls under) before it reaches a tool. A tool CAIRN cannot classify is refused.
Signed corporate policy, operator-declared autonomy ceilings and protected targets, and egress allow-listing, decided before the tool runs, and recorded either way.
Code runs in a Docker container with no network and a read-only filesystem, or in Windows Sandbox, a Hyper-V virtual machine, wherever either is present. Where neither is, the result says static checks only.
Tamper-evident SHA-256 decision records, with every interval CAIRN was not running recorded as a gap. Exported as JSONL an auditor verifies without CAIRN.
Inside the product, the work is divided among seven named components. You meet their names where they matter, a refusal says which component refused and why, and every record of a decision carries them, not before you start.
Every recommendation and automated action is graded across 6 deterministic assurance tiers.
Raw LLM string or unparsed script.
AST syntax parsing and secret regex scan.
Ephemeral container run with read-only root.
Zero network egress & disk delta confirmed.
Identical output across multi-run seed tests.
Safely repeatable without state corruption.
These are grades an action is assigned, not stages every action passes through. Tier 2 and above require Docker or Windows Sandbox to be present; where neither is, the result is recorded as static-only with the reason, never downgraded silently to a pass.
The answers below are the ones an evaluation asks for early, and they are the answers CAIRN gives in writing rather than in a meeting.
CAIRN Trust Fabric sits between what an AI agent proposes and what actually runs. The model stays probabilistic; the decision about what it may do is not. CAIRN refuses what policy does not allow, runs code in an isolated sandbox where Docker or Windows Sandbox is present, and records every decision in a tamper-evident SHA-256 ledger an auditor can check without CAIRN.
CAIRN evaluates every tool call it receives against schema and policy. The governance decisions (blocking, sandboxing, secret masking, and parameter schema enforcement) are 100% deterministic and do not rely on a secondary LLM judge. On CAIRN 2.10.17 a decision that runs no code takes 0.22–0.29 ms at the median, measured on our development machine, and reaching about 2.4 ms at the 99th percentile when the ledger checkpoints; one that must first parse a PowerShell script on Windows takes about 332 ms. Re-take both figures against the release you download.
For assurance tier 2 and above, yes, those tiers are defined by execution in an
isolated runtime, so without one they are unreachable. On a machine with neither, the
result is recorded as static_only together with the reason. It is never
silently downgraded to a pass, which is the distinction the assurance ladder exists to
hold.
No, and deliberately not. There is no push distribution, no heartbeat, no agent, no inbound connection from a node, and no remote revoke or reconfigure. Getting a signed policy to a node is the operator's own channel, a file, a share, an MDM. A node can export its evidence on a schedule to a directory you declare; CAIRN writes, and your organisation moves it.
Five requests from a real agent session. The verdict, the reason, the remedy and the timing are what CAIRN prints, and every decision is appended to the ledger below, hashed to the one before it, in your browser.
A refusal that only says what happened leaves an operator stuck. Each of these names the file to change and the decision they are making by changing it, which is the difference between a control that blocks work and one that governs it.
An agent is asked to clean a customer file and send it on. Three actions: one allowed, one run only after approval inside an isolated container, one refused before anything left the machine. Then the record an auditor receives.
vault/mcpInboundClients.json, per client, not in vault/egress_policy.json,
which decides what kinds of data may leave for each boundary.
One request. Every decision on the way. Watch CAIRN govern an AI agent from prompt to sandbox to evidence. Illustrative session. Interface simplified; behaviour as documented for CAIRN 2.10.
The request: deduplicate customers.csv on customer ID, then upload the clean file to reports.acme-analytics.io. CAIRN: the agent has proposed 3 actions. Nothing runs until each one has been decided. Three actions, none of them run yet: read file customers.csv; run script dedupe.mjs, written by FORGE; upload file to reports.acme-analytics.io.
The Gate. Each action is checked before it reaches a tool. Read file customers.csv: allowed. A read needs ANALYSE, within the autonomy ceiling. Decided in 0.24 ms. Run script dedupe.mjs: code parsed before it runs; secrets scanned, none found; execution needs EXECUTE_WITH_APPROVAL. Approve this exact script? Approval is tied to the script's content, not its name. If it changes, CAIRN asks again. The operator approves.
Isolated execution. CRUCIBLE runs it where it cannot reach anything: Docker, node:20-alpine, ephemeral; network none; root filesystem read-only; host not exposed; no route out. 4,812 rows in, 4,650 rows out, 162 duplicate IDs removed. CRUCIBLE: sandboxed, method docker, ran, 140 ms. Assurance tier 2, sandbox executed. The tier assigned is what was actually verified; with no Docker or Windows Sandbox, it says static_only, never a silent pass.
Action 3 tries to leave the machine. Destination checked against the allow-list: refused. Refused by COMPASS, destination not allowed: reports.acme-analytics.io is not on the egress allow-list, so nothing was sent. To permit it, an operator adds the domain to vault/egress_policy.json. That is a policy decision, and it is recorded. The clean data stays on this machine. The refusal names the file to change, so the operator knows exactly what they would be deciding.
Decision ledger: SHA-256, each record chained to the one before. Record 1, read customers.csv, allowed; record 2, run dedupe.mjs, allowed, approved, Docker, tier 2; record 3, upload, refused. Allowed and refused alike. Alter any record and every link after it breaks.
Evidence. Hand your auditor the bundle, not a promise: ledger.jsonl, every decision above, hash-chained with SHA-256; VERIFY.md, the check procedure, shipped inside the bundle; a signature, signed with Ed25519, naming the machine that produced it. On the auditor's machine, with no CAIRN installed: follow VERIFY.md with openssl; 3 records, chain intact.
Governance defines what an AI is allowed to do. CAIRN proves it did only that. Verified, recorded, and refused where warranted. cairnetp.com.
The decisions above were made on this page. This is a real evidence bundle, a vault driven through the real gates and exported by the real exporter, with the hash chain it shipped with. Your browser recomputes every hash on your machine; nothing here runs on a CAIRN server, because in a customer deployment there is none. Alter a record and the chain says so. Repair its hash and it still says so. Recompute every hash after it, though, and the chain is intact again, which is what tamper-evident means and all it means. The receipt page does that rewrite in front of you, and says what catches it.
The verification procedure is not ours to keep: it ships as VERIFY.md inside every
bundle CAIRN exports, and the code running on this page implements it verbatim. An auditor with
the bundle and openssl reaches the same answer without this site, without CAIRN,
and without trusting either.
Read one record in full, an allowed call and a refused one from this bundle, every field, what each receipt establishes and what it does not.
Business Source License 1.1, converting to Apache 2.0 on 2030-08-23.
A security review of an agent platform asks the same four questions every time. These are the four, answered with mechanism rather than with assurance.
Local-first: no account, no CAIRN-operated server, no usage telemetry and no remote kill-switch. If you configure a cloud model provider, that provider receives what you route to it, and the egress policy decides what may be routed.
This proves the files have not changed since they were built and that the same key signed them as signed previous releases. It does not prove who holds that key, it is a self-published Ed25519 key, not a CA certificate. Compare the fingerprint the verifier prints against the one in the repository before trusting a first download.