It's Not What the Model Writes. It's What the Agent Runs.
Recent threat intelligence details how cybercriminals are using headless coding agent frameworks on compromised hosts to automate source code exfiltration.
The most important shift in AI coding agent security isn’t about what the model writes. It’s about what the agent is willing to run.
Last week a thread popped up on a Russian cybercrime forum showing exactly how that plays out, and it’s a lot more casual than people think.
The setup looked routine at first: another discussion about “cheap Claude APIs”. A few replies in, it had transformed into a working playbook for turning Claude Code into a malware delivery channel.
No vulnerability. No prompt injection. Just a clean setup:
- A “discount Claude API” that’s actually a proxy under the seller’s control (
awstore[.]cloud). - Recommending a
𝚜̲𝚎̲𝚝̲𝚝̲𝚒̲𝚗̲𝚐̲𝚜̲.̲𝚓̲𝚜̲𝚘̲𝚗̲that removes basically every safety check:𝚍̲𝚘̲𝚗̲𝚝̲𝙰̲𝚜̲𝚔̲, no confirmation prompts, wildcard permissions. - Letting the proxy control the responses.
At one point, those responses include a PowerShell loader.
And the agent just runs it. No exploit. No pop-up. No “are you sure?” Just trust doing its job.
What stood out wasn’t the technique. It’s how casually it’s shared. This is happening inside a cybercrime forum, where participants are actively testing the setup on their own machines - comparing APIs, tweaking configs, and sharing what actually works. Some realize the API isn’t even real Claude. Some notice strange behavior. Some mention accounts getting banned. And in between all that - a payload is being delivered through model responses.
That’s the part worth sitting with… This isn’t a sophisticated APT tradecraft. It’s commodity level abuse, packaged as a “config tip”. The barrier to entry is gone.
If this feels familiar, it should. It’s early browser security all over again. You take something that executes external content locally, you give it too much trust, and the client becomes the attack surface. AI coding agents are sitting in that exact spot now: they fetch content, interpret it, and sometimes execute it.
Strip the guardrails and you’re not “using an AI tool” anymore. 𝗬𝗼𝘂’𝗿𝗲 𝗿𝘂𝗻𝗻𝗶𝗻𝗴 𝗮 𝗿𝗲𝗺𝗼𝘁𝗲 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲 controlled by whoever answers your requests.
That’s the real shift here. It’s not about what the model writes. 𝗜𝘁’𝘀 𝗮𝗯𝗼𝘂𝘁 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝗮𝗴𝗲𝗻𝘁 𝗶𝘀 𝘄𝗶𝗹𝗹𝗶𝗻𝗴 𝘁𝗼 𝗿𝘂𝗻. No phishing. No social engineering. Just plugging into the wrong endpoint and pasting a “recommended config”.
What’s missing is the layer browsers spent two decades building: domain reputation, CRLs, extension review, sandboxing, runtime visibility. AI agents are at the start of that curve.
We shared this with Anthropic earlier this week along with IOCs and context. I’m posting it here because the pattern will repeat.
Recommendation and Countermeasures
Four things worth paying attention to:
- 𝗬𝗼𝘂𝗿 𝗯𝗮𝘀𝗲 𝗨𝗥𝗟 𝗶𝘀 𝗽𝗮𝗿𝘁 𝗼𝗳 𝘆𝗼𝘂𝗿 𝘁𝗿𝘂𝘀𝘁 𝗯𝗼𝘂𝗻𝗱𝗮𝗿𝘆. If it’s not an official endpoint, you’re trusting whoever sits behind it to control execution.
- 𝗔𝗴𝗲𝗻𝘁 𝗰𝗼𝗻𝗳𝗶𝗴𝘀 𝗮𝗿𝗲 𝗮𝗻 𝗮𝘁𝘁𝗮𝗰𝗸 𝘀𝘂𝗿𝗳𝗮𝗰𝗲.
𝚍̲𝚘̲𝚗̲𝚝̲𝙰̲𝚜̲𝚔̲+ wildcard permissions is basically𝚜̲𝚞̲𝚍̲𝚘̲ ̲𝙽̲𝙾̲𝙿̲𝙰̲𝚂̲𝚂̲𝚆̲𝙳̲for your agent - 𝗬𝗼𝘂 𝗻𝗲𝗲𝗱 𝗿𝘂𝗻𝘁𝗶𝗺𝗲 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻𝘁𝗼 𝗮𝗴𝗲𝗻𝘁𝘀 𝗮𝗰𝘁𝗶𝘃𝗶𝘁𝘆. This doesn’t show up in code. It only shows up in what the agent actually does.
- 𝗧𝗵𝗶𝘀 𝗶𝘀𝗻’𝘁 𝗮 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗶𝗹𝗶𝘁𝘆. It is vulnerable because of the lack of mature guardrails like domain and extension reputation systems found in browsers.
If you’re running Claude Code, Cursor, or similar tools, the question isn’t “is the model safe?” It’s: who does your agent actually trust?