Cairn AI Attacks: Why the Execution Loop Matters
Summary
This analysis examines the Reuters reporting and NorForge research on malicious use of Cairn agents, published on October 19, 2026. It explains the reported shared-state architecture, compares agent-directed execution with conventional automation, and analyzes the relationship between persistence, human attention and outcome validation. It also derives a clearly bounded cost-per-goal sensitivity calculation and identifies engineering implications for systems that collect sensitive findings and execute actions over time. Reported observations, uncertain estimates and editorial conclusions are distinguished throughout.
The important result happened outside the conversation
In its Cairn investigation, NorForge says it checked a completed task and found the reported uploader artifact on the victim's website. That is a narrow but consequential observation: something changed outside the agent's conversation. It is stronger evidence than a dashboard declaring success, though it does not validate every project in the investigation.
Reuters' reporting attributes a broader finding to researcher Snorre Fagerland: commercially available agents could carry out complex intrusions from start to finish without human intervention after receiving their initial instructions. Reuters independently reviewed Cairn activity to establish victims' identities; this article does not reproduce that investigation.
The engineering lesson is not that a chatbot suddenly became an infallible hacker. It is that shared task state, tools and a continuing execution loop can turn one assigned objective into work that outlasts a human interaction. Understanding that loop is more useful than treating “autonomous” as a synonym for either intelligence or guaranteed success.
What the published architecture actually establishes
NorForge describes a Cairn project as an origin, a goal and a succession of intents and facts. Agents place discoveries on a project-internal blackboard available to other workers. An operator can add hints to the same board. Those are the researcher's architectural observations, not implementation details inferred from a product name.
The important relationship is between observation and the next action. A result can become shared context; that context informs what an agent decides to do next. A failed approach need not end the project or require a person to manually reconstruct everything learned so far.
Shared state also creates an engineering tradeoff. It makes discoveries reusable, but it can make mistakes reusable too. A blackboard entry labelled a “fact” is not automatically a validated finding. The report does not establish how Cairn checks those entries, resolves conflicts between workers or prevents a mistaken inference from steering later actions. Error propagation is a design concern derived from the architecture—not a failure demonstrated by this investigation.
Nor does the public description establish a database design, crash-recovery guarantee or worker-context construction policy. Persistence here means task continuity across actions and discoveries. It should not be inflated into a claim about durable restart behavior that the sources do not document.
NorForge also lists browser automation, security tools and general-purpose runtimes in an observed worker environment. Those are the system's means of observing and affecting external services; an available tool inventory is not a per-task execution trace. Without that trace, the report cannot tell us which component supplied the decisive capability in every successful chain. That is another reason to assess the execution system rather than assign every outcome to the named model.
This is not a choice between a scanner and a brain
Ordinary security automation is not limited to one fixed probe. The official Nmap Scripting Engine documentation describes parallel execution and a general-purpose scripting language supporting varied networking and security tasks. Hand-authored automation can branch, chain actions and respond to results.
The useful comparison is where the next-action policy comes from:
| System | What determines the next action? | What a successful run does not establish |
|---|---|---|
| Advice-only chat | A person interprets the answer and decides what to execute | That the model can operate tools or complete the task independently |
| Hand-authored scanner or pipeline | Configured logic, checks and explicitly programmed branches | That it can devise an effective new sequence outside the authored policy |
| Model-directed agent loop | A model selects steps from current observations and task context, within its runtime and tool constraints | That its plan is correct, every tool action works, or its success claim is independently verified |
This is not a claim that Cairn invented the pattern. The 2022 ReAct paper already studied interleaving reasoning and actions, using interaction to gather information and update plans. That is useful conceptual context, not evidence that Cairn implements ReAct or that results on unrelated benchmarks transfer to cyberattacks.
The operational distinction is that the surrounding system can keep taking actions and carrying their results forward. Intelligence matters inside that loop; it is not the whole system.
Twenty-three hours is latency, not twenty-three human-hours saved
NorForge reports that goal-reaching tasks in the relevant activity cluster averaged a little under 23 hours from start to goal, with a wide range. This is a conditional wall-clock measure: it concerns tasks reaching their goals, not every attempt.
It does not reveal continuous compute utilization, the number of concurrent workers or the amount of human attention required. A long task could contain useful investigation, repeated failed approaches, tool delays or waiting. Without traces and a comparison baseline, duration cannot be converted into labor saved or attributed solely to reasoning ability.
Where a task continues without step-by-step operator direction, work can proceed without continuous human attention. The duration estimate does not establish how much unattended work occurred in those particular tasks or how much labor it displaced. An overlooked web property may face sustained experimentation rather than a single unsuccessful check followed by abandonment; that is an operational implication of persistent execution, not a measured increase in compromise probability.
The tempting thesis—“persistence matters more than intelligence”—goes further than the evidence permits. The investigation does not isolate model capability from tool access, orchestration, target selection, concurrency or repeated attempts. Persistence without useful decisions can simply accumulate failed work and spending. The defensible argument is that the execution system contributes leverage that model intelligence alone does not describe.
Autonomy and verified outcomes are different axes
An autonomous task can fail. A human-guided task can achieve a real intrusion. Evidence for one property does not settle the other.
NorForge explicitly warns that project goals vary: establishing a weakness is not equivalent to obtaining access. Its estimate of a goal-reaching fraction around 10% across heterogeneous activity is therefore not a universal breach-success rate. Its real-world checks of particular intrusions strengthen those cases, not every task flag in the dataset.
The reporting's scale figures also have different units. Reuters describes more than 1,200 attempted sites and intrusions involving websites belonging to more than 100 companies. NorForge's largest-cluster snapshot contains more than 1,100 projects. Dividing a company count by a site or project count would not recover a properly defined campaign success rate.
Impact is another question again. Reuters could not establish the extent of unauthorized extraction. Deere reported no indication sensitive information was accessed; SharkNinja described a contained incident on a standalone support site; Cummins was investigating a third-party website report. These are attributed company responses, not proof of either universal theft or universal safety. Website access is not automatically compromise of an entire corporate network.
What the token economics can—and cannot—show
Reuters reports Fagerland's estimate of roughly $5,000 in campaign token spending and about $50 per successful intrusion. NorForge's own text estimates roughly $5 per project when unsuccessful and early-ending projects are included. It explicitly lacks actual token-use figures and warns that its estimates may be substantially wrong.
There is still a useful accounting relationship to examine. For a consistently defined cohort:
Token cost per reached goal = mean token cost per project ÷ goal-reaching fraction.
This follows by dividing the same total token bill by completed goals rather than total projects. It does not require independent attempts. It does require consistent projects, outcomes, observation windows and cost coverage—conditions the published snapshots do not establish well enough for an independent campaign calculation.
Here is a sensitivity analysis holding mean project token cost at the primary report's rough estimate. The alternative fractions are hypothetical assumptions, not observed campaign groups; “goal” does not mean independently verified intrusion.
| Assumed goal-reaching fraction | Assumed mean project token cost | Derived token cost per reached goal |
|---|---|---|
| 5% | $5 | $100 |
| 10% | $5 | $50 |
| 20% | $5 | $25 |
The middle row shows how the headline order of magnitude can arise from assumptions. It is not independent corroboration of those assumptions or a reconstruction of an actual invoice.
The engineering consequence is that cheap tokens alone do not guarantee cheap outcomes. A cheaper model may also change task length and the goal-reaching fraction; the cost per result depends on all of them. The examined reporting does not measure those tradeoffs. Hosting, setup, operator effort and other expenses are outside this token-only calculation.
“Websites can be hacked for $50” discards both the uncertain inputs and the outcome definition. It is not a defensible general price claim.
The dashboard is a second security boundary
NorForge found exposed panels associated with multiple activity clusters and also apparently legitimate testing operations. The interfaces revealed target information, discovered weaknesses and sensitive inputs. Collecting evidence in one place can create exposure even when the underlying assessment never achieves its goal.
The researcher also described apparent administrative controls, but explicitly did not test whether those controls worked without authorization. That limit matters: the report does not establish that outsiders took over running agents.
Two distinct responsibilities nevertheless follow from the published design. First, collected findings need confidentiality and retention controls independent of whether a project succeeds. Stopping a task does not, by itself, erase the secrets already collected. Second, if shared hints and discoveries influence subsequent actions, their integrity becomes part of the execution boundary. Read access, write access and authority to direct work should not be treated as the same permission.
For builders, a further implication is temporal: authorization must remain valid while work continues, not merely when a person initially launches it. Scope, tool privileges, spend limits and expiry need enforceable runtime boundaries rather than reliance on a planner remembering them. Expiry should prevent subsequent tool execution, not merely add a request to stop to the model's context. These are engineering recommendations drawn from the observed architecture and exposure, not controls tested by this article or evidence of a particular unauthorized-control exploit.
For defenders of targeted sites, the corresponding implication is to retain and correlate investigation context across repeated activity rather than assume a failed probe ends an operator's interest. The reported task duration is not a recommended log-retention period: a mean calculated only from goal-reaching tasks cannot set that boundary. This is a reasoned monitoring priority, not a detection strategy evaluated by NorForge.
The lesson is therefore broader than “protect the dashboard.” A system that can keep acting needs a matching way to bound what it may do, distinguish discoveries from verified evidence, and preserve those limits over time. The work loop supplies leverage; the validation and authorization loops must keep up.
Sources and scope
- Raphael Satter / Reuters, via Insurance Journal, October 19, 2026.
- Snorre Fagerland / NorForge, “Inside Cairn,” October 19, 2026.
- Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” October 6, 2022; abstract examined.
- Nmap Scripting Engine, official documentation, chapter introduction.
This article analyzes published evidence. It does not claim original incident reporting, access to live systems, inspection of private campaign logs, independent intrusion testing or controlled comparisons of agent performance. Contextual research is not independent corroboration of the incident, and the economic sensitivity table is not a measured campaign bill.