CSIPE

Published

- 21 min read

The AI Agent Attack Changes the Defender’s Clock

AI Agents Web Security Incident Response Application Security

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

One operator gave an AI system a list of shopping sites and a short objective. The system kept probing. It recorded what worked, shared findings between workers, changed direction after failures, and continued until some projects reached a working foothold. The operator did not need to sit at a keyboard for every request.

By 19 October 2026, researchers had observed attempts against more than 1,200 sites and reported successful intrusions at more than 100 organisations. Those numbers deserve care. They come from exposed attacker control panels, a security company’s validation, Reuters reporting, and acknowledgements from several affected companies. They do not prove that every target lost sensitive data. They do show a real change in the working day of an attacker.

The useful lesson concerns one person keeping many patient workers busy at once, rather than every website suddenly facing a brilliant machine. Defenders should answer that change with controls that impose cost automatically: narrow public routes, enforced request limits, small application identities, fast isolation, and records collected outside the compromised process. A ticket waiting for Monday has become a bigger bet.

What the exposed panels actually showed

NorForge found the campaign because its operators made an elementary mistake. They left web-based control panels open to the internet. Those panels exposed project instructions, discovered facts, human hints, credentials, and progress from target selection toward a stated goal. The attackers had built a machine for persistence and then failed to put a door on its control room.

The software was Cairn, an open-source problem-solving framework. A project begins with an origin and a goal. Workers choose an intended next step, record facts on a shared blackboard, and use that accumulated state to decide what to try next. A human can add a hint, but the system can continue through many cycles without a human choosing each action. NorForge describes this as state-based problem solving rather than a tool limited to security testing (NorForge, 19 October 2026).

That distinction matters. The damaging capability did not come from a single button labelled “hack.” It came from a loop that could observe a result, preserve it, choose another action, and keep going. The same shape makes agents useful for debugging, research, and software maintenance. Connected to offensive tools and a list of live targets, it makes patient intrusion work easier to run in parallel.

NorForge grouped the exposed activity into three clusters. The largest cluster used Chinese-language instructions across 14 panels and held more than 1,100 attack projects. Its targets were mainly commerce sites in the United States, Canada, Japan, and Australia. The stated aim was persistent access to commerce and payment infrastructure, according to the researchers. Two smaller clusters appeared focused on financial theft and exploratory compromise (NorForge, 19 October 2026).

The strongest claims received more than one check. Reuters independently reviewed Cairn activity to identify affected organisations that NorForge had not named publicly. Deere said it took remedial action and had no indication that sensitive information was accessed. SharkNinja said the affected site was a standalone support site and that it contained the threat. Cummins said it was investigating a potential attack on a site run by a third-party vendor. Two smaller businesses also acknowledged compromise (Reuters via RTÉ, 19 October 2026).

Those statements set an important limit. “A site was compromised” does not tell us that a company’s central network, customer database, or payment system was taken. Reuters could not establish how much data, if any, was extracted across the reported breaches. A support site at a supplier carries a different blast radius from a production payment service. Treating them as identical would replace evidence with drama.

NorForge did validate several technical outcomes. In one case, it requested a URL recorded by a completed project and received an upload tool running on the victim’s server. It also said it validated a compromise involving a large retailer. The company reported that successful projects in the busiest cluster took a little under 23 hours on average and accumulated about 140 recorded facts. Across the different clusters, it estimated success near 10 percent, while warning that goals and target sets differed (NorForge, 19 October 2026).

Ten percent is not machine omnipotence. It means most attempts did not reach their declared goal. More than 100 reported compromises still matter when the queue contains over 1,200 targets and the operator can let workers continue overnight. The scale comes from repetition and concurrency, not from a perfect answer on the first try.

The new advantage is patient throughput

A conventional automated scanner already sends thousands of requests. Security teams have dealt with broad scans, password guessing, and mass exploitation for years. The Cairn activity adds a more adaptive layer between a fixed scanner and a skilled person working one target by hand.

