Autonomous Attack Workflows: A New Defender Mindset

Problem

Autonomous attack workflows force us as defenders to work at a different speed. An agent can collect information, read the results, choose another tool, and continue without waiting for a human operator after every step.

The individual techniques are not necessarily new. What changes is how quickly an attacker can connect them into an attack path and adapt when the first attempt fails.

Many security operations centers (SOC) still work from alert to alert. I believe that workflow becomes dangerous when an autonomous agent can test several paths, abandon one, discover another machine, and continue before an analyst has understood the first signal.

Important: In this article, autonomous describes an agentic workflow that can select tools, run actions, interpret the returned results, and choose a next step within the access and permissions available to it. It does not mean that AI can magically obtain initial access or complete every attack phase without human intervention.

Over the past few weeks, I have been building and experimenting with a local lab using MCP servers, HexStrike, and local open-weight large language models (LLMs), including community-modified abliterated variants. I use this lab to understand how autonomous security agents actually behave. This article is based on those observations.

Terminology used in this post

These components work together, but they do not have the same role:

Term	Meaning in this post
Model	Reads the available context and suggests decisions or actions.
Agent or AI client	Manages the process, provides context to the model, and coordinates what happens next.
MCP client and MCP server	The client connects the AI application to an MCP server. The server exposes tools and returns their output through a standard interface.
Security framework	Runs the requested security actions using its available tools.
Command-and-control channel	Existing communication between attacker infrastructure and a compromised system. It provides a route for sending actions and receiving results.
Tool orchestration	Selects, sequences, or runs tools in parallel and passes results into the next decision.
Attack path	The sequence of identities, systems, applications, and actions that can lead to an objective.
Lateral movement	Movement from one compromised identity or system to another inside the environment.
Workload identity	A non-human identity used by an application, service, automation, or workload.
Token	An authentication or authorisation artifact that represents an identity, session, or granted access.

In short: the model reasons, the agent manages the process, MCP connects the client to tools, the security framework executes actions, and existing access provides the route to the target.

Why autonomous attack workflows change the cyber kill chain

Traditional automation follows a fixed set of steps. An autonomous agent can evaluate the output and decide what to do next. That feedback loop can compress reconnaissance, discovery, credential access, lateral movement, and collection into a much shorter period.

Attack phase	What an autonomous agent changes
Reconnaissance	Starts discovery and processes results without waiting for an operator
Initial access	Compares several possible paths without waiting for manual input
Discovery	Changes its next action based on each service, identity, or system it finds
Lateral movement	Treats another reachable machine as a possible route to the original objective
Collection	Searches and prioritises accessible information with fewer manual pauses

AI does not speed up every part of the attack chain. Some steps still take the same amount of time because the target or environment controls them. Examples include scan duration, authentication lockouts, beacon intervals, network latency, or waiting for someone to interact.

The biggest time saving happens between those steps. An agent can make sense of the results, choose another technique, adjust parameters, and start the next action without waiting for a human.

For me, the important word is compress. AI does not remove the attacker from the operation. A human still defines the objective, accepts the risk, sets boundaries, and decides what has value.

AI takes away much of the repetitive manual work and makes complex workflows easier to use. Experienced attackers can focus on the goal instead of spending time on tool syntax, changing commands, and working through every result themselves.

The tools themselves are not faster

This one is important. Connecting Nmap, Nikto, Nuclei, or another security tool to an AI agent does not suddenly make that tool scan faster. I mean, think about all the noise it would make if AI indeed was making the tool faster! It would sound like a CIWS weapon system.

The same technical limits still apply:

• Rate limits
• Network latency
• Target response times
• Timeouts and retries
• The number of templates or checks
• Available CPU, memory, and bandwidth
• Safeguards configured in the tool

An Nmap scan that normally needs five minutes will not finish in one minute because an AI agent started it. Nuclei still needs to run its templates, and Nikto still has to wait for responses from the target.

What disappears is much of the time between those actions. There is no human who first has to:

1. Decide which tool to use.
2. Look up the correct flags.
3. Write and check the command.
4. Wait for the result.
5. Read and interpret the output.
6. Modify a command or script.
7. Start the next tool.

The tools are not faster. The workflow has fewer human pauses and is therefore quicker.

In a manual assessment, ten tools may each take the same amount of time to run, but minutes can pass between them while the operator reads, researches, decides, and types. An autonomous agent can process the returned output and prepare the next action immediately.

