Adversarial AI Is Already Inside Your Network

By MixMode Threat Research / Oct 07, 2026
MixMode Threat Research

MixMode Threat Research is a dedicated contributor to MixMode.ai’s blog, offering insights into the latest advancements and trends in cybersecurity. Their posts analyze emerging threats and deliver actionable intelligence for proactive digital defense.

From autonomous attackers to shadow AI and AI-enabled applications, security teams need a new way to detect what is operating inside their environments.

AI has changed the threat landscape faster than most security controls have been able to adapt.

Attackers are already using AI agents to perform reconnaissance, discover vulnerabilities, write exploits, harvest credentials, and move laterally at machine speed. In late 2025, Anthropic documented GTG-1002, a cyber espionage campaign in which AI was used to autonomously execute much of the attack lifecycle, including reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting, and data analysis.

Malware is evolving too. Google Threat Intelligence Group documented PROMPTFLUX and PROMPTSTEAL, malware families that query LLMs during execution to dynamically generate or modify malicious code and commands. Criminal AI tooling is also becoming increasingly accessible.

But malicious AI is only part of the problem.

The AI operating inside your environment may also be coming from your own employees, personal AI accounts, coding agents, AI browsers, local models, or even applications your organization has already approved.

That creates a much bigger question for security teams:

Do you actually know which AI is operating inside your network, what it has access to, and whether it is behaving as expected?

A More Useful Way to Think About Adversarial AI

Adversarial AI is typically associated with attackers: AI-generated malware, malicious models, deepfake phishing, or jailbroken systems.

But from a network security perspective, intent isn't always visible. Behavior is.

Rather than treating every unsanctioned AI tool as inherently adversarial, security teams need to consider the risk created when AI operates maliciously or outside the controls established to govern it.

That means looking for AI that lacks an attributable enterprise identity, operates outside an approved path, or exhibits behavior that falls outside its expected scope.

That could include an attacker's autonomous agent. But it could also include an employee using a personal AI account, a coding agent connected through a personal API key, an unapproved AI browser, or an AI capability quietly introduced through software your organization already uses.

The employee using that AI may have no malicious intent at all. The label describes the security risk created by the AI's operation, not the intent of the person using it. An AI tool can inherit an employee's access while operating outside the controls the organization established to govern that access.

The AI Risk You Approved May Not Be the AI Risk You Have Today

Enterprise security teams spend enormous effort reviewing vendors, negotiating contracts, establishing approved applications, and defining acceptable AI use.

The problem is that AI environments don't stay still.

Vendor terms can change. Privacy settings can change. New models can fall outside previously negotiated protections. Employees can access the same AI platform through personal accounts governed by entirely different terms.

And approved applications can introduce new AI capabilities, model providers, SDKs, and subprocessors through ordinary product updates.

That means an organization can approve one risk profile and unknowingly operate under another months later.

This is increasingly a fourth-party problem. Your organization approves a vendor. That vendor introduces an AI provider. The provider may operate under terms your organization never reviewed, and that relationship can change with a product release.

The application is still on your approved list. Its behavior isn't necessarily the same.

Why Traditional Security Controls Struggle With AI

Most existing security controls weren't designed for this environment.

Blocklists assume malicious destinations can be identified and cataloged in advance. But the AI ecosystem now spans dozens of major inference providers, countless self-hosted and regional model endpoints, and tens of thousands of MCP servers, many running on the same shared cloud infrastructure as legitimate business traffic. New endpoints and services can appear quickly, making static lists difficult to maintain.

Allowlists assume a reputable destination means safe traffic. But legitimate AI services can also be abused by attackers. Microsoft's SesameOp backdoor, disclosed in 2025, used the OpenAI Assistants API as a command-and-control channel, demonstrating how trusted AI infrastructure can become part of malicious activity.

Signature-based detection assumes malicious code remains relatively stable. AI-enabled malware can instead generate or modify code at runtime. Google GTIG's research into PROMPTFLUX and PROMPTSTEAL demonstrates how malware can query LLMs during execution to modify code or generate commands on demand.

DLP and CASB tools can provide important visibility into traffic routed through their inspection points, including TLS traffic when configured for inspection. But they have other limitations in an agentic AI environment. Local models and local MCP servers may never cross the proxy at all, while model routers can obscure which underlying provider ultimately processes a request. Network monitoring may not see a purely local AI interaction either, but it can reveal the downstream effects when that activity results in new network connections, lateral movement, unusual data flows, or other changes in network behavior.

And periodic software audits tell you what was installed when the audit occurred. They don't necessarily tell you what is acting right now, with whose credentials, and what it is doing.

The common problem is simple:

Traditional controls focus heavily on where traffic is going and what something claims to be. AI can change both. What it cannot hide as easily is how its activity changes the behavior of the network around it.

Shift the Question From "What Is It?" to "How Is It Behaving?"

Instead of trying to maintain an exhaustive inventory of every AI provider, model, agent, and tool, security teams can anchor detection around three properties of authorized AI:

Identity: Is it operating under a registered, attributable enterprise identity?

Path: Is it reaching AI services through an approved, monitored gateway?

Behavior: Is it acting within the scope for which it was approved?

Security teams can then look for systems that behave like AI agents but don't meet one or more of those requirements.

Behavioral indicators can include patterns such as an unexpected process communicating with an AI service, repeated AI-service connections followed by bursts of internal activity, or AI-related traffic bypassing the organization's sanctioned gateway.

These patterns matter because they don't depend on knowing every provider in advance.

From Finding AI After the Fact to Seeing It While It Happens

Historical threat hunting still has value. Security teams can examine DNS, TLS metadata, and flow data to identify exposed model servers, determine which hosts are communicating with AI services, identify hosts reaching consumer AI endpoints rather than approved enterprise ones, and search for network patterns consistent with agent-like activity.

But adversarial AI operates at machine speed.

A weekly or quarterly review can tell you what happened. It can't necessarily give you the opportunity to respond while it is happening.

That changes the detection question from:

"Is this destination on our list?"

to:

"Is this behavior different from what normally happens in our environment?"

A host that has never communicated with an LLM service suddenly opens the long-lived streaming sessions typical of LLM APIs.

AI-service connections are followed by unexpected lateral connections to internal systems.

A previously unseen destination suddenly begins receiving an unusual volume or pattern of outbound data.

Those signals can reveal something important even when the provider, tool, or infrastructure has never appeared on a threat list before.

How MixMode Detects What Lists and Signatures Miss

MixMode monitors network flows in near real time and learns autonomously how an environment normally behaves.

MixMode's contextually aware AI builds an understanding of normal network behavior and reasons about new activity within that context. Rather than depending on static blocklists or signatures, MixMode uses dynamical-systems modeling to identify anomalous and never-before-seen behavior as it occurs.

That means security teams can surface the network effects associated with an attacker's autonomous operator, malware communicating with an LLM, or an unsanctioned AI agent operating under an insider's credentials without waiting for a threat feed or signature to catch up.

Because the next AI-powered threat may use a new model, provider, agent, or infrastructure, the goal isn't simply to know every possible AI destination.

It's to recognize when your network starts behaving in a way it never has before.

Want to see what agent-shaped activity looks like on your own network? Talk to MixMode.

‍