Blog

Where the Learning Lives: Out-Learning the AI Attacker

Evan Powell
|
October 18, 2026

Attackers learning; how about us?

An attacker's learning loop has always been simple to describe. Try something. See what the target's systems fired in response. Adapt. For twenty years the loop ran at human speed and was expensive to turn: a crew would build a tool, test it against copies of the defender's products, run it, read the incident write-ups that followed, and come back in a week or two or three with a variant of their attack. The loop was real, but it was largely manual, hence slow, and it depended on fairly rare expertise.

AI has accelerated the attacker's learning loop and democratized the expertise on which it is based. For example, a recent review by Anthropic of 832 accounts banned for malicious cyber activity found two thirds of them using AI to write malware, and a shift over the year from AI-assisted initial access toward AI-assisted activity inside a compromised network, such as account discovery. Google Threat Intelligence Group (GTIG) has described malware families that call a model while they run: one that asks Gemini to rewrite its own source and saves the result for persistence, one used by a Russian state actor that asks a model for the next Windows commands to run, and one that uses locally installed AI tools to hunt for developer secrets. In September 2026 GTIG also reported a financially motivated actor running an autonomous multi-agent framework from a compromised cloud account: Markdown playbooks as instructions, scanning and IP rotation handled by the agents, errors troubleshot in real time with no human directing each step, and thousands of third-party credentials taken in under six hours. Exploit development that took weeks and thousands of dollars now costs close to nothing, which makes bespoke attacks against a single company practical and shrinks the gap between a patch and the exploit that beats it.

Put those together and the attacker's loop of 2026 looks something like this:

  • Prepare an attack with the help of an open-weight model.
  • Test against the defender's controls until nothing fires, which is to say, learn the defender's rules.
  • Run the attack with agents that take live feedback and adjust mid-campaign.
  • Keep what worked as a playbook, discard what was caught, and come back in hours rather than months.

Going forward, the loop closes further: agents that watch which actions draw a response and route around it, playbooks curated by the campaign's own results, and a cost per attempt low enough that the attacker can afford to be caught often, provided each failure teaches the next attempt something.

Confronted with a learning attacker, a defender has one option that is not merely a faster version of losing.

There is no escaping it. We must out-learn them.

Tempo, and the loop that matters

I have written a couple of times about the OODA loop in this context: once on how AI attackers turned the defender's situation into a SNAFU, and what a faster OODA loop looks like, and once on what DevOps and SRE teach us about closing the loop at machine speed. The short form: observe, orient, decide, act, and the side that completes the cycle faster and with better orientation sets the terms of the engagement. Boyd's insight, the one that gets lost in the acronym, is that orientation is the stage that decides the contest.

Speed without a better model of the situation is thrashing.

The attacker's loop is fast and smart now. So the question is where a defender finds tempo and orientation the attacker cannot match. Patching faster is not enough; we were well behind before, and the vulnerability apocalypse is just getting going. Doing the old SOC work faster is not enough either. We think learning is all-important: the defender's loop must itself get shorter and better oriented each time it runs, which means a SOC whose learning is a property of the system rather than a quarterly exercise. We want recursive self-improvement from a defensive system, on one condition: that we can be sure it stays aligned with the people responsible for the environment it defends. I will come back to that condition, because it is a design requirement.

Unequal information, and whose advantage it is

It might be my old information economics background coming out, but to me the information asymmetry we still possess, even as attackers train against our defenses, is what makes out-learning them possible.

Remember, generally speaking the attacker learns from the outside. Their loop is fed by one signal: did the defender's systems respond? They see the controls that tripped, the sessions that were cut, the response that followed. They do not see the environment as it is. They do not know which service account always talks to which database at three in the morning, which subnet never speaks to the internet, which workstation belongs to the finance lead who travels each quarter. Each probe they make to find those things out is itself a behavior in our telemetry. The attacker's loop cannot help but leave a record in the one place they cannot read.