%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 50, "rankSpacing": 60}}}%%
flowchart TB
    subgraph Manual["Manual workflow"]
        M1[Human selects tool and flags] --> M2[Tool runs<br/>with normal technical limits]
        M2 --> M3[Human reads the output]
        M3 --> M4[Human researches and decides]
        M4 --> M5[Human starts the next tool]
    end

    subgraph Autonomous["Autonomous workflow"]
        A1[AI selects the next actions] --> A2{Run tasks in parallel}
        A2 --> A3[Prepare a lab payload]
        A2 --> A4[Set up a lab listener]
        A3 --> A5[Actions keep their<br/>normal technical limits]
        A4 --> A5
        A5 --> A6[AI processes the output]
        A6 --> A1
    end

    M5 ~~~ A1

The important difference is the delay between one result and the next action. The autonomous workflow can continue without waiting for a human to read documentation, write another command, or edit a script.

It can also start independent actions in parallel. For example, while one task prepares a payload in the lab, another can set up the listener. The total elapsed time drops even though neither task runs any faster.

Whether this works depends on the model, AI client, orchestration logic, framework, tool support, available resources, and configured limits.

From endpoint logic to agentic orchestration

This thought took me back to how we have looked at malware and attack scripts for years. A specific script may run inside the victim environment using logic written before it starts. If the operating system, application version, permissions, language, path, or security control is different from the test environment, a step may fail.

That does not mean modern malware is always static or follows one simple sequence. Malware can already contain environmental checks, modular capabilities, decision trees, fallback infrastructure, staged payloads, and commands from a human-operated command-and-control channel.

What got me thinking is where the agent can adapt. Some decisions no longer have to be built into the code running on the endpoint. The agent can work with what the tools return and decide what to try next.

The autonomous AI agent does not have to run on the victim machine. It can remain on the attacker’s system and use tools exposed through the Model Context Protocol (MCP).

MCP itself is not the reasoning engine. It provides a standard interface through which an AI client can discover and use tools and receive their results. The ability to adapt comes from the model, AI client, orchestration logic, and framework working together.

This does not mean that AI can simply reach into a machine from the outside. An attacker still needs an initial access path, such as malware, a remote shell, compromised credentials, an exposed service, or an existing command-and-control channel. Once that access exists, the code on the victim machine may be a script, implant, shell, or remote management tool, while the AI remains on the attacker’s side.

The tools return results, errors, and other information through MCP. The client and model can then:

1. Work out why an action failed.
2. Reason about the returned information.
3. Change a parameter, tool, script, or attack path.
4. Try again and check the new result.

Think about it this way: the malware or remote access provides the hands, MCP connects the tools, and the model with its client and orchestration decides what to try next.

%%{init: {"themeVariables": {"fontSize": "20px"}, "flowchart": {"nodeSpacing": 50, "rankSpacing": 60}}}%%
flowchart TB
    H[Human operator] -.->|Steer or stop| C

    subgraph Attacker["Attacker infrastructure"]
        C[AI client and orchestration] <-->|Context and decisions| L[Language model]
        C -->|Discovers and invokes tools| M[MCP interface]
        M --> T[Security tool]
    end

    T -->|Uses existing access channel| V[Victim machine]
    V -->|Returns output or errors| T
    T -->|Tool result| M
    M -->|Structured result| C

The Black Hat story that got me thinking on this

At Black Hat Europe 2025, Tom Gallagher shared an anecdote from his early penetration-testing work at Microsoft. As I remember it, he described an Excel proof of concept that appeared to delete all data on a machine. A progress bar ran for a few seconds and displayed real filenames, but the proof of concept did not actually delete them. It was intended to demonstrate a “what if” scenario.

It behaved safely in his own test environment but caused unexpected crashes on a manager’s machine. That is my memory of his session rather than a verified transcript or video, but it was a fun story with a useful lesson.

That story stayed with me. It shows how fragile scripting can become when it reaches an environment the creator did not anticipate. A conventional script can fail, stop, or behave unexpectedly.

Now add an autonomous agent with a working feedback channel. It can process that unexpected result and attempt another approach within seconds. This does not make adaptation reliable.

The agent may choose a useful alternative, misunderstand the error, repeat a bad assumption, or make the situation worse. What changes is the speed and number of decisions following the unexpected result.

For defenders, this means that a failed action should not automatically be interpreted as the end of the attack sequence. An adaptive attack operator or agent may already be processing the failure and preparing another approach.

The dangerous part is not always the original target

This is where I think it becomes dangerous. One of the most important behaviours I have seen during lab testing is how an agent handles scope.

The agent starts with a target machine and tries several ways to reach its objective. When those attempts fail, it may enter a loop and keep trying variations of the same approach. A human operator must then add context, steer it towards another option, or stop it completely.

