{"id":30760,"date":"2026-07-23T12:47:32","date_gmt":"2026-07-23T11:47:32","guid":{"rendered":"https:\/\/www.kaspersky.co.uk\/blog\/ai-agents-under-attack-2026-incidents\/30760\/"},"modified":"2026-07-23T12:47:32","modified_gmt":"2026-07-23T11:47:32","slug":"ai-agents-under-attack-2026-incidents","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.uk\/blog\/ai-agents-under-attack-2026-incidents\/30760\/","title":{"rendered":"Practical attacks on corporate AI agents"},"content":{"rendered":"

Cybersecurity news increasingly focuses on attackers using AI for reconnaissance, vulnerability hunting, and writing scripts or malware. Against this backdrop, a less conventional category of attacks remains largely overlooked: threat actors leveraging AI tools that are already deployed within the target infrastructure.<\/p>\n

AI agents designed for coding, as well as command-line tools\u00a0\u2014 such as Claude Code CLI, Gemini CLI, Codex CLI, Amazon Q CLI, and the like\u00a0\u2014 are particularly attractive targets. These agents can read and modify files, execute shell commands, install packages, and connect to external services. Developers frequently allow them to run in autonomous mode to avoid manually confirming every action. For an attacker, such an agent becomes a ready-made multitool that has the right privileges, access to critical data, and security clearances from the get-go. That said, other types of AI agents, such as automated financial workflow assistants, are equally vulnerable to exploitation.<\/p>\n

Why trusted agents pose a threat<\/h2>\n

An AI agent differs from standard software in its broad access privileges, the wide array of ways it can be prompted to execute actions, and the difficulty of detecting its anomalous behavior. Enterprise security controls (EPP, EDR, XDR, SIEM) scan for malicious files, known command patterns, and suspicious action sequences. Even if a specific strain of malware hasn\u2019t been seen before, its behavior often gives it away: bulk searches for documents, spawning PowerShell processes, accessing credential stores, or exfiltrating data to an external server from an unknown application will trigger a deluge of alerts in the SOC.<\/p>\n

It\u2019s much harder to apply that same detection logic to a legitimate, pre-installed AI agent. By design, these tools are capable of executing an extremely broad range of operations. Running scripts, reading configuration files (including secrets), moving documents, and installing dependencies can all be a part of their normal operation \u2014 especially on a developer\u2019s machine.<\/p>\n

When an attacker attempts to exploit this kind of AI system, they use natural language to convey their instructions to the agent. A request to hunt for passwords, API keys, or cryptocurrency wallets can be framed in thousands of ways, expressed in a variety of languages, or phrased indirectly. Furthermore, a malicious command can be hidden in any data stream the agent reads\u00a0\u2014 including text fields in documents, file names, or even error logs, as shown in one of the examples below.<\/p>\n

Integration between agents and third-party software further expands the attack surface. Agents are frequently connected to email, instant messaging apps, task management systems, knowledge bases, and MCP servers. As a result, a malicious instruction can originate from virtually any source whose data the agent processes automatically.<\/p>\n

Below are several examples of attacks where threat actors leveraged AI agents to achieve their goals.<\/p>\n

The Nx attack: a coding agent hunting for passwords<\/h2>\n

The most prominent and widespread example is the compromise of Nx npm packages in August 2025, dubbed s1ngularity<\/a>. Attackers exploited a vulnerable GitHub Actions workflow, stole a package-publishing token, and released trojanized versions of several @nx packages that harvested developer secrets.<\/p>\n

The malicious post-install script checked whether Claude Code, Gemini CLI, or Amazon Q CLI were installed on the victim\u2019s machine. If any of these were detected, the agent was issued an instruction to scan for cryptocurrency wallets, ENV files, API keys, and other sensitive data. The agents were executed with auto-approval flags enabled, such as --dangerously-skip-permissions<\/code>, --yolo<\/code>, and --trust-all-tools<\/code>.<\/p>\n

The search results were then exfiltrated to public GitHub repositories created by the attackers. Over several waves of the attack, thousands of secrets belonging to hundreds of organizations were exposed.<\/p>\n

Instead of developing a complex, custom harvesting tool, the attackers repurposed the victim\u2019s own legitimate agent. It already could navigate the file system, understand file context, and identify high-value target data. However, post-incident analysis by security experts revealed drawbacks to this approach: the AI occasionally refused to carry out unethical tasks. Furthermore, the malware authors had to adjust their code so that it \u201cwaited\u201d for the AI agent, which could take a considerable amount of time to process the task while generating significant intermediate output.<\/p>\n

Communication via\u2026 error logs<\/h2>\n

The AgentJacking<\/a> study was not a malicious attack, but it differed from one only in intent: its authors had no interest in stealing secrets. After developing the attack technique, the researchers tested it on a global scale and received callback responses from AI agents belonging to more than a hundred real-world companies \u2014 some of them major enterprises.<\/p>\n

The attack targeted Sentry, a widely used telemetry service. Websites and mobile applications automatically transmit error reports to Sentry so developers can monitor issues without requiring active user reporting. These reports are accepted without authentication because errors often occur for anonymous visitors that the site or application knows nothing about.<\/p>\n

The researchers configured their own MCP server within Sentry, allowing AI agents to analyze reports automatically. Next, they submitted a fake error message containing a data block formatted to match Sentry\u2019s MCP server data structure. Embedded inside was an indirect prompt injection\u00a0\u2014 an instruction to run \u201cadditional diagnostics\u201d via a command like: npx @controlled-validation-package --diagnose<\/code>.<\/p>\n

If error handling were delegated to an agent, it could take the instruction as legitimate and execute a command resulting in the automatic installation of a third-party package. In this experiment, the package merely contacted the researchers\u2019 command-and-control server without exfiltrating any sensitive data. A genuine malicious package, however, could steal credentials, tamper with code, or establish persistence in the system. Identifying targets for such an attack is equally straightforward: an organization\u2019s use of Sentry is easily detectable by analyzing website code or checking the strings in mobile application binaries.<\/p>\n

Notably, according to the study\u2019s authors, Sentry acknowledged the issue but stopped short of implementing comprehensive fixes, opting instead to block only the specific variant of the malicious query routed through the MCP. Screenshots included in the study reveal that a Sentry employee described the system as \u201ctechnically not defensible\u201d against the attack.<\/p>\n

Stealing financial data via MCP<\/h2>\n

Abusing unsecured MCP servers\u00a0\u2014 as seen in the Sentry case\u00a0\u2014 is just one way to attack this protocol. Introduced just a year ago, and already dubbed \u201cUSB for AI agents\u201d, the Model Context Protocol standard was adopted rapidly without robust built-in security controls. As a result, attacks targeting MCP are bound to proliferate \u2014 a trend Microsoft recently warned about<\/a>.<\/p>\n

Threats can lie hidden even within the description of an MCP tool before the agent ever uses it. Agents parse tool descriptions to determine when to call the tool and what data to supply. If an MCP server provider stealthily alters a description \u2014 adding an instruction that demands collection of additional data \u2014 the agent may execute it as part of its standard workflow.<\/p>\n

Microsoft highlights a scenario involving a financial agent that verifies vendor banking details via an external MCP service. Following a malicious update to the tool\u2019s description, the agent begins appending unpaid-invoice data to its responses. The user sees a normal response, while confidential financial data is quietly exfiltrated to the server owner. Individually, each operation appears authorized: the agent operates under the employee\u2019s permissions, queries an approved service, and uses a standard interface. Yet a data breach still occurs.<\/p>\n

It remains unclear from Microsoft\u2019s ambiguous phrasing whether this example is purely hypothetical or based on an investigation into a live incident. However, the fact that the post originated from Microsoft Incident Response points to the latter.<\/p>\n

Prompt injections have already gone mainstream<\/h2>\n

In 2026, Unit 42 researchers identified<\/a> widespread attempts to covertly embed instructions designed for AI systems across numerous public websites. Many of these instructions aim to force models to reveal system prompts, approve sites and posts during ad placement reviews, or boost phishing pages through SEO manipulation.<\/p>\n

Similarly, an analysis of Common Crawl data<\/a> by Google recorded a surge in such material: between November 2025 and February 2026, the share of malicious injections increased by 32%.<\/p>\n

That said, confirmed cases of successful compromise using these techniques remain scarce. The presence of an injection on a webpage does not guarantee that an agent ever actually executed the command. Nevertheless, threat actors have clearly begun optimizing web content for an era when it will be read not just\u00a0\u2014 and perhaps not primarily\u00a0\u2014 by humans.<\/p>\n

How to defend against agent-based attacks<\/h2>\n

The key takeaway for cybersecurity teams and all AI users alike is simple: an AI agent should never be considered trusted merely because it has been officially approved for enterprise use.<\/p>\n

Organizations must:<\/p>\n