Security leaders keep debating whether AI will produce an entirely new class of cyberattack. The nearer change is quieter and already visible: AI has made a failed attack cheap to retry.

The routine version looks like this. An attacker lands on a low-privilege cloud account, and the first try at privilege escalation goes nowhere. That dead end used to cost hours of documentation reading, permission checks, and script debugging, and plenty of operators simply got stuck. With a model in the loop, the error gets explained, the script gets fixed, and a fresh enumeration path is under test within minutes.

No step in that sequence is a new capability. Together they strip time, skill, and cost out of the unglamorous middle of an intrusion, the research and troubleshooting that sit between intent and outcome.

What the threat reporting shows

The public record traces the arc. In early 2025, Google's Threat Intelligence Group found state-backed actors treating generative AI as a productivity tool: translation, scripting help, troubleshooting, research. By late 2025, the same team was writing about malware samples that phoned a model mid-execution and about a maturing underground market for illicit AI tools, while Anthropic disclosed shutting down an extortion operation that leaned on AI at nearly every stage, from reconnaissance and credential harvesting through to setting ransom demands. In May 2026, GTIG reported that cyber crime actors found a two-factor bypass in an open-source administration tool and built working exploits for it, and that based on the structure and content of those exploits it assessed with high confidence that an AI model supported both the discovery and the exploit development. GTIG worked with the affected vendor on disclosure and disrupted the activity, and its own assessment is that the counter-discovery may have prevented the exploit from being used.

That last distinction matters. Assessed AI assistance and a planned operation are not the same claim as confirmed deployment in the wild, and the difference tends to get lost once a finding like this starts circulating. Attribution is hard, prevalence is unclear, and none of these reports is a census of global activity. The direction is what counts, and the direction is toward AI sitting inside attacker workflows rather than beside them.

Provider guardrails deserve credit here. Safety classifiers and abuse disruption push the cost of misuse up, and the disruption cases above show the work paying off. A guardrail still lives outside the enterprise. An operator can poke at it until a reframed request slides through, move the job to an open-weight model, split one malicious task into a dozen innocent-looking ones, or wrap tooling around the model and route around the policy layer entirely. Friction of that kind slows misuse without ever becoming a security boundary, and an organization that treats provider policy as a boundary has substituted reassurance for defense.

Attacks run as loops

Textbooks draw the attack lifecycle as a line: reconnaissance, access, escalation, impact. A working attacker runs a loop instead. Watch the environment, form a guess, try something, read what came back, adjust the guess. AI compresses the time between those steps. A novice stays in the game longer. An expert runs more experiments per day.

Defense is supposed to loop the same way. A signal fires, context gets gathered, a hypothesis forms, scope gets validated, an action lands, and the outcome feeds back into detection. In practice, queues and handoffs interrupt that loop at every joint. The alert idles unassigned. The identity picture lives in a different console. A telemetry gap turns into a backlog item, and the explanation behind a closed false positive dies in the ticket instead of reaching whoever owns the rule.

The environment answers the attacker's experiment in seconds. The defender's answer arrives whenever the ticket gets picked up.

Mean time to acknowledge and mean time to remediate hide this. An alert can be acknowledged in minutes and then spend hours being reconstructed: finding the right identity, confirming whether the endpoint was managed, restating the incident to each new owner along the approval path. That reconstruction interval is decision latency, and few SOCs measure it at all.

Five things every handoff drops

The work is commonly described in five functions: threat intelligence, threat hunting, detection engineering, investigation, and remediation. That is a useful lens rather than a universal org chart. In a small team, one person wears several of those hats. In a large enterprise they spread across the SOC, identity, endpoint, cloud, and business teams, and an MDR provider may own the investigation without owning the authority to contain.

The functions are rarely the problem. The transfer between them is. Threat intelligence understands why a technique matters. Threat hunting can say where it would surface. Detection engineering carries the rule's unstated assumptions. The investigator holds the evidence trail that settled the verdict. The team that acts can name the actions that would break the business. Each transfer squeezes that knowledge into an indicator, an alert, or a ticket, and the squeeze is lossy.

This is the lossy handshake, laid out in a recent three-part series, and the inventory of what a handoff has to carry is worth keeping whole:

