When the Attacker Is an Agent, Not a Person

A SIEM fires an alert. It lands in a queue. An analyst picks it up between two other tickets, pulls the raw logs, checks a couple of related hosts, and decides whether to escalate. On a good day that whole cycle takes twenty minutes. On a bad day, with a queue backed up and an analyst juggling five things, it takes an hour or more.

That cycle was built for an adversary who also worked at human speed, someone typing commands, second-guessing themselves, pausing to research the next step. A growing share of intrusions no longer look like that. An operator sets an objective and an agentic tool chains reconnaissance, exploitation, credential access, and lateral movement with little or no human input along the way. The attacker is not waiting on you to notice. It is not waiting on anything.

This is not a call to buy an AI SOC platform and call it solved. It is a case for rethinking what has to happen automatically, what still needs a human, and how you decide the difference before an incident is already underway.

Why the old cadence stops working

Security operations centers were designed around a reasonable assumption. Attackers are slower than defenders, most of the time, because attackers are human. Recon takes days. Access brokering takes longer. An intruder sitting inside a network usually pauses to figure out what they have, what is valuable, and how to move without tripping something. That pause is where detection, triage, and containment have historically done their work.

Agentic tooling removes the pause. Vendors and researchers across the industry, including CrowdStrike's annual threat reporting, Elastic Security Labs, Red Canary, and Torq, have independently converged on the same observation over the past year. AI systems are executing more of the intrusion chain end to end, with a human directing at the objective level rather than the command level. The Carnegie Endowment has written about the governance implications of autonomous cyber operations at the nation state level, which suggests this is not a vendor talking point invented to sell a product.

The practical consequence is that the gap between initial access and meaningful impact, the window your SOC has historically used to detect, decide, and contain, has compressed. A workflow that assumes a human reads every alert, opens a ticket, and works a decision tree in order cannot react inside that window. It was never designed to. The fix is not making analysts type faster. It is redesigning how much of the response is decided in advance.

What actually has to change

Four things move together here, and none of them work in isolation.

Detection has to move from events to chains. A single suspicious login or an unusual process spawn is not the signal that matters anymore. The signal is the pattern. Recon followed immediately by credential access followed immediately by lateral movement, compressed into a timeframe no legitimate operator would produce. Detection engineering has to build and tune behavioral chain logic, not just tune individual rules for false positive rates. If your detections still key off isolated indicators, you will see the fifth step of the chain, if you see anything, well after the third and fourth have already happened.

Triage cannot be a queue anymore. It has to be a routing decision. Every alert getting the same human review, in order, at the same depth, was already a losing model before agentic attackers showed up. Now it is untenable. Alerts need to be classified by confidence and consequence at ingestion, not by an analyst's judgment twenty minutes later. High confidence, well understood patterns route to automated response. Ambiguous or high impact ones route to a human, immediately, not after they clear a backlog.

Automation has to be pre-authorized, not improvised. The distinction the industry has settled on is human in the loop versus human on the loop. Human in the loop means an analyst approves each step before it executes, which reintroduces the latency problem you are trying to remove. Human on the loop means the system acts within a defined, narrow scope on its own, and a human supervises, intervenes, and can reverse. That only works if the scope was defined ahead of time, with real thought given to which actions are reversible, isolating an endpoint or disabling a session, and which are not, deleting data, notifying a regulator, or taking a production system offline.

Guardrails have to be built into the agent's own permissions, not just the workflow around it. If you are running any autonomous or semi-autonomous response tooling, including AI copilots inside your SOAR platform, that tooling needs its own scoped identity, its own allowlisted set of actions, and logging that shows the reasoning behind every action it took, not just the action itself. An agent that can read an alert and also write to your identity provider is one compromised prompt away from being the incident, not the response to one.

What this looks like operationally

In practice this means your playbooks stop being documents an analyst reads during an incident and start being configuration a system executes before one. A playbook for a credential theft into lateral movement chain should specify, in advance, exactly which conditions trigger automatic account disablement and host isolation, at what confidence threshold, and which conditions instead page a human with the evidence already assembled. That decision should never be made live, under pressure, at 2 a.m.

Detection engineering and SOC operations have to work from the same chain model. If detection is still organized around individual attack techniques in isolation, and response is organized around individual alert types, the two will never line up cleanly enough to automate the handoff between them. Build the chain detections first, then build the response scope around what those chains actually look like in your environment.

Expand automated authority gradually, and prove it. Start with actions that are cheap to reverse and easy to validate, then widen scope as the false positive rate on a given chain detection stays low across real incidents, not across a lab test. Command risk policy, not enthusiasm, should decide when an agent gets more rope.

Where teams get this wrong

The most common mistake is buying autonomy before earning it. Teams stand up an AI driven SOAR workflow, grant it broad response permissions on day one, and then discover during the first false positive that it locked out an executive or quarantined a production database host. Confidence in automation has to be built the same way trust in a junior analyst is built, incrementally, with review.

The second mistake is treating this as a tooling purchase instead of a detection and playbook problem. A platform marketed as an agentic SOC does not know your environment's crown jewels, your change windows, or which systems can be isolated without taking down a customer facing service. That context has to be engineered in, and it takes the same disciplined work detection engineering has always required.

The third is leaving human escalation criteria vague. Escalate if it looks serious is not a guardrail. It is a guess made under pressure by whoever is on call.

Where this leaves you

The attacker's tempo is no longer bounded by human patience, and assuming your current SOC processes will scale to meet it is wishful thinking. The organizations that hold up are the ones that decide, in calm conditions, what gets to happen automatically, what gets a human, and how much authority automation earns over time. That decision work is not glamorous. It is detection engineering, playbook design, and access scoping, done before the next incident instead of during it. That is the whole job now.