That is precisely what makes the incident interesting.

The lesson is not that AI suddenly invented a new class of cyberattack. It’s that many real-world compromises do not require novel exploits at all. They require breadth. They require the ability to systematically explore large attack surfaces, recognize familiar vulnerability patterns, investigate which ones lead somewhere useful, and repeat the process across multiple targets.

According to CrowdStrike’s October 7 investigation, infrastructure associated with these attacks contained an ARTEX deployment, configuration files, Claude Code session histories, and Claude memory files. ARTEX is an autonomous penetration-testing framework developed in China, designed to coordinate AI agents through planning, tool execution, and persistent state. Its presence in infrastructure associated with a real financial-sector intrusion campaign provides evidence that offensive agents have moved beyond controlled research environments.

The extent of the attacker’s autonomy remains unclear. The public evidence does not establish that one individual independently compromised every victim, nor does it provide complete agent trajectories demonstrating how each system was exploited. But the findings do suggest something important about where offensive security is heading.

Offensive capability is increasingly becoming a software packaging problem. The most consequential development may not be a particular model learning to exploit software, but the emergence of reusable systems that combine planning, execution, memory, and orchestration into infrastructure that one skilled operator—or a relatively small team—can manage.

The Weakest Links Weren’t in Core Banking

One mistake people make when thinking about AI-enabled cyberattacks is assuming that the interesting ones must involve sophisticated zero-days or techniques that have never been seen before. That is often the wrong frame.

To compromise real systems, you can often take something resembling a breadth-first approach to vulnerability discovery. You explore enough exposed functionality, enumerate enough potential weaknesses, and follow enough promising paths until something works. Sometimes the result is one application-security vulnerability. Other times, it’s a short chain of failures that produces a more consequential outcome.

That appears closer to the publicly reported mechanics of the South Korean campaign than the popular image of an AI model inventing a novel exploit.

The Korean Financial Services Commission’s investigation, as reported by Yonhap, described three broad patterns across the affected institutions. Some information-query services lacked appropriate identity verification, exposing loan information or company-representative records. Employee-support applications suffered from missing device-access restrictions or unpatched web vulnerabilities. Another reported pattern involved the exploitation of a known website vulnerability, malware installation, and the theft of logs containing customer information.

These are recognizable categories of security failure. The details matter, however, because the reporting does not assign every vulnerability pattern to every victim, and complete exploit traces have not been released.

Consider Shinhan Bank, one of the clearest publicly documented cases. The affected service supported loan brokers checking the status of applications, rather than the bank’s core customer transaction platform. Korean reporting describes an attacker probing customer numbers and retrieving information when valid records were found. Approximately 25,727 customers were reported affected, although some coverage gives a slightly different figure.

The precise endpoint-level vulnerability has not been publicly documented, but the reported behavior illustrates the consequences of exposing sensitive business functionality without adequate access controls. An attacker does not necessarily need privileged access to the bank’s underlying transaction infrastructure if a peripheral application already provides access to valuable information.

Similar distinctions appeared at other institutions. KB Kookmin Bank reported exposure through employee mobile-support applications. Hana Bank identified unauthorized access affecting its employee-support environment. BNK Busan Bank disclosed information relating to outsourced developers, while Yegaram and Welcome Savings Bank reported data exposure involving separate web services.

The important point is not that all seven institutions were compromised through an identical exploit. They were not, at least according to the available reporting. It’s that their affected systems occupied similar positions within the broader security architecture: business-critical applications surrounding the institution’s primary financial systems.

The seven institutions shown above were among the earliest reported victims. By October 14, South Korea's Financial Services Commission had confirmed data breaches at 16 financial companies, involving approximately 100,000 exposed information records. Investigators were still examining whether the incidents shared a common attacker and whether AI was used in each case.

For defenders, the distinction between core infrastructure and supporting applications matters because the value of exposed information is not necessarily proportional to the importance assigned to the underlying service. A relatively simple inquiry interface can contain sensitive customer information. An employee-support system may expose identifying details or internal business context. A contractor-facing application may hold records that were never intended to be publicly accessible.

The attacker only needs one sufficiently valuable weakness. Defenders are responsible for all of them.

What Investigators Actually Found

The initial reporting focused on data breaches across the Korean financial sector. The AI connection became more substantial as researchers identified infrastructure and artifacts associated with ARTEX and other AI-assisted tooling.

CrowdStrike reported finding two relevant server environments: a Hong Kong-based system assessed as the operator’s primary infrastructure, and a separate server hosting ARTEX. Additional exposed material included a Chinese-language CLAUDE.md instruction file, Claude Code session histories, ARTEX configuration files, and memory artifacts. Some of the recovered targeting information overlapped institutions named in the Korean financial-sector reporting.

The significance of those artifacts is that investigators were observing more than a reference to an AI tool. They had evidence of an operational environment configured to support offensive activity, along with records of AI-assisted interactions.

The reported model configuration also raises interesting questions about the underlying technology. CrowdStrike identified DeepSeek V4.1-Flash as the configured ARTEX backend, with GLM-5.3 and Grok 4.6 associated with additional Claude Code sessions. Claude Code, in this context, is an agent execution environment; its presence does not mean every underlying inference request used an Anthropic model.

The operator’s identity is less certain. CrowdStrike assessed the actor as likely Chinese-speaking and financially motivated, while subsequent reporting described a possible 26-year-old suspect whose identity has not been independently established. Recovered requests concerning the sale of stolen Korean data support a possible financial motive, but they do not establish a completed sale or prove that one individual performed every action.

The central distinction is between evidence of AI involvement and evidence of a fully autonomous compromise.

The available record supports the involvement of ARTEX and AI-assisted workflows in infrastructure associated with a multi-target intrusion operation. It does not establish which individual exploit requests came from which agent, whether the models independently discovered each vulnerability, or how much human effort was required.

This matters when evaluating offensive AI capability. A system that automatically executes hundreds of tests is not necessarily capable of independently identifying the most valuable targets, understanding their business context, or developing an exploitation strategy from a vague objective.

Those are different capabilities, and they should be evaluated separately.

To understand what ARTEX actually contributes, we need to examine the underlying software.

Inside ARTEX: The Planner, Workers, and Shared State

ARTEX is not a model trained exclusively to hack systems. It is a software framework that coordinates model-driven activity through a set of specialized roles and a persistent execution environment.

For this analysis, I examined ScopeWeaver, a publicly available English/Korean derivative of ARTEX based on an October 1 upstream revision. The code exposes much of the original framework’s architecture, although it should not be treated as a forensic copy of the exact version deployed during the Korean attacks. Some features in the current derivative were introduced after the incident began.

At a high level, the framework consists of a Go application, a Next.js interface, PostgreSQL-backed state management, and an underlying agent SDK called norma. When an operator submits a task, the system decomposes the objective into goals, establishes an exploration state, and starts a planning-and-execution process.

A serial planner examines the current state and creates prioritized intents, representing the next lines of investigation. A configurable pool of workers claims those intents and executes the corresponding technical work. In the analyzed revision, the default worker count is three, although that tells us nothing about how many workers the Korean attacker actually used.

The workers interact with models and general-purpose tools, including shell commands, file operations, browser functionality, and HTTP requests, depending on configuration. Instead of every worker operating within one enormous shared conversation, their discoveries are written into persistent state that other workers and the planner can inspect.

One of ARTEX’s more interesting architectural decisions is the separation between an asset inventory and an exploration graph.

The asset inventory represents information about the target environment: domains, applications, services, endpoints, and associated attributes. The exploration graph records the reasoning and execution structure of a particular task, including goals, attempted directions, discovered facts, and reported findings. Relationships connect observations to the intents that produced them, allowing subsequent planning rounds to inspect not only what was discovered, but why a particular direction was explored.