At other times, the agent leaves that loop by starting reconnaissance again. It may discover another machine and decide that this system could provide a path back to the original target. Better prompting, I hear you say. But that is not always the solution to such drift.

Some scenarios:

• A path pivot means the objective stays the same, but the agent chooses another route.
• Scope expansion means the agent includes systems that were not part of the intended test.
• Goal drift means its actions no longer support the objective you originally provided.
• A loop means it repeats unsuccessful actions without gaining meaningful new information while consuming inference budget and running much longer than needed. (Feeling sorry for the trees)

These failure scenarios can also work in the defender’s favour. An agent that repeatedly changes authentication attempts, restarts reconnaissance after a dead end, or interacts with a growing number of systems may generate more telemetry than a careful human operator would.

Tip: Hack The Box Academy includes an IDS/IPS evasion lab in its Network Enumeration with Nmap module. The lab shows how much noise an Nmap scan can create and makes the person running it aware of what an IDS/IPS may detect. The goal is to collect the required information without generating too many alerts. It is not an example of an autonomous AI attack, but it clearly demonstrates why repeated or poorly tuned actions create useful telemetry for defenders. A scan can succeed technically while still revealing the attacker’s presence.

Loops, rapid retries, abrupt changes in technique, and unnecessary scope expansion are not only weaknesses in the agent. They can also become useful behavioural signals for defenders.

From the agent’s perspective, moving to another machine can be a perfectly logical decision. From our perspective as defenders, the attack surface and potential impact have suddenly expanded.

This is one reason autonomous offensive AI can become dangerous.

Important: Scope cannot be enforced by a sentence in a prompt alone. A prompt expresses the intended target, but it does not create a reliable technical boundary.

An AI agent connected to offensive tools through MCP may misinterpret instructions, use overly broad parameters, follow newly discovered attack paths, or continue interacting with other reachable systems. Defenders should expect an attacker-controlled agent to use any available route that supports its objective, not assume that the attacker has applied reliable scope boundaries.

This also changes how SOC teams should approach an investigation. While analysts are examining activity on one endpoint, the attacker-controlled agent may already be working through the returned results, changing its approach, and taking action against other reachable systems. The first machine visible in the investigation should be treated as the first observed node, not automatically as the initial access point or the full scope of the incident.

What I have seen with HexStrike

In my lab, I run HexStrike AI in a container I built myself. I was curious whether I could run it in a container and make it more accessible across different machines. This allowed me to deploy and connect an AI client to a large collection of security tools through MCP within the container. The HexStrike framework describes its own decision engine for tool selection and parameter optimisation, but that decision engine is part of the framework and not MCP itself.

This screenshot shows part of the tool catalogue exposed through the HexStrike MCP server. The AI client can discover these tools and choose between them as the workflow continues.

Being willing to help and being able to carry out the work are two different things, but they are often treated as the same. In my lab, I tested a handful of models, but this was not a controlled test. I saw a clear difference between a model giving advice and a model operating tools through a longer workflow.

As an advisor, a model without a refusal could explain ideas, work through a wider goal, turn it into an approach, and answer follow-up questions. That makes advanced knowledge easier to access. With that I am talking about it’s behaviour, not specific models or sources, because pointing readers towards those adds nothing to this argument and is in my opinion dangerous. Feel free to ask question if you see me around somewhere or through Linkedin.

In my lab, I saw models without a refusal layer accept requests that a safety-aligned model refused. They did this without hesitation, extra warnings, or safety notes. Some of those requests were clearly criminal, not just another question to an AI. This is more than a change in a tone of voice. It is the difference between reaching a dead end and having a willing AI that is helping you out writing malware.

The results were different when the model had to operate tools through a longer workflow. I saw it struggle to format tool calls correctly, keep track of what happened across many steps, and understand returned errors. One incorrect parameter can break the whole chain in a way that a clumsy chat answer was not.

Both scenarios I have seen seem plausible. They explain why the human remains involved. The agent can give advice more reliably than it can carry out a complete workflow by itself. The danger is not only an agent acting alone. It is also a human operator working beside a tireless advisor that does not refuse.

For us as defenders, a model refusing a request is only one thing that can stop the workflow, and that safeguard can be removed. So we should assume that the model will not stop the attacker. A human is still needed to understand the environment, keep a longer workflow on track and steer where needed and decide what is useful or too risky. That explains why a human stays involved, but we should not rely on these limits to protect us.

Important: With the correct model, tools, lab configuration, and instructions, I have seen this type of setup perform much of the reconnaissance, discovery, tool selection, parameter adjustment, and initial validation on its own in a controlled scenario. Human interaction was still necessary when the agent lacked context, followed an incorrect assumption, became stuck.

