How Malicious Plugins Transform AI Agents Into Insider Threats

Contributors: Vinoop Chandran, Vishak U Kavitha

Introduction

AI coding agents—tools capable of reading files, writing scripts, and executing commands on behalf of developers—are being adopted at a significantly faster rate than traditional enterprise software. Their value is clear: they accelerate development cycles, automate repetitive tasks, and extend their capabilities through modular “skills” or “plugins,” often installed directly from public marketplaces similar to browser extensions or VS Code plugins.

However, this extensibility model introduces a critical and often under-appreciated attack surface. In a recent Security Operations Center (SOC) investigation, we observed a live incident where a legitimate, digitally signed, and broadly deployed AI coding agent was leveraged as the delivery and execution mechanism for a credential-theft attack. The breach did not stem from a vulnerability within the agent software itself, but rather from the abuse of its permission model and the implicit trust it places in installed skill packages.

This post details our findings (fully anonymized to protect host, user, and customer identifiers), explains why this shift in threat methodology matters for organizations deploying agentic AI, and provides actionable detection logic to identify this activity in your environment.

What We Observed

The compromised endpoint had a mainstream AI coding agent installed. The software was present across hundreds of enterprise devices, confirming it was a sanctioned tool rather than unauthorized “shadow IT.” Crucially, the agent was configured in an “unattended” or “auto-approve” execution mode, granting it permission to execute shell scripts (Bash and PowerShell) without requiring interactive user confirmation.

Located within the agent’s local skills directory was a package disguised under an innocuous, business-aligned name designed to mimic a routine approval workflow. Concealed within this package were scripts configured to perform the following actions:

1. Reconnaissance: Enumerate running browser processes (e.g., Microsoft Edge, Google Chrome, Mozilla Firefox) active on the host.
2. Credential Decryption: Invoke the operating system’s native credential-decryption API against saved browser password vaults.
3. Data Access: Read the browser’s local credential-store database file directly.
4. Secondary Targeting: Repeat the extraction sequence against a secondary browser in a separate session minutes later, simultaneously launching the browser with a remote-debugging flag enabled to establish deeper access.

Because the agent operated in auto-approve mode, this entire sequence executed silently twice within 15 minutes without presenting authorization prompts to the end user. The operation relied exclusively on legitimate, trusted system components: the agent’s bundled shell, its embedded Python interpreter, and its sandbox execution layer.

Endpoint Detection and Response (EDR) mechanisms flagged the activity not based on static file signatures, but via behavioral analysis. The combination of credential-store decryption API calls, direct reads of browser login database files, and subsequent memory-protection modifications within the interpreter process matched established Credential Access patterns.

Figure 1: EDR telemetry displaying process lineage and detected credential-access events.

Why This Represents a Distinct Security Challenge

1. The Absence of Malicious Binaries

Every executable involved in the execution chain—the primary agent binary, the shell, the Python runtime, and the sandbox wrapper—was legitimate, vendor-signed software. Standard binary reputation lookups, signature validation, and application allow-listing controls failed to trigger alerts because the malicious payload resided entirely within the uncompiled script content of an add-on skill package.

2. Shifts in the Trust Boundary

In traditional application security, controls focus primarily on verifying whether an executable binary is authorized to run. With agentic AI environments that support extensible plugins and skills, the control point shifts to evaluating whether a specific instruction, prompt, or skill package is safe to execute. Most enterprise environments currently lack security controls tailored to this operational layer.

3. Impact of Permission Configuration

The primary control capable of preventing this attack is enforcing human-in-the-loop authorization prior to command execution. Disabling auto-approval features or tightly scoping execution privileges serves as the most effective immediate mitigation against this attack vector.

4. Fleet-Wide Exposure

Because AI coding agents are frequently deployed across broad developer populations, a single malicious skill package or overly permissive default configuration poses an enterprise-wide risk immediately upon deployment.

MITRE ATT&CK Mapping

Detecting This Pattern

Analysis of the process lineage revealed a consistent execution sequence:

$$\text{AI-Agent.exe} \longrightarrow \text{sandbox-cli.exe} \longrightarrow \text{bash.exe / powershell.exe} \longrightarrow \text{python.exe} \longrightarrow \text{[Decrypt Script]} \longrightarrow \text{Browser Credential Store}$$

The most reliable telemetry signal relies on process lineage combined with target file and API activity, rather than static file names or package identifiers, which can be easily modified. Security teams should monitor for AI-agent-spawned interpreters that access credential files or invoke system decryption routines via an intermediary shell.

The following KQL rules (compatible with Microsoft Defender for Endpoint and Microsoft Sentinel) detect these behavioral patterns. The AgentProcessNames array can be customized to include the authorized AI tools present in your environment (e.g., Copilot CLI, Cursor, Claude Code, Cline, Continue).

Detection Rule 1:
AI-Agent-Spawned Process Accessing Browser Credential Stores

// Detects: An AI coding-agent process tree (Agent -> Shell -> Interpreter)
// reading or accessing a browser's local credential-store file.
// Update AgentProcessNames to match approved AI tooling in your environment.