The defender knows the environment. Clausewitz would call that the advantage of the defense, and in this domain it is literal. A model that reads network flows and logs as sequences, and understands what adversary behavior looks like across environments it has never seen, turns that knowledge into a signal: the pattern of life of the estate, and the departures from it that are malicious. That is what LogLM is for. It emits malicious events with a confidence and a MITRE ATT&CK tactic, from telemetry rather than from a rule list, and it flags attack patterns it was not trained on. The attacker's loop is judged by whether our rules fired (and some of our users now obscure even that signal, through approaches both obvious and subtle). Ours can be judged by what the attacker actually did.

That difference in access to useful information matters more than it may appear. Every learning loop needs a judge it cannot game. A SOC that learns from rule alerts learns the rules, which the attacker has already learned too. A SOC judged by a behavioral signal it does not control, and the attacker cannot see, learns something the attacker cannot anticipate. Unequal information is an advantage only if it informs the learning.

How does learning happen in an autonomous and autonomic SOC?

I am sometimes asked about the difference between agentic, autonomous and autonomic. We have a blog on that, which also explains what each means in the SOC, and a short definition in the Learning Center. In short, autonomous means it acts without being asked, under a ceiling its operator sets. Autonomic means it regulates itself the way the autonomic nervous system does: it configures, heals, protects and optimizes itself without a person attending to each adjustment. Learning is the optimizing part, so it is accurate to call an AI SOC like Vigil that can improve itself over time an autonomic SOC. So how does this improvement over time happen in a SOC?

One of the best accounts I have seen of how agents can learn is a guest lecture Chen-Yu Lee of Google Cloud AI Research gave at UC Berkeley on October 15, From Goldfish to Self-Improving Agents. The slides are worth reading in full.

Lee's starting point was the goldfish: a deployed agent whose weights are frozen learns nothing between sessions and forgets everything. His talk walks through a series of approaches Google has researched, developed and deployed to enable agentic learning:

  • Memory: organize what happened by topic and merge similar facts, so an agent retrieves what matters instead of rereading its history (MemoryBank, ACL 2025).
  • Lessons: store strategies distilled from successes and failures rather than transcripts, judged by the model itself with no labels; it lifted each backbone tested, and then, as the bank grew, the memory became too expensive to keep around (ReasoningBank, ICLR 2026).
  • Skills: train a small curator, an 8B model, to insert, update and delete skills in a Markdown library, rewarded only when later tasks improve; this approach beat a frontier model asked to curate zero-shot (SkillOS, NeurIPS 2026). This is one area where DeepTempo research is exploring fast, System One models.
  • Environments: wrap static benchmarks with stages, contracts and chains, and let an agent make tasks harder or easier from the traces (EnvHarness).
  • Harness: last but not least, let the agent edit its own prompts, tools and control flow. One finding is that unregularized self-improvement learns the test: four earlier methods gained on the benchmark they evolved against, and on three they never saw, two lost ground, one stood still and one gained under a point. Regularized with a leakage critic, a noise floor, a cost rule, a held-out set and pruning, the loop gained on all six held-out benchmarks (RRSI). The lesson is that the details matter, and the right combination of techniques yields the sustained improvement we need.

How the five land in Vigil

Here is how these five techniques land in Vigil, DeepTempo's open source AI SOC, mapped back to the OODA loop.

Memory shortens Observe and Orient

When a hunt terminates or a case closes, Vigil distills the run into what was seen and concluded about each host, user and address, and each later run can recall it as it starts. Recall reorders what the agent looks at first and never decides anything. We are researching memory merge functionality as well.

Lessons orient the next run with the last one's mistakes

Vigil records each ingredient of a lesson today: the Ledger holds each call and result, the record can be rebuilt as a learner would read it, and the reviewer guard, the declared gaps and the analyst's closure category are the no-label judgment signals Lee's method needs. What we are adding is the step that writes strategy-level lessons per finished run, from failures as well as from successes.

Skills are how Decide improves

