Zero Networks examined three scenarios in which AI agents help an attacker move inside a corporate network. For a Pigman engineer, the problem is familiar: a tool gained access to data, while the limits of its authority were left somewhere between the settings and good intentions. The Lateral Movement Exposure Report 2026 is about speed, scale, and actions performed under trusted accounts.
Lateral movement is moving from an already accessible system to other resources inside the network. The technique has been around for a long time, but an agent can perform many tasks in parallel or process requests without the usual manual review. For defenders, that shifts the focus: it’s important to see not only login attempts, but also whether the agent’s behavior matches its intended purpose.
A prompt in an email can make an agent spill data
The first scenario involves a support agent that the company has given access to its CRM, internal knowledge base, and Jira ticket creation. Employees can ask it to summarize an incoming request, then work from the summary instead of the email itself. That familiar convenience creates a point of risk: the request may contain a hidden instruction for the agent.
In the scenario described, while preparing a summary, the agent follows instructions embedded in the email, creates Jira tickets containing customer data, and sends them to an address controlled by the attacker. In the traffic, this may look like ordinary interaction with the agent, not an obvious attack. A signature for a specific prompt text isn’t always a practical solution, because writing one is difficult.
Another line of defense is to monitor the agent’s behavior and its permitted areas. If the tool is supposed to work with the CRM, knowledge base, and Jira, then accessing Outlook, the user directory, or a file server doesn’t match its described role. An unusual volume of data operations may also be suspicious. The logic here is simple: the agent’s access should be compared with what it actually does.
For a single agent with clearly defined functions, policies can be set manually. When there are many tools or their roles change, the report proposes training an ML model on normal behavior and detecting deviations. The two approaches can be combined: define obvious boundaries with rules, and leave less predictable deviations to the model. An agent that suddenly needs a file server to summarize an email is practically telling you to check the access rules.
NTLM hash guessing turns into mass testing
The second scenario starts with a workstation from which the attacker has obtained stored NTLM hashes. They can then be tested against available internal systems. A person working manually would limit themselves to a few priority targets; an AI agent can test thousands at once. The method is well known. It just has a very diligent operator now.
According to the report, as summarized by the article’s author, 43,2% of internal authentication still relies on NTLM. The more systems accept this mechanism, the more potential targets there are for this kind of guessing. That doesn’t mean every one of them will be compromised: the figure describes how widespread NTLM use is, not how often attacks succeed.
The network signal in this case is a burst of authentication requests: one host reaches out to many others on the internal network. In the example for a regular workstation, that means a few requests to the file SMB network per day; thousands of requests instead of the usual level warrant attention. Such a spike indicates reconnaissance or abnormal activity, though it doesn’t by itself explain what caused it.
Separate detection models for NTLM, Kerberos, and LDAP can be used for monitoring. Some scenarios, including password guessing, can be described with deterministic rules. At the same time, a spike may have an ordinary explanation: for example, a script keeps trying to log in with a password that has expired. So the signal should be treated as a reason to investigate, not as automatic proof of an attack.
An unaccounted-for agent leaves a blind spot
The third scenario is so-called Shadow AI. A developer connects an internal language model to a personal MCP server that has access to a corporate database. “Personal” here means the server was deployed for individual tasks, not that it is isolated from the corporate network. According to the claim cited in the article, an average of 85% of internal systems are accessible from one such compromised machine.
The model and MCP server together act as an agent, but may not go through the usual integration with the access management system and may not be visible to the information security team. If such an agent processes requests, the attacker doesn’t have to break every connection themselves: in this scenario, it’s enough to make the agent export data and send it somewhere. The database access is performed under a trusted service account, so ordinary network traces may not reveal the suspicious source.
The practical answer is inventory: you need to know which agents are running, which systems they interact with, and what data they can access. It’s the lack of inventory that makes this tool resemble Shadow IT, except with ready-made automation and access to corporate data. The article also notes that such agents can be detected by their presence or by requests to domains and networks associated with AI services.
Protection starts with visibility and access boundaries
The examples described don’t require a fundamentally new understanding of lateral movement. According to the author of the analysis, the technique has been used at least since the Stuxnet attack in 2010. What has changed is the speed, scale, and number of parallel actions, and some activity may take place through legitimate tools and trusted accounts. So the absence of an exploit or an obviously stolen password doesn’t guarantee that internal activity is safe.
Specialized tools for protecting language models and agents are being developed, but according to the article, they haven’t yet become widespread. Some risks can already be monitored with existing tools: deviations from normal behavior, mass authentication requests, unusual access paths, and lists of unregistered agents. For a prompt attack, the consequences of carrying out the instruction may matter more than its wording. So in practice, the key question is whether the security team can see what the agent is doing and what it can access.