let AgentProcessNames = dynamic([
    "workbuddy.exe","codebuddy.exe","cursor.exe","claude.exe","claude-code.exe",
    "cline.exe","continue.exe","copilot.exe","aider.exe","windsurf.exe"
]);
let ShellProcessNames = dynamic(["bash.exe","powershell.exe","pwsh.exe","cmd.exe","sh.exe"]);
let InterpreterNames = dynamic(["python.exe","python3.exe","node.exe"]);
let BrowserCredPaths = dynamic([
    @"\User Data\Default\Login Data",
    @"\User Data\Default\Login Data For Account",
    @"\Profiles\",   // Firefox profile logins.json / key4.db
    @"\Local State"
]);

DeviceFileEvents
| where ActionType in ("FileRenamed", "FileModified") or ActionType == "FileRenamed"
| where FolderPath has_any (BrowserCredPaths)
| where InitiatingProcessFileName has_any (InterpreterNames)
| join kind=inner (
    DeviceProcessEvents
    | where InitiatingProcessFileName has_any (ShellProcessNames)
    | where FileName has_any (InterpreterNames)
    | project ProcessId, InitiatingProcessParentFileName, InitiatingProcessCommandLine, DeviceId
) on $left.InitiatingProcessId == $right.ProcessId, DeviceId
| where InitiatingProcessParentFileName has_any (AgentProcessNames)
   or InitiatingProcessCommandLine has_any (AgentProcessNames)
| project Timestamp, DeviceName, AccountName = InitiatingProcessAccountName, FolderPath, FileName,
          InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName
| order by Timestamp desc

Detection Rule 2:
Credential-Unprotect Call Chain Spawned by AI Agent Shell

// Detects: A scripting interpreter (Python/Node) modifying memory protection
// shortly after launch via a shell initiated by an AI agent process.
// Aligns with native DPAPI CryptUnprotectData invocations (T1555.004).

let AgentProcessNames = dynamic([
    "workbuddy.exe","codebuddy.exe","cursor.exe","claude.exe","claude-code.exe",
    "cline.exe","continue.exe","copilot.exe","aider.exe","windsurf.exe"
]);

DeviceEvents
| where ActionType in ("ProcessPrimaryTokenModified","AntivirusDetection","ProcessMemoryProtectionChanged")
    or ActionType has "MemoryProtection"
| where InitiatingProcessFileName in~ ("python.exe","python3.exe","node.exe")
| join kind=inner (
    DeviceProcessEvents
    | where InitiatingProcessFileName has_any (AgentProcessNames)
       or InitiatingProcessParentFileName has_any (AgentProcessNames)
    | project ChildProcessId = ProcessId, DeviceId, AgentParentCmd = InitiatingProcessCommandLine
) on $left.InitiatingProcessId == $right.ChildProcessId, DeviceId
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, AgentParentCmd, ActionType
| order by Timestamp desc

Detection Rule 3:
Skill Package Creation Preceding Credential Access

// Detects: File creation or modification within an AI-agent skill directory,
// followed shortly by browser credential-store access from an interpreter.

let SkillDirHints = dynamic([".workbuddy\\skills", ".cursor\\skills", ".claude\\skills", "\\plugins\\", "\\extensions\\"]);

let SkillWrites = DeviceFileEvents
    | where ActionType in ("FileCreated","FileModified")
    | where FolderPath has_any (SkillDirHints)
    | project SkillTime = Timestamp, DeviceId, DeviceName, SkillFolder = FolderPath, SkillFile = FileName;

let CredAccess = DeviceFileEvents
    | where FolderPath has @"Login Data" or FolderPath has "key4.db" or FolderPath has "logins.json"
    | project CredTime = Timestamp, DeviceId, CredFolder = FolderPath, CredProcess = InitiatingProcessFileName;

SkillWrites
| join kind=inner CredAccess on DeviceId
| where CredTime between (SkillTime .. (SkillTime + 7d))
| project DeviceName, SkillTime, SkillFolder, SkillFile, CredTime, CredFolder, CredProcess
| order by CredTime desc

Recommended Implementation Strategy:

Deploy these detection rules initially in audit or report-only mode. Establish a baseline for authorized AI agent activity across your fleet, account for legitimate developer workflows, and refine alert thresholds prior to enabling active block or response policies.

Strategic Recommendations for Security Teams

1. Governance for Agent Extensions: Treat AI-agent skills, plugins, and extensions with the same rigor as third-party binaries. Enforce digital signature verification, code reviews, or centralized repository controls prior to installation.
2. Restrict Unattended Execution: Disable global auto-approval modes. Mandatory human-in-the-loop authorization should be enforced for shell command execution, file system access, and any interaction with sensitive directories.
3. Behavior-Based Detections: Focus telemetry and alerting on process parentage, command-line arguments, and sensitive target resource interactions rather than static file hashes or script names.
4. Maintain Tool Visibility: Maintain an accurate inventory of all agentic AI deployments across the organization to enable rapid scoping and incident response.
5. Collect Session Context During Investigations: When analyzing potential AI-agent incidents, capture complete prompt history and session logs alongside standard endpoint telemetry to determine whether actions originated from a user request, a compromised skill, or indirect prompt injection.

Conclusion

Agentic AI tools deliver substantial development efficiencies and will remain an integral part of enterprise workflows. However, as these platforms gain capabilities—including self-managed extensions and autonomous command execution—the security model must evolve accordingly. The primary focus of enterprise defense must expand from assessing what software is installed to continuously auditing what commands an agent is executing and verifying the authenticity of its instructions.

Establishing baseline visibility into active agentic tools, restricting execution permissions, and enforcing behavioral detection strategies provide SOC teams with a robust defense against emerging AI supply-chain attack vectors.