AI-Generated Code Is Shipping Vulnerabilities by the Thousands. Marketing Teams Need a Scanner, Not a Policy.

Marketing teams are building their own internal tools now. Dashboards, scraping scripts, lead-routing utilities, Slack bots, all generated by an AI coding agent in an afternoon instead of filed as an engineering ticket that sits in a backlog for a quarter. That shift is real and it is not reversing. What most marketing orgs got wrong is the fix they reached for. They wrote a governance policy. Policies do not catch SQL injection. Scanners do.

The Numbers Stopped Being Hypothetical

For the first year of the vibe coding boom, the security risk was theoretical, the kind of thing a CISO raised in a meeting and everyone nodded at before moving on. That window closed. Security researchers scanning close to 5,600 vibe-coded applications found more than 2,000 vulnerabilities and over 400 exposed secrets sitting in code that was already live. Veracode ran more than 100 large language models through security-sensitive coding tasks and found 45 percent of the output introduced an OWASP Top 10 vulnerability. Independent audits put the share of AI-built applications shipping with at least one critical flaw at 62 percent.

end

That last number matters most. The CVE count traceable to AI coding tools did not creep up, it climbed six to fifteen to thirty-five in three consecutive months. That is a curve, not a blip, and it tracks almost exactly with how many non-engineers started shipping production code without anyone downstream checking it.

Why the Policy Document Never Stood a Chance

Most marketing orgs that took vibe coding seriously wrote a review process. Someone from engineering signs off before an AI-generated tool touches customer data. It reads well in a governance deck and it fails in practice for one reason: it does not scale to the speed it is supposed to govern. A marketer can generate, iterate, and deploy a working internal tool in the time it takes to schedule the review meeting. The policy assumes the bottleneck is still human code review. The bottleneck moved to the AI agent, and the AI agent does not wait for a calendar invite.

A review board also cannot see what it cannot read. Most marketing operations staff cannot evaluate whether a generated authentication flow is sound or whether an API call is leaking a key into a log. Handing a non-technical reviewer a code diff and calling it governance is theater, not security. The gap is not process discipline. It is the absence of a machine that reads the code as fast as the code gets written.

The Scanning Stack That Actually Fits the Workflow

The fix is the same one application security teams already run, compressed into the same loop the AI agent already operates in. Three layers, and marketing ops needs to know what each one actually catches:

end

What changed this year is that this stack stopped being a separate tool marketing ops has to bolt on. Anthropic's Claude Security plugin, in beta since July, runs a multi-agent vulnerability scan from inside an existing Claude Code session and turns the findings into patch files a human reviews before applying. That is the pattern worth copying regardless of which coding agent your team standardized on: the scanner lives in the same terminal session as the generation, not in a separate security team's backlog. Tools like OX Security's VibeSec take the same idea further, embedding live organizational context, API behavior, cloud config, current secrets exposure, directly into the generation step so the agent gets steered away from the vulnerable pattern before it ever writes it.

The practical move for a marketing team is not to pick a perfect enterprise AppSec platform. It is to make sure whatever coding agent your team uses has a scanning step wired into the same session, and that nothing generated internally reaches a shared server, a customer list, or a live API key without clearing it first.

What to Put in Place This Week

end

None of this requires marketing to become a security team. It requires marketing to stop treating a governance policy as a substitute for a tool that actually reads the code. The teams already shipping AI-generated internal software and getting away with it are not the ones with the best-written policy. They are the ones who put a scanner in the loop before the risk had a chance to become an incident.