AI coding tools expanded your attack surface beyond the code
For years, the security rule in software development was simple: secure the code, secure the system. That rule no longer holds.
According to the 2025 Stack Overflow Developer Survey, more than 80% of developers are using or planning to use AI tools in their development process, with over half using them daily. Microsoft CEO Satya Nadella noted that as much as 30% of Microsoft’s code is now written by AI. The tooling has changed faster than the security thinking around it.
What the old model misses
Most application security approaches are built to analyze code after it exists: static scans, dependency checks, runtime protections. Some teams have added prompt engineering to encourage more secure code generation upfront. But in an AI-native development stack, the code artifact is only part of the picture.
The rest of the stack includes AI agents operating independently, plugins extending model capabilities, MCPs introducing new automation layers, external API integrations with minimal oversight, and identity and access controls governing what an AI tool can see or do. None of these sit inside a traditional code scanner.
Shadow AI is the new shadow IT
The same survey found that more developers distrust AI-generated output than trust it, yet adoption keeps climbing. The bigger concern is that adoption is spreading beyond engineering. Sales, marketing, finance, and operations teams are running AI agents on employee endpoints, often outside any formal approval process, with access to proprietary data and customer information.
The artifacts they produce carry risk too: PowerPoint presentations, analyzed spreadsheets, reports, and summaries that may contain sensitive data or create downstream exposure. This mirrors the shadow IT problem, but at a significantly faster pace.
What a breach looks like now
The author argues that a breach no longer needs to exploit application code. It can start with a compromised employee endpoint, an over-permissioned integration, or persistent memory poisoning, and escalate quickly to expose credentials, source code, or sensitive data, or install backdoors for future access. These attacks move faster than code review cycles and sit entirely outside the codebase.
The piece also notes that recent model developments, citing Claude Mythos as an example, can now find and prevent code vulnerabilities faster and more reliably than before. The author’s position: code vulnerabilities will become a more manageable challenge sooner than most teams expect. The harder problem is the infrastructure surrounding AI-driven development.
The practical shift
The article calls for three changes: visibility into which AI tools are running, how they are connected, and what data they can access; policy enforcement embedded directly into tools and workflows rather than documentation that no one reads in the moment; and security controls that operate alongside AI systems continuously rather than relying on static point-in-time analysis.
If you are responsible for any part of your stack’s security posture, the argument here is worth reading in full. The perimeter moved, and most teams have not caught up.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
