Coding Agents and Developer Security

Coding agents — Claude Code, OpenAI Codex, Mistral Vibe, etc. — are all the rage, and with good reason. At the same time, developers might chuckle at the various stories about people using OpenClaw-type personal agents and running into catastrophic problems, like the agent deleting whole directories unexpectedly. Surely, as we are experienced users of technology, we will not let our agents do silly things like that, right?

Right?!?

Particularly with the current generation of coding agent technology, bear in mind that it is not just you and the agent in the mix. It is also whoever developed the skills, plugins, MCP servers, etc. that you are employing.

It is easy to look at something like a SKILL.md file and conclude “it’s just Markdown”. However, to a coding agent, Markdown is executable code. If the skill convinces the agent to invoke a tool that will delete the contents of your C: drive, your protections are down to:

• Any “that tool request looks sketchy” defenses that the agent harness (e.g., Codex) has

• Your own inspection of the tool request, if you have “Ask permission”-style settings enabled

• The fact that, for the love of $DEITY, hopefully you are not running Windows and therefore have no C: drive

Those first two bullets are weaker protections than you might think. For example, in my light Claude Code experiments, Sonnet 4.6 is more than willing to code-generate a chunk of Python, then ask to invoke python3 to execute it. It is unlikely that the agent harness will intuit whether or not some random block of Python is harmful. So now we’re down to my ability to grok a random block of Python and determine conclusively what it does. 😑

Also, bear in mind:

• Skills can include “executable code that agents can run”

• Plugins can register hooks that run JavaScript when the agent harness starts up, at least on some harnesses like Claude Code and OpenCode

• While a skill may be static, a skill in conjunction with an MCP server or tool execution can be dynamic, reacting to what it sees in your environment (since, at present, MCP is largely limited to locally-run servers)

From a developer security standpoint, it is a scary time. Built-in “Web fetch”-style tools give rogue Markdown the ability to exfiltrate something from your developer machine… which is a statement that would have seem farcical just a couple of years ago. And, once MCP gets expanded to support remote-hosted servers, even more avenues open up for agents to be coerced into sending data from your developer machine to semi-arbitrary hosts.

As I continue experimenting with this technology, I will be trying to keep one eye out for these sorts of security concerns. Hopefully, you will too.