A scanner usually checks a known condition. It asks whether a path exists, whether a version appears vulnerable, or whether a familiar input produces a familiar response. An agent can use the answer to form another plan. It can inspect related hosts, compare application behaviour, search public records, try a different route, and carry useful facts into the next attempt. The operator supplies the goal while the loop supplies much of the patience.

The exposed projects show that adaptation in concrete terms. Reuters described one case in which workers failed against a company’s obvious public application, searched associated infrastructure, found another public control panel, identified a subtle data-handling weakness, and kept experimenting until the project reported command execution. NorForge’s fuller report shows projects with hundreds of intents and facts, with one running for more than five days (Reuters via RTÉ, 19 October 2026; NorForge, 19 October 2026).

That workflow changes the economics of unfinished defensive work. A forgotten administration route used to need the right person to notice it and spend time understanding it. Now it can remain in a machine-maintained queue. A slightly different response, a useful error message, or a related hostname becomes another recorded fact rather than a dead end somebody may forget.

The operator still paid, but the reported cost was modest beside ordinary intrusion labour. Reuters reported NorForge’s rough estimate of about $5,000 in model tokens for the prolific campaign, or roughly $50 per successful compromise. NorForge’s published report is more cautious: it estimates about $5 for an average task, says long tasks may exceed $100, and stresses that the uncertainty is considerable because it did not have actual token records (Reuters via RTÉ, 19 October 2026; NorForge, 19 October 2026).

The difference is a useful warning against false precision. We do not know the attacker’s exact bill. We know enough to say the work was cheap compared with assigning a human specialist to each target for a day. That makes weak, low-value sites worth trying because failure costs little and the next project can begin without clearing somebody’s calendar.

It also changes what “unlikely to be targeted” means. A small support site may not deserve an attacker’s personal attention. It can still deserve a slot in an automated queue assembled from traffic estimates, commerce features, and browser checks. NorForge found evidence that targets had been ranked and tested with browser automation before they were sent into the agent system. Selection itself was becoming a pipeline.

Teams can take a clear position here: obscurity has become an even weaker scheduling strategy. A secondary site, old campaign domain, supplier-hosted portal, or regional storefront should not rely on being too boring to inspect. If it is reachable and linked to the brand, a machine can afford to be curious.

Your response clock now starts before a human reads the alert

The campaign’s reported average of about 23 hours from project start to goal is not a universal countdown. Some projects failed. One ran for days. Different applications expose different routes. Still, the number gives defenders a practical planning case: assume a persistent worker can move from first observation to a foothold inside one day.

Many security processes are slower by design. A scan runs overnight. A finding enters a queue in the morning. An owner is assigned after triage. The service team confirms the asset, schedules a change, and waits for a maintenance window. That rhythm may be reasonable for a low-risk internal defect. It is a poor default for an exposed route showing signs of active exploration.

The first improvement is classification. An alert about repeated requests becomes more urgent when the same source or campaign touches related hosts, changes methods after errors, requests unusual administrative paths, or follows a newly exposed hostname. Each event may look ordinary on its own. The sequence shows a worker building a map.

Detection therefore needs continuity. Keep enough edge and application metadata to join requests by source, session, target, and time. Record denials as well as successes. Preserve the hostname, route, method, status, response size, user agent, authentication result, and a stable request identifier. Do this at a gateway or logging service the application cannot rewrite after compromise.

A web application firewall can add immediate friction. Rate limits, route restrictions, request-size limits, and rules for known attack patterns force the worker to spend attempts. They also reduce noise for the service behind them. They are useful because they run at machine speed, before an analyst opens a case.

They cannot carry the whole response. An adaptive worker can change paths, distribute traffic, use a related host, or reach an application through a route that bypasses the expected edge. A valid authenticated request may also be dangerous if the account has too much authority. The edge should slow and expose the sequence while the application enforces the real boundary.