• Entity identity: the actual user, device, workload, or business process at the center of the case
• Evidence and provenance: the observations behind the conclusion, their origin, and their timestamps
• Hypothesis and confidence: the leading explanation, the alternatives still standing, and the certainty behind the choice
• Telemetry sufficiency: which claims the available data can support, which it cannot, and which absent source caps the confidence
• Decision ownership and constraints: who holds authority to act, which approvals stand in the way, and what the action might break

Lose the first and two teams end up investigating the same user under different names. Lose the last and a correct recommendation sits in a queue while the intrusion ages. Evidence without provenance is decoration.

One incident, five vantage points

A worked example from that series makes the loss visible in motion.

A finance employee signs in from a hosting provider the account has never used. MFA is satisfied. Inside 10 minutes, a new mailbox rule starts forwarding to an external address, and the account begins pulling files from a finance SharePoint site in a pattern it has never shown. No single event proves compromise. The sequence deserves attention.

Threat intelligence has been tracking a wave of adversary-in-the-middle phishing built to steal authenticated sessions, which is why an MFA success cannot clear the account on its own. That context ships onward as a short advisory with indicators and technique IDs. The behavioral sequence, and the local conditions under which it matters, stay behind.

The hunter translates the advisory into queries and learns two things the advisory never asked about: device-compliance data covers only part of the environment, and SharePoint audit records show up hours late. The hunt forwards a list of suspicious accounts. The coverage caveats stay behind.

Detection engineering builds logic that fires only when the unfamiliar network, the MFA success, and the new forwarding rule cluster inside a short window, knowing full well the rule has no device-state visibility for a slice of the user base. What goes out the door is a severity level and a description field. The assumptions and the expected false-positive patterns stay behind.

The alert reaches an analyst mid-shift, showing a sign-in and a mailbox rule with none of the reasoning that connected them. The analyst rebuilds the picture across four consoles: identity, email security, the SIEM, the asset inventory. Two explanations stay live. The user could be traveling or trying a legitimate new service, which accounts for the unfamiliar network but not for an external forwarding rule and an access pattern the account has never shown. Or an authenticated session was stolen, which accounts for the whole sequence. The second fits the evidence, and endpoint scope stays unknown, because the device is unmanaged and there is no process or network telemetry to check. The case closes with a recommendation to disable the account. The competing explanation, the confidence level, and the endpoint nobody could examine stay behind.

A ticket lands with the identity team: disable this account. The team knows something the SOC never saw: the account is mid-payroll-run, and a blunt disable interrupts a time-sensitive business process. That does not give finance a veto over containment. It means the containment decision and the continuity decision have to be made by people who can see both. Revoking the live sessions and stripping the forwarding rule are the low-risk moves. Suspending the account sits under incident policy and belongs to whoever holds that authority. Moving the payroll run depends on whether a backup operator exists and is free to take it. Reopening access waits on credential reset, MFA re-enrollment, and a managed device, and somebody still has to confirm the actions took effect.

Every function did its job. The system still forced each one to rebuild the incident from scratch, and it handed the one team holding business context a one-line task instead of a decision.

The unicorn analyst is a symptom

When organizations feel this loss, the reflex is a job posting: someone fluent in identity, endpoint, cloud, email, malware analysis, detection logic, and executive communication, assigned to the alert queue. The mythical unicorn analyst is not a talent strategy. It is a workaround for missing system state.

The senior analyst succeeds by knowing things no dashboard shows. Which log source lies. Which service account must never be touched. Which application owner picks up at 2 a.m. The company's real runbook lives in that one head, and it resigns when the person does. A meaningful share of analyst burnout is exactly this, re-deriving what the organization already knew and failed to keep.

The most expensive loss lands after the incident closes. Say the truth turns out benign: the employee was traveling, and the forwarding rule had been approved. The rule's owner needs the evidence that flipped the verdict. The telemetry owner needs to hear that device coverage came up partial. What the system keeps is a closure reason. The verdict survives; the lesson evaporates. That is why a noisy rule stays noisy for years, and why each new analyst rediscovers the same blind spot on their own shift.

What a stateful SOC remembers

