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.

AI agents designed for coding, as well as command-line tools — such as Claude Code CLI, Gemini CLI, Codex CLI, Amazon Q CLI, and the like — 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.

Why trusted agents pose a threat

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’t 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.

It’s 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 — especially on a developer’s machine.

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 — including text fields in documents, file names, or even error logs, as shown in one of the examples below.

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.

Below are several examples of attacks where threat actors leveraged AI agents to achieve their goals.

The Nx attack: a coding agent hunting for passwords

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

The malicious post-install script checked whether Claude Code, Gemini CLI, or Amazon Q CLI were installed on the victim’s 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, --yolo, and --trust-all-tools.

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.

Instead of developing a complex, custom harvesting tool, the attackers repurposed the victim’s 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 “waited” for the AI agent, which could take a considerable amount of time to process the task while generating significant intermediate output.

Communication via… error logs

The AgentJacking 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 — some of them major enterprises.

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.

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’s MCP server data structure. Embedded inside was an indirect prompt injection — an instruction to run “additional diagnostics” via a command like: npx @controlled-validation-package --diagnose.

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’ 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’s use of Sentry is easily detectable by analyzing website code or checking the strings in mobile application binaries.

Notably, according to the study’s 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 “technically not defensible” against the attack.

Stealing financial data via MCP

Abusing unsecured MCP servers — as seen in the Sentry case — is just one way to attack this protocol. Introduced just a year ago, and already dubbed “USB for AI agents”, the Model Context Protocol standard was adopted rapidly without robust built-in security controls. As a result, attacks targeting MCP are bound to proliferate — a trend Microsoft recently warned about.

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 — adding an instruction that demands collection of additional data — the agent may execute it as part of its standard workflow.

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’s 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’s permissions, queries an approved service, and uses a standard interface. Yet a data breach still occurs.

It remains unclear from Microsoft’s 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.

Prompt injections have already gone mainstream

In 2026, Unit 42 researchers identified 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.

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

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 — and perhaps not primarily — by humans.

How to defend against agent-based attacks

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.

Organizations must:

• Maintain an inventory of agents, MCP servers, and the various tools available for them. Use allowlists to restrict agent tools, and package installations to components explicitly vetted and approved by information security. Allowlists must specify exact package versions.
• Monitor version changes to MCP tools and other dependencies. Re-evaluate updates before adding them to the approved inventory.
• Apply the principle of least privilege. Grant agents only the specific permissions needed for a given task, and only for the duration of that task.
• Enforce human-in-the-loop approval for package installations, script executions, file sends, and other high-risk actions.
• Run agents in isolated environments with limited access to developer workstations.
• Disable dangerous auto-approval modes.
• Restrict outbound network connections, and permit data transmission only for approved services.
• Store secrets in centralized, secure vaults, using short-lived tokens and rotating them regularly.
• Forward prompt logs, tool calls, shell commands, and agent network traffic into SIEM and XDR systems. For these tools to be effective, they require deep operational context regarding agent activity alongside specialized rule sets tailored to AI data processing pipelines.

Starting last year, Android users have been seeing the “number is now verified” system notification more frequently. And in some cases people even find mysterious outgoing text messages in their history that they never sent.

These messages often cause confusion and even anxiety: has a virus infected the phone? Are tech giants spying on our phone numbers? Let’s break down how this feature works, and what potential risks it poses to your privacy.

Why all these phone number verifications?

The notification pops up whenever Google’s phone number verification feature is triggered on your device.

Its main job is to make sure that the SIM card tied to a specific phone number is physically inside the phone. Once verified, that phone number automatically links to all active Google accounts on the device.

