Vibe Coding Security Risks: What MSPs Inherit From Client Built Apps

A client calls on Monday because their internal quoting app is throwing errors. Nobody on your team has ever seen it. Their ops coordinator built it over a weekend with an AI coding agent, wired it into the CRM with a live API key, and parked it on a VM inside the network you manage. That app is your problem now, and no human ever reviewed the code inside it. Vibe coding security risks stopped being a developer topic the moment AI-written software started landing on networks MSPs are paid to protect.

TL;DR

• The short answer. Vibe coding security risks are the auth gaps, leaked secrets, and injection flaws that ship when an AI writes code nobody reviews.
• The data. Carnegie Mellon's SusVibes benchmark found 61% of agent-written solutions worked and only 10.5% were secure.
• The exposure. Clients build these apps without telling IT, so discovery comes before hardening.
• The move. Put AI-written code in your scope of responsibility in writing, then price the cleanup as work.

What The Research Says About AI-Written Code

The numbers have been consistent across three years of testing, and they haven't improved much.

Veracode's 2026 GenAI Code Security Report put more than 100 models through curated coding tasks and found the pass rate stalled at 56%. The 2025 edition had it at 45% insecure, with Java failing 72% of the time. Models got faster and more fluent in twelve months. They did not get safer.

Carnegie Mellon researchers built SusVibes, a benchmark of 200 real feature requests pulled from open-source projects. When SWE-Agent paired with a frontier model tackled them, 61% of the results were functionally correct and 10.5% were secure. For every ten features the agent shipped, roughly nine carried an exploitable flaw. The researchers also tested the obvious mitigation, adding vulnerability hints to the feature request, and it didn't move the numbers.

The downstream effect is already showing up in the CVE feed. Georgia Tech's Vibe Security Radar tracked 74 AI-linked CVEs through March 2026. Six in January, fifteen in February, then 35 in March alone, more than all of 2025 combined.

Chris Wysopal, Veracode's co-founder, framed the trajectory bluntly in SD Times: "We are compressing time. Years of latent technical debt are now being surfaced in months." His guidance for teams is the part worth stealing: treat AI-generated code like any unreviewed code. Scan it, fix it, never ship it blind.

The Failure Modes That Reach Your Helpdesk

Knowing the aggregate failure rate doesn't help a technician on a Tuesday. Knowing which flaws repeat does.

Credentials Written Straight Into The Code

AI coding agents optimize for working software. A working integration needs a key, and the fastest path to a working integration is pasting the key into a config file. GitGuardian's State of Secrets Sprawl 2026 put the leak rate on AI-assisted commits at 3.2%, against a 1.5% baseline across all public GitHub commits, alongside 28.65 million new hardcoded secrets found in public repos during 2025. Those keys usually belong to systems you manage, which means the blast radius of a client's side project is your RMM, your backup platform, or their production CRM.

Endpoints With No Authentication At All

In February 2026, a public reproduction repo alleged 21 findings in Huntarr, a popular self-hosted app that the community had flagged as looking entirely vibe coded. The headline finding: a settings endpoint that returned a full config dump, API keys and passwords for every connected service, with no authentication required. Two-factor setup routes were reportedly reachable without verification, so an attacker could register their own device. The repo went dark and the self-hosting community told everyone to pull the app offline and rotate every key.

That pattern is the one to watch for. The app itself may be low value. The credentials inside it are not, and an unauthenticated endpoint on an internal VM punches a hole through whatever network controls sit around it.

The Injection Classes Models Keep Getting Wrong

Veracode's testing found generated samples failing to defend against cross-site scripting 86% of the time and log injection 88% of the time. These aren't exotic attacks. They're the ones a first-year appsec course covers, and they show up because a model writing code from a prompt has no reason to imagine a hostile input unless someone tells it to.

Why The Same Flaws Keep Coming Back

These aren't random slips. A study of vibe-coded applications traced the recurring patterns, placeholder logic left in place, unfiltered input, and exposed secrets, back to systematic limits in how agents work: memory that drops context across a long build, objectives optimized for the immediate request rather than the finished app, and security knowledge applied inconsistently. The same researchers found that stronger models and sharper prompting lower the rate without removing the underlying risk. That's the part worth carrying into a client conversation. A promise to be more careful next time doesn't change a failure mode baked into how the tool works, so the control has to sit outside the prompt: review, scanning, and a hard limit on what the app can reach.

Dependencies That Nobody Vetted

Coding agents pull packages with confidence, including packages that don't exist until an attacker registers the name a model likes to invent. A client app assembled in an afternoon can carry dozens of transitive dependencies that never passed through any review, any license check, or any software bill of materials. If you're already running vendor risk management on the tools in your own stack, this is the same problem arriving through a side door.

Watch the same failure modes get found and fixed in a real app:

Why This Lands On The MSP

The people building these apps don't consider themselves developers, and they don't tell anyone what they've built.

Help Net Security reported that 65% of surveyed US employees use AI tools their employer never approved, and 71% of those admitted feeding sensitive data into them: customer records, employee data, internal documents. Only 38% of organizations have a formal AI policy covering any of it. Roughly nine in ten IT and security professionals believe their people are using AI anyway.

So the app gets built, it works well enough for the team that wanted it, and it runs quietly until something breaks or someone finds it. The person who calls when that happens is you. Not the coordinator who built it, not the model that wrote it.