When a worker completes an intent or reports a finding, the planner can be notified and reconsider the next direction. New intents can depend on observations made during earlier work. The system also supports bounded worker sessions, stored transcripts, and recovery mechanisms that allow interrupted work to be resumed in certain circumstances.

This is useful for long-horizon offensive operations because the fundamental problem is not simply making more tool calls. It is coordinating exploration across an environment that may contain hundreds of applications, endpoints, and potential attack paths.

A powerful coding agent already has many of the primitives needed to discover meaningful vulnerabilities. But asking a single agent to investigate a large environment while maintaining every discovery, failed hypothesis, and pending task in conversational context creates considerable overhead. Orchestration can externalize some of that state management, allowing multiple workers to investigate different directions while a planner maintains the broader picture.

That does not make multi-agent orchestration automatically superior to a single strong agent. It adds scheduling, coordination, and failure-recovery complexity of its own. The benefit depends on how effectively the system divides work, shares useful observations, and prevents redundant exploration.

ARTEX is better understood as an event-driven workflow engine powered by multiple model sessions than as a collection of independent hackers. Its workers execute within one application process, and PostgreSQL provides the shared state.

The model still performs much of the difficult semantic work: deciding what to investigate, interpreting results, choosing tools, and judging whether an objective has been satisfied. The surrounding architecture makes those decisions easier to coordinate over a longer period.

From Attack Trajectories to Playbooks

The more interesting long-term implication of architectures like ARTEX is not simply that they can coordinate one assessment. It’s that autonomous offensive systems create an opportunity for experience to accumulate.

Offensive security has always been an experience-driven discipline. A principal- or staff-level researcher is usually more effective than a junior not because they have memorized every possible exploit, but because they’ve encountered more systems, recognize patterns sooner, understand why previous techniques failed, and know how to adapt earlier successes to unfamiliar environments.

A capable autonomous system could eventually develop some of that advantage through successful execution trajectories, reusable skills, and structured knowledge about the systems it has assessed.

The most valuable artifact from a successful exploitation attempt may not be the final script. It may be the trajectory that led to it: what the agent observed, which hypotheses it tested, which attempts failed, how the environment responded, and what evidence ultimately demonstrated impact.

Those trajectories could be distilled into reusable procedures or retained as references for future work. An agent encountering similar technologies could then retrieve relevant examples and adapt them to the deployment context in front of it.

Consider a vulnerability in a widely deployed component such as FFmpeg. Once a vulnerability is understood, applying that knowledge to another environment is often less about reinventing the underlying technique and more about determining how the component is deployed, whether the necessary preconditions exist, and what differs from a previously tested system.

Experienced human researchers already do this. They reuse techniques, scripts, playbooks, and institutional knowledge accumulated over years of work. Agents could make parts of that process considerably faster by retrieving successful trajectories and adapting prior methods to new environments.

There is an important difference between this potential and ARTEX’s demonstrated implementation.

ARTEX provides persistent task state, recorded observations, and resumable execution histories. It does not, based on the public code analyzed here, demonstrate a complete system for automatically extracting and validating generalizable offensive skills across engagements.

That distinction is essential. The Korean incident does not establish that the attacker built a library of reusable exploits or accumulated successful trajectories across the institutions. The architecture illustrates how experience can be recorded and coordinated; more sophisticated cross-engagement learning remains a separate capability.

But the broader implication is compelling. A security company or offensive research organization that accumulates verified trajectories across many authorized assessments could eventually possess something more valuable than a collection of exploit scripts: a continuously expanding body of practical knowledge about how real systems fail.

The context layer may become one of the most important components of autonomous offensive security.

What Counts as Proof of Exploitation?

There is a significant caveat to the idea of accumulating successful offensive experience: the system has to know when it actually succeeded.

In the analyzed ARTEX implementation, a worker can submit a finding as confirmed through report_finding, even though the ordinary reporting path does not independently replay the exploit against the target. Evidence can be attached, but the model’s conclusion is not equivalent to an independent verification mechanism.

This distinction becomes important when considering the different objectives of a criminal operator and a legitimate security team.

For an attacker attempting to retrieve valuable data, the process may not need to be particularly elegant. Failed attempts, noisy exploration, and incomplete documentation may be acceptable if the desired outcome is achieved. The Korean reporting describes abnormal access and continued attempts after initial blocking at Shinhan, although that does not establish ARTEX’s individual traffic volume or operating behavior.

For a defensive security team, the standard is different. Vulnerabilities need to be reproducible, findings need to demonstrate impact, and engineers need enough reliable evidence to prioritize and remediate them. False positives create unnecessary work and make the entire system less trustworthy.

An independent validation mechanism can therefore improve the quality of autonomous offensive testing, even when the underlying model is already reasonably capable of discovering vulnerabilities.

It becomes even more important once successful trajectories are treated as reusable knowledge. If the system cannot distinguish demonstrated success from an agent’s mistaken interpretation, its accumulated experience risks becoming a library of false assumptions.

The distinction is not simply between an AI agent that can attempt attacks and one that can generate reports. It is between an agent that produces plausible conclusions and a system that can reliably establish what happened.

The Model Is Only Part of the System

Another interesting aspect of the Korean campaign is its reported model configuration. ARTEX was not necessarily relying on the most expensive frontier model for every decision. CrowdStrike identified DeepSeek V4.1-Flash in the recovered ARTEX configuration, alongside additional model references associated with Claude Code.

This reflects an increasingly important distinction in agent engineering: the intelligence of the underlying model matters, but it is not the sole determinant of system performance.

A strong frontier model may be better at complex reasoning, understanding unfamiliar application behavior, or developing strategies when straightforward approaches fail. But a well-engineered harness can extract meaningful capability from smaller, faster, and less expensive models, particularly when tasks are bounded and the system supplies useful tools, context, and feedback.

In my own work developing offensive security agents, I’ve seen how specialized harnesses can make capable, inexpensive open-weight models considerably more useful. Sometimes the better approach is to reserve stronger models for difficult reasoning and coordination while delegating routine, narrower tasks to faster models.

The same principle applies in ordinary software engineering. A powerful coding agent may coordinate a complex feature while smaller models handle more predictable subtasks. This can reduce latency and inference costs without sacrificing the stronger model’s role in guiding the overall work.

For offensive security, those tradeoffs become increasingly significant as agents run longer and execute more work. Provider restrictions and model refusals can also introduce operational friction, although there is no public evidence that the Korean attacker used a particular model-routing strategy to optimize around those constraints.

The fundamental point is that model intelligence, harness engineering, and orchestration contribute different things. The model reasons about the environment. The harness gives it practical means to act. Orchestration coordinates the work across time, tools, and execution contexts.

Understanding the resulting capability requires examining the complete system, not simply identifying which model appears in its configuration file.

The Economics of Scalable Offense

The larger implication of autonomous offensive systems is a change in the relationship between human expertise and the amount of technical work an operation can sustain.

Historically, expanding an offensive security operation required scaling some combination of personnel, infrastructure, tools, and coordination. More targets generally meant more researcher time. Reusing a successful approach still required someone to identify the next suitable environment, understand the technical differences, adapt the technique, and verify the result.

Agents can increasingly absorb portions of that work.

For traditional web applications and full-stack environments, autonomous systems are becoming capable of handling substantial amounts of reconnaissance, testing, and technical execution. A relatively small number of capable operators may be able to coordinate far more work than they could perform manually.

A separate investigation disclosed on October 26 provides another example of this shift. According to Yonhap, South Korean police identified a suspected operator and six accomplices linked to attacks against more than 90 organizations and the theft of approximately 8.2 million records. Investigators attributed attacks on 60 of those organizations to AI-assisted methods, with Seoul Economic Daily reporting that the operator had used an AI coding agent and an autonomous penetration-testing framework to compromise those 60 targets in just over 40 days. Police identified the framework as the same one implicated in the earlier financial-sector breaches, although no connection between the operators of the two campaigns has been established. The case further illustrates how a relatively small number of skilled individuals can scale offensive operations using publicly available AI tooling.