There are several key services that rely on the verification. Most importantly, it drives Rich Communication Services (RCS) — the modern standard for “rich” messaging right inside your standard text messaging app. It feels like a popular chat app, but without the need to install anything extra. Unlike iMessage, which is locked to Apple’s ecosystem, RCS works across compatible smartphones on various platforms since it’s an industry standard set by carriers rather than tech giants. Since recently, both Apple and Android users have been able to exchange RCS messages. For this feature to work in the Google Messages app, Google needs ongoing confirmation that your SIM card is active. If you pull out your SIM card, RCS chats will keep working for about eight days before turning off automatically.

According to Google, phone number verification serves several other purposes as well:

• Account security and recovery. A verified phone number enables quick sign-ins to your Google account, two-factor authentication, and easy password recovery.
• Emergency services and device location. This includes Find My Device, remote phone lock, and sharing your location with emergency responders — including via satellite messaging on the Pixel 9 and certain other modern smartphones.
• Better sharing on Google. This feature helps other people find you faster on Google Meet or Duo, use Quick Share to send you files, and see that the phone number is linked to your profile.

Google also recently confirmed that this data is used to counter scams. Verification helps block calls or text messages from spoofed numbers if both the real owner of the number and the recipient are using Android devices with verified phone numbers.

How does Google verify phone numbers?

Phone number verification technology has been around on Android for quite some time — Google was sending test SMS messages as far back as in 2019. However, it became widely visible to most users following a Google system update in September 2025. The process was baked deeper into the operating system, with number verification now running by default during initial phone setup, and re-running periodically in the background.

There are two main technical methods for the verification process. Which one your device uses depends on your mobile carrier and your version of Android.

The older method relies on hidden text messages. In the background, your smartphone sends a specialized technical text message to Google’s servers. The operating system intercepts this message before you ever see it, which is why it rarely appears in your standard text messaging app. However, due to software glitches or Android customization quirks, these texts occasionally surface in sent messages, startling users. They typically look like this: “(string of letters and numbers) Google is re-verifying the phone# of this device.” Google explicitly notes in its help documentation that standard messaging rates from your carrier may apply.

In recent years, direct carrier verification (via carrier APIs) has become the primary verification method. This approach is more modern and secure than previous ones. The smartphone sends an encrypted token containing device and SIM card identifiers to the mobile carrier, and the carrier responds with the confirmed phone number. The whole process takes just a couple of seconds and runs completely unnoticed by the user. Both global telecom giants and smaller providers have connected to this verification network. Notably, third-party apps can also tap into the results of this check through Firebase Phone Number Verification, getting confirmation from your mobile carrier about which phone number is active on the device.

“Other device data” and privacy concerns

In its official documentation, Google notes that device identifiers and SIM card data may be collected during verification. In practice, this refers to unique identifiers for the SIM card and its subscriber profile (ICCID and IMSI), as well as technical device identifiers needed to run mobile networks. Google also explicitly states that it does not sell your personal information, including your phone number, to anyone.

Naturally, sending additional unique identifiers to Google — especially given the scale of its advertising business — always raises concern among privacy-conscious users. Here’s what you should keep in mind:

Metadata collection. To run RCS, Google exchanges data with your mobile carrier. Even when the content of RCS messages is encrypted, metadata — such as who is messaging whom and when — can still be stored on your carrier’s servers, and in some cases, on Google’s servers. As cybersecurity experts at the Electronic Frontier Foundation point out, if privacy is your top priority, you’re better off sticking to dedicated encrypted messaging apps.

Linked accounts. If you have both a personal and a work Google account (or a personal and a family account) set up on the same phone, the verified number will automatically link to both profiles. The operating system does not offer built-in tools to separate numbers for different accounts on a single device.

Phone number leaks. Apps on your device can already access various user identifiers, including your phone number. However, this verification system makes it easier to link multiple phone numbers to a user who has multiple Google accounts. And while Google states that it never sells phone numbers, you cannot say the same with confidence about obscure third-party Android developers.

On by default. The feature is enabled out of the box, and most users have no idea their device is silently querying their carrier in the background. While you can opt out in your Google settings once you notice it, there’s no guarantee that any data already collected will actually be deleted.