There's a compliance edge to this as well. A client in a regulated vertical who quietly stands up an app handling patient records or card data has changed the scope of their own audit without telling anyone, and the assessor will ask the service provider what controls covered it. Cyber insurance applications ask a version of the same question: does the applicant maintain an inventory of software and enforce change control. An honest answer gets harder when a chunk of the estate was written by an agent over a weekend. Neither of those conversations goes better six months later, which is the argument for finding the apps now rather than after a claim.

Petri's coverage of AI shared responsibility gets the boundary right: an MSP can't own every prompt or business decision a client makes, but it can own the environment around the tool, policy, permissions, identity, and governance. That distinction is worth writing down before an incident forces the conversation, because the default assumption from a client after a breach is that anything on the network was covered by the contract.

Who Owns What When A Vibe Coded App Breaks

This is the table the rest of the internet's vibe coding coverage leaves out. Every article warns developers to scan their code. Almost none of them address the service provider who inherits the code without ever seeing the repo.

Law365's guidance for AI provisions in MSP contracts lands on the same question this table answers: if an AI tool suggests code with a security flaw, who carries it? A standard agreement covering uptime, helpdesk, and device management doesn't answer that. An agreement with a shared responsibility annex does, and it turns an argument into a line item.

The Discovery Pass To Run This Quarter

Hardening comes second. You can't harden what nobody has found yet. This pass takes a couple of hours per client and surfaces most of what's hiding:

1. Sweep internal subnets for web services on non-standard ports, then match every listener to a known asset. Anything unmatched is a candidate.
2. Pull the software inventory for AI coding tools and IDE agents on client endpoints. Those installs mark which teams are building.
3. Check egress logs for API calls from workstations to production systems. A user machine talking to the CRM API on a schedule is usually a script somebody wrote.
4. Ask each department head one question: what did your team build this year that IT doesn't manage? People answer that honestly when it isn't framed as an audit.
5. Scan any repo or shared drive the client gives you access to for committed keys, then rotate everything you find rather than reporting it and waiting.
6. Put every discovered app into the asset register with an owner name attached, so the next incident has a person to call.

Do this once and the inventory stops being a guess. Do it quarterly and you have a service line, plus a defensible record of what was in scope when.

Triaging One After You Find It

Discovery produces a list, and the list needs an order. Sort by what the app can reach rather than by how important the client says it is. An app holding a read-only copy of last quarter's numbers matters less than the one with write access to the CRM, however proud its author is of it.

Start with credentials, because they're the fastest thing to fix and the most damaging to leave. Pull every key the app uses, rotate it, and reissue scoped credentials that can only touch what the app needs. If the app was using a shared admin account, that account was a problem before the app existed.

Then check exposure. Confirm whether the thing is reachable from outside the network, from the guest VLAN, or from any segment its users don't sit in. Most client-built apps need to be reachable by a handful of people, and constraining that is usually a firewall rule and a DNS entry rather than a project.

Only then look at the code, and only if the client is paying for it. Scanning is where the hours go, and hours given away become the expectation. Report findings against the app's owner name in the asset register, with a remediation quote attached. Some clients will pay to fix it. Others will decide the app wasn't worth what it costs to run safely and switch it off, which is a fine outcome and a fast one.

Price The Cleanup Instead Of Absorbing It

Security debt already sits with 82% of organizations, and 60% carry critical debt, up 20% year over year by Veracode's count. AI-written code is accelerating that curve, not creating it. The commercial question for a service provider is whether that acceleration shows up as unbilled hours or as revenue.

Three packages work well here, and they don't require new tooling to start. A discovery and inventory engagement, run quarterly, priced per site. A code review add-on for any client-built app that touches production data, priced per app with a named turnaround. An AI acceptable use policy build, delivered once with an annual review, that names which tools are allowed, where output can be deployed, and who signs off before anything reaches a live system.

That third one does the most work per hour spent. A written policy converts a vague expectation into an agreed boundary, and it gives the technician on the call something to point at when a client asks why their weekend project needs a review before it goes live.

The rest is enforcement, and enforcement is where the shape of your own stack starts to matter. If asset discovery lives in the RMM, the ticket lives in the PSA, the policy lives in a document nobody opens, and the security alert lives in a fourth console, the AI app a client stood up in March gets found in November. Consolidation isn't a philosophy here, it's how the inventory stays current between quarterly passes. That is the same argument behind the MSP security stack discussion, applied to a category of risk that didn't exist two years ago.

What To Tell Clients Who Ask If They Should Stop

They shouldn't, and telling them to stop won't work anyway. The CMU researchers found that structured prompting, real specifications, systematic review, and security scanning cut vulnerability rates meaningfully compared to unstructured generation. The tooling isn't the problem. Shipping without review is.

Give the client three rules and they'll follow them, because they're cheap: nothing built with AI touches production data before a review, no credentials live in code, and every app has a named owner in the asset register. Everything else is refinement.

For MSPs weighing where AI belongs in their own delivery, the same logic holds. Output gets reviewed, credentials stay out of prompts, and the tool is judged on what it produces under scrutiny. That's the standard worth applying to the AI tools MSPs adopt internally too.

The other side of the same wave: a growing share of MSP tooling is now open-sourced and vibe-coded by the practitioners who use it. Ed Mozley runs infrastructure for a London law firm by day and built FreeITSM at his kitchen table in months - a 20-module, free-forever open-source ITSM platform already running in production. Built with review and shipped with discipline, the same workflow that produces the liabilities above produces real tools. He tells the story on the OpenMSP podcast:

Vibe coded apps aren't going back in the box. Clients will keep building them, faster every quarter. Communities like OpenMSP share more info about such cases. If you'd like, join OpenMSP here. It's peer-driven and vendor-neutral.