10 posts tagged with "AI coding agents"

A web route has an obvious attacker: whoever sends the request. A tool in an MCP server or an AI agent looks different. Its arguments are filled in by a model, the model is working for your user, and the code reads as if the caller were trusted. That is the mistake. The model picks the arguments from everything in its context, and part of that context can be written by someone else.

So we stopped treating tools as internal functions. Since Vulkro 0.30.0, MCP server tools and AI agent tools are entry points, the same as HTTP routes: a tool whose argument reaches a shell, a query or a file is reported, with the path from the argument to the call.

Ask a team which AI their product uses and you will usually get one answer: the provider on the invoice. Then look at the code. There is the SDK everyone knows about, a second provider someone added for embeddings, a model name hardcoded in a background job, a LangChain agent in an internal tool, a .pt file checked into a test folder, and an MCP server declared in a config file that nobody remembers adding.

None of that is unusual. AI components arrive the way dependencies always have: one import at a time, by whoever needed them that week. The difference is that more people now want a list. Regulators, customers' security reviews and your own incident response all start with the same question, and "we use one provider" is rarely the full answer.

An AI coding agent can write a new endpoint, its handler and its database query in the time it takes to read this paragraph. It will compile. It will probably pass the tests it wrote for it. Whether it checks that the caller owns the record it returns is a separate question, and nobody asked it.

That gap is the security problem with AI coding agents. Not that they write worse code than people, but that they write a lot of it, quickly, and the review that used to happen while a person typed it no longer happens at all.

"Paste the repo into the model and ask it to find the security bugs" has become a common first attempt at AI-assisted security review. It is easy to try, and the first run is often impressive: the model names a plausible injection, explains it well, and suggests a fix.

The trouble starts on the second run. And the third. And when somebody asks what it did not look at.

Vibe coding security is not a new kind of security. The apps that come out of AI app builders and AI coding agents fail in the same ways hand-written apps do. What changes is the rate. An app that would have taken a team a month now takes an afternoon, and nobody on that afternoon was thinking about who else can call the endpoints.

The bugs are also surprisingly consistent. Pages that look locked but are not. A database queried straight from the browser with nothing on the server side deciding who sees which row. A secret key in the JavaScript bundle. A token that is read but never verified. A record fetched by id with no check on whose it is.

This post goes through those five, with the research behind them, then gives a pre-ship checklist and the commands to check an app before it goes live.

Supply-chain security is usually sold as a list problem: keep an inventory of your packages, match it against a vulnerability feed, patch what turns up. That works for the bug a maintainer shipped by accident. It did very little for the attacks of 2025, because in almost every one the malicious version was installed and running before any feed knew it existed.

The 2025 compromises were not vulnerabilities. They were programs. Each one read a credential, called a network endpoint, ran a shell command or republished itself, and each of those is a shape you can read in code without waiting for anyone to publish an advisory.

An AI coding agent adds a tenantId parameter to findById, updates the two call sites in the file it was looking at, writes a cheerful summary and stops. There were five call sites. The other three are in files it never opened, they still pass one argument, and in a dynamically typed codebase nothing will complain until a request reaches one of them in production.

This is the most ordinary way an agent's edit goes wrong. Not a subtle logic error, not a security hole: a change whose consequences live somewhere the agent did not look. People make the same mistake, but people tend to make small changes and run the build. Agents make wide changes quickly and often declare victory before anything has been run.

Watch an AI coding agent fix a small bug. It searches for the function name and gets forty matches across comments, tests and unrelated files. It opens the file with the best-looking match and reads all 900 lines. It searches again for the callers, opens three more files, and reads those whole as well. The fix it finally makes is four lines.

Every one of those reads stays in the conversation, and the conversation is sent again on every turn. The agent was not careless. It used the tools it had, cat, grep and sed, and none of them can answer the question it was really asking: show me this function, and who calls it.

Ask an AI coding agent to "check this repository for security issues" and watch what it does. It lists the tree. It opens the route files, then the middleware, then the database layer, then a few helpers it was not sure about. Each file goes into its context window. By the time it has an opinion about one endpoint, it has paid to read forty files that had nothing to say.

That is not a flaw in the agent. It is the only way a model can look for a vulnerability on its own: by reading. And reading a codebase is the most expensive thing you can ask a model to do.

An MCP server is a program your AI assistant starts on your machine, with your environment, your files and whatever tokens you put in its config. It is installed by name, often re-downloaded on every launch, and its tool descriptions are read by a model that does what text tells it to. In most teams nobody reviewed any of that. It was one line in a JSON file, pasted from a README.

In 2025 attackers noticed. Each of the incidents below is public, each one is small, and together they describe the whole surface: the package, the transport, the tool and the agent's own reach.