Attackers Are Moving at Machine Speed. Is Your Network Edge Secure?

From AI-Assisted to Agentic

For the past few years, most reporting on adversarial AI described attackers using it as an assistant: drafting phishing lures, translating content, debugging scripts, and researching targets. Useful to attackers, but not a change in how operations are structured.

GTIG's Q2 2026 report, From Prompting to Autonomy, describes the next step. According to GTIG, threat actors are moving "from basic prompting to agentic AI workflows and AI-enabled automation."

When the Attack Traffic Comes from Legitimate IPs

The clearest example in the report comes from a Mandiant investigation. A suspected financially motivated actor compromised an organization's cloud infrastructure and deployed a multi-agent attack framework on it. Using an AI coding chatbot, a prompt, and a set of agent instructions written as markdown playbooks, the actor planned, built, and executed a mass credential-harvesting campaign in less than six hours, compromising thousands of third-party credentials. GTIG reports that the agents managed the vulnerability scanning pipeline, performed real-time troubleshooting, and executed IP rotation logic without manual intervention. Because the operation ran from the victim's cloud environment, its traffic originated from legitimate IP addresses.

The report documents other examples as well:

• A PRC-nexus group attempting to design an automated penetration-testing framework that observes a target, reasons about next steps, and executes them.
• Actors using generative AI to rapidly prototype and iterate on exploit components following public disclosures, including LLM-generated exploit artifacts for a recently patched Firefox n-day.
• Distillation campaigns exceeding 100 million prompts, run through proxy infrastructure and rotated across thousands of compromised credentials and fraudulent accounts.

GTIG is also clear about the limits. It notes that recent disclosures show frontier models can autonomously identify zero-days and execute intrusions, but that it "has not yet observed threat actors deploying fully autonomous pipelines against targets in the wild."

That caveat matters. The report does not describe fully autonomous attacks. It describes AI taking on more of the work between the stages of an attack.

The Real Shift Is Speed

In many traditional operations, transitions between attack stages still depend on human review or intervention. An operator reviews scan results, selects a target, adapts an exploit, checks whether it worked, fixes what broke, and moves on. Each of those handoffs takes time, and much of the time between disclosure and impact is spent there.

Agentic workflows remove many of those pauses. GTIG notes that the six-hour campaign significantly reduced human-in-the-loop latency. The agents did not need to be more capable than a skilled operator. They only needed to avoid waiting between steps.

From our perspective, this compresses the attack lifecycle at several points:

• Discovery of weaponization. AI helps turn a public disclosure into working exploit code faster.
• Scanning to targeting. Automated pipelines can identify and prioritize exposed assets continuously rather than in batches.
• Failure to retry. When a request is blocked, an agent can troubleshoot, change infrastructure, and try again without waiting for someone to notice.

Looking ahead,and going beyond what GTIG itself claims, we expect these compressions to compound. As agentic tooling becomes cheaper and more reliable, the time between "a vulnerability is known" and "that vulnerability is being exploited against my applications" is likely to keep shrinking for more organizations, not only high-profile targets.

The Network Edge Still Moves at Human Speed

Compare that with how most organizations manage the controls in front of their applications.

A typical enterprise network edge includes more than one WAF and more than one CDN, along with bot controls, rate limiting, DDoS protection, and API security. These often span AWS WAF, Cloudflare, Akamai, F5, Fastly, Azure WAF, and others, added over time by different business units, acquisitions, or cloud environments. Each vendor has its own console, rule language, logging format, and policy model. No single team usually owns all of it.

In that environment, basic questions still require manual work to answer:

• Which applications sit behind which controls?
• Is the same rule deployed consistently across every vendor, or only some?
• Which rules are blocking, which are only logging, and which have quietly changed behavior?
• Which rules are outdated, duplicated, or no longer protecting anything?

None of this is new. Edge teams have dealt with fragmentation for years. What is new is how little time an attacker may now leave them to deal with it.