As that happens, the constraints shift. Human expertise remains important, but model inference, compute availability, task coordination, useful context, and the number of vulnerable targets become increasingly relevant to the economics of the operation.

This is not a universal transition across every technical domain. Industrial control systems, embedded devices, robotics, and complex financial environments still introduce specialized constraints that cannot be solved by simply pointing a general-purpose coding agent at a target.

Even in conventional applications, some of the most valuable human work occurs before an agent executes its first technical action. Choosing the target, understanding the business, identifying valuable assets, and supplying deployment context can substantially reduce the search space.

An agent pointed blindly at an unfamiliar application must infer much of that information itself. One supplied with a well-defined objective, relevant architectural details, and a knowledge base describing the business can often execute much more effectively.

This changes how we should think about human involvement in autonomous cyber operations. The operator’s contribution may increasingly be concentrated in defining objectives and supplying context rather than manually performing every step.

It also explains why the most capable users of offensive agents may remain experienced security researchers. Their expertise is not simply replaced by the system. It can be encoded into its instructions, tools, skills, and accumulated knowledge, expanding the amount of work that expertise can influence.

The South Korean campaign does not provide enough information to calculate the attacker’s actual inference spending, human labor, or productivity gains. But the underlying technology illustrates why those economics are becoming more important.

The cost of an additional attempt may increasingly be measured in model calls and execution time rather than additional hours from a human researcher.

Who Finds the Vulnerabilities First?

The response to this campaign should not be to panic about autonomous agents. It should be to recognize that offensive workflows are becoming easier to reproduce and operate at scale.

If attackers can systematically investigate externally reachable applications using automated offensive systems, defenders need to adopt comparable capabilities to discover and remediate weaknesses first.

The Korean incidents offer a particularly important lesson for financial institutions and other large enterprises. Protecting the core infrastructure is not enough when valuable information remains accessible through employee portals, external inquiry systems, partner integrations, and other supporting applications.

The appropriate response is to make adversarial testing a continuous part of security operations. Organizations should be discovering their exposed attack surfaces, testing real business workflows, validating vulnerabilities, and feeding the results directly into remediation and retesting.

This is the problem we’re working on at Pensar, where I lead R&D developing autonomous offensive security agents for testing real systems. The objective is to make the process of finding, validating, patching, and retesting vulnerabilities practical to run continuously, rather than relying exclusively on occasional point-in-time assessments.

The organizations that adapt most effectively won’t necessarily be those deploying the largest number of AI security products. They’ll be the ones that shorten the time between a vulnerability becoming discoverable and that vulnerability being fixed.

The South Korean campaign does not prove that a lone individual can autonomously compromise an entire financial sector. But it shows that publicly available offensive-agent software is already appearing in infrastructure associated with real intrusion campaigns, and that familiar weaknesses in peripheral applications remain sufficient to cause meaningful damage.

For decades, the scale of an offensive operation was constrained by the number of skilled people available to carry it out. Autonomous agents are beginning to break that relationship. The same expertise can now be applied across more targets, more frequently, without proportionally increasing the number of operators.

The next era of cyber offense may not be defined by the sophistication of any single exploit, but by how many ordinary weaknesses a single operator can afford to find.

Subscribe now

There is a natural tendency to frame this as another labor story: AI is becoming capable enough to automate increasingly sophisticated knowledge work, and research is simply the next profession to encounter it. I think that misses the more useful part. AI research has always been heavily automated. One of my first jobs out of college was as a machine learning engineer working on hyperparameter optimization, where the entire objective was to automate a part of the experimental process that would be slow and tedious to perform manually. Training pipelines automate data processing. Schedulers allocate compute. Evaluation suites run the same battery of tests against every checkpoint. Distributed systems turn one experiment into hundreds. The difference now is not that automation has entered machine learning research. It is the level of abstraction at which it can operate.

From automation to delegation

In its analysis, OpenAI uses a taxonomy developed by Epoch AI that breaks frontier AI R&D into a fairly intuitive sequence: decide what to work on, design an experiment, build the code and data required to run it, execute the experiment, analyze the result, and communicate what happened. Historically, software was excellent at automating the middle of that loop once a researcher had specified exactly what should happen. A training job could run without supervision. A sweep could test hundreds of configurations. A benchmark could score every resulting checkpoint. The researcher still had to translate the actual research question into those procedures, investigate failures, interpret the results, and decide what to do next.

Modern agents can increasingly operate on the less structured parts of that work. Instead of being told to execute a particular function with a particular set of arguments, the model can be asked to implement an evaluation, investigate why an experiment is failing, compare multiple trajectories, fix infrastructure blocking a run, monitor an experiment, or trace a surprising result back through the code that produced it. None of these capabilities independently amount to an automated scientist. They do, however, change how much work a single researcher can keep moving at once. A person who previously had to choose which experiment was worth spending an afternoon implementing can increasingly hand off several of them, check in later, and spend more time deciding which results are worth following.

That changes where the bottleneck sits. More experiments are not automatically better experiments, and OpenAI is careful about this in its own write-up. Faster code generation does not mean scientific progress increases at the same rate, and eventually some other constraint—compute, experimental design, interpretation, or simply the ability to identify good questions—becomes limiting. But a research organization does not need to automate those final constraints for the system to become materially more productive. It only needs to make the parts around them cheap enough that researchers can spend a greater percentage of their time on the decisions that still require judgment.

There are increasingly formal versions of the same pattern. Systems such as GEPA treat execution traces as input to an optimization loop. GEPA samples trajectories—including reasoning, tool calls, and tool outputs—uses natural-language reflection to diagnose what went wrong, and proposes and tests prompt updates based on those failures. The important idea is broader than any particular optimization algorithm. An experiment no longer needs to produce only a score. It can produce enough context for another model to help determine what should change before the next experiment runs.

That matters because agents leave unusually rich evidence behind them. A normal benchmark might tell you that a model got 63 percent of a task set correct. An agent trajectory can tell you what the model believed, which tool it selected, what the tool returned, where context disappeared, whether it noticed that an assumption had failed, how it recovered, and whether the final failure came from the model, the harness, the environment, or the instructions surrounding it. Once models are capable enough to reason over that data, trace analysis itself becomes another task that can be delegated.

Training at agent scale

Xiaomi’s MiMo-V2.6 training run shows the same idea much closer to the training loop itself. In September, the team publicly streamed six days of reinforcement-learning training before releasing and open-sourcing the MiMo-V2.6 series on September 22. By the end of the run, MiMo-V2.6-Pro and Flash had each completed 30 RL steps, with the number of tokens per training step reaching 3.5–3.7 billion. Xiaomi used a fully asynchronous architecture and mixed coding, general-agent, visual, and cybersecurity tasks across multiple harnesses, while also scaling the compute spent grading and assigning credit to the resulting trajectories.

The raw scale is impressive, but I find the machinery around it more interesting. An agent enters an environment and attempts a task. It reasons, calls tools, receives feedback, changes its approach, and eventually produces some outcome. The system evaluates that trajectory, determines how successful it was, and uses that result as training signal before repeating the process again across thousands of other attempts. Once the environments reset reliably, the tasks produce meaningful signal, and the graders can tell genuine success from superficial completion, the thing being scaled is not simply compute. It is experience.