Turning off verification — why and how

For most users, verification is genuinely helpful. It simplifies account recovery, makes finding a lost phone easier, powers modern text messaging features, and assists emergency services when every second counts.

However, if you want to minimize the amount of metadata sent to Google, mobile carriers, and other data brokers, you can manually disable the feature. Here’s how:

1. Open your Android smartphone’s settings.
2. Tap Google, select the account at the top, and switch to the All services tab.
3. Under Privacy and security, tap Phone number verification.
4. Turn off automatic phone number verification.

If you also want to disable Better sharing on Google, go to Settings → Google → Manage your Google Account → Personal info → Contact info → Phone, select your number, and turn off the setting.

If you have multiple Google accounts on your phone, you’ll need to repeat these steps for each one. Unfortunately, verification sometimes turns itself back on automatically, and there’s no reliable way to prevent this on standard consumer phones with stock software.

Keep in mind that disabling verification means losing access to RCS chats in Google Messages — forcing you to fall back on basic SMS, or switch to alternative secure messaging apps. You also won’t be able to use that number for quick account recovery should you forget your password.

To thoughtfully customize your privacy settings across all your devices — regardless of the operating system, browser, or app — check out our free online tool, Privacy Checker.

Curious about other privacy risks you might not even know exist? Check out our other deep dives, here:

• Post-breakup digital hygiene: what to check and shut down
• What happens in the bedroom stays in the bedroom
• Is telehealth actually safe?
• Predator vs. iPhone: the art of invisible surveillance
• Brain drain: vulnerabilities in mental health apps

When targeting an organization to steal information, maintaining a low profile is critical for attackers. They typically aim for long-term persistence, which requires avoiding security alerts while preserving access in case they’re detected and the organization initiates incident response or routine password resets. Malware such as infostealers or ostensibly legitimate remote monitoring and management (RMM) tools fail the first requirement: their use triggers EDR and generates suspicious events in SIEM consoles. Relying on stolen credentials conflicts with the second requirement: the moment the security team suspects a compromise, passwords can be changed immediately — terminating access. If attackers attempt to steal browser cookies instead of passwords, they face a different challenge: many online services now correlate device characteristics with the expected session cookie and block access if the cookie is used on an unrecognized device. Furthermore, cookie theft protection mechanisms implemented in Chromium-based browsers (such as Chrome, Edge, and Opera) this year have made this approach significantly more difficult.

To address this persistence challenge, the ToddyCat APT — whose main game is spying — developed a novel technique. Kaspersky experts discovered this method during an incident investigation and named it Shadow Token via Remote Debug (STRD). This technique allows the attackers to establish reliable, persistent access to a victim’s mailbox and other resources in Google Workspace. With minor adjustments, the same approach could potentially be adapted to target other services that grant third-party application access via OAuth 2.0 authentication.

How an STRD attack works

First, the attackers must compromise the victim’s system with malware. In past campaigns, ToddyCat gained initial access to organizations by exploiting known vulnerabilities in server software and distributing malicious loaders via messaging apps. The specific employee targeted by the attackers might not notice the intrusion at all. This can occur, for example, if the adversary first obtains privileged administrative credentials and uses them to deploy the malware onto targeted machines remotely. Crucially, the deployment and execution of this malware mustn’t trigger immediate security alerts.

Once active, the malware executes an STRD attack, connecting the attackers’ remote service to the victim’s mailbox using the OAuth 2.0 protocol. This process requires no user interaction and shows no visible activity on the screen. To the cloud environment (Google Workspace, in the case at hand), the activity appears as if the user has legitimately authorized a third-party app for email access or data backup.

After that, the malware can terminate its operations and even delete itself from the system. The adversary retains direct access to the mailbox using the acquired OAuth token — and they need no connection to the victim’s endpoint or to the corporate network for that. Depending on the organization’s Google Workspace configuration, this access can persist for an extended period and survive subsequent password resets.

