Technical analysis of a novel EDR bypass technique discovered at RSAC 2026, leveraging AI coding assistants to execute malicious payloads with system-level p...
How an AI Coding Assistant Becomes an Execution Path
AI coding assistants sit in a privileged spot inside a developer's environment. They read files, generate code, and in many setups can run commands, install dependencies, or apply edits on the developer's behalf. The technique demonstrated at RSAC 2026 treats that capability as an execution primitive: instead of dropping a binary and hoping it runs, an attacker steers the assistant into performing the malicious action itself. Because the assistant already holds the developer's access, the payload inherits whatever the workstation grants — often reaching system-level privileges without a separate escalation step.
The delivery surface is broad. Prompts can be poisoned through repository contents, dependency documentation, issue text, or any external data the assistant is asked to summarize or act on. When the tool is configured to execute rather than merely suggest, hidden instructions embedded in that data can turn "help me fix this build" into an unattended command run.
Why EDR Misses It
Endpoint detection tools are tuned to flag suspicious processes, unusual parent-child chains, and known-bad binaries. The bypass works because the offending actions originate from a trusted, signed developer tool doing exactly what it is designed to do — spawning shells, writing files, fetching packages, and modifying code. To the sensor, this looks like ordinary engineering activity, so the behavior blends into a baseline that is already noisy and permissive.
The assistant also launders intent. A human never types the malicious command; it is assembled from context the model ingested, so there is no obvious operator action to correlate. Detection logic that keys on specific command strings or file drops has little to grab onto when the same benign tool produces both legitimate and hostile output.
Practical Mitigations
The defensive goal is to break the link between "the assistant can suggest" and "the assistant can execute with my privileges." Treat the assistant as untrusted middleware that processes attacker-influenced input, and constrain what it can do without review.
- Require explicit human approval before the assistant runs shell commands, installs packages, or applies file changes — disable silent auto-execution.
- Run the assistant and its tool calls inside a sandbox or container with least-privilege credentials, not the developer's full session.
- Isolate untrusted context: don't let the assistant act on repository text, issues, or dependency docs from unvetted sources in the same session where it can execute.
- Log every command and file mutation the assistant initiates as a distinct, auditable event so EDR and reviewers can inspect the actual action, not just the parent tool.
Rethinking the Trust Boundary
The broader lesson is that an AI coding assistant is now part of the attack surface, not just a productivity feature. Any tool that can both consume external data and execute privileged actions needs a boundary between those two capabilities. Where a human developer would pause at a strange instruction, an assistant configured for autonomy may not — so the safeguard has to live in the environment, not in the model's judgment.
Security teams should inventory which assistants are deployed, what each can execute, and under whose credentials, then apply the same scrutiny given to any other agent with system access. Monitoring should focus on the actions these tools take rather than the process that takes them, because the process itself will almost always look trusted.