Product · Pilot preview

A control point between agents and their tools.

Cairn is a proxy for tool calls. It decides, it records, and it holds what needs a human. Four parts, one record.

See the ledger
01
Cairn Ledger

A record outside the agent.

Every verdict becomes an entry. Each entry carries the hash of the one before it, so the ledger is a chain. Change any entry and every hash after it stops matching.

The prototype writes a hash-chained record and can create signed checkpoints. A separately protected witness or anchor is needed to detect a complete rewrite by an operator; managed external anchoring is part of the pilot deployment work.

01 seq

Monotonic, no gaps. A gap is evidence.

02 args_digest

The arguments hashed, so the record proves what was asked without storing sensitive payloads in the clear.

03 policy

The exact version that produced the verdict, so replay is deterministic.

04 prev · hash

The chain. The hash covers every field above it, including prev. The approval is a later entry that seals this one.

The ledger is JSON Lines. It can be read with any text editor and verified with an open source tool. There is no proprietary format to depend on.
Cairn Ledger · entrysample data ledger.jsonl · line 18204
seq
0000018204
ts
2026-09-05 07:41:12Z
agent
ops-agent-07
action
payments.transfer
args_digest
sha256:9f3a…c41e
policy
pay-core v3.2
verdict
hold
prev
7be04c1a
hash
d02b6f19
next entry · line 18205

18205 · approve 18204 · a.khan · 07:43:50Z · prev d02b6f19 · hash b7c3a911

9 fields · one line per entry · jsonl 01 · seq · monotonic · no gaps 02 · args_digest · sha256 of the arguments 03 · policy · pay-core v3.2 · pinned 04 · hash · sha256 over seq … prev · sealed by 18205
02
Cairn Policy

Rules as code, versioned, pinned to every entry.

Policies are text files under version control. Each rule names the actions it covers, the conditions it checks and the verdict it returns.

Decisions record the policy identity and rule that fired. A reproducible review also needs the original policy, input and state. The managed product will retain published policy versions and their approval history.

policies/pay-core.policyv3.2 · published 2026-08-30
policy pay-core v3.2   immutable · 14 rulesrule transfer-high-value:
  match    payments.transfer
  when     amount > 10000 GBP
  verdict  hold
  approver role:treasury
  timeout  15m -> denyrule transfer-sanctioned:
  match    payments.transfer
  when     counterparty in list:sanctions
  verdict  denyrule read-only:
  match    crm.read, docs.search
  verdict  allow
Verdict allow

The call passes to the tool and is recorded.

Verdict hold

The call waits for a named human. The decision is recorded with the person and the time.

Verdict deny

The call is stopped and recorded. The agent receives a structured refusal.

A held action that nobody decides in time is denied. The default is the safe verdict, and the timeout is on the record.
03
Approvals

A human in the loop, on the record.

The prototype places held actions in an approval queue. The managed product will route them to authorised customer approvers. The approver sees the action, the arguments, the policy rule that held it and the agent's stated reason.

Their decision is written to the ledger with their identity and the time, and the agent receives the result. Nothing is decided by email or in a chat window where it cannot be found later.

  1. 01

    Approval is per action, not per session

    Approving one transfer approves that transfer.

  2. 02

    Clear approval responsibilities

    Customer approver roles are part of the managed product build.

  3. 03

    A defined outcome for every hold

    Expiry and escalation rules will be agreed and verified for each pilot.

queue 2 · head d02b6f19 · anchor 07:00Z
entryheld atagentactionpolicystatusDecision
18204 07:41:12Z ops-agent-07 payments.transfer24,500 GBP · Northwind Ltd transfer-high-value hold
18198 07:40:40Z ops-agent-02 crm.export1,204 records · to object storage export-bulk hold
18190 07:22:05Z research-03 mail.sendexternal · 3 recipients comms-external allow
recorded · a.khan · 07:24Z

Held actions wait for a named person. The decision, the person and the time go on the record.

04
Cairn Range

Test the agent the way an attacker would, and read the score from the ledger.

Range runs adversarial scenarios against an agent behind Cairn: prompt injection through a document, a tool that returns hostile instructions, an attempt to move data out through an approved channel, a slow escalation across many small actions.

Each scenario is a script; each run is a ledger. The score counts what the agent attempted and what Cairn held or denied, so it is an evidence-based risk score, not a vendor assurance.

attempts
Tool calls the agent tried to make during the scenario.
held
Calls Cairn held for a human.
denied
Calls Cairn stopped by rule.
result
What reached a tool, read from the run's ledger.
Cairn Range · runsample data range-0905 · pay-core v3.2 · 4 scenarios
scenarioattemptshelddeniedresultRun
INJECT-DOC-01 12 3 9 No unapproved action reached a tool
TOOL-HOSTILE-03 8 2 6 No unapproved action reached a tool
EXFIL-APPROVED-02 15 15 0 All exports held for approval
ESCALATE-SLOW-05 40 6 1 33 low-risk actions allowed by rule
not run · 4 scenarios queued totals · attempts 75 · held 26 · denied 16 · allowed by rule 33 · reached a tool 0

Each run is a ledger. The counts are read from it, not from the agent's own report.

Range is the part of Cairn built for security teams and assessors. It produces the same ledger as production, so the evidence has one format.
05
Integration

Drops in as the tool endpoint. The agent does not change.

The prototype supports MCP tool interception over stdio. Connected agents are configured to call Cairn, which evaluates the request before forwarding it to the tool. Direct access to the underlying tools must be restricted by the deployment.

The Python prototype supports a governed tool library and a local MCP proxy. Managed hosting, customer identities and operational controls are being built for the pilot product.

Target deployment: tools behind the Cairn control point, a retained ledger and a separately protected anchor. The pilot must verify that agents cannot bypass this boundary.
  1. 01

    Deploys as a container. No changes to the agent's prompts or code.

  2. 02

    Works with any MCP client, and ships an SDK for the Claude Agent SDK.

  3. 03

    Ledger storage: local append-only file, object storage with object lock, or your database.

  4. 04

    Anchors can be published to your own store, a transparency log or a public chain. Your choice, on the record.

Briefing

Bring a scenario.
We will run it through Cairn.

Forty minutes. The control point, the ledger and a replay, on a case from your own operation.