Cairn Breakdown: No Roles, No Workflows — Agents Search the State Space Themselves

1. At a Glance: Is It Worth Your Time

Rating: ★★★★☆ (4 / 5)

Why this score: it is the most conceptually different open-source AI security project I’ve looked at recently. Almost every tool in this space does the same thing — decompose pentesting into roles and stages, then have agents each play their part. Cairn inverts that: no roles, no workflows. You give it an origin and a goal, and the engine searches for a path through a near-infinite state space on its own. And it isn’t a toy: at the Tencent Cloud Hackathon AI Penetration Testing Challenge (2nd edition), it was the only team out of 610 to AK — 54 problems out of 54.

The missing star comes from three places: the project is only five months old (open-sourced 2026-04); it’s AGPL-3.0 with an extra “commercial use requires contacting the author” clause in the README that you need to think about; and the worker backends are Claude Code / Codex / Pi, so a full search run will not be cheap in tokens.

Key Numbers (as of 2026-09-20)

Who It’s For

Building On Top of It

Allowed? AGPL-3.0 lets you modify and self-host, but offering it as a service means publishing your changes. The README’s extra “personal and educational use, contact me for commercial” line is the author’s own addition — AGPL itself draws no such distinction, so honor both, and ask the author before anything real.

How hard? Three levels:

• Swap model backend / change config: ★☆☆☆☆ (fill in LLM endpoints and worker type in dispatch.yaml)
• Change integrations: ★★★☆☆ (the Server exposes read/write HTTP APIs; the protocol, however, is written exclusively by the Dispatcher)
• Change the core: ★★★★☆ (the graph, scheduling policy and stigmergy coordination all live in the core — Python, but high-abstraction; you must internalize OODA and the three task types first)

2. What It Is — and What It Isn’t

It is not “yet another AI pentesting tool”. The README says it plainly: Cairn is a general-purpose problem-solving engine, and penetration testing is simply the first domain it has been validated on.

The author’s framing:

Penetration testing is fundamentally a directed search through a near-infinite state space: the origin is known (target IP, target system), the goal is defined (get a shell, capture the flag), and the path is unknown.

That shape isn’t unique to pentesting. Vulnerability research, mathematical proof, CTF challenges — any problem with a clear start, a clear success condition, and an unknown path in between has it.

Compare it with Shannon (Issue #2) and the difference snaps into focus: Shannon is “read source → map attack surface → actually attack → verify → report”, with roles and stages hardcoded. Cairn has zero roles and zero workflows — you supply origin and goal, and the path grows out of the engine.

3. Blackboard Architecture: Fact / Intent / Hint

The engine is built on a Blackboard Architecture with an explicit fact-intent graph. Three primitives are all it needs:

The graph grows from origin toward goal. Every new Fact is a stepping stone; every Intent is a step into the unknown.

Agent Workers run an OODA loop: Observe the full graph → Orient to current state → Decide the next intents → Act to explore — then write findings back as new Facts.

The coordination model deserves its own mention: agents have no direct communication at all, coordinating only by reading and writing the shared board — stigmergy. No information silos, and no cost spent shipping context between agents. The flip side: an agent sees others’ conclusions, never their reasoning.

4. Three Task Types: Roles Emerge at Runtime

Three task types, all executed by the same Worker:

There is no “recon agent”, “exploit agent” or “report agent” here. Tasks are generated at runtime from the graph’s current state, not dispatched from predefined job descriptions. This is the deepest difference between Cairn and the majority of multi-agent frameworks.

5. Architecture: Server / Dispatcher / Worker

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

     ┌──────────────────────────────────┐
     │           Cairn Server           │
     │    Facts + Intents + Hints       │
     └─────────────────┬────────────────┘
                       │
                Read / Write API
                       │
     ┌─────────────────┴────────────────┐
     │             Dispatcher           │
     │  Schedules tasks, manages        │
     │  containers, writes protocol     │
     └──────────┬───────────────┬───────┘
                │               │
┌───────────────┴──┐     ┌──────┴──────────────┐
│  Worker Container│     │  Worker Container   │
│   (Project A)    │     │   (Project B)       │
└──────────────────┘     └─────────────────────┘

• Cairn Server maintains graph consistency and nothing else.
• Cairn Dispatcher reads the graph, schedules tasks, spins up and tears down worker containers, and is the sole writer to the protocol.
• Worker Container: one per project, with multiple Agent Workers running concurrently inside. A Worker receives a prompt and returns structured output — that’s its whole interface.

If you’d rather skip Docker, there’s local mode: no containers, reusing the claude / codex / pi CLIs already installed and logged in on the dispatcher host, with no API keys in the config. The cost: agents run with your user permissions and no sandbox — don’t fire it up carelessly on your main machine.

6. Results: 54/54, the Only AK at Tencent Cloud Hackathon

Tencent Cloud Hackathon · AI Penetration Testing Challenge · 2nd Edition

610 teams · 1,345 participants · top universities and security firms across China

More interesting than the rank is the confession in the README:

The system had never been tested before the competition. The full pipeline came online for the first time at 4 AM on race day. No training, no tuning, no domain-specific tooling. Zero MCP tools, zero RAG, zero predefined agent roles.

In other words, the AK didn’t come from a pile of tool integrations and prompt tuning — it came from the generalization of state-space search itself on unseen problems. That is exactly what the project set out to prove.

7. Getting Started

Prerequisites: macOS or Linux, Python ≥ 3.12, Docker (container mode only).

1
2
3
4
5
6
7
8
9

# 1. Pull the worker container image
docker pull --platform=linux/amd64 ghcr.io/oritera/cairn-worker-container:latest
docker pull ghcr.io/astral-sh/uv:python3.13-trixie

# 2. Create your config and fill in LLM endpoints + API keys
cp dispatch.example.yaml dispatch.yaml

# 3. Bring it up
docker compose up --build

docker compose starts cairn-server on :8000, then cairn-dispatcher once the health check passes. Data persists to ./datas/cairn/.

No Docker (local mode):

1
2
3

cp dispatch.local.example.yaml dispatch.yaml   # runtime.execution: local
uv run --project cairn cairn serve
uv run --project cairn cairn dispatch --config dispatch.yaml

On startup the dispatcher verifies each configured worker CLI is installed and runnable, and reminds you they must already be logged in.

Run the tests (no Docker, no live model endpoints needed):

1

uv run --project cairn --group dev pytest

8. Limits and Risks (Don’t Skip These)

1. AGPL-3.0 + commercial clause: if you want this in a company, sort out compliance first — and consider contacting the author for a commercial license.
2. It really acts: like Shannon, it changes target system state. Only run it where you have explicit authorization.
3. Model cost: backends are Claude Code / Codex / Pi. A full search run isn’t cheap — start small.
4. Very young: open-sourced 2026-04, five months old. APIs and internals may shift.
5. Local mode is unsandboxed: agents run as your user. Don’t run it bare on a machine you care about.

9. One-Line Verdict

If what you want to see is “how AI finds its own path without a script”, Cairn is one of the closest answers in open source today. If what you need is “a pentest report I can wire into CI today”, it’s still too young — Shannon’s fixed pipeline is the more practical choice.