That boundary starts with prompt isolation for your own agents, but this incident is primarily about ordinary web security. The victims did not need to deploy Cairn for Cairn to attack them. Input validation, safe deserialisation, current frameworks, narrow file permissions, protected administration routes, and segmented service identities remain the work. AI changes how persistently mistakes are tested. It does not repeal the conditions that make a mistake exploitable.

The fastest defensive move is often temporary containment rather than a perfect patch. Disable an unused upload route. Put an administration panel behind a trusted access gateway. Remove direct origin access. Block a vulnerable feature while the owner prepares a tested release. Rotate a credential when its path may have been exposed. A reversible control applied in minutes can buy the engineering team the hours it needs.

Write those moves down before the alert. If an incident commander must invent the procedure, locate the owner, and negotiate authority while requests continue, automation has already won the first race. Every exposed service needs a named person who can restrict traffic and an on-call path that works outside office hours.

Put cheap friction on every public route

The right answer makes sustained exploration expensive while keeping normal use predictable. It does not make every request difficult for every customer. That requires controls tied to the application’s actual shape rather than one global request limit.

Begin with the inventory an attacker can see. List public hostnames, direct origin addresses, old application versions, regional copies, support portals, staging systems, storage endpoints, and vendor-managed sites carrying your name. Include hosts outside the main platform team. Reuters reported that Cummins was investigating a site operated by a third-party vendor, which is exactly the kind of boundary a central dashboard can miss (The Verge, 19 October 2026).

For each host, name the route that should receive traffic. A public site behind a content-delivery network should not also accept arbitrary requests at its origin. An administration interface should not share the same exposure as a product page. A support site that serves static manuals should not have write access to a customer database. Architecture claims become useful only when a network test proves them.

Next, price unusual behaviour. A customer may browse dozens of product pages, but rarely requests every diagnostic endpoint across six related domains. Set per-route and per-account ceilings that match normal work. Reduce concurrency on expensive search, export, upload, and preview functions. Make repeated authentication failures, malformed requests, and route discovery consume a tighter budget.

Avoid a single permanent ban threshold. A fixed limit teaches an automated worker exactly how to remain below it and can punish shared networks. Use several signals: request rate, path novelty, error ratio, account age, destination spread, and changes in method. Escalate gradually from observation to delay, challenge, temporary restriction, and isolation. Record which control acted and why.

Errors deserve careful design. A production response should help a legitimate client recover without publishing framework versions, internal paths, query details, stack traces, or object names. The Cairn workers shared facts through a blackboard. A verbose error is ready-made research for that board. Give the customer a request identifier and keep the diagnostic detail in protected logs.

Uploads and server-side fetching need their own boundaries. An upload feature should restrict type, size, storage location, and execution. Uploaded content should land outside executable application paths. A feature that fetches a supplied URL should allow only necessary schemes and destinations, check every redirect, block private address ranges, and run under a small identity. These rules close whole classes of routes without needing to recognise a particular model or agent framework.

Administration surfaces should assume somebody will eventually discover the hostname. Require strong authentication, but do not stop there. Limit access by device, network, or trusted gateway when practical. Separate read and change permissions. Alert on new administrator sessions and unusual configuration changes. Keep recovery access out of the same system it may need to repair.

Third-party sites need enforceable requirements. Ask the provider for the exact hostname inventory, patch responsibility, logging retention, incident contact, and method for urgent isolation. Confirm where data and credentials flow. A contract that says “industry-standard security” will not tell an incident commander how to take a compromised microsite offline at 03:00.

The result should be measurable friction. A worker that explores too broadly gets slowed. A worker that reaches a sensitive route meets a stronger identity check. A worker that causes errors leaves a connected trail. A worker that finds one application bug lands inside a process with little authority. None of these controls is dramatic. Together, they turn cheap persistence into visible, bounded work.

Assume one request eventually succeeds

Prevention should be strong, but a useful design review asks what happens after the first successful request. The Cairn report describes projects aiming for persistent server access. If one route produces code execution, the application process lends the attacker whatever files, credentials, network paths, and write permissions it carries.

