AI coding tools have done something nobody planned for: they've made the security review cycle the bottleneck. Not CI. Not deployment. Security.
Snyk's latest research into AI agent security puts hard data behind what a lot of engineering teams are quietly feeling — velocity went up, security coverage didn't. The gap between "code is written" and "code is safe to ship" has never been wider.
"AI is shipping code faster than security was built to handle."
That's not a warning about some future state. It's a description of now.
What actually changed
Traditional appsec was built around a human development cadence. Quarterly pentests. Code review before merge. Manual triage of scanner output. It worked — roughly — when a team of ten engineers shipped features over weeks.
AI agents don't work on that cadence. They generate working, testable code in minutes. An agent-assisted sprint can produce more surface area than a traditional team shipped in a quarter. The security tooling inherited from the pre-AI era was never stress-tested at this throughput.
The specific gaps Snyk flags:
- Pentesting frequency hasn't scaled. Most orgs still run penetration tests on a fixed cycle — quarterly or annually. AI-generated code that ships weekly never gets tested.
- AI agents introduce novel attack vectors. Prompt injection, tool misuse, insecure context passing — these don't show up in traditional SAST rules written for human-authored code patterns.
- Dependency surface is exploding. AI assistants pull in packages to solve problems fast. The dev doesn't always audit what got added. Snyk's scanner data shows dependency counts rising sharply on AI-assisted repos.
- Security feedback is too slow. When a vuln surfaces weeks after an AI agent wrote the code, no one remembers the decision context. The fix is blind surgery.
The real problem is the model, not the tools
Individual scanners aren't the problem — most teams already have them. The problem is that security was architected as a gate at the end of the pipeline. AI moved the productive work so far left that the gate is now almost always playing catch-up.
Snyk's argument is that security needs to move to where AI agents operate: inline, in the IDE, in the agent loop itself. Not "scan after commit" — security signals integrated into the moment of generation.
This is a meaningful shift. It means treating your security tooling as part of your AI agent's context, not a separate audit step.
What to do
If you're using AI coding assistants:
- Add Snyk (or equivalent) as a step in your AI-assisted flow, not just in CI — the feedback loop needs to close before the code leaves the agent session
- Audit your AI-generated PRs for novel dependency additions; your existing alert rules won't catch everything
- Review whether your pentest cadence reflects your actual shipping cadence — if you're shipping AI-generated code weekly, a quarterly pentest is archaeology, not security
If you're running AI agents autonomously:
- Treat tool scope like a least-privilege problem — agents should not have write access to production systems by default
- Instrument for prompt injection patterns at the boundary layer; this is a class of attack your traditional WAF won't see
- Make security a first-class input to the agent, not an afterthought in post-deployment review
If you're a security team trying to keep up:
- The argument for continuous automated security testing just got a lot stronger — build the business case now
- Look at DAST tooling that can exercise AI-generated API surfaces, not just static analysis
The shift isn't optional. The code is already shipping.
Source: The New Stack — AI is shipping code faster than security was built to handle
✏️ Drafted with KewBot (AI), edited and approved by Drew.