Coding agents crossed a line in the last two years that a lot of process has not caught up with. They do not suggest a line at a time any more. Given a task, they read the repository, plan a change across several files, run the tests, read the failures and try again. The developer's job moved from writing the code to reviewing work that is already done.
That shift is where the security problem lives, and it is not really a model problem.
What Coding Agents Actually Do Now
A coding agent takes a task in plain language, analyzes the relevant code, forms a plan and executes it. Ask for email verification on an Express API and it will find where routes and middleware are defined, write the migration for user records, add the middleware, implement the verification endpoints, write tests, run them and fix what fails. Dozens of file edits and terminal commands, no approval step between them.
Every agent, whatever the product name, is built from the same four parts. A planner that decomposes the task. An execution environment with a terminal, a file system and usually git. A feedback loop that carries test output and errors back into the plan. A context layer that decides what the model gets to see. The execution environment is the real dividing line between an agent and a chatbot that emits code, because it lets the agent check its own work by running it.
The tasks they handle reliably are broader than people expect: feature work across multiple files, bug diagnosis and repair, refactoring, test generation, documentation, dependency upgrades, performance work.
Where The Vulnerabilities Come From
Agent written code can carry SQL injection, cross site scripting, insecure deserialization and broken authentication checks. That much is well documented. What gets missed is the cause.
These flaws usually do not appear because the model cannot write secure code. They appear because the task description never said security was in scope. A prompt that reads "add a search feature" and says nothing about sanitizing input frequently produces code that is vulnerable to injection, and the agent had no signal that this mattered. It optimized for the requirements it was given.
That is a specific and useful diagnosis, because it means the fix is not waiting for a better model. Agents are strong on stated requirements and weak on assumed ones, so the flaws that survive into production are the ones nobody wrote down.
Feature Level Requirements Beat General Warnings
The instinct is to bolt a paragraph of security boilerplate onto every prompt. That produces less than you would hope. Broad threat model language tends to generate security shaped work, plans and tests that read as though someone thought about it, without the specific flaw actually being addressed. Worse, output that looks reviewed invites less review.
What works is narrower. For the change in front of you, state the threat, the attack path and the countermeasure you require. Write outcomes that can be verified rather than principles that cannot. "Parameterize every query built from the search string" is checkable. "Follow security best practices" is not.
This is the same lesson that shows up in document extraction, where a single global accuracy target tells you nothing and per field validation tells you everything. A general instruction has nothing to check itself against.
Reviewing Agent Output Like A New Contractor
The teams getting good results converge on the same posture. Agent output is treated exactly like work from a competent new contractor: a functional review, then a separate security review, before anything merges.
In practice that means automated scanning on every agent branch, before a human ever opens the diff. It means the vulnerability categories that matter for your system live in the task template rather than in one senior engineer's head. Some teams run a second agent tuned specifically for vulnerability detection as a dedicated pass.
Code quality metrics like complexity and test coverage come out roughly comparable between agent and human code when the agent can see the project's linting and test configuration. The differences show up in the subtler places, naming, comment quality, architectural coherence across a large change. Those are exactly the places human review still earns its keep. The full breakdown of how coding agents plan, execute and where they go wrong covers the architecture and cost side of this in more detail.
The Takeaway
The agent is not the weak link. The specification is. Every assumption you leave out of the task description is a requirement the agent was never asked to meet, and security assumptions are the ones teams leave out most often because they were never written down for human developers either. Nobody had to tell a senior engineer that the search box gets typed into by strangers.
Write it down. Then review the result like you would review a contractor's first pull request.
Top comments (0)