A service identity is therefore part of the web boundary. Give each application its own account. Separate public sites from payment systems, deployment services, customer records, and internal administration. A support portal should not inherit access because it happens to live in the same cloud account or deployment cluster.

Secrets should match one workload and one purpose. A shared database password copied across ten sites turns one weak route into ten incidents. A deployment token inside a web process lets an application compromise become a release compromise. Prefer short-lived credentials issued to a named workload, then restrict the databases, buckets, queues, and APIs that identity can reach.

Network access needs the same treatment. A container is a process boundary, not a complete damage boundary. If it can connect to every internal service and the public internet, code running inside it can still explore, retrieve tools, and send data away. Allow the destinations the service needs. Deny the rest at a network control the process cannot edit.

Storage permissions often reveal whether containment is real. Make application code and configuration read-only at runtime. Put uploads in a separate service or object store that cannot execute them. Use a small temporary area with a size limit when a process must write. A successful attacker may still read data available to the service, but persistence through a modified application file becomes harder.

Session and cache systems deserve direct review. NorForge described a validated case in which unauthorised write access to a session store combined with unsafe deserialisation and older framework components. The defensive lesson is broad: a cache or session service is part of the application’s trust boundary. Bind it to private routes, require authentication, limit the client identity, and avoid treating stored objects as executable instructions (NorForge, 19 October 2026).

Separate production from the control plane. The identity serving customer requests should not change firewall rules, create cloud users, read deployment secrets, or alter monitoring. Emergency isolation should remain possible from a protected account even when the application identity is hostile. Otherwise the intruder and responder arrive at the same controls with the same key.

Containment also changes the investigation. If a compromised support site had no route to customer data, no deployment credential, and no writable application code, the team can state those boundaries and test their records. If the site shared a broad identity, every reachable system joins the scope until evidence clears it. Least privilege saves investigation time as well as reducing damage.

This is the central design move from The Secure Harness: autonomy belongs inside boundaries that do not depend on the autonomous process choosing to behave. In this case the untrusted process belongs to an attacker, but the architectural rule is the same. Put the authority limit outside the worker.

Collect evidence outside the application

The exposed Cairn panels gave defenders an unusual view of attacker decisions. Most teams will not receive that gift. They need their own record of the sequence, stored where a successful application compromise cannot quietly edit it.

Start at the edge. Send gateway, load-balancer, domain-name, authentication, and web application firewall records to a separate logging account or service. Preserve a consistent timestamp and request identifier. Keep enough history to look back before the first obvious alert, because the successful request may follow hours of ordinary-looking discovery.

Add application decisions rather than dumping every secret-bearing payload. Record which route handled the request, which account and tenant were involved, which authorisation rule allowed it, which downstream service was called, and whether a file or record changed. Redact tokens, passwords, session values, and sensitive body content before storage. An evidence system that copies every secret creates its own breach path.

Watch identities after the web request. Cloud audit logs, database access records, object-store writes, queue activity, and outbound network metadata can show what the process did with its authority. A strange request followed by a new outbound destination and an unusual administrative query is stronger evidence than any event alone.

Baseline by service. A static support site should have a very small set of outbound destinations and write operations. A payment application will be busier, but its normal database tables, APIs, and deployment rhythm are still knowable. Alert on changes in capability use, not just on a universal list of suspicious commands.

Protect the records with another identity and retention policy. The web service may be allowed to emit events, but it should not delete or rewrite them. Security staff should be able to place relevant logs under longer retention during an incident. Test that the timestamps line up across systems before needing a minute-by-minute reconstruction.

Evidence has limits. A clean file scan cannot prove that no code ran in memory. Missing outbound traffic in one sensor cannot clear a route that sensor did not cover. An application log written by the compromised process may be incomplete. Incident notes should say what was checked, for which time window, and which blind spots remain.