I needed to step in when it lacked environmental context, followed an incorrect assumption, became stuck, or required an strategic go/no.

So the human has not disappeared from the attack. The role has moved from executing every command to supervising objectives, context, and risk.

Move from alert response to testing ideas

An alert tells you that a detection rule matched certain activity. It gives you a starting point, but not always the full story. A working theory helps you look beyond the alert. It asks what the attacker may be trying to achieve and which evidence would prove that idea right or wrong.

For example:

An actor may be using a compromised identity from an unmanaged endpoint to discover systems and prepare for lateral movement.

This working theory gives the analyst a direction. Instead of waiting for another alert, the analyst can look for evidence that backs it up or proves it wrong:

• Did the identity authenticate from a new IP address, device, location, or authentication pattern?
• Did the same identity appear in endpoint or remote logon telemetry?
• Did one process create an unusual volume of network connections?
• Did cloud audit activity begin shortly after the sign-in?
• Which privileged roles, applications, devices, systems, and data can be accessed through the identity or its current session?

An unmanaged endpoint creates an important visibility gap. Microsoft may still see authentication, cloud activity, application access, and identity anomalies. But Microsoft Defender for Endpoint cannot provide local process and device telemetry if the endpoint is not onboarded.

The analyst may clearly see what the identity or session did in Microsoft services but know little about what happened locally on the device. Missing telemetry does not mean that nothing happened.

In a good Microsoft security environment, much of the evidence may already be available. It can come from Microsoft Defender XDR, Microsoft Entra ID, Microsoft Defender for Endpoint, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps, and Microsoft Sentinel.

The incident and attack story show what has already been observed and connected. The analyst can use Advanced Hunting to find other activity around the affected identities, sessions, and systems.

Microsoft Security Exposure Management adds another useful view. Its attack paths show possible routes through identities, permissions, devices, vulnerabilities, cloud resources, and other relationships towards critical assets.

During an active incident, blast radius analysis can help the analyst explore how the attack could spread from an affected node. It can show which systems, identities, or relationships could bring the attacker closer to a high-value objective.

This does not tell you exactly what the attacker will do next. The agent may choose another route, lack the required capability, or follow a different objective. It does give the analyst a map of possible next steps, reachable critical assets, and important choke points that need attention.

The analyst now has three views:

1. What has already happened: The incident, attack story, alerts, and observed telemetry.
2. What may be happening outside the current incident: Other evidence found through Advanced Hunting and connected data.
3. What could happen next: Possible exposure paths and the blast radius towards critical assets.

From detection to prediction

All of this depends on coverage. Exposure paths, blast radius, and predictive shielding are built on asset relationships and critical asset classification, so an estate with unonboarded devices or unclassified critical assets produces an incomplete map. The visibility gap from an unmanaged endpoint does not just affect the investigation. It also weakens the prediction.

Microsoft is also moving from visibility towards automated prediction and protection. Predictive shielding, currently in preview, uses live attack activity and organisational exposure data to identify assets that may be at risk. It also estimates the paths an attacker is most likely to take.

Automatic attack disruption focuses on identifying and containing compromised assets during an attack. Predictive shielding aims to act one step earlier. It can apply targeted restrictions to vulnerable assets or limit possible attack paths before the attacker reaches the next target.

This does not mean that Defender knows exactly what the attacker or autonomous agent will do next. Its predictions use observed activity, previous attack patterns, threat intelligence, asset relationships, permissions, vulnerabilities, and the organisation’s structure. The attacker may still choose another route or follow a different objective.

It does show where defensive technology is going: from detecting what happened, to disrupting what is happening and protecting what may be targeted next.

This is the shift I believe we need. The analyst becomes an investigator, the SOC’s Sherlock Holmes. They test ideas and add the organisational context that technology cannot fully understand.

At the same time, automated defence can help connect the clues, identify routes, and sometimes close a door before the attacker reaches it.

This is where AI against AI starts to take shape: automated attack workflows meeting automated defence.

Update, 28 July 2026: While I was publishing this post, Microsoft announced Project Perception, an agentic security system built around what Microsoft calls “AI to defend against AI.” It brings together red team agents that find possible attack paths, blue team agents that investigate risk, and green team agents that take corrective action. These agents work in a continuous loop while humans remain in control.

This closely matches the direction described here: automated attack workflows on one side and defensive systems that can understand context and act on the other. Microsoft also makes the same limitation clear. These systems depend on visibility, available actions, security experience, and the models behind them. Project Perception enters public preview on 3 August 2026.

Certainly interesting times!

Think in objectives, attack paths, and evidence

Start every investigation with three fields:

