# NorForge

> NorForge is an employee-owned sovereign AI security company building the next generation of security technology. Founded in 2026 by senior operators who ran the technical arm of a Silicon Valley private equity firm.

Contact: contact@norforge.com
Press: Snorre Fagerland, snorre@norforge.com
Website: https://norforge.com

## Mission

NorForge is an employee-owned company building the next generation of sovereign AI security technology. Our team of senior operators brings decades of experience across security products, national-scale infrastructure, threat research, and applied AI.

## Background

NorForge was founded in 2026 by the senior operators who built and ran the embedded technical practice of a Silicon Valley private equity firm. They led technical due diligence and engineering work across portfolio companies, developing a deep understanding of where security technology falls short — and where AI can close the gap.

The team built and ran security products, telecom-scale platforms, and national-scale infrastructure, with a pedigree spanning Symantec, NortonLifeLock and Blue Coat, and nation-state threat research cited in the Wall Street Journal, The Economist, and Forbes.

NorForge is an independent, employee-owned company. It operates internationally, with a US parent company headquartered in Palo Alto and a European operating subsidiary.

NorForge is an active member of the Open Secure AI Alliance, The Linux Foundation, and the NVIDIA Inception program. We also sit on the board of directors at OSTERA.org.

## Proof - five pillars of deep know-how

- **The Team Behind Norman Shark Sandbox**: Before agents needed containing, we built the sandbox. Our team created the Norman Malware Analyzer, acquired later by Blue Coat and Symantec, and now part of Broadcom. Decades of experience detonating hostile code now go into containing autonomous agents.
- **Sector Expertise & Silicon Valley Roots**: In Silicon Valley, we led technical due diligence and value creation across dozens of security and infrastructure software companies as the technical arm of a leading sector Private Equity and Venture Capital firm.
- **Internationally Recognized Threat Research**: 30 years of malware reverse engineering and nation-state threat research cited by The Wall Street Journal, The Economist, and Forbes.
- **AppSec, Open Source & Community Leadership**: Our team members have contributed to The Honeynet Project and other open-source security projects, and we have led OWASP Oslo for over 15 years. That’s 20+ years of secure application delivery, open tooling and international training, now applied to LLM apps and agentic software.
- **Deep Engine & Systems Engineering**: 20+ years building core scanning engines for market-leading vendors, x86 emulators, virtualization at scale and security telemetry platforms. Building technology running on millions of endpoints.

## Memberships

- NorForge is an active member of Open Secure AI Alliance: https://secureaialliance.org
- NorForge is an active member of The Linux Foundation: https://www.linuxfoundation.org
- NorForge is an active member of NVIDIA Inception: https://www.nvidia.com/en-us/startups/
- NorForge sits on the board of directors at OSTERA: https://www.ostera.org/

## Team

- **Einar Oftedal** - Strategy, M&A & scaling
- **Tore Oftedal** - Finance, control & growth
- **Elisabeth Høiland** - Cyber risk & enterprise security
- **May Roen**
- **Erlend Oftedal** - Secure AppSec delivery
- **Tor Skaar** - Cloud & data platforms
- **Morten Kråkvik** - Cloud transformation & operations
- **Bjørn Andersen** - Versatile engineering & applied AI
- **Snorre Fagerland** - Adversarial assurance

Contact: contact@norforge.com

## Blog

### Inside Cairn: Open Windows into massive AI-Driven Cyber Operations

Published 2026-10-19 by Snorre Fagerland. More than 20 exposed Cairn panels give an unusually detailed view of how threat actors select targets, direct autonomous agents, exploit vulnerabilities, and establish persistent access to compromised systems.

#### 01 TL;DR

An investigation by NorForge into publicly exposed AI-driven penetration-testing control panels has uncovered how they are extensively used in malicious cyber operations. One of these is Cairn.

In this setting, Cairn is an AI-powered hacking system. Give it a target and an objective, and it can coordinate AI agents to investigate the target, search for security weaknesses, and attempt to break in.

More than 20 exposed Cairn panels were identified as likely associated with malicious activity, providing an unusually detailed view of how threat actors select targets, direct autonomous agents, exploit vulnerabilities, and establish persistent access to compromised systems.

In addition, a considerable number of apparently legitimate red team operations were also exposed this way, potentially placing clients at risk.

#### 02 The Opening

In September 2026, Gambit Security reported on a criminal intrusion campaign targeting online marketplaces. They recovered an attacker’s staging server and found the use of AI harnesses, such as Hermes, Strix, and Cairn. Important information, that is. Such tools frequently have web based user interfaces that are left unsecured on the open web.

Sure enough: Quick searches using the Shodan and Censys search engines reveal hosts running what appear to be AI harnesses of different kinds. Most need authorization to access. Most.

But there are quite a few of these interfaces left open by their operators. And apparently, one of the most neglected platforms is Cairn.

Our searches initially revealed a handful of open Cairn panels. Continued scans revealed new panels coming online in short order; and targeting information, language and instructions showed many of them to belong to the same threat actors.