The core concept of Shadow Token via Remote Debug

At the heart of this attack is a connection to Google Workspace services via OAuth 2.0. This is a legitimate workflow used whenever a third-party application requests access to calendar data, emails, or Google Drive files. For example, to display calendar meetings in Zoom and automatically generate conference links, a user must authorize Zoom to access Google services. Similarly, configuring a third-party email client or calendar app requires granting permission. During this authorization process, the service requesting access opens a new browser window. In this window, Google Workspace first prompts the user to select the appropriate account. Once the account is chosen, the subsequent screen displays the specific permissions requested by the third-party app, allowing the user to either approve or deny access. For this scenario to proceed seamlessly, the user must already be authenticated to Google services in their browser — which is typically the case in organizations using Google Workspace. If the user isn’t authenticated, additional steps for entering credentials and completing multi-factor authentication are introduced into the sequence.

The ToddyCat hackers developed a malicious tool called Umbrij to facilitate a two-step covert authorization process when the user is already authenticated in Google. First, the malware identifies the browsers installed on the system, and locates the specific folder storing the user’s active profile for each. The attackers target Chrome and Edge, as these are the browsers most likely serving as the primary ones within the organization.

Next, Umbrij copies the entire user profile folder to a different directory on the machine. It then launches an instance of the browser, specifying the path to the duplicated profile via the command line. Because this duplicate profile contains the user’s session cookies, websites with saved credentials won’t prompt for re-authentication. Furthermore, since this occurs on the exact same computer where the primary browser is running, online services detect no anomalies. The browsing history for this newly launched instance is isolated within the new folder, keeping it hidden from the user’s main account activity.

Crucially, the browser is launched in a dedicated debugging mode typically reserved for web development. The browser window and user interface don’t appear on the screen at all (headless mode). Instead, the browser can be controlled through a debugging port using the DevTools protocol, allowing the malware to issue commands and read the state of the screen. To orchestrate these actions, Umbrij leverages Puppeteer, a legitimate automation library.

After verifying that the debugging browser instance has launched successfully, Umbrij opens a legitimate Google Workspace OAuth screen within it. The request sent to Google is engineered to bypass additional security checks while requesting maximum access privileges. For the application ID — the identity supposedly requesting these extensive permissions — the malware impersonates one of two legitimate tools: Google Workspace Migration for Microsoft Outlook (GWMMO), or Google Workspace Sync for Microsoft Outlook (GWSMO).

When Google opens the window within the headless browser, Umbrij uses debugging tools to programmatically click on the corporate account name and the confirmation buttons. As a result, Google generates an authorization code for the app. Umbrij extracts and saves this code, subsequently forwarding it to the attackers’ command-and-control server. Finally, operating entirely within their own infrastructure rather than on the victim’s computer, the attackers exchange this authorization code for an OAuth access token. This single token is all they need to maintain long-term unrestricted access to the mailbox.

How to protect against OAuth token theft

If a Google Workspace account is compromised, incident response measures must include the following steps after collecting the necessary logs and other forensic data for investigation:

• Resetting the affected user’s password
• Terminating all active web sessions for the user
• Revoking OAuth tokens and third-party app permissions
• Reviewing and removing access granted through legacy App Passwords

In addition, security and IT teams must systematically audit issued OAuth permissions, revoke unjustifiable access rights, and restrict capabilities that allow excessive or unauthorized permission grants. We covered this topic in detail in our article on blocking unwanted AI assistants.

How to prevent exploitation of Shadow Token via Remote Debug

While Kaspersky users are protected against the Umbrij tool, security teams should proactively implement policies that prevent standard users from launching browsers in debugging mode. This functionality is intended exclusively for website and web app developers. This restriction can be enforced through the DeveloperToolsAvailability group policy (available for both Chrome and Edge).

Additionally, configure monitoring within your SIEM/XDR to track the launch of browser instances with an active debugging port. This event serves as a strong indicator of this specific attack technique.