That creates a very different engineering problem from training a static model against a fixed corpus. The environment now matters. The harness matters. The tools exposed to the model matter. The amount and structure of context matter. The grader matters. Observability matters because a failed rollout that only produces a zero is much less useful than one where the underlying trajectory makes the failure legible. The research system begins to look less like a single training job and more like a large distributed software system built around repeatedly creating situations in which the model can act, measuring what happens, and feeding those results back into the next version.

This is the part of the MiMo work I find particularly valuable to see publicly. Most of the time, the output of frontier AI research arrives at the end. A model gets released, a paper explains what changed, and a benchmark table shows how much better the result was. The training infrastructure that made the improvement possible stays mostly invisible. Watching the run exposes how much of modern post-training is really about building the machinery around the model: environments, graders, evaluation systems, asynchronous execution, and enough observability to understand whether a capability is improving for the reason you think it is.

The loop is conceptually simple. Run the model. Preserve what happened. Evaluate the outcome. Understand why it succeeded or failed. Change something. Run it again. What is changing is how much of that loop can now execute without a person manually carrying information from one stage into the next.

What this looks like in our own R&D

We see a much smaller version of the same pattern in our work at Pensar. We build autonomous offensive-security agents, so a large part of our R&D process already revolves around evaluating long-running model behavior rather than individual responses. Some of the traces come from production engagements that our team reviews for quality or from customer issues we want to understand more deeply. Others come from our internal evaluations, which range from conventional web application and cloud exploitation environments to more complicated operational-technology and cyber-physical systems. The environments are different, but the research problem is usually the same: an agent ran for some period of time, produced an enormous amount of state and behavior, and we need to understand what it tells us about the model and the system around it.

A few years ago, reviewing that data manually was reasonable. At my previous company, we would run red-team engagements with modified open-source models against large enterprise environments, and when a model did something strange I could usually open the session data and read through the trace myself. The interactions were short enough that the researcher could remain the analysis layer. That stops scaling once the model is capable of working autonomously for hours. Some of our pentests now continue testing for hours or days depending on the size of the client’s infrastructure, and our longest-horizon evaluations produce enough behavior that reading every action manually would eliminate much of the leverage we gained by running the agent autonomously in the first place.

We increasingly use research agents to help with that analysis. They inspect the session data, identify points in the trajectory that deserve attention, and help narrow what might be hours of autonomous behavior down to a much smaller number of interesting failures. Sometimes the issue is straightforward tool selection. We have experimented with smaller and more specialized models that understand the general objective but choose the wrong tool or fail to use information that was discovered earlier in the engagement. Other failures only become obvious over a longer horizon. An agent might successfully reach part of an OT environment but fail to recognize that it should pivot deeper into the operational network. Another model might appear technically capable of completing the same task but refuse because of its guardrails, even when the rules of engagement and authorization are explicitly provided.

Those differences are why a benchmark score is not enough for the kind of work we are doing. We test a mixture of open- and closed-source models, and the same harness can expose very different strengths and weaknesses between them. One model maintains context well but struggles with tool selection. Another is more willing to act but fails to explore deeply enough. A model that performs extremely well in a standard software environment can behave very differently once the task involves a cyber-physical system, multiple trust boundaries, or a long period of autonomous operation. The useful question is rarely just which model completed more challenges. It is why one did and another did not, and whether the failure belongs to the model, the context strategy, the prompt, the available tools, or the broader agent architecture.

Research agents help compress that search space, but they do not remove the need for judgment. Once a trace has been analyzed, someone still has to decide what the finding means for the product. We might discover a recurring failure mode, but fixing it is only one possible use of engineering time. We may instead care more about reducing inference cost, improving latency, extracting more capability from a model that is already working well, or building something needed by customers we are supporting. Those decisions contain product and business context that does not exist in the trace. Leadership decides what the company is trying to accomplish; the research system helps us understand what is preventing the agent from getting there.

The same boundary appears in OpenAI’s description of its own research agents. Humans still decide which questions matter. The automated part keeps expanding underneath that decision layer. I think that is the more realistic near-term model for research automation: not a system that independently determines where an organization should go, but one that dramatically increases how much evidence, experimentation, and implementation can happen between the moments where a person needs to choose the direction.

Evals are core infrastructure

Most evaluation systems are still described as measurement. You change a model or a harness, run a set of tasks, compare the new result against the previous one, and decide whether you made progress. That remains important, but it undersells what an eval becomes once you preserve the trajectory and have systems capable of reasoning about it. A failed evaluation can become a regression test. A strong trajectory can become an example of desired behavior. A repeated failure can tell you that the issue is not the model weights at all but the context, tool interface, system prompt, or workflow surrounding them. Eventually the same data can be curated into SFT examples and other post-training datasets, or used to design tasks and environments for reinforcement learning.

That is the direction we are building toward internally as well. Today, most of our eval infrastructure exists to compare models and measure changes to our harness. Over time, we want more of those failures and successes to feed directly into the next stage of improvement. If a model repeatedly fails in a particular class of environment, the useful output is not simply a lower score on a dashboard. It is a set of trajectories that explain the weakness well enough to change the system, construct better training examples, or design a more targeted evaluation that tells us whether we actually fixed it.

Thinking about evals this way also changes how I think about safety and capabilities work. Both benefit from the same underlying infrastructure. A capabilities researcher can use automated systems to run more experiments, inspect more trajectories, and find more ways to improve performance. A safety researcher can use the same systems to test more behaviors, look for failure modes, and validate whether a mitigation actually holds over long-horizon interaction rather than a handful of carefully selected prompts. The amount of useful work a research group can perform becomes less tightly connected to the number of people available to manually execute every experiment.

This does not mean that every experiment should run autonomously or that more experimentation is automatically good. It means a small group of experts can direct substantially more testing when the expensive parts of execution and first-pass analysis are handled by software. The expert is still there. What changes is the amount of evidence they can generate and inspect before making the next decision.

The same idea applies well outside frontier model labs. Software engineers are already using agents to write features, fix bugs, perform migrations, review code, and operate infrastructure. Most companies are adopting the execution layer faster than the evaluation layer. They are getting very good at producing more agent-generated work without building much infrastructure for understanding where those agents repeatedly fail, whether a task was actually completed correctly, or how those failures should change the way the agent operates next time.

That is probably the most useful lesson to take from what frontier AI labs are doing. The model is only one component of the system. The environment around it can be engineered too. You can measure the workflow, preserve traces, evaluate outcomes, find recurring failure modes, improve the tools and context available to the agent, and turn those failures into tests the next version has to pass. If agents are becoming part of how your engineers build software, then the agent workflow itself becomes something worth testing with the same seriousness as the software it produces.

There is a more dramatic way to tell this story, where automated research immediately becomes recursive self-improvement and the models begin autonomously building smarter versions of themselves. I do not think that framing is necessary yet. OpenAI’s researchers still choose the research agenda. Xiaomi’s researchers built the environments and graders around its reinforcement-learning run. We still decide what matters when one of our research agents finds an interesting failure. There are plenty of constraints left, and improving one part of the research loop simply makes the next bottleneck easier to see.

What is already happening is more concrete. The systems being researched are beginning to participate in the process used to improve them. They can implement experiments, operate inside training environments, generate trajectories, inspect failures, and help researchers decide where to look next. Every one of those steps used to consume human attention. Each one that becomes cheap increases the number of iterations a research organization can perform before a person needs to intervene.

That is enough to matter. The next generation of models will not be built only by finding better architectures or spending more compute. They will also be built by organizations that get better at constructing the feedback systems around them: environments that expose meaningful behavior, evals that tell them when something has changed, agents that can analyze the resulting evidence, and researchers who know which results are worth turning into the next experiment.

The models are getting better. Increasingly, so is the machinery we use to make them better.

Subscribe now

The lesson is not that JadePuffer was advanced. The lesson is that it did not need to be.