The fix is architectural. The series lands on a specific prescription: the SOC has to become stateful. SOCs are not amnesiac. They retain evidence and case histories, often for years. What tends not to survive a handoff is the reasoning around that evidence, the uncertainty that qualified it, and the constraints on who could act. Those stay buried in whichever system produced them instead of informing the next decision. The alternative is shared operational memory, five kinds of state that every workflow reads and writes:

• Environmental state: the identities, devices, workloads, and business services that exist, their relationships, their owners, and which of them are privileged, exposed, or unmanaged
• Evidence state: each observation, its source, its timing, and a path back to the original event
• Decision state: the current hypothesis, the alternatives weighed, the evidence for and against, and what new evidence would change the answer
• Control state: the actions on the table, the approvals they require, the owner of the affected system, and anything that has to be preserved before containment
• Learning state: the corrections analysts made, the assumptions that failed, whether the fix held, and what should change in a threat hunt, rule, or playbook as a result

A shared model on those lines lets the SIEM, the EDR, the identity platform, and the case system contribute to one decision. None of those tools gets replaced by it.

The hardest discipline in that list is treating "unknown" as a legitimate answer. When endpoint telemetry is missing because a device is unmanaged, a weak system files the finding as "No malicious process activity was observed." The sentence is technically true and operationally misleading. A stateful system records that the endpoint could not be checked at all, cuts its stated confidence in endpoint scope, and routes the coverage gap to whoever owns device management. The gap becomes part of the case rather than vanishing into a reassuring sentence.

Agents need jobs and boundaries

Agentic AI enters this picture last, and deliberately so, because bolting agents onto a stateless SOC gives a broken operating model more speed. Bounded workflows working from shared memory are a different proposition. Threat intelligence decides whether an outside threat matters locally and shows its reasons. Threat hunting reports the populations it covered next to the ones it could not see. Detection checks that the environment can feed a rule the data it needs before that rule goes live. Investigation packages timeline, competing explanations, evidence, and confidence as a single object. Remediation maps the decision onto available actions, owners, and approvals.

Authority stays separate from confidence. The framework distinguishes four modes for any action: observe and gather further evidence; put a recommended action and its reasoning in front of a human who holds the authority; execute only after explicit approval; or execute automatically, and only where policy, confidence, entity type, and potential-impact conditions are all satisfied. The mode lives in control state, versioned and auditable. A confident-sounding narrative earns an agent exactly nothing in execution rights.

The same caution governs learning. A single false-positive verdict from a single analyst is thin evidence for changing production detection logic. Analysts make mistakes, and some cases are simply exceptions. A stateful system captures the evidence behind the correction, gathers similar cases, drafts a proposed change, and routes the proposal to the owner of the rule. That review step is what separates learning from self-corruption.

The analyst's job moves up the stack

The evidence-assembly half of the investigation is already done when the analyst arrives. The analyst's first move is to challenge the structured case: whether the hypothesis holds together, whether a competing explanation got missed, whether the proposed action is proportionate to the evidence, and what the business context changes.

Measurement moves the same direction. Counting completed agent tasks flatters the software. Four questions do the job better: does the analyst open a case that already contains the context, does the case record what could not be seen, does a corrected verdict reach the rule's owner while the correction still matters, and did every automated action stay inside policy with an audit trail behind it. Revised federal guidance points the same way: NIST's updated incident response recommendations in SP 800-61r3 treat response as part of an organization's wider risk management rather than a self-contained SOC activity.

The attack loop is tightening on a curve, and waiting for full autonomy to arrive is a slow way to concede it. The starting points are unglamorous: measure where the same context keeps getting reassembled by hand, record what an investigation could not see next to what it concluded, decide who owns each action and who approves it while things are calm, and route what the investigation learned back into threat hunting and detection.

The finance employee's account gets suspended either way. In one SOC, the lesson evaporates with the closure reason and the payroll problem surfaces after the fact. In the stateful one, the people who act can see what the investigation could not, the coverage gap has an owner, and the next analyst inherits a memory instead of a queue.

Note: This article is based on a three-part series by Jonathan Waknin, Director of Solution Architects/CISO at Conifers.ai.