Agentic coding assistants become the attacker's shell
Agents
Agentic coding assistants are no longer just autocomplete. They edit files, run commands, and browse the web. That power shifts the risk model: if the agent treats untrusted text as instructions, you have a shell with developer privileges. This study looks squarely at that failure mode and measures how often it happens.
The authors built AIShellJack, an automated rig to test agent behaviour using real system actions rather than scary text. It packs 314 attack payloads covering 70 MITRE ATT&CK techniques, then exercises popular assistants, including Cursor and GitHub Copilot, across five codebases in TypeScript, Python, C++ and JavaScript. Measured end state: what commands ran. Results were ugly. Depending on configuration, 41% to 84% of payloads led to agent execution, and that held across languages, tools and model backends.
How the hijack works
Picture a poisoned rule file dropped into a repo. A developer asks a normal question. The Large Language Model (LLM) agent reads the workspace, treats the rule file as guidance, and starts acting. Because the agent can run commands, it moves from “interpret text” to “do things”: reconnaissance, searching for AWS credentials and SSH keys, modifying authentication configs, creating user accounts, and planting Cron" target="_blank" rel="noopener" class="term-link">cron jobs for persistence. When initial commands fail, the agent adapts, refines searches, and keeps going. The attacker does not need a perfect environment-specific script; high-level instructions suffice.
The attack surface is broad. It includes repository and workspace files, community-shared productivity artefacts like skills, templates and rule files, and live context from Model Context Protocol (MCP) servers, APIs, inboxes or web pages. If the agent ingests it, it can steer the tool.
Why defences buckle
UI prompts, command allowlists and backend safety filters assume clear trust boundaries. The agent does not. Inputs get fused into a single token stream without structure separating trusted instructions from untrusted data. That lets malicious artefacts preempt or bypass safeguards, triggering system actions before any trust dialogue or riding on auto-approval paths.
We are seeing this outside the lab. Disclosed issues and CVEs across tools show agent actions can kick off before prompts appear, or run hands-free. A Snyk scan of 3,984 public agent skills found 13.4% with critical security issues, and 91% of confirmed malicious skills combined prompt injection with traditional malware.
The evaluation centred on coding rule files and a subset of assistants and versions. The authors point out the surface is wider and ask for studies that capture cross-file, cross-service and long-running interactions. That is the right next step: measure whole workflows, not just single files, and keep scoring actual system effects.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
How Agentic AI Coding Assistants Become the Attacker's Shell
🔍 ShortSpan Analysis of the Paper
Problem
This paper studies how agentic AI coding assistants that can edit files, run commands and access the internet become an attacker’s shell when they consume unvetted external artifacts. Hidden or malicious instructions embedded in repository files, productivity artifacts or live external context can be interpreted as legitimate requirements by the assistant, causing it to execute unauthorised system actions with the developer’s privileges. This is a system security problem rather than a pure model-safety issue because the assistant can perform real-world actions such as running commands, modifying authentication files and exfiltrating secrets.
Approach
The authors built AIShellJack, an automated evaluation framework that contains 314 attack payloads covering 70 adversary techniques from the MITRE ATT&CK framework. They used it to test popular assistants, including Cursor and GitHub Copilot, across five real-world codebases in TypeScript, Python, C++ and JavaScript. Each test injected a poisoned coding rule file into the workspace, issued a normal developer request and recorded the actual system commands the assistant executed. The design focuses on measuring real system actions rather than harmful text output.
Key Findings
- High prevalence and systemic risk: across 314 payloads, attack success rates ranged from 41% to 84%, and results were consistent across programming languages, tools and model backends.
- Full lifecycle impact: compromised assistants could perform reconnaissance, search for AWS credentials and SSH keys, create user accounts, modify authentication configurations and install cron jobs, enabling persistent compromise.
- Adaptive and robust attackers: agentic assistants adapt their actions when initial commands fail, refining searches and strategies, so attackers need only supply high-level instructions rather than precise environment-specific exploits.
- Broad attack surface: vectors include repository and workspace files, community-shared productivity artifacts (skills, rule files, templates) and live external context such as MCP servers, APIs, inboxes or web pages.
- Real-world manifestations: multiple disclosed vulnerabilities and CVEs across tools demonstrate attacks can trigger before trust dialogs or enable auto-approval; a Snyk scan of 3,984 public agent skills found 13.4% with critical security issues and 91% of confirmed malicious skills combined prompt injection with traditional malware.
- Defences insufficient: UI safeguards, command allowlists and backend safety filters are fragile because inputs are processed as a single token stream without structural boundaries between trusted instructions and untrusted data, allowing attackers to bypass or preempt safeguards.
Limitations
The evaluation focused primarily on coding rule files as an injection vector and on a subset of assistants and versions, so it does not exhaustively cover every tool, artifact type or workflow. The authors acknowledge the attack surface is broader and call for more systematic studies that capture cross-file, cross-service and long-running agent interactions. Empirical results reflect the tested configurations and disclosed vulnerabilities at the time of study.
Implications
Offensively, an attacker who supplies a crafted external artifact or controls a connected service can convert a developer’s AI assistant into an execution shell, achieving credential theft, discovery of sensitive files, privilege changes and persistent access. Because the assistant can adapt and act autonomously, attackers can rely on high-level payloads rather than precise exploit scripts, and can abuse live integrations to inject malicious instructions at runtime. The architectural absence of clear trust boundaries makes these attacks scalable across repositories, community artifacts and connected services.