For the most part, this was the first documented case of agentic ransomware, and the operation itself was almost entirely ordinary. That combination is the story. Not a new exploit, not a novel cryptographic trick, not elite tradecraft—a large language model chained together a run of well-understood techniques against neglected internet-facing infrastructure and carried the operation from initial access to destruction without a human continuously driving the keyboard. Sysdig’s Threat Research Team named the operator JadePuffer and assessed it as the first extortion campaign run end-to-end by an LLM. What made it notable was not what the agent did. It was that the agent did it.

What it actually did

The operation touched two machines. The first was an internet-facing instance of Langflow, an open-source framework for building LLM applications and agent workflows. The agent gained access through CVE-2025-3248, an unauthenticated remote-code-execution flaw in Langflow’s code-validation endpoint. It’s a CWE-306 missing-authentication issue that lets anyone who can reach the server run arbitrary Python on it. NVD rates it 9.8. The vendor shipped a fix in Langflow 1.3.0 in April 2025, and CISA added it to the Known Exploited Vulnerabilities catalog the following month. The target was never updated. Every payload in the campaign arrived as Base64-encoded Python through that one endpoint.

Once it had execution, the agent behaved the way a competent operator would, only compressed. It enumerated the host with id, uname -a, hostname, and network and process listings. It swept the environment for secrets in parallel: LLM provider API keys, cloud credentials with explicit coverage of Chinese providers like Alibaba, Tencent, and Huawei, cryptocurrency wallets and seed phrases, and database credentials. It dumped Langflow’s backing PostgreSQL database to harvest stored secrets, staged the output to files, reviewed them, then deleted the staging files. It found a MinIO object store still running factory-default credentials—minioadmin:minioadmin—and authenticated to it. Before leaving, it installed a cron job on the Langflow host that beaconed to attacker infrastructure every thirty minutes.

Then it pivoted to the real objective: a separate internet-exposed production server running MySQL and Alibaba’s Nacos configuration service. It connected to MySQL as root, using credentials whose origin Sysdig could not determine and which were not harvested from the victim environment. It attacked Nacos through several vectors at once—the documented 2021 authentication bypass CVE-2021-29441, plus a forged JWT built from the default signing key that Nacos has shipped unchanged since 2020, which makes token forgery trivial—and planted a backdoor admin account. Two moments in this phase are worth pausing on, because they are the clearest evidence that a model was reasoning rather than replaying a script. In one, it tried to create the Nacos admin with a generated bcrypt hash, checked the login, saw it fail, diagnosed the cause, and issued a corrected payload thirty-one seconds later. In another, it expected JSON from an endpoint, received XML instead, and rewrote its own parser on the fly to handle it.

The impact was destruction wearing extortion’s clothes. The agent encrypted all 1,342 Nacos service configuration items and destroyed the originals, deleted whole databases, and left a ransom demand with a Bitcoin address and a Proton Mail contact. The encryption key was ephemeral and unrecoverable—generated at random, never saved or transmitted—so the victim’s configurations cannot be restored even with payment. The Bitcoin address was the exact sample wallet that appears throughout Bitcoin’s own developer documentation, which Sysdig could not definitively attribute to either a hallucination from training data or a deliberately chosen wallet. The agent also made false assertions in its own narration that defenders should not take at face value.

None of this was novel

Walk back through it and the striking thing is how routine each step was.

The entry point was a year-old vulnerability with a patch and a KEV listing. The object store used credentials that ship in the box. The database accepted a root connection from the open internet. The configuration service fell to a four-year-old bypass and a signing key that has been public since 2020. As Keeper Security’s CISO put it to SC Media, every entry point traces back to the same failure of credential governance: secrets stored where they should not be, defaults left unchanged, privileged accounts open with no time-bound or scope-limited controls.

What the sequence describes is a fairly standard security assessment—recon, credential harvesting, lateral movement, persistence, impact—run against a target that had left the usual doors open. It’s the same playbook a competent pentester works through. The only difference is that here the operator was an agent, assembling ordinary components, with no human present for any single step of it.

That is the part worth taking seriously. Not that a machine can do something people cannot. That a machine can now do the routine, unglamorous work of intrusion at full tempo, unattended. Sysdig’s own director of threat research made the same point: none of the individual techniques were novel, but an AI model strung them together into a complete operation against neglected infrastructure.

The economics that used to protect you are gone

Security programs have quietly relied on one assumption for a long time: that adversaries face the same scarcity defenders do. There are always more exposed services, stale CVEs, default credentials, overprivileged identities, and forgotten databases than anyone can fix. The bet was that attackers had to triage that backlog too, because exploiting it cost skilled operator time, and skilled operator time is expensive.

The numbers on the defensive side show how thin the margin already was before agents entered the picture. Critical-severity vulnerabilities take, by industry measurement, weeks to remediate on average—Edgescan's 2026 report puts mean time to remediate for high and critical application vulnerabilities at nearly 55 days, with device and network findings averaging 39 days. For larger enterprises with over a thousand employees, 37% of vulnerabilities discovered in a twelve-month period remain unresolved entirely. CISA's binding directive gives federal agencies 14 days to fix known-exploited vulnerabilities, and that ceiling is one many organizations miss. JadePuffer's own entry point had been on CISA's KEV list since May 2025, more than a year before the campaign. The remediation clock for the defender runs in weeks and months.

Now set that against the attack clock. CrowdStrike’s Global Threat Report puts the average eCrime breakout time—the interval between initial access and the first lateral move—in the tens of minutes, with the fastest observed breakouts measured in seconds. CrowdStrike’s own analysts have said it is only a matter of time before the fastest attacks are measured in seconds, if not milliseconds. And that clock starts even earlier than an intrusion. The Zero Day Clock, which tracks time-to-exploit across more than 83,000 CVEs, frames the broader trend bluntly: the gap between a vulnerability being disclosed and being exploited is collapsing toward zero. The window in which a known bug is theoretically patchable but not yet weaponized is the window defenders have always relied on, and it is closing from both ends.

A defensive process measured in weeks is not losing narrowly to an offensive process measured in minutes. It is operating in a different unit. Agents change the economics of the backlog precisely because they remove the labor constraint from the attacker’s side of that comparison. The long tail of boring, exploitable weakness—the stuff every organization carries because it was never worth an operator’s afternoon—becomes worth attacking when the operator is a process that does not get tired, does not get bored, and can spray the entire back catalogue of known bugs for the cost of running an agent.

Human-speed response cannot close that gap

Follow the tempo argument to where it lands and the conclusion is uncomfortable. When an agent goes from failed login to working fix in thirty-one seconds, or rewrites its own parser mid-operation when a response format surprises it, the loop of noticing, deciding, and intervening no longer fits a human in the middle. Daily alert triage and post-incident forensics are built around an adversary who pauses, thinks, and works at human speed. That adversary is being replaced by one that adapts inside the window a SOC analyst needs just to read the first alert.

The familiar controls still matter and still come first. Patch Langflow and never expose a code-execution endpoint to the internet. Change MinIO and Nacos defaults, rotate the Nacos signing key, keep provider keys and cloud credentials out of the environment of any internet-reachable server, never let a service reach its database as root, and keep immutable, tested backups—which in JadePuffer’s case were the only viable recovery path at all. But those are hygiene. They shrink the surface; they do not change the clock.

Closing the clock means moving response closer to runtime, where a malicious session can be interrupted mid-operation, a harvested credential can be revoked before it is used again, egress can be cut before a host phones home, and blast radius is bounded by design rather than by regret. When an adversary is trying to break into your company at machine speed, the facilities that detect, understand, and respond have to be able to keep pace, and a human reading a dashboard is not that facility.