When Exploitation Takes Hours, Understanding Coverage Cannot Take Days

The shortening attack timeline changes the value of coverage assurance.

Consider a newly disclosed vulnerability affecting an internet-facing application. The immediate questions are operational: Is the application affected? Is the vulnerable path reachable? Does an existing WAF rule provide coverage? Is that rule deployed across the relevant environments? If native coverage is unavailable, which existing network edge control can mitigate the exposure?

Virtual Patching 

GTIG's observations show why these questions increasingly need to be answered quickly. In one campaign, a threat actor used an AI coding chatbot, a prompt, and a set of agent instructions to build and execute a mass credential-harvesting operation in less than six hours. The workflow autonomously managed vulnerability scanning, performed real-time troubleshooting, and rotated IP addresses without manual intervention. GTIG notes that this significantly reduced human-in-the-loop latency.

This is the more immediate security implication of agentic attacks: the time available to understand exposure and respond is shrinking, even when the attack itself is not fully autonomous.

This is where Virtual Patching becomes particularly important. A network control can provide temporary mitigation while the underlying application is being fixed - so that protection and remediation do not have to happen sequentially - but a virtual patch is only useful if the organization understands where it applies, what it covers, what traffic it may affect, and whether it remains necessary after remediation.

Huskeys describes the same principle in its NESM model: virtual patches without assessment and management can become temporary fixes that mask the underlying exposure.

The same applies to policy changes more broadly. A mitigation rule should not simply be pushed into production because it exists. It needs to be evaluated against the application and traffic it will affect, tested where appropriate, versioned, and deployed safely.

As attack timelines shrink, coverage assurance and policy management become part of the response itself.

The Network Edge Needs a Management Layer

The network edge has accumulated controls for years: CDNs, WAFs, bot mitigation, edge services, cloud firewalls, API security, rate limiting, DDoS protection, and other technologies. The problem is that these layers were not designed to be managed as one system.

This is the problem Network Edge Security Management (NESM) addresses.

NESM is the discipline - and the layer - that finally manages the stack every company runs but no one owns: from legacy CDNs, WAFs and edge services to AI-driven traffic sources and applications, making the network edge visible, measurable, and orchestrated as one system.

The goal is not to replace the controls already in place. It is to provide the management layer needed to understand what is happening across the edge, determine what is actually working, and coordinate the changes required to improve the outcome.

That creates a continuous Assess → Recommend → Orchestrate loop rather than a collection of disconnected manual tasks.

From Manual Security Management to an Adaptive Edge

Huskeys applies this model across the network edge through three connected stages.

Assess

Understand what is exposed, where coverage exists, where gaps remain, and how existing policies are performing.

Recommend

Translate that understanding into actionable policy, including coverage changes and temporary mitigations such as Virtual Patching.

Orchestrate

Apply and manage those changes across the relevant controls, with testing, versioning, deployment, and rollback built into the policy lifecycle.

The objective is not automation for its own sake. It is removing the manual bottlenecks between understanding a security problem and acting on it.

Machine-Speed Attackers, Managed at Machine Speed

GTIG's research does not show that every attack is becoming fully autonomous. It shows that adversaries are increasingly integrating AI into multiple stages of their operations and using agentic workflows to automate complex, multi-step tasks. GTIG specifically observed AI-enabled automation across reconnaissance, vulnerability research, credential harvesting, exploitation support, and post-exploitation activity.

The implication for network edge security is straightforward: if the attack lifecycle can increasingly operate at machine speed, the processes used to understand exposure, validate coverage, and manage the controls protecting applications cannot remain predominantly manual.

The network edge already contains the enforcement points. What is missing is the ability to manage them as one system: continuously assessing what is happening and what is working, recommending what needs to change, and orchestrating those changes across the infrastructure already in place.

The network edge already contains the enforcement points. What is missing is the ability to manage them at the speed of the environment they protect.

Learn more: Book a Demo