Vigil's procedures are portable SKILL.md files with an evaluation gate and telemetry on which ones get read. Curation today is human only. We are looking to add an agentic curator that proposes inserts, updates and deletions as diffs, with the runs and lessons that motivated them, scored on a held-out set before anyone sees them; a person promotes. Deletion is a first-class proposal, because the lesson of the crowded bank is that something has to decide what to keep.

Environments are rehearsals

We are actively building enhancements to Vigil that correspond to the environments Lee outlines. Vigil will shortly have at least three practice worlds: known-answer probes injected on a schedule, a thirty-case evaluation estate with blind, injected and benign-but-suspicious cases, and adversary emulation. All three are static. The loop will wrap them with stages, contracts and chains, plus a rigger that reads the trajectories of runs that failed or passed trivially and writes the next task. The curriculum follows the weakness, which is the one thing the attacker's loop can never do for us.

The harness is the loop that improves the loop

Each run kind in Vigil is a plugin with a system prompt, a skills list, a fold policy and a guard; each model call's inputs are hashed to the Ledger; declared intent already runs in observe mode, with a replay that answers which decisions would differ under a change. That is most of Lee's regularizer, built for other reasons. The loop we are building adds the rest: propose an edit, evaluate it three times so a gain inside the noise is a revert, reject anything that names a case or a probe's answer, require the gain to pay for its cost, hold it to cases it never saw, and prune what stopped helping. The survivor is a pull request a person merges.

Judges the attacker cannot edit

Across all five, the judges are the same: the analyst's closure, the reviewer guard, the known-answer probes and, where LogLM is present, a ground truth from a foundation model for detecting advanced attacks, a scoreboard that does not move when a rule, a skill or a prompt is edited. "LogLM fired and the rules did not" is a detection the authoring loop can write tonight. "The rules fired and LogLM did not" is a labeled episode that points the base model at a blind spot. "Neither fired" is an honest gap, and a reason to adapt a classifier head inside the customer's boundary, which is the one place experience does go back into weights, on episodes the customer chose to keep.

To be sure, Vigil is complete without LogLM. Each loop degrades to the judges it has; what is lost without LogLM is a class of lessons.

Keeping the loop ours

Let me share our biases here, inherited from the enterprises and governments that have helped us build LogLM and Vigil.

The sort of self-improving defensive system we are building is an advantage only if it remains the operator's. Lee's results show what goes wrong otherwise: the loop learns the test. In a SOC the equivalent failure is a harness that learns to be quiet, or to close cases, or to please whichever score it was given, and an operator who can no longer say why it decided anything.

Our approach in building Vigil and the broader platform is to keep the learning inspectable and owned by its users, and each loop we add holds to that design. Memory has rows an operator can read and delete. Lessons name the runs they came from. Skills are Markdown, version-controlled and reviewed in your GitHub. Stages are data beside the cases they wrap. Harness edits are pull requests, scored on a hash-chained Ledger that cannot be rewritten and replayed to the exact bytes the agent was shown. Declared intent is a file under version control that sets the ceiling for what runs unattended. The defender holds the reins, and can prove it.

The attacker will keep learning. Their loop is fast, cheap and fed by one bit of information per attempt. Ours can be fed by the environment attackers must probe, the behavior attackers cannot hide, and a judge they cannot edit. Learning is everything, and learning can live with the defender.

So I am optimistic that we will achieve Machine Speed Intelligence, and an OODA loop that is faster and more intelligent than defenders. It will not come from a snap-of-the-fingers flurry of patching, whatever some experts proclaim. The path forward is to build systems that use information asymmetry to out-learn the attackers.

What do you think? Did this post help explain the cutting edge of self-improving systems? Can you see how this flavor of recursive self-improvement can help organizations stay ahead of attackers?

References

See the threats your tools can’t.

LogLM works with your existing stack to uncover the evolving threats traditional systems overlook. Vigil, the open source AI SOC, turns those findings into action. No added complexity, nothing replaced.

Request a demo