Two major AI providers published threat research this week describing a similar change in cyber operations. Attackers are moving beyond using artificial intelligence to answer questions, translate phishing messages, or write isolated pieces of code. They are beginning to use AI to coordinate several connected parts of an attack.
Google reported that an attacker compromised a cloud resource and then planned, built, and executed a mass credential-harvesting campaign in less than six hours. The system managed vulnerability scanning, troubleshooting, and IP-address rotation with limited manual work. Thousands of third-party credentials were compromised.
Anthropic reported that AI had supported direct execution or orchestration in a majority of the cyber operations included in its latest case studies. Individual operators used AI to conduct work that previously would have required teams with specialized skills.
These reports do not establish that fully autonomous cyberattacks have become common. Google stated that it has not observed fully autonomous attack pipelines operating against targets in the wild. Anthropic also cautioned that its published cases were selected for being notable or novel and should not be treated as typical activity.
The evidence still supports an important conclusion: AI is changing the economics of an attack before it completely changes the techniques.
Familiar attacks become more dangerous when their labor cost falls
Many of the reported techniques are well known. Attackers still exploit exposed services, steal credentials, send phishing messages, use unpatched systems, move between connected environments, and extract data.
AI makes those activities easier to coordinate and repeat. It can assist with reconnaissance, create or adjust code, troubleshoot failed commands, process stolen information, and manage several targets at once. An operator does not need to possess every skill personally or hand each task to another specialist.
This reduces three constraints that once limited an attack. Fewer people may be required to operate a campaign. AI can help less-experienced operators complete more advanced tasks. And work can continue across several tasks or targets with less delay between steps.
Anthropic concluded that technical sophistication is becoming a less reliable way to judge who is behind an operation. In its reported cases, a hacktivist, financially motivated actors, and a suspected state espionage operator used similar AI-supported methods. Anthropic also described breaches completed in two to three hours and multiple victims handled in parallel.
Google reported a related progression. Its researchers observed attackers moving from basic prompts toward agentic AI: systems that can plan and execute connected tasks using software tools with limited human input. Google found these systems being used to manage scanning, resolve errors, and support credential harvesting.
The risk is therefore broader than a new group of highly capable attackers. Existing adversaries can do more work, make more attempts, and recover from mistakes faster.
The defender's decision window is getting shorter
Cybersecurity programs often measure control coverage: how many devices are monitored, how many vulnerabilities are scanned, or how many alerts are generated. Those measurements remain useful, but they do not answer the most important operating question: can the organization detect and contain harmful activity before the attacker reaches systems that matter?
CrowdStrike reported in February that the average time between initial access and an attacker's first lateral movement fell to 29 minutes during 2025. Lateral movement means moving from the first compromised account or system toward other, often more valuable, resources. The fastest observed case took 27 seconds, while data extraction began within four minutes in another incident.
AI is changing the economics of an attack before it completely changes the techniques.
Those figures come from CrowdStrike's own incident visibility and should not be treated as universal performance benchmarks. They still show why a response process measured in hours can be too slow for some attacks.
The problem is rarely limited to detection technology. A security tool may identify suspicious activity quickly while the organization takes much longer to decide what to do. An analyst may need to confirm the event, locate the system owner, determine the business effect, request permission, and coordinate containment across security, cloud, identity, legal, and application teams. Every handoff consumes part of the defender's remaining time.
Use a response-time budget
Senior technology leaders need a shared way to examine this problem without reducing it to a technical dashboard. A response-time budget defines the maximum acceptable time for four connected intervals: exposure to detection, detection to decision, decision to containment, and containment to recovery.
The budget should be established for a specific business service, not the enterprise in general. A payroll system, customer-facing platform, software-development environment, and AI research repository do not have the same risk or acceptable interruption.
The useful unit is also actual elapsed time. A policy that says an incident must be escalated “promptly” cannot be tested. A target of ten minutes from a high-confidence identity alert to token revocation can.
This approach exposes operating weaknesses that a technology inventory may miss. Detection may be fast while approval is slow. Containment may work for employee devices but fail for software agents or cloud services. Recovery plans may restore an application without confirming whether API credentials, model files, source code, prompts, or data pipelines were compromised.
Protect the AI environment as part of the enterprise attack surface
The same research shows that AI is both an attacker's tool and an enterprise asset under attack.
Google reported attempts to steal proprietary models, source code, prompts, API credentials, and cloud computing capacity. It also observed criminals targeting configuration files used by AI coding assistants because those files can contain plaintext API keys or custom model-routing information. In one incident, an exposed GitHub access token was used to enter a cloud environment and deploy unauthorized AI infrastructure.
This means AI security cannot be confined to reviewing model outputs for bias or unsafe content. The surrounding environment includes identities, developer tools, source repositories, third-party packages, model connections, cloud resources, data access, and automation privileges.
An AI agent with access to email, code, customer data, or cloud administration should be treated as an operational identity. Its permissions should be limited to the work it needs to perform. Its credentials should be short-lived where practical. Its actions should be logged. The organization should be able to suspend the agent or revoke its access without taking down unrelated operations.
The Google findings also connect AI-assisted development with software supply-chain risk. Faster code generation can increase the number of dependencies entering an environment while reducing the time available for review. Attackers are exploiting that intersection through malicious packages, compromised development workflows, and attempts to deceive AI coding and security tools.
The executive implication is clear: accelerating software production without redesigning verification and response simply transfers time from development to risk.
Pre-authorize the actions that cannot wait for a meeting
Technology can automate detection, but it cannot repair an unclear decision model. Leaders should determine in advance which actions security teams and systems may take when confidence and potential harm meet defined thresholds.
Those actions might include revoking or rotating a compromised token, suspending a non-human identity, isolating an endpoint or cloud workload, blocking external data transfer, freezing a suspicious automation, limiting access to a critical repository, or moving an essential service into a restricted operating mode.
The action should be proportionate and, where possible, reversible. An automated system should not be given unlimited authority simply because attackers are moving faster. The goal is to pre-authorize a narrow response when waiting would create greater risk.
Each critical service should have an identified business owner, technical owner, security owner, and recovery authority. When those roles are unclear, a serious incident becomes an organizational search problem at the worst possible time.
Test the operating model, not just the technology
A tabletop exercise often asks what participants would do during a hypothetical incident. That can reveal gaps in policy, but it does not prove that the organization can act within its response-time budget.
A stronger test uses a realistic signal and measures every interval. When was the activity detected? Who received the alert? When was a decision made? Could the team disable the relevant identity? Was the business owner reachable? Did containment create another operational failure? Could the system be restored using trusted credentials and software?
The exercise should include AI assets when they support important operations. Teams need to know how they would respond if an agent's credentials were stolen, an AI coding tool introduced a malicious dependency, a model connection was redirected, or unauthorized workloads began consuming cloud capacity.
The result should be a measured operating record, not merely a completed exercise.
The executive decision
Senior technology leaders do not need to assume that every attacker now operates at machine speed. The current evidence does not support that conclusion. They should assume that familiar attacks can be attempted faster, by smaller groups, and across more targets.
The LXSGRP recommendation is to establish and test a response-time budget for each critical business service, including the AI systems, identities, and development tools connected to it. Where the required response is faster than the current approval process, leaders should pre-authorize narrow, reversible containment actions and assign clear decision rights.
The central question is no longer whether the organization owns enough security tools. It is whether the full operating system, from signal to decision to containment, can act before the remaining window closes.