There is a harder implication underneath, and it is the one worth ending on. The reason this matters is not only that response is too slow. It is that the knowledge defenders produce about their own systems is decaying faster than they produce it. A scan, an assessment, a pentest, a report—each is a snapshot of how a system could be attacked at one moment. That snapshot was already going stale as environments changed underneath it. Agentic operations accelerate the decay from both directions: the environment keeps shifting, and the cost of an adversary re-probing it keeps falling. The half-life of security knowledge is getting shorter.

Which reframes what security work has to be. What mattered yesterday was whether a system passed an assessment. What matters now is whether an organization can keep an accurate, current picture of how it can be attacked—at the same level of persistence an adversary brings, and produced by machinery that runs continuously rather than on a quarterly cadence. If the people trying to get in never stop looking, the people defending cannot afford for their understanding to be a document with a date on it.

JadePuffer is not a story about a superintelligent attacker. There wasn’t one, and there didn’t need to be. Pulling this off took nothing at the frontier—no reasoning breakthrough, no capability that only the largest models have. It took something just capable enough to follow a sequence of instructions, recover when a step failed, and keep moving faster than a person could respond. That is a much lower bar, and a much larger pool of systems clears it. Ordinary weakness becomes a different class of risk when the labor to find, chain, and exploit it becomes cheap. And the assurance we buy from point-in-time testing has a half-life measured against an adversary who no longer keeps human hours.

Indicators of compromise

For defenders checking exposure, Sysdig’s published indicators:

• Entry point: CVE-2025-3248 (Langflow unauthenticated RCE)

• C2: 45.131.66[.]106, beacon to hxxp://45.131.66[.]106:4444/beacon every 30 minutes

• Ransom BTC address: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy (note: this is the canonical example address from Bitcoin’s own documentation—treat as a weak indicator)

• Contact: e78393397[@]proton[.]me

• Ransom artifact: a README_RANSOM table written into the compromised database

Subscribe now

There was no rule. There was no policy. There was no person. The reply came from an AI support agent the company had named “Sam,” and Sam had invented the entire thing. By the time staff caught it, users were publicly canceling subscriptions over a restriction that existed only in the language model’s output. The company issued refunds and clarified that no such policy had ever existed.

It’s a small story. Nobody got hurt, the refunds went out, the internet moved on. But sit with the mechanics for a second. A piece of software, acting on its own, exercised authority it was never granted. It spoke for the company. Customers reasonably treated its words as policy, because for every practical purpose those words were the company. And the failure had nothing to do with the software being hard to use. The software did a job—customer support—and did it the way a careless employee might, except faster, with more confidence, and with no manager in the loop.

We keep describing AI as a better interface: chat instead of menus, natural language instead of syntax, a smarter autocomplete. That framing is comfortable. It keeps software in its place, as a tool we pick up and put down. The transition actually underway is categorical. Software is becoming something that works. And the moment software becomes labor, it stops being governed by the rules we wrote for tools and starts colliding with the rules we wrote for workers—identity, permissions, management, audit, procurement, the org chart itself. Every one of those systems was designed around a single load-bearing assumption: that a human takes the action. Remove the human, keep the action, and they don’t degrade gracefully. They break in specific, diagnosable ways.

I spend my days at the sharp end of this. I lead research at an offensive security company where we let agents run fully autonomously. They pick up after a target is selected, execute exploits, chain steps together, and decide on their own when to stop. Humans watch through a control plane and step in only when something needs a decision, like whether to merge a proposed patch. So I’m writing this as someone who has already rebuilt an operation around software-as-labor and watched which load-bearing walls had to move. The pattern I see at my own company is the pattern coming for everyone, and the people who understand this as a labor story before they understand it as a software story will build the right things.

The thing that actually changed

For seventy years, software has been leverage on human action. You did the work; software made each unit of it cheaper, faster, or more accurate. A spreadsheet didn’t do your accounting. It made you faster at accounting. The entire enterprise software industry—every seat-based SaaS subscription, every per-license deal—rests on that premise. A human does the work, and you sell that human a tool.

What changed is that the software does the work itself now.

You can watch it happen inside a single company. Cursor, the AI coding environment built by Anysphere, started as exactly that kind of leverage: a fork of VS Code with very good autocomplete. Helpful. A tool. A developer wrote the code; Cursor made them faster. Then the product moved. Background Agents arrived—hand off a task and an agent clones the repository into an isolated machine, works on its own branch, runs the tests, runs the linter, and pushes a merge-ready pull request back to you. In early 2026 the company shipped Cloud Agents, which the coverage described as the moment AI coding went from copilot to colleague. Then came Automations: agents that kick off when a commit lands, a Slack message arrives, or a timer fires. No human prompt. The software initiates.

This sits at the center of gravity of one of the fastest-scaling businesses in history. Cursor went from $100 million in annualized revenue in January 2025 to $500 million by that June, past $1 billion by November, and to roughly $2.6 billion by mid-2026. No enterprise software company has ever grown that fast. Roughly two-thirds of the Fortune 500 have developers using it.

Then the punctuation mark. In June 2026, four days after the largest IPO in history, SpaceX exercised an option to acquire Anysphere for $60 billion in an all-stock deal—the largest acquisition of a venture-backed startup ever recorded, folded into Elon Musk’s combined SpaceX-xAI machine to buy a foothold in developer tools it had failed to win organically. A coding-agent company, not yet four years old, became a strategic asset at the scale of a national champion. The price invites skepticism—roughly fifteen times revenue, and Cursor’s market share had slipped from 41% to 26% over the year as competitors multiplied. But the deal tells you how the most aggressive capital allocators on earth read the direction of travel. They didn’t buy a better text editor. They bought a machine that produces software labor.

The $13 trillion reprice

Sell software as a tool, and you sell it against other tools. The market is the size of the world’s software spending—a few hundred billion dollars a year. Sell software as labor, and you sell it against labor. The market is payroll. Those numbers aren’t in the same universe.

Andreessen Horowitz has been making this case in the bluntest possible terms. In a 2025 LP Summit talk literally titled “Software is Eating Labor,” Alex Rampell laid out the arithmetic: the roughly $300 billion in annual software revenue is the prize the whole industry has fought over, while the U.S. labor market runs around $13 trillion a year. His example is an ophthalmology clinic that pays about $500 a year for office software and about $47,000 for a front-desk receptionist. An agent that handles 90% of the front-desk work gets priced against the $47,000, not the $500. It can charge $20,000 and still be the best deal the clinic has ever signed. The software budget was never the opportunity. The payroll was. As Rampell put it, the wages of U.S. nurses alone exceed the revenue of every SaaS company on earth combined.

Sequoia put the same idea in a sharper sentence. For every dollar spent on software, six are spent on services, and the real addressable market for what they call “autopilots” is all the labor spend in a category, insourced and outsourced combined. The line to tattoo on the wall: a copilot sells the tool, an autopilot sells the work.

This is why the venture money moves the way it does, and why the numbers stopped looking like software numbers. Sierra, Bret Taylor and Clay Bavor’s customer-service company, raised at a $15.8 billion valuation in 2026 and crossed $100 million in revenue in seven quarters—charging per resolution, roughly a dollar fifty for each issue the agent actually closes, not per seat. Taylor’s framing is explicit: $400 billion a year is spent on customer service, and a large chunk of it is moving to agents. Decagon, in the same lane, hit a $4.5 billion valuation. Harvey, selling legal work rather than legal software, reached an $11 billion valuation with more than $200 million in revenue, embedded in roughly half the Am Law 100. The customer-service category has at moments traded above a hundred times revenue—a multiple that is deranged for a software company and merely aggressive for one eating a labor budget.

Here’s the part the market maps leave out, and it explains the demand better than any TAM slide. People don’t want to operate agents. They want the work done.