The companies named in public reporting used appropriately narrow language. Deere said it had no indication that sensitive information was accessed. SharkNinja described the affected site and containment. Cummins described an investigation into a potential attack at a vendor. Those statements avoid claiming more than the available evidence supports (Reuters via RTÉ, 19 October 2026).

Your internal conclusion should be equally disciplined. “No unusual use of the site identity appears in retained cloud, database, and network records between these times” is useful. “Nothing happened” is rarely something a sparse log can establish. Calm accuracy helps the next team decide what remains to be done.

A one-day review for exposed services

You do not need an agent-security programme to respond to this story. Pick one public service and complete a review against a 23-hour planning case. The aim is to produce working controls and evidence, not a new slide deck.

  1. Name the complete public surface. Record the main hostname, alternate and regional names, origin routes, administration panels, storage endpoints, old versions, and vendor-operated sites. Test each route from outside your network. Mark anything that bypasses the intended edge.

  2. Assign an owner and an isolation path. Write down who can restrict traffic at any hour, how they authenticate, and which reversible action buys time. Test the contact route. A disabled feature is often cheaper than an uncontrolled investigation.

  3. Patch from the serving asset backward. Verify the framework, runtime, plugins, and operating image that handle real requests. Repair the build input, create a new artifact, deploy it, and prove old instances stopped serving. A changed dependency file is not a production receipt.

  4. Price sustained exploration. Add limits for expensive routes, repeated errors, path discovery, authentication failures, uploads, and server-side fetching. Apply controls at an edge the origin cannot bypass. Confirm that normal customer flows still work.

  5. Reduce the application identity. List every secret, database, bucket, queue, internal service, and public destination the process can reach. Remove access that the feature does not need. Split shared credentials and block unnecessary outbound routes.

  6. Make writes non-executable and reversible. Keep code read-only, put uploads outside executable paths, cap temporary storage, and preserve clean deployment artifacts. Test a rebuild from the trusted source rather than relying on in-place repair.

  7. Join the evidence. Follow one test request from edge to application, identity, downstream service, and outbound network record. Confirm the request identifier and timestamps survive. Store the records under an identity the application cannot alter.

  8. Rehearse the first hour. Simulate persistent exploration followed by one suspicious success. Restrict the route, preserve logs, rotate the affected secret, replace the workload, and check related systems. Measure how long each handoff takes.

The rehearsal will expose ordinary weaknesses. The inventory will be incomplete. The vendor contact will be stale. A direct origin will still answer. One service will use a shared key nobody wants to rotate. Those discoveries are the value of the exercise.

Fix the shortest path to a large consequence first. A public upload route with executable storage deserves attention before a cosmetic header. A deployment credential in the web process deserves attention before a perfect dashboard. A vendor site with no emergency contact deserves a real phone number before another annual questionnaire.

Then keep the receipts. Record the tested hostnames, fixed artifact, isolation owner, identity policy, logging path, and rehearsal time. When the next campaign changes tools or model names, those controls still answer the same problem: cheap persistence meeting an exposed route.

The machine is patient, so make the boundary automatic

Cairn did not invent vulnerable applications. It made continued attention cheaper. One operator could feed a queue, let workers share discoveries, and return to projects that would once have demanded many hours of direct effort. Most attempts still failed. Enough continued to matter.

The defensive mistake would be buying an “AI defence” label while leaving direct origins, broad service identities, executable uploads, old vendor sites, and editable logs untouched. Those are the conditions the observed workers used. They are also conditions a human attacker or conventional script can use.

Answer machine-speed persistence with machine-speed friction. Slow unusual exploration at the edge. Enforce small permissions behind it. Isolate a route before the perfect diagnosis. Preserve evidence somewhere the application cannot reach. Give a person clear authority to make the next decision.

That approach is less cinematic than a contest between attacking and defending models. It is also more durable. Models will change, harnesses will change, and the next exposed panel may reveal a different workflow. A public service with narrow routes, a small identity, and an independent record remains difficult to turn into a large incident.

If you want more practical security explanations without a daily flood, join the newsletter on this site. It is one email per month.

Sources