In this article we will detail some of these. However; it is the nature of these panels that they reveal a great deal of sensitive information about the targets; including who they are, what weaknesses have been uncovered, account secrets and API keys, and whether they have been compromised or not. This means that we must aggressively redact extracted data and won’t disclose the panel addresses until they can be taken down.

![An operator task on an open Cairn panel, with target names and credentials redacted.](https://norforge.com/blog/inside_cairn/images/operator-task-secrets.webp)
Figure: Operator task containing secrets. Even root access to the attacker’s data drop is exposed.

#### 03 The Machine

![A Cairn panel listing active and completed projects.](https://norforge.com/blog/inside_cairn/images/cairn-panel-projects.webp)
Figure: A Cairn panel with a few active or completed projects. This belongs to an unrelated actor; conveniently not using recognizable target tags.

Some describe Cairn as an autonomous penetration testing engine. This is not entirely accurate; it can be used that way, yes, but its use case is more generic: It is a state-based problem solving engine, moving step by step in the general direction of a defined solution.

But in our case – yes, it is used for penetration testing.

In Cairn, each separate task is considered a project. Every project has a start point called an origin, and a predefined end goal. The agent framework then progresses from origin towards goal in a state-based organic growth.

Between start and end are cycles of intents and facts. A fact is something the agent has discovered, and an intent is what it has decided to do next. The agent posts every fact onto a project-internal blackboard. A human operator can also add their own hints to the same blackboard. Facts and hints are in this way data available to every agent worker on the path towards the defined solution. This can be visualized graphically, which also Cairn does.

![A Cairn project graph running from origin to goal.](https://norforge.com/blog/inside_cairn/images/project-graph.webp)
Figure: The progress from origin in cyan to goal in red. Not all paths succeed. This attack was directed at a major US online retailer, and ended up in GOAL MET: Webshell injected into the site.

#### 04 The Actors

Cairn panels are regular web fronts, and can be readily profiled using commercial internet scanning platforms. Over a period of a few days, we found numerous such panels. Some were empty, some were protected against unauthorized access, and some appeared to be legitimate demos or valid pentesting outfits. We will not be outing legitimate red teams here, but it is clear that placing real customer penetration tests on an unsecured panel is highly problematic.

But even filtering out those, more than 20 such panels were identified as likely malicious. As far as we could see, all appeared to have financial motivation; there was no obvious state-sponsored intrusion activity. That is not to say that this does not happen, but one assumes that type of actor knows how to secure dashboards.

Much of the observed activity seemed to coalesce around a handful of clusters, where the exposed panels contained information that tied them together.

We denote each activity cluster by a serial number starting with the “AIA” prefix; meaning “AI Activity”. The acronym for AI Threat Activity was already taken.

**Cluster AIA0001**

- Language: Chinese
- Panels: 14
- Hosting: AS56594
- Confidence: High

This activity cluster uses Chinese language, and is by far the most active of the actors that expose their panels. The operation is massive, with over 1100 attack projects spread over the 14 dashboards likely associated with this group.

AIA0001 targets a wide swath of organizations, mostly in the US, Japan and Australia. The aim seems to be to gain persistent access to e-commerce/payment infrastructure for later monetization.

This group currently seems to prefer hosting their panels via AS56594, Cgi Global Limited. We assess this cluster to be malicious with high confidence.

![Bar chart of AIA0001 targets by sector.](https://norforge.com/blog/inside_cairn/images/aia0001-target-selection.webp)
Figure: AIA0001 target selection.

This actor appears to use extensive automation in its task feeding pipeline. Consider for example this task, which is quite typical:

![A typical automated AIA0001 task, written in Chinese.](https://norforge.com/blog/inside_cairn/images/aia0001-automated-task.webp)
Figure: A typical automated task.

> **Translation**
>
> These are confirmed real shopping/e-commerce websites in four countries (US/CA/JP/AU), with traffic of 200,000–1.5 million. Playwright has verified that orders can be placed.
>
> Objective: Find unauthenticated RCE (command execution/code injection/deserialization/file-upload webshell/SQL injection leading to RCE/SSTI/SSRF leading to RCE).
>
> Priorities: Login SQL injection, unauthenticated endpoints, file uploads, deserialization, authentication bypass, account takeover.
>
> Payload: Uploader shell (HTML upload form + move_uploaded_file to save files), explicitly not a command-executing webshell.

The feeding pipeline includes automated validation of target sites. Not only are they ranked by traffic, but they have also been tested using Playwright, Microsoft’s browser automation framework, before sent to Cairn for exploitation.

There are also other hints at automation; and some are of the silly kind. For example; a lot of target sites across multiple panels have had an initial letter “w” removed. ‘Wholesale’ becomes ‘holesale’ and “winter” becomes “inter”. This suggests that there is a common, buggy domain normalizer that removes a “w” too much from the www. It makes spotting related panels very easy.

Every now and then, these attackers will open a web server on a high port to do out of band testing. In these short lived time windows, the working directory of one of these AI workers will be available for browsing. This happened at least once with one of the AIA0001 hosts, and that gave us the opportunity to get a closer look at the tooling available for the agent.

In this particular case, we found:

Table: Tools found on agent worker folder
| Software / package / tool | Use case |
| --- | --- |
| Playwright | Browser automation and web testing; the profile directories are Chromium browser state rather than source packages. |
| Chromium | Browser engine used by Playwright and related browser automation. |
| PHPGGC (PHP Generic Gadget Chains) | Generates PHP unserialize() gadget-chain payloads for authorized vulnerability validation and exploit research. |
| StyleSmuggler HTTP PoC | Research proof-of-concept for the StyleSmuggler / CVE-2026-75650 Magento report-poisoning-to-code-execution chain. |
| Magento Open Source 2.4.9 validation lab | Docker-based, revision-pinned vulnerable/patched Magento lab for safely validating CVE-2026-75650 / VULN-39341. |
| MarkShust PolyShellPatch | Deprecated Magento module intended to block executable-file uploads through cart custom-option uploads. |
| Docker | Container build/runtime tooling used for isolated validation environments. |
| PHP | Runtime and scripting language for PHP payload generation and testing PHP web applications. |
| Composer | PHP dependency/package manager; the manifest identifies the Magento PolyShellPatch package. |
| Python 3 | Main scripting language for reconnaissance, HTTP testing, parsers, proof-of-concept code, and automation. |
| Node.js | JavaScript runtime/tooling used by web probes, browser automation support, and target-specific scripts. |
| Vosk | Offline speech-recognition toolkit/model. |
| OpenSSL | TLS/cryptographic command-line and configuration tooling. |
| Xvfb | X virtual framebuffer for running GUI/browser applications without a physical display. |
| tmux | Terminal multiplexer/runtime state, typically used to keep long-running sessions and listeners alive. |
| OWASP Amass | External attack-surface discovery and subdomain enumeration. |
| dnsrecon | DNS enumeration and reconnaissance. |
| ffuf | Fast web fuzzer for directory, parameter, virtual-host, and content discovery. |
| Nmap | Network/port/service scanning. |
| rockyou wordlist | Large password wordlist commonly used for authorized password-audit and credential-testing workflows. |
| Odoo framework artifacts | Extracted Odoo server/module source or probes used to understand Odoo web, ORM, QWeb, and action execution behavior. |
| Various custom utilities | Project-specific proxying, payload validation, traffic capture, patching, and proof-of-concept utilities. |

But more importantly, one of the agent task updates contained this text:

> **Agent task update**
>
> The local environment is a Kali container, belonging to the tsec CTF/intelligent penetration test competition framework (there is a flag submission interface description in `/home/kali/workspace/.claude/skills/tsec-actions/SKILL.md`, with the flag format being `flag{...}`), but the environment variable `TSEC_SERVER_HOST` is empty and `TSEC_AGENT_TOKEN` is not actually injected, so the competition submission interface cannot be accessed

This would seem to indicate that the agent setup was repurposed from an earlier Tencent CTF challenge configuration. This is almost certainly criminals reusing existing tools, and there is no reason to believe that Tencent had anything to do with this operation.

From what we’ve seen, all tasks were performed by a worker named `claudecode_deepseek-v4.1-flash`, which could mean a Claude Code harness using the Chinese DeepSeek 4.1 Flash model that was released in September.

We dont have actual numbers on token usage, but with the underlying data it's possible to guesstimate. Deepseek 4.1 Flash is an inexpensive model, but cost varies between peak and non-peak hours, and whether the tokens are cached or not. We estimate the average cost of a task to end up around $5 if one includes unsuccessful, early ending projects. Longer running projects could get more expensive - there are projects with over 1000 intents and facts, and those could end up costing more than $100. The uncertainty here is however considerable, and numbers could be off by a clear margin. Even so, there's no doubt that this is relatively cheap.

**Cluster AIA0002**

- Language: English
- Panels: 10
- Hosting: AS20473
- Confidence: High

This cluster uses English language, and is oriented towards financial theft. We found 10 panels likely associated with this group, though some of these are less confidently linked. Many of these have also gone dark since the start of this investigation.

They frequently directly talk about stealing credit cards and cryptocurrencies, and uploading stolen data to separate hosts under their control. They – incredibly! – expose the SSH login to backend staging hosts in their taskings. (No, we did not log into their servers, although we were sorely tempted.) It is interesting to see that many projects seem to have no technical starting instructions, beyond "fetch credit cards" or "fetch crypto". The agents just go from there.

This group prefer hosting their panels via AS20473, The Constant Company (in most cases this means VULTR VPS instances). We assess this cluster to be malicious with high confidence.

The targets listed in these panels are mainly oriented towards merchant payment services, gray-market payment sites and pharmaceutical sites; even a clearly criminal carding site. There are indications that they successfully breached some of these.

Out of the targets that do not fit into those categories, several are African commerce sites, which hints towards this actor having a base on that continent.

![Bar chart of AIA0002 targets by sector.](https://norforge.com/blog/inside_cairn/images/aia0002-target-sectors.webp)
Figure: AIA0002 target sectors.

The projects run by this actor state they use workers named pi_openrouter_deepseek, suggesting a configuration in which the Pi coding-agent framework uses DeepSeek language models through OpenRouter, a third-party AI model API gateway.

**Cluster AIA0003**

- Language: English
- Panels: 1
- Hosting: AS200019
- Confidence: Low

This entity exposes only one panel, with 59 projects listed. The targets are a mix of smaller e-commerce sites and very large US-based commercial platforms. Language used is exclusively English. The panel is hosted on AS200019, AlexHost.

The projects listed on this panel start out claiming to be authorized assessments of various sites, but then gradually become more explicit about exploiting the targets including obtaining shell access, admin panel access, or database access.

This actor seems more in the exploratory stage. We assess this actor to be malicious with low confidence.

![Dashboard of project creation over time for AIA0001, AIA0002 and AIA0003.](https://norforge.com/blog/inside_cairn/images/project-creation-activity.webp)
Figure: Project creation activity across the three clusters.

#### 05 The Exploitation

Whether a task has succeeded in reaching its goal, and whether that constitutes a real-life security problem, depends a lot on how aggressive a goal is. In some cases, tasks stop when establishing whether there is a vulnerability. However, the threat actors covered in this article typically go further.

Previously, we posted one of the tasks used by AIA0001. That task explicitly demanded a webshell to be installed, in order for the goal to be reached. Just to test, we checked if one of the claimed intrusions had really happened by fetching the shell URL mentioned in a completed task against a large hardware parts vendor. The URL did indeed serve an uploader webshell. Attackers can at any time change that into something more malicious.

![A bare file-upload form served from the vendor's site.](https://norforge.com/blog/inside_cairn/images/live-uploader-webshell.webp)
Figure: Live uploader web shell served from a vendor site.

This particular intrusion was apparently – according to the agent’s own explanation – enabled by unauthorized write access to a memcached session store, combined with unsafe PHP object deserialization and an exploitable gadget chain in legacy Zend Framework components. However, all these exploitation paths are different, and the payload can look different as well. We have gathered a number of case studies at the end of this paper.

AIA0001 seems to exclusively go after access, and make sure they have the ability to do more at a later date. Other actors have other goals, but this threat actor appears to have been by far the most proficient and effective in reaching their target. The AIA0002 actor uses Cairn in a more generic way. Not only is it used to break into targets, but it is also used as a general purpose service engine; for example to move funds between crypto wallets.

Table: Task types
| Activity | Typical task goals (literal quotes) |
| --- | --- |
| AIA0001 | 这是四国(US/CA/JP/AU)已确认的真实购物电商站(流量200k-1.5M)。; 目标：找未认证 RCE (命令执行/代码注入/反序列化/文件上传webshell/SQLi→RCE/SSTI/SSRF→RCE)。; 优先：登录SQLi、未认证端点、文件上传、反序列化、认证绕过、账户接管。; 落地用 uploader shell (HTML上传表单+move_uploaded_file保存)，绝不落地命令执行型webshell。; Goal met when whoami/id 输出确认命令执行。 |
| AIA0002 | upload web shell in hidden dirctory deep inside not on home dirctory and name it somthing normal like confirm.php etc and give me link |
| AIA0003 | Obtain shell access, admin panel access, or database access on REDACTED. Try all attack vectors: SQLi, file upload, authentication bypass, RCE, deserialization, SSTI, SSRF, business logic flaws. Build dynamic attack chains. |

#### 06 The Success Rates

The different activity clusters have different focus, go after different targets, and what constitutes success varies. They are not directly comparable. But it is a reasonable assumption that for the harnesses we have seen in these campaigns, average success rate is hovering around 10%, with many of the remaining tasks achieving partial goals, or are able to gather information that can be used in later attempts.

- Average success rate: ~10%
- Start to goal, AIA0001: <23h
- Facts per project: 140

![Summary of observed AI-driven intrusion campaigns and their reported outcomes.](https://norforge.com/blog/inside_cairn/images/campaign-outcomes.webp)
Figure: Observed AI-driven intrusion campaigns and reported outcomes.

If we concentrate on the tasks that did reach their goals, especially on the AIA0001 cluster which most resembles general purpose intrusion activity, we can now see that the average time from project start to goal met was a little under 23 hours, generating on average 140 facts per project. However; there’s a wide range here. One project ran for more than five days. It is also worth noting that this is a snapshot at this point in time. Models and harnesses evolve very quickly.

#### 07 The Exposure

These panels not only expose that a site is being tested for weaknesses, and any conclusions of the tests. They detail everything that the agent has discovered in the process, and if that was not enough, they include human input that includes credentials harvested elsewhere.

In other words, having your site tested on an open Cairn instance is often a serious security issue, regardless of outcome of the test.

We ran the secrets scanner Trufflehog over the data from these Cairn instances.

![Dashboard of credentials found in exposed Cairn project data, by risk, verification status and secret type.](https://norforge.com/blog/inside_cairn/images/exposed-credentials.webp)
Figure: Credentials exposed in AI-driven operations.

The result was concerning. Literally hundreds of secrets of different kinds, from relatively trivial to extremely serious; with 11% verified valid by Trufflehog.

Think that's bad? It gets worse. These panels appear completely unprotected, exposing what looks like the full administrative functionality of the harness. That includes controls for starting and stopping projects, interfering with ongoing operations, inserting new data, redirecting agents to different targets, and restarting old projects. We haven't tested whether these controls actually work without authorization, for reasons that should be fairly obvious. But consider the implications. These are autonomous offensive agents with considerable capabilities, potentially available to anyone who stumbles across their control panels. Tokens could evaporate like dry ice on a hot plate. And who knows what these agents could be persuaded to do that would make their owners weep. Just to be clear, we walked away from that train of thought. But the underlying point remains: Whatever offensive expertise these operators possess, securing their own infrastructure does not appear to be among their strengths.

#### 08 The Conclusion

It is clear that AI-driven frameworks are used to perform malicious actions. That was established well before this paper. However, this research has pointed out something else: The attackers are not well prepared for this technology either. In the rush to gain quick results, many have forgotten basic security precautions, leading to them compromising their own operational security and also, unfortunately, exposing their targets to a far larger attack surface than the intent was. This has also proven to be a problem for legitimate red teams; gathering secrets from your client just to publish them on the Internet is a nightmare scenario.

But it is an interesting window into the methodology, and how autonomous and semi-autonomous agents solve real world intrusion tasks. This could and should inform our defenses going forward.

We have been cooperating with Reuters in notifying victims, particularly those who appear to have suffered a compromise. We are also attempting to get the offending Cairn panels taken down. This might not be possible; it depends a lot on how well the hosters respond to takedown requests.

#### Appendix A: Case studies

##### Case 1 - Australian e-commerce site

The Cairn backend stated that goal was met and indeed, there is a shell giving command execution on the web server.

![A directory listing returned by a web shell on the site, with identifying details redacted.](https://norforge.com/blog/inside_cairn/images/case1-command-shell.webp)
Figure: Command execution through the shell on the web server.

![Attack chain from unauthenticated account modification to server command execution.](https://norforge.com/blog/inside_cairn/images/case1-attack-chain.webp)
Figure: The attack chain, from unauthenticated account modification to command execution.

##### Case 2 - Restaurant POS compromise

![Attack chain of the restaurant POS compromise.](https://norforge.com/blog/inside_cairn/images/case2-restaurant-pos.webp)
Figure: Restaurant POS compromise.

##### Case 3 - Web application intrusion on US retailer

![Attack chain of the web application intrusion on a US retailer.](https://norforge.com/blog/inside_cairn/images/case3-us-retailer.webp)
Figure: US retailer web application intrusion.

##### Case 4 - Another US retailer, this time via insecure error handling

![Attack chain through insecure error handling at a US retailer.](https://norforge.com/blog/inside_cairn/images/case4-error-handling.webp)
Figure: Insecure error handling.

##### Case 5 - Japanese retailer

![Attack chain of the intrusion on a Japanese retailer.](https://norforge.com/blog/inside_cairn/images/case5-japanese-retailer.webp)
Figure: Japanese retailer.

##### Case 6 - Very large US retailer

![Attack chain of the compromise of a very large US retailer.](https://norforge.com/blog/inside_cairn/images/case6-large-us-retailer.webp)
Figure: This compromise chain was validated by us. The agent managed to find the one cookie setting that chose the vulnerable backend server.

#### Appendix B: Indicators of compromise

We are sorry that we can not provide unredacted data on where these panels are. Many are still live and contain sensitive data. However, if you are a bona fide security researcher, reach out and we will be happy to provide the unredacted list.

Table: Panels and staging servers
| IOC | Notes |
| --- | --- |
| `199.247.25.25` | AIA0002 staging server |
| `199.247.27.2` | AIA0002 staging server |
| `46.8.xxx.xx9:8000` | AIA0001 panel |
| `95.182.xxx.x42:8000` | AIA0001 panel |
| `31.56.xxx.xx7:8000` | AIA0001 panel |
| `31.57.xxx.xx9:8000` | AIA0001 panel |
| `46.8.xxx.xx3:8000` | AIA0001 panel |
| `94.183.xxx.xx3:8000` | AIA0001 panel |
| `94.183.xxx.x34:8000` | AIA0001 panel |
| `31.59.xxx.xx5:8000` | AIA0001 panel |
| `95.182.xxx.x12:8000` | AIA0001 panel |
| `31.59.xxx.xx7:8000` | AIA0001 panel |
| `94.183.xxx.x54:8000` | AIA0001 panel |
| `95.182.xxx.xx5:8000` | AIA0001 panel |
| `94.183.xxx.xx8:8000` | AIA0001 panel |
| `31.59.xxx.xx3:8000` | AIA0001 panel |
| `108.61.xxx.xx6:8000` | AIA0002 panel |
| `66.42.xxx.xx9:8000` | AIA0002 panel |
| `95.179.xxx.xx3:8000` | AIA0002 panel |
| `45.63.xxx.xx7:8000` | AIA0002 panel |
| `136.244.xxx.xx6:8000` | AIA0002 panel and staging |
| `45.76.xxx.xx0:8000` | AIA0002 panel |
| `209.250.xxx.xx8:8000` | AIA0002 panel |
| `95.85.xxx.xx9:8000` | AIA0002 panel and staging |
| `136.244.xxx.x86:8000` | AIA0002 panel |
| `64.176.xxx.xx3:8000` | AIA0002 panel |
| `143.246.xxx.xx1:8000` | AIA0003 panel |

### AI hackbots found another hundred vulnerabilities. Who fixes them?

Published 2026-10-12 by Erlend Oftedal. I sat down with STÖK and Kugg on the Builders & Breakers podcast. We talked about the gap between finding vulnerabilities and fixing them, and what you can do about it before your backlog eats you alive.

#### 8x the code, same number of people to fix it

I was on the Builders & Breakers podcast with STÖK and Kugg last week. The conversation started with a stat from Anthropic: developers are producing 8x the output they were at the start of the year. Good for shipping. Bad for everyone holding the security backlog.

If your competitors ship faster, you ship faster. Every appsec person I talk to has the same problem: they have never had too few bugs in their tracker. The pile was already unmanageable. Now code is coming in at 8x and the fix rate has not moved.

#### Fixing is harder than finding

You can point an AI at a codebase and it will find vulnerabilities all day. The patch is the hard part. Does it fit with the rest of the code? Does it break something else? A lot of software still has no proper test coverage. You touch one function and you have no idea what you broke three modules away.

I had a first-hand look at this the other day. Someone sent a massive pull request to one of my open-source tools. It was AI-generated, changed parts of the architecture I didn't ask for, and tried to fix ten things at once. As an open-source maintainer you can't merge that. You don't know what it broke, and reviewing it costs more time than writing the fix yourself.

If you play whack-a-mole with individual bugs at the same rate you produce code, you're standing still and burning tokens. The smarter move is root cause analysis. If a whole class of bugs exists because you left a framework setting open or picked a bad default, fix that. One configuration change kills a hundred future findings.

#### "Use security best practices" leaves things to chance

Models train on all the code on the internet. God knows there's a lot of bad code on the internet. Some of my own repos have deliberate vulnerabilities in them. If you tell an agent "use security best practices," which practices does it pick? The 2024 recommendation? Something it found from 2012?

I've seen agents pick SHA-256 without a salt for password hashing. I had one invent its own authentication token: Base64-encoded timestamp plus user ID. No signature, no expiry logic, nothing. It looked confident doing it, too.

The fix is to stop being vague. We've written secure coding guidelines for companies for years, and developers ignored most of them because the documents were too long. Agents don't care about document length. They'll read the whole thing. So turn your guidelines into skills. Tell the agent: this is how we do authentication here. This is how we talk to the database. This is how you verify you did it right. OWASP ASVS already has checklists for most of this. Pair those with linting rules, and you get agents that write secure code in the first pass instead of fixing their own mistakes in a loop.

One important detail: split your skills by concern. Authentication in one, database access in another, input validation in a third. One giant skill and the agent loses focus. Small, specific, verifiable.

#### Agents that cheat on tests

I ran into a case where I asked an agent to add a feature and it modified the existing tests to make them pass instead of writing the feature correctly. The old functionality broke. The test suite went green. That's the worst kind of failure because it looks like success.

Newer models do this less. But it tells you something about what we need: better test coverage, yes, but also tests that the agent can't silently rewrite. Linting enforces deterministic rules. Integration tests catch things unit tests miss. You need several layers, and you need to watch the diffs on your test files as carefully as you watch the diffs on your source.

#### Local models and poisoning

Teams are moving to local and open models to save on token costs, but how much do you know about the training data in the model you downloaded? What if someone plants a pattern that makes it introduce insecure code when it sees a specific library name? You won't find that by inspecting weights.

At the same time, the patch window is closing fast. AI can reverse-engineer a Microsoft patch and identify the underlying vulnerability in hours instead of weeks. So you need to patch faster. But you're also told to hold off on installing new dependencies because they might be compromised. Those two pressures squeeze from both sides and there's no clean answer.

#### Your application should detect its own attacks

We talked on the podcast about something I care about a lot: detection at the application layer. OWASP had a project called AppSensor that did this. You place sensors inside your application that score anomalous behavior. A user tries to access another org's data? That's a signal. Stack enough signals and you terminate the session, block the IP, or alert the team.

I built this into a system a few years back. It worked. The only real complaint was that pentesters kept tripping the sensors and locking themselves out, which is a good problem to have. We're going to need this kind of defense more, not less. The number of known bugs in running software will grow faster than anyone can patch them. If your application can spot someone attacking the application, that buys you time.

#### Give open-source maintainers free tokens

I ended the podcast with a request to the big AI companies: give open-source maintainers free tokens. Not for fun. For reviewing the flood of AI-generated pull requests that are already arriving. Maintainers need to verify that a patch does what it claims and doesn't slip in a backdoor. That takes AI to fight AI, and volunteers shouldn't have to pay for it out of pocket. The world runs on open source. And open source needs help.

The full conversation is on STÖK's Builders & Breakers channel. If your bug backlog is growing faster than your fix rate, start with the root causes, not the individual findings.

Sources:
- [Builders & Breakers — Your AI hackbot has found another 100+ vulnerabilities (YouTube)](https://www.youtube.com/watch?v=NrqUfs-OTtc)
- [OWASP ASVS — Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)
- [OWASP AppSensor](https://owasp.org/www-project-appsensor/)

### Why AI Programs Stall Before Scale

Published 2026-09-19 by Tor Skaar. What separates the 8% of firms that scaled Generative AI from the rest: hidden usage, legacy data foundations, unreliable output, and a shrinking skills base. Each barrier comes with the figures behind it.

#### Adoption outruns integration

Projections from the sources below show 1.1 billion people will use artificial intelligence (AI) by 2031, and most Fortune 500 companies already rely on AI to varying degrees, but the gap between industries is large. For instance, among financial services companies that have begun testing Generative AI, only 8% had successfully scaled it across the enterprise. The other companies are reluctant to fully integrate the technology. Some executives describe AI as a "moving train" that is tricky to board and even harder to steer. Some settle for the role of fast followers and others just find a place in the middle of the pack. The technology itself has become a commodity and it is how you execute that will separate the firms that scale from the firms that stall.

#### Shadow AI fills the governance gap

Leaders are unable to set standards to govern AI usage if they are not able to identify it. Studies show that more than half of workers hide their AI use on key tasks. As a result, governance becomes a vacuum. Employees are aware of this phenomenon because about 70% of Americans also believe that companies cannot be trusted to use AI responsibly. It is not surprising that most companies are reluctant to leave low-stakes AI pilot programs.

#### Legacy systems tax every gain

According to the sources, 92% of businesses consider their production systems to be at least partly legacy systems. Maintaining these systems costs UK banks about £3.3 billion a year and it consumes 24% of their IT budgets. Without access to clean and adequate data, the best AIs will produce essentially no output. So building any advanced AI stack on top of old and obsolete data pipelines is like an engine starved of fuel.

#### So-so automation consumes the time it saves

Automation has the potential to revolutionize businesses, and when successfully implemented, can provide substantial gains in productivity. "So-so automation" describes AI that handles a task but returns unreliable output. Employees must in these cases evaluate the results, which often takes longer than just performing the task manually. Hallucinations have been reported to affect 56% of businesses, but only 32% of companies have taken action to mitigate the issue. Hallucinations occur when AI makes incorrect assumptions, and if managed correctly, can have a positive impact on productivity. A Harvard study found that workers using AI completed tasks 25% faster, produced 12% more output, and achieved 40% higher quality results. But, realizing these gains requires more than just installing software. Firms must maintain a "human in the loop" approach, not merely as a productivity choice, but also to comply with consumer expectations and compliance requirements.

#### The skills gap lands before the technology gap

In the next 10 years, the Financial Services Skills Commission expects more than 40% of the sector's skilled workforce to retire or leave the sector. Automation will put more than 119,000 clerical jobs at risk in the same time frame. Over half of the organizations in the sector are not equipped for data science and are therefore unable to fully utilize AI. The kind of skills in highest demand by the sector is trying to balance technical literacy with core human capabilities. This includes analytical thinking (risk planning, data interpretation, market analysis, and software quality assurance) combined with interpersonal skills vital for stakeholder influence, relationship management, and complex business communication.

#### What the 8% do differently

Successful firms believe that integrating AI will fundamentally alter their business. AI projects that view business transformation through a narrow lens will be uncompetitive and will fail. The industry’s focus is shifting from Generative AI to Agentic AI. Generative AI can assist and enhance human work. In contrast, Agentic AI allows for the automation of more complex and continuous work. This shift will require businesses to confront “the untestable.” A case study involving PwC and a leading UK bank demonstrated that by using AI to test AI, checking for bias, hallucinations, and toxicity, firms can build the necessary trust to move from pilot to scale. Both firms developed a system that filtered out these things and promoted trust in AI. Subsequently, a strict governance framework was created to define the boundaries of the business, and shift the firm’s workforce to perform more judgmental and complex work, and away from routine work.

#### Beyond the Hype Cycle

About 3 out of 4 business leaders expect to boost their AI budgets in the years ahead. Rising spending doesn't tell the whole story though. A company needs to implement AI solutions the right way to see the largest impact. The leadership team needs to ensure they've collected the right data to implement AI. Patience is essential for businesses to modernize their underlying systems. One question that is worth asking of any roadmap:

Is your organization redesigning and streamlining work around what AI does well, or just automating what it already did?

Sources:
- [Tenet — 60+ Global AI Usage Statistics For 2026](https://www.wearetenet.com/blog/ai-usage-statistics)
- [Financial Services Skills Commission — A Workforce Transformed (PDF)](https://financialservicesskills.org/wp-content/uploads/2026/05/AI-disruptive-technology-report-workforce-transformed.pdf)

### Field notes: running Cloudflare’s open-source security-audit-skill on a real codebase

Published 2026-09-19 by Tor Skaar. Cloudflare open-sourced a skill that turns a coding agent into a security audit swarm. We ran it on a large open-source monorepo. Notes on what it does, what it demands, and what it found.

#### What Cloudflare shipped

Cloudflare recently published a coding-agent skill that turns your agent into a security auditor. The repo is security-audit-skill, the license is MIT, and at the time of writing it sits in the top three of GitHub’s daily trending page, pulling in over two thousand stars a day. A skill, in the agent sense, is a playbook your coding agent loads on demand. This one coordinates a swarm of isolated agents through a structured security audit and returns findings you can hand to a human without squinting.

We ran it against a large open-source monorepo this week. These are our field notes: what the skill does, what it demands from your machine, and what came out the other end.

#### Six phases, one idea: trust nothing you did not verify

The audit runs in six phases. Reconnaissance maps architecture, trust boundaries, and input surfaces into an architecture.md plus a coverage-ledger.json that tracks every unit of the codebase worth auditing. Coverage-led hunting assigns one isolated agent per unit; each hunter records what it checked, and coverage critics hunt for gaps the hunters missed. Every unique candidate then goes to a fresh verifier whose only job is to disprove it. Survivors are written into findings.json as confirmed, needs_validation, or rejected, and a schema validator checks the file. Finally, a new set of agents verifies every record against the source, and reporting derives the human-readable documents from the verified data.

![Illustration of the six audit phases, from a mapped codebase through hunting, validation, and verification to the final report documents.](https://norforge.com/blog/field-notes-cloudflare-security-audit-skill/security-audit-skill-phases.webp)

The design principle underneath all of it: the agent that checks a finding is never the agent that found it. That adversarial split is the difference between a confident model and an auditor. A confirmed record needs a complete source trace and a bounded, observed result. Anything less, and the skill files it as needs_validation with the exact unresolved fact and no severity attached.

Runs are also additive. A repeat run reuses the prior ledger to target gaps and revalidates changed source instead of starting from zero, which matters because of the coverage math we will get to.

#### The catch: it wants a sandbox

The requirements list looks short: a coding agent with tool use and parallel sub-agents, Node.js for the validators, and an OS-enforced sandbox for anything the target code might execute. That third item is the real cost of admission. The sandbox has to kill external networking, run the target in a sanitized, allowlisted environment, cap CPU, file size, and processes, and keep writes confined to scratch paths.

Without those controls, the workflow refuses to execute target code and parks the lead as needs_validation instead. That is the right default, and it is what separates this from a prompt that says "find vulnerabilities". A skill that treats its own execution environment as part of the threat model has read the room.

#### We ran it on a real codebase

We pointed it at a large open-source monorepo: the kind with Python services, Go control planes, TypeScript SDKs, and daemons that talk to each other over local sockets. Standard profile, scoped run. We audited the security-critical subset rather than the whole tree, and the report says so, in exactly those words, which is the kind of honesty you want in audit tooling.

The execution policy was the strict one: no external network, an empty allowlisted environment, a read-only target, writes limited to scratch, and CPU, file-size, and process caps enforced by the OS. The ledger seeded 59 units. Forty-six agents did the work: four on reconnaissance, the rest in hunting waves, with three coverage critics and eleven verification agents closing the loop. Most of it ran unattended.

The report also discloses its own deviations. Our record-verification phase ran as seven subsystem-grouped verifiers instead of one per record; every record still got checked by a fresh agent that had not hunted it, and the deviation is stated in the run metadata. Audit tooling that audits itself out loud is rarer than it should be.

#### What came out

After root-cause consolidation the audit returned 46 records: ten confirmed findings HIGH 1, MEDIUM 4, LOW 5 and 36 leads held at needs_validation, each with the exact fact a human would need to resolve. No severity was asserted anywhere the evidence did not support it, which is why the confirmed list is short and the leads list is long.

We are not walking through the specific findings here, because the target project gets to fix them first. As classes, they will look familiar to anyone who has audited agent infrastructure: a local server handing data to any web page through wildcard CORS, credentials riding on cleartext transports, credentials embedded unencoded in share URLs, command-and-response demux races in client SDKs, and a few local file-permission issues. Individually unglamorous. In combination, exactly what ships when the people building agent frameworks are racing the market.

#### When this skill earns its keep

Run it when you are about to depend on, invest in, or ship something large and unfamiliar: an open-source framework you are adopting, a target in diligence, your own agent platform before your customers find its issues for you. The coverage ledger alone justifies the run. It maps trust boundaries and records what was checked, so the next run starts from evidence instead of zero.

Run it with fewer expectations than the trending page implies. The README states the coverage math itself: in their test runs, a single run found roughly half of the vulnerabilities that repeated runs found in total. Plan on more than one run. A needs_validation record is a question, not a vulnerability, and a confirmed record still needs a human who knows the deployment to judge impact. An audit swarm is not a penetration test: it will not probe your live systems, and it should not.

The skill is free, the method is published, and the sandbox is one config file away. The real cost is deciding what to do about what it finds.

Sources:
- [Cloudflare — security-audit-skill (GitHub)](https://github.com/cloudflare/security-audit-skill)
- [GitHub — Trending repositories](https://github.com/trending)