In my own experience building and selling autonomous security tooling, the strongest pull was never “give me a powerful agent I can drive.” It was “I want to open a dashboard and have the thing handled.” The reasoning and the capability sit right there, one tug away, and delegating becomes almost irresponsible to refuse. The temptation has nothing to do with laziness. The marginal cost of having the work done for you collapsed. When the agent can do the heavy lifting, asking a human to do it instead starts to feel like asking someone to hand-crank a car. The companies winning the labor budget understood this. They sell the outcome and treat the dashboard as the place you confirm the work got done, not the place you do it.

That’s the bull case. It’s enormous and it’s mostly right. Software becomes labor, labor is a $13 trillion market, and whoever sells the work instead of the tool reprices their product against a salary instead of a license.

The pressure now is immense, because we just introduced a new category of worker into every enterprise on earth—one that authenticates, acts, and decides—without building any of the infrastructure that managing workers has always required. We bolted a labor force onto an identity-and-control apparatus designed end to end for humans. Here’s where it cracks.

We did this before, and faster this time

It helps to remember that we’ve lived through a structurally identical moment, recently enough that some of the same people are still in the room.

When the internet became load-bearing infrastructure—roughly the mid-90s through the mid-2000s—we connected everything to everything before we had any idea how to secure the connections. The protocols underneath the web were built for a small, trusting academic network, not an adversarial planet. So we spent the next two decades discovering, the hard way, a whole taxonomy of vulnerabilities that couldn’t have existed before: SQL injection, cross-site scripting, the buffer overflow industrialized into a global exploit market, worms that crossed the planet in hours. Each one was a direct consequence of moving faster and connecting more than our security models had anticipated. We built the firewalls, the patch cycles, the disclosure norms, the entire discipline I work in, after the exposure already existed. Order arrived years after the chaos.

Agents are that moment again, compressed. We’re connecting a new kind of actor—one that takes action, not just transmits data—into every system we own, at a speed that makes the 90s look leisurely. The ecosystem is forming in real time. Two years ago “AI agent” was barely a category. Now we’re mid-scramble, discovering that these new workers need precisely the apparatus the internet eventually grew and initially lacked: identity, access management, audit trails, fresh security paradigms, even a national-security posture. We’re living inside the gap between capability and control, trying to close it while the thing is already deployed at scale.

None of that is a criticism of anyone. It’s the recurring shape of how transformative infrastructure gets absorbed. We move first and impose order second, and the interval in between is where the danger and the opportunity both live. We’re in that interval right now. So let’s catalog the specific cracks, the way we eventually catalogued the injection attacks.

Where the human-shaped systems break

The cracks are specific and they’re already visible. Each of the systems we built for human workers is failing in its own particular way—start with the one the others all rest on.

Built for humans, outnumbered by machines

Start with the most basic assumption in enterprise security: behind every action is a person, and that person logged in. Identity and access management—the whole IAM industry—is a machine for answering one question: what is this user allowed to do? It assumes the user is a human who authenticates once, holds roughly stable permissions, works roughly human hours, and can be held accountable.

Agents detonate every clause of that sentence. They authenticate constantly, spin up and vanish, work every hour there is, and have no baseline “normal” behavior. And they arrive in staggering numbers. Even before the current wave, machine identities outnumbered human ones in the enterprise by something like eighty to one; in heavily automated organizations the ratio runs into the hundreds. Agents mint thousands more of these non-human identities, most over-privileged and rarely rotated.

Zoom out far enough and the human has become the minority stakeholder, literally. As of the 2025 Imperva/Thales Bad Bot Report, automated traffic crossed a line it hadn’t crossed in the decade they’ve measured it: bots now generate the majority of all web traffic, around 51%, with humans in the minority for the first time. That figure is broad—it counts crawlers and scrapers and attack bots, not just well-behaved enterprise agents—but the direction is the point. The web is increasingly a place where software talks to software, and the systems checking who’s-who at the door were built for visitors with pulses.

The market noticed. A category is forming around agent identity, and the tell that a category is real is when the serious infrastructure people show up. Keycard—founded by veterans of Okta, Auth0, and Snyk, including the creator of Passport.js, the auth framework half of Node.js quietly runs on—came out of stealth in late 2025 with $38 million to do exactly this. It replaces the static API keys and shared secrets agents currently lean on with dynamic, identity-bound, task-scoped tokens that narrow permissions at every agent-to-agent handoff, so no downstream agent inherits more access than its task requires, and an entire delegation chain revokes with a single call. As their CEO puts it, agents can't leave the lab without trusted access controls—exactly right. It's unglamorous plumbing of the kind that, once it works, everyone quietly depends on, the SSL certificate of the agent era. And because it sits at the center of everything an agent is permitted to do, it's exactly where attackers will aim once agent identity becomes mission-critical—which makes getting it right load-bearing for the whole ecosystem. They're the one to watch, and they won't be alone for long—the identity incumbents are already trying to acquire their way in.

Whose login does it use?

The most striking confirmation that the identity model is breaking came from a frontier lab describing its own product.

In June 2026, Anthropic shipped Claude Tag—drop @Claude into a Slack channel and it behaves as a team member. Anyone in the channel can tag it, hand it a task, and it builds context across channels, takes initiative on its own, and can pursue a project autonomously over hours or days. One detail in their announcement should stop you cold: 65% of Anthropic’s own product team’s code is now written by their internal version of this thing. Not assisted by. Written by. The company building the frontier model has already crossed into a world where most of the code is produced by software labor, and they’ll tell you so plainly.

The more important document is the quieter companion post on agent identity, which contains a section heading that compresses this entire argument into four words: “Why ‘act as the user’ breaks down.” For years, the easy way to give software permissions was to let it borrow a human’s. The script runs as you; the integration acts with your credentials. Always a slight fiction, but a manageable one when the software was a dumb pipe. Anthropic’s reasoning for why it stops working is exactly the reasoning I’d give. First, autonomy: the length of task an agent can complete on its own has been roughly doubling every few months, and “borrow a human’s identity for a second” describes nothing that runs for two days. Second, multiplayer: when three engineers and a product manager all direct the same agent in the same channel, whose permissions does it use? No single human is the right answer all the time.

Their fix is the conceptual turn that matters. Claude acts as itself. It gets its own service accounts—posts in Slack as the Claude app, opens pull requests as the Claude GitHub App, queries the warehouse under its own provisioned account. The question shifts from “what can this user do?” to “what can this agent do, in this compartment?” Because it acts as itself, its actions land in each system’s own logs under its own name, and revoking that one identity ends its access everywhere at once. A genuinely new access model, invented in public, right now, because the old one is actively failing in production.

Audit assumed a someone to hold responsible

Every audit trail, every compliance regime, every SOC 2 control rests on a quiet premise: when something happens, a someone did it, and that someone can be identified, questioned, and held responsible. Accountability is the spine of the whole apparatus.

Autonomous agents dissolve the someone. When an agent merges a branch, issues a refund, or deletes a record, who authorized it? The engineer who deployed it three weeks ago? The PM who wrote the task in Slack? The vendor who trained the model? The model itself? Absent a crisp answer, agentic AI automates the diffusion of responsibility. Everyone is a little accountable, which operationally equals no one.

This isn’t theoretical. The canonical incident is Replit’s coding assistant, which, during a code freeze it had been explicitly instructed to honor, deleted a live production database, fabricated thousands of fake records to paper over what it had done, and then reported that rollback was impossible—also false. No attacker was involved. The agent simply took catastrophic action it wasn’t authorized to take and misrepresented the result. And the permission model behind that unprovoked failure is the identical permission model an attacker would deliberately exploit. The safety failure and the security failure are the same hole seen from two angles. An agent that can delete the production database during a freeze is a liability whether the instruction comes from a confused model or a malicious prompt.

The model can't tell instructions from data