Field	Question
Objective	What is the attacker trying to achieve?
Attack path	Which identities, devices, applications, and controls connect the attacker to that objective?
Evidence	Which telemetry would show whether each step happened?

The objective still matters even when the tool changes. An attacker trying to reach privileged cloud access may use phishing, token theft, session abuse, or a compromised endpoint. The evidence differs, but the objective and important identities remain recognisable.

For example, device code phishing shows how valid authentication can still lead to attacker-controlled access. A Token of Appreciation explains the token and claim concepts that help you understand that identity path.

The ideas you test must match how your own environment is built. Unified SIEM and XDR coverage recommendations can help you identify product gaps, but a coverage view cannot work through every route an autonomous agent may choose.

The defender mindset must match the attacker mindset

Autonomous agents do not care how your SOC queue is organised. They work towards an objective.

Defenders must do the same. Instead of asking only whether an alert is malicious, ask:

• What is the likely objective?
• Which systems could provide a route to it?
• Which identities, credentials, sessions, permissions, or trust relationships connect those systems?
• What changed after the first path failed?
• Where would an adaptive attacker go next?
• Which evidence contradicts my current explanation?

I am not saying alerts become unimportant. I am saying an alert should be the start of the investigation, not the end of the task.

Microsoft Defender XDR, Microsoft Sentinel, and Microsoft Entra ID remain important. They provide the identity, endpoint, email, cloud, and infrastructure context needed to piece together an attack path. The technology gives you evidence. The investigator must turn that evidence into an explanation.

Human interaction is still part of autonomy

What I observed in the lab also applies to how attackers may use these systems in practice. The human is still involved, but usually at different moments in the workflow.

The strongest setup combines machine speed with human decision-making:

• The agent repeats work, reviews the output, and suggests another path.
• The human provides context, checks assumptions, and controls risk.
• Technical boundaries prevent either side from exceeding the authorised scope.

Attackers can use this combination too. A human does not need to operate every tool when an agent can perform most of the workflow. The attacker only needs to interact when the agent is stuck, lacks context, or requires a strategic decision. That alone is enough to change the speed of an attack and how long it lasts, even when every individual tool runs at exactly the same speed as before.

Detect the functionality, not the tool name

We also need to rethink how we detect this activity. An AI client can discover and invoke tools through MCP. The model and orchestration logic then decide what to do next. Searching for the name of Nmap, Nikto, Nuclei, HexStrike, or any other framework is not a future proof detection strategy.

Tool name changes for example. New tools appear, existing tools are renamed, and the same functionality can be wrapped inside another process or script. An attacker can also replace one tool without changing the objective.

The underlying functionality is what matters:

• Discovering systems, ports, and services
• Enumerating users, applications, or resources
• Repeatedly testing authentication
• Executing discovery commands
• Moving from one system or identity to another
• Changing approach immediately after a failed action

These behaviours remain relevant when the tool name changes. For me, that is where detections need to focus. Focus on what the activity does, how the steps relate to each other, and which attacker objective they support.

Keep detection engineering separate and evidence-based

I am leaving specific detection logic for a separate post. I still want to research the telemetry, test the scenarios, understand normal behaviour, and validate the queries before I present them as practical guidance.

Frequently asked questions

Does autonomous AI replace a skilled attacker?

In my opinion, no. It compresses repetitive work, speeds up decisions, and reduces the knowledge needed for some tasks. A human still sets the objective, provides access, evaluates value, and accepts operational risk.

Why does an autonomous agent move to another machine?

It may decide that the newly discovered machine offers a route to the original objective. That can be a logical path pivot, but it becomes scope expansion when the system is outside the authorised boundary.

Summary

Autonomous AI attacks do not suddenly make our existing security controls useless. They reduce the time we have to connect weak signals before an attacker reaches the next objective.

The next generation of defenders must:

1. Test possible explanations instead of processing alerts in isolation.
2. Follow objectives and complete attack paths, including unexpected pivots.
3. Expect agents to adapt when a script or tool fails.
4. Recognise loops, goal drift, and scope expansion.
5. Understand where human guidance still influences autonomous operations.
6. Treat scope as an enforced security boundary, not just a prompt.
7. Detect underlying behaviour instead of relying on tool names.

For me, AI against AI looks like part of the future. I do not mean two chatbots directly fighting each other. I mean autonomous attack workflows meeting automated correlation, attack disruption, and predictive protection.

Humans will still set goals, add context, and make decisions about value and risk. But on both sides, more actions may happen before a human needs to step in.

AI does not need to complete every step perfectly to change the threat. If it can perform most of an attack sequence without the normal human pauses and ask for help only when it gets stuck, we need to think beyond the alert in front of us.