TL;DR — Key Takeaways
- Approval is no longer the finish line. A sanctioned AI coding platform can quickly expand through MCP servers, connectors and data sources that were never reviewed.
- Speed can amplify insecure code. AI-generated software may be functionally correct while still introducing vulnerabilities that faster delivery cycles fail to catch.
- Security teams need to monitor tool drift continuously, review new connections, assume some generated code will fail security checks and make approved workflows faster than unsanctioned alternatives.
Security teams know how to handle shadow IT. Audit what’s running, block what isn’t approved and build policy around the list. The assumption is that if you’ve approved the tool, you’ve contained the risk.
AI coding tools break that model. They don’t sneak in the back door. They walk in the front door and then expand in ways nobody signed off on.
Unchecked Access at Scale
AI-powered coding tools are hungry for access. They connect to systems, pull context and push changes. The more access they have, the more useful they are, but also the harder they are to govern.
Claude Code illustrates this tension. It is fully approved inside a growing number of organizations, reviewed and sanctioned by security. The Model Context Protocol (MCP) servers it connects to are a different story. A developer can wire up a new connector in minutes into a database, a chat workspace, a ticketing system or a file store. That connector usually doesn’t go through the review the platform did. Sometimes it isn’t reviewed at all.
This played out last year in several cases. Code was inserted into an update of postmark-mcp, a widely used package connecting AI clients to the Postmark email service, and began blind-copying corporate emails to an outside address. In another case, attackers embedded SQL commands inside support tickets submitted to a company running Supabase’s Cursor agent. The agent followed the instructions and leaked sensitive tokens.
The platform remains sanctioned, but the risk surface around it doesn’t. Instead of “is this tool approved?” the question for security teams becomes “what has this approved tool been turned into?” New MCP connections rarely trigger formal reviews and fall between teams. Security doesn’t know they exist. Engineering and IT each assume the other, or the platform provider handles it.
The Velocity Trap
Beyond connector sprawl, there is a second issue that amplifies risk: the quality and security of AI-written code.
Vibe coding is useful. It shortens the distance from idea to working prototype, and in plenty of cases, it’s a faster route to production. But speed isn’t the same thing as quality. AI tends to be bad at two specific tasks: writing tests and writing secure code.
A Carnegie Mellon study quantified that gap. Researchers tested AI coding agents against real-world software engineering tasks pulled from open-source projects. On the hardest tasks, 61% of the AI-generated solutions were functionally correct. Only 10.5% were secure. Functional and secure are different bars. Most of what’s shipping clears the first and misses the second.
The CMU researchers used a benchmark called SUSVIBES specifically designed to test vibe coding workflows. They found that adding security prompts or vulnerability hints actually degraded performance without fixing the security flaws. Because prompting treats security as a suggestion and not a rule, a persistent agent or a prompt injection will find a way around it. If the model’s context window can’t hold the fix, it has to happen at the infrastructure and protocol layer.
Speed makes both weak spots worse. Shorter review cycles leave less room to catch what untested, insecure code lets through.
When Tool Sprawl and Bad Code Converge
In isolation, security teams understand both risks. They know vibe-coded output needs scrutiny and unsanctioned tools are a governance headache. The real danger emerges when both show up in the same workflow at once. The result is a sanctioned coding platform that is extended through unreviewed connectors, producing fast but insecure code heading to production faster than anyone can review it.
The sharpest security teams have stopped treating these as separate problems. Historically, application security owned bad code and corporate security chased down unsanctioned SaaS. Agentic platforms have combined the threats. When an AI agent autonomously pulls in an unvetted community tool to fulfill a developer’s prompt, it creates a shadow tooling footprint and introduces insecure runtime logic at the same time.
Build a Posture for Tool Drift
Locking AI coding tools down isn’t realistic. Banning them tends to push the behavior further out of view instead of stopping it. To establish visibility without halting development:
- Treat new MCP connections the same way you’d treat a new agent going into production. Give them a risk review, not a rubber stamp.
- Approval isn’t the finish line. Monitor what these connections actually do after they’re live, not just what they were approved to do.
- Assume some of this code will ship with flaws. Know when it happens and undo it fast.
- Developers route around slow processes. If the sanctioned path takes weeks and the unsanctioned one takes minutes, you already know which one wins. Make the approved path faster.
Build a security posture that holds up when an approved tool becomes something you never reviewed.