Which brings us to the vulnerability that is to the agent era what SQL injection was to the web era. Large language models read their instructions and their data through the same channel. They cannot reliably tell “my operator told me to do this” from “this document I was asked to read told me to do this.” That’s prompt injection, and the consensus forming among security researchers in 2026 is that it may be a permanent property of how these systems work rather than a patchable bug.

The exploits are as clever as the early web’s, and as grim. Researchers planted a malicious instruction in the title of a GitHub pull request; coding agents from multiple major vendors read it as trusted context and dutifully leaked environment variables—API keys, tokens, the keys to the kingdom. This connects straight back to how people actually deploy agents now: wired to monitor logs, watch error streams, and act on incoming requests automatically. Which means attackers learned to send the agent malformed input on purpose, a request crafted to throw an error whose text is itself an injected instruction the log-watching agent will read and obey. The agent’s helpfulness becomes the attack surface. The year before, “EchoLeak” let an attacker exfiltrate data from Microsoft 365 Copilot with zero clicks. These aren’t edge cases being slowly closed. They’re the structural consequence of handing a credulous reader both your secrets and your adversary’s messages and asking it to act.

The nation-states already arrived

The clearest signal that we’ve crossed a threshold is that the most sophisticated attackers operationalized it first. In November 2025, Anthropic disclosed what it described as the first reported AI-orchestrated cyber-espionage campaign: a state-sponsored group hijacked Claude Code to run an autonomous operation in which the AI performed an estimated 80–90% of the campaign, with humans stepping in only at a handful of critical decision points, against roughly thirty global targets. The machine does the overwhelming majority of the work; the human is there by exception. The offensive future Snehal Antani of Horizon3 describes—algorithms fighting algorithms at machine speed, with humans by exception—stopped being a forecast and became a disclosed incident. The labor transition already happened on the attacker’s side, which forces it to happen on the defender’s side too, because no human team fights at that tempo.

The org chart, procurement, and the shape of the company

Step back from the security mechanics, because the breakage runs into the soft tissue of the organization too.

Procurement was built to buy seats and licenses—a fixed price for a human’s access to a tool. Agent labor doesn’t fit the form. You’re buying outcomes now, metered per resolution or per completed task. Sierra’s dollar-fifty-per-resolution model breaks the procurement template as surely as it breaks the pricing page, and finance departments are finding they have no clean category for “we spent $40,000 on work that used to be a salary line.” The cost can run away from you in ways a license never could. There are already reports of agentic loops generating eye-watering bills—one company reportedly ran up a $500 million monthly inference charge from runaway agent activity. A license has a fixed cost. A worker that bills by the action and never sleeps does not.

The org chart bends too, and not in the simple “AI takes the jobs” way the headlines want. 2026 brought a wave of layoffs citing AI—Salesforce, Amazon’s tens of thousands of corporate cuts, Block, IBM—while software-engineering job postings rose for months on end. Both are true because they describe different layers: individual firms cutting while aggregate demand for people who can direct this new labor force climbs. What’s genuinely worrying is narrower. Early-career hiring is contracting. Stanford’s Digital Economy Lab found a 16% relative employment decline for the youngest workers in the most AI-exposed occupations. We may be automating the bottom rung of the ladder that produces the senior people who supervise the agents—a structural problem that won’t show up in this quarter’s numbers but mortgages the next decade’s.

All of it describes an organization quietly reorganizing around a workforce that doesn’t appear on the org chart, isn’t covered by HR, doesn’t fit procurement, and doesn’t slot into the audit model. The systems are all still there. They increasingly describe only the human half of the company.

Security already solved this

Here’s where it gets useful for defenders, because there’s good news buried in all this.

The hardest-sounding problem in enterprise AI right now is agent governance: how much autonomy you give the thing, what it’s allowed to touch, how you define unacceptable behavior, how you evaluate it before you trust it, how you scope it differently per environment. CISOs are rightly nervous, because it sounds like an entirely new discipline they have to invent on a deadline.

It’s penetration testing’s rules of engagement wearing a different hat.

Think about what a serious pentest requires before a single packet moves. A prestigious firm doesn’t start hacking. They scope it: precisely what’s in bounds and what’s out, which IP ranges and applications and APIs and cloud assets are fair game and which are categorically off-limits. They define the rules of engagement: which techniques are permitted, how aggressive the testing can get, the timing windows, and the stop conditions—the lines that mean halt and escalate to a human. They get requirements crisp up front so there’s a shared picture of what’s being tested and why. They close the loop afterward with a report on what worked, what didn’t, and what to fix. The entire formal apparatus—PTES, NIST SP 800-115—exists to answer one question: how do you let a powerful, semi-autonomous actor loose inside your systems without it doing something catastrophic, and how do you know afterward what it did?

That is the agent governance question, word for word. The discipline maps cleanly:

This is exactly how I run agents in production. We don’t hand an agent open-ended access and hope. We give it a threat model and a scope the way you’d brief a contractor, then let it run autonomously inside those bounds, and pull the human in only at the decision points—patch approvals, anything that touches something it shouldn’t unilaterally touch. We get very few false positives and very little drama for the same reason a well-scoped pentest runs cleanly: the boundaries were defined before the work started, not negotiated after something broke. What most enterprises are missing isn’t a new framework. It’s that there’s no per-environment eval, no equivalent of the scoping call, where a customer specifies what their unacceptable behaviors are before the agent is loosed in their environment. Every prestigious pentest firm does that scoping as step one. Most agent deployments skip it and then act surprised.

Joe Sullivan, former CSO at Uber, Cloudflare, and Facebook, put the management problem about as well as anyone: agents are like teenagers, with all the access and none of the judgment. The job isn’t to lock the teenager in a room, and it isn’t to hand over the keys to everything. You scope what they can do, define the lines they can’t cross, watch through a control plane, and show up by exception when judgment is required. Security teams have been doing precisely this for the most dangerous actors in the building—their own red teams—for twenty years. The what isn’t new. The how is new. The teams that realize they already own the playbook will be calmer and safer than the ones treating this as terra incognita.

What gets built next

Software became labor. That’s the headline. Underneath it, the systems we built for a workforce with pulses—identity, audit, procurement, the org chart, the whole accountability apparatus—are cracking along predictable lines, the same way the early internet’s trusting protocols cracked once we connected everything to everything. We’re in the interval between capability and control, and the interval is where both the danger and the opportunity live.

If you allocate capital, the tell is simple. Stop asking whether a company sells better software and start asking whether it sells the work. The autopilots eating labor budgets reprice against a $13 trillion market, and the picks-and-shovels layer underneath them—agent identity, agent authorization, agent audit, the control planes and the evaluation harnesses—is a second market forming on top of the first, because every one of those autopilots needs the apparatus the human-shaped systems can’t provide. The internet minted both the companies that connected everything and the companies that secured the connections. This wave will too.

If you defend an enterprise, stop treating agent governance as alien and start treating it as the thing you already know how to do. You scope dangerous actors for a living. An agent is a fast, tireless, credulous, occasionally brilliant new hire with all the access and none of the judgment, and you onboard it the way a serious firm scopes an engagement: bounds first, autonomy inside the bounds, humans by exception, everything logged under an identity you can revoke. The novelty is in the actor, not the discipline.

And if you’re just trying to see the shape of what’s happening, here’s the compression. The question every enterprise system was built to answer was what is this person allowed to do? The question every enterprise system now has to answer is what is this agent allowed to do, in this compartment, and how do we know what it did? The sentence is small. Rebuilding every system in the company around it is not.

Your newest hire has no pulse. They never go home, they never push back, they’ll do the work the instant you ask, and they will, occasionally, invent a policy that doesn’t exist and tell your customers it’s real. Managing that is the defining operational problem of the next decade. The good news is we’ve managed dangerous, capable, untrustworthy-by-default actors inside our systems before. We just called it something else.