{"id":2472,"date":"2026-06-22T11:29:37","date_gmt":"2026-06-22T11:29:37","guid":{"rendered":"https:\/\/silvybrand.com\/?p=2472"},"modified":"2026-06-22T11:29:37","modified_gmt":"2026-06-22T11:29:37","slug":"vibe-coding-security-risks-apps","status":"publish","type":"post","link":"https:\/\/silvybrand.com\/?p=2472","title":{"rendered":"Read this before you vibe-code another app"},"content":{"rendered":"


\n<\/p>\n

\n
\n

Bob Starr was delighted with his vibe-coded website. \u201cBoomberg\u201d<\/a> showed how much US tax money is going to tech companies, and Starr launched it online immediately after making it. It wasn\u2019t until months after the site went live that he realized there was a problem: a hidden SQL injection risk. It could\u2019ve left the site open for an attacker to read or alter data they shouldn\u2019t have access to.<\/p>\n<\/div>\n

\n

\u201cIt was just a glaring oversight on my part. It was a complete blindspot in my state of learning this new technology and understanding it, and I\u2019m sure there are others making the same mistake,\u201d said Starr, a project manager in the tech sector.<\/p>\n<\/div>\n

\n
\n

\u201cIt was a complete blindspot in my state of learning this new technology and understanding it.\u201d<\/p>\n<\/div>\n<\/div>\n

\n

Starr fixed the issue, but he isn\u2019t alone. Across social media, there are horror stories about vibe-coded apps full of security vulnerabilities. Jer Crane, founder of PocketOS, posted on X about an AI coding agent<\/a> wiping out his company\u2019s production database. Joe Procopio, a serial entrepreneur and former developer, vibe-coded a web app<\/a> to privately show demos of other apps he\u2019d built. Hackers came, so he took the app down. \u201cNow I do demos the old fashioned way, from my local machine over Zoom,\u201d he wrote. \u201cIt\u2019s sooo 2023.\u201d<\/p>\n<\/div>\n

\n

We\u2019ve entered a new \u201cera of personal software,\u201d<\/a> as The Verge<\/em>\u2019s David Pierce said, where anyone can use AI to create their own private apps that can do exactly what they want. But with it comes a new era of security issues. Apps may be easy to build, but they\u2019re difficult to secure \u2014 especially in a world where AI can also be used to attack them.<\/p>\n<\/div>\n

\n

\u201cMy general core take is that vibe coding is not bad because amateurs can build software. That\u2019s actually the good part,\u201d says Gabriel Bernadett-Shapiro, distinguished AI research scientist at AI-powered cybersecurity firm SentinelOne.<\/p>\n<\/div>\n

\n

The danger, he says, is when a personal app drifts into the realm of business software and stores shared, hosted data without anybody realizing that shift has happened. And, he says, the calculus changes when vibe coding moves away from local apps for tracking migraines or meals or package deliveries and enters the realm of apps that handle customer logs, medical data, financial records, or internal documents.<\/p>\n<\/div>\n

\n

\u201cThose need to be held to a different standard. Even if it was built by one person in an afternoon. Even if the software creating the software was trivial. The moment that it touches other people\u2019s personal data, then that\u2019s when I think the standard changes.\u201d<\/p>\n<\/div>\n

\n

Jack Cable, CEO and cofounder of Corridor (the security platform built for AI-native software development), agrees.<\/p>\n<\/div>\n

\n
\n

\u201cVibe coding is not bad because amateurs can build software. That\u2019s actually the good part.\u201d<\/p>\n<\/div>\n<\/div>\n

\n

\u201cVibe coding is great for lower risk things,\u201d Cable says, such as a prototype, or a fitness tracker that isn\u2019t super sensitive. But financial records deserve more scrutiny, he says, as does anything on the public internet. \u201cAre you exposing any of your own or other people\u2019s data there?\u201d he asked. \u201cThink through what the threat model looks like, and if you\u2019re not sure if something you\u2019re doing is secure, better safe than sorry.\u201d<\/p>\n<\/div>\n

\n

That is what Max Segall, chief operating officer at the crypto wallet firm Privy, had done after he vibe-coded EzRun as a fun way of rewarding his kid with $10 in Ethereum every time the two went running together. Thankfully, a colleague found a critical flaw that would have let anyone modify user accounts to gain access \u2014 before launch.<\/p>\n<\/div>\n

\n

In a more concerning and high-profile case in late January, a developer named Matt Schlicht launched a viral social network called Moltbook. It was built entirely for AI agents, and he did not write<\/a> a single line of code. Within days, researchers at the security firm Wiz says it found the app\u2019s entire production database wide open<\/a>, exposing tens of thousands of email addresses and private messages. Moltbook patched the bug shortly after being told about it, but this wasn\u2019t a one-off. Wired<\/em> reported that researchers at cybersecurity firm Red Access found roughly 5,000 publicly accessible apps<\/a> built with popular vibe-coding tools that had no authentication, and close to 2,000 of those appeared to be leaking sensitive data like medical and financial information, strategy documents, and even logs of chatbot conversations.<\/p>\n<\/div>\n

\n

To be fair, plenty of professionally made pre-AI software is woefully insecure, too. But just as vibe coding exponentially increases the number of apps being produced, the number of security risks is also likely skyrocketing. And it adds the risk of overconfidence. When an AI tool tells you code is secure, it\u2019s easy to believe it.<\/p>\n<\/div>\n

\n
\n

\u201cIf you\u2019re not sure if something you\u2019re doing is secure, better safe than sorry.\u201d<\/p>\n<\/div>\n<\/div>\n

\n

And in a normal vibe-coding session, nothing stops to check on its own unless you\u2019ve installed something that has, which most casual coders have not. The build just keeps going. The security tools that exist have to be invoked. While Claude Code has a \/security-review command that scans for vulnerabilities, you have to ask it to do so. There\u2019s an automatic version, but only if you set it up<\/a> to run on pull requests<\/a> in advance, which is something that most casual builders aren\u2019t doing.<\/p>\n<\/div>\n

\n

OpenAI\u2019s own coding agent Codex has a built-in security agent, Codex Security, that scans commits as they land and re-scans its own proposed patches, but it\u2019s aimed at developers with real version-control workflows, not someone chatting an app into existence. For everyone else, the takeaway is simple: You have to prompt for security up front when you build, and again at the end, especially, any time the tool has access to data you care about.<\/p>\n<\/div>\n

\n

\u201cA lot of security is contextual,\u201d Cable says, so while it definitely doesn\u2019t hurt to run a coding agent\u2019s own review, he cautions against having a false sense of security from it, especially when the agent doesn\u2019t understand your threat model, or you haven\u2019t given it the correct guidance.<\/p>\n<\/div>\n

\n

Bernadett-Shapiro says that his biggest concern is not buggy AI-generated code, but a lack of authentication, something developers may not think about when they transition an app they run locally into the cloud with a bunch of configuration options they don\u2019t understand, leading to sensitive data being exposed. This is the failure that worries him most, and for good reason: Apps that run fine locally put on the cloud can be like leaving a box of secrets open on the sidewalk \u2014 something researchers keep finding.<\/p>\n<\/div>\n

\n

AI is good at finding bugs when prompted. There have been improvements in models with things like Mythos, the same Anthropic model that set off alarm bells for how easily it finds vulnerabilities to attack, which can also be used to harden apps vibe coders are building. Bernadett-Shapiro says GPT-5.5-Cyber, or even the base models of other applications, can assess the security and identify issues in an app that even a skilled developer may have looked over. Of course, he points out that people may not understand security tradeoffs they\u2019re making or even ignore warnings as acceptable risk.<\/p>\n<\/div>\n

\n
\n

\u201cA lot of security is contextual.\u201d<\/p>\n<\/div>\n<\/div>\n

\n

Some of the scaffolding is starting to exist. OWASP, the nonprofit behind many web security standards, has published an AI security verification standard<\/a> aimed at organizations. Firms like Trail of Bits have started releasing \u201cskills,\u201d add-on instruction packs that point a coding agent at specific security tasks, like flagging insecure default settings or hardcoded passwords before they ship. Skills have to be specifically triggered, so they don\u2019t fit very naturally into the flow of development, Cable says, and it\u2019s hard to keep them updated and synchronized across coding agents and as the codebase changes.<\/p>\n<\/div>\n

\n

Beyond that, skills can cut both ways, because malicious skills also exist.<\/p>\n<\/div>\n

\n

In February, 1Password\u2019s Jason Meller examined the most downloaded skill on a popular OpenClaw skill registry and found that it directed users to install a dependency that ended up being malicious itself<\/a>. It\u2019s still the Wild West out there and can be difficult to tell whether a skill will harden your app or hand an attacker your credentials.<\/p>\n<\/div>\n

\n

The potential of insecure vibe-coded apps isn\u2019t a problem limited to hobbyists. Cable says engineers and even sales and marketing teams at big companies are now shipping far more agent-written code than before. Security teams need baseline visibility into how the agents are being used, he says, as well as guardrails that get enforced \u2014 either through skills or through products like the one Corridor sells, which aim to stop flaws before the code is even written.<\/p>\n<\/div>\n

\n

For individuals, Cable\u2019s guidelines are much simpler: Be aware that a model running locally on your own computer is far less risky than one made public, especially if it contains sensitive data.<\/p>\n<\/div>\n

\n

\u201cLiterally overnight, the way most companies produce software has changed completely,\u201d Cable says. He\u2019s not especially worried about the coding agents themselves as long as they\u2019re given the right guardrails in which to operate. The models themselves are increasingly built on a memory-safe stack that eliminates entire classes of vulnerabilities to begin with. \u201cI do think there is reason to be optimistic here,\u201d he says.<\/p>\n<\/div>\n

\n

Government affairs specialist Jeff Rothblum vibe-coded an app for tackling mountains of tedious data entry with security in mind. He thought about what information the app holds, how sensitive it is, and what could happen if it got out. It\u2019s a striking approach because it is so rare, and because the ground beneath us is shifting so quickly.<\/p>\n<\/div>\n

\n

While working as head of government affairs and strategy at Lilt, he had to submit input forms to various government committees to get ideas into appropriations bills. No two forms are alike, so lobbyists may submit dozens or even hundreds of unique ones in a six-week period. After eight 75-hour weeks, and a layoff, he built a tool in case he ever had to do this again. It\u2019s an app that scrapes links and due dates into a single dashboard and uses an LLM to prepopulate each form, so users only need to review and edit it (and paste in an account number) before submitting.<\/p>\n<\/div>\n

\n
\n

Vibe-code the app of your dreams, but think through what data the app is storing and has access to and what could go wrong.<\/p>\n<\/div>\n<\/div>\n

\n

He was well aware of the risk because he didn\u2019t write his own code. \u201cThe last time I wrote code was probably in undergrad in 2006 writing Fortran to analyze fluid flows as an aerospace engineer,\u201d Rothblum told The Verge<\/em>. The biggest risk is that companies could inadvertently leak strategies or sensitive lobbying rationale, which stay private even when the filings are public. He\u2019s mitigating this risk by running regular security reviews in Claude, keeping user data local rather than on his servers and building toward stricter retention safeguards.<\/p>\n<\/div>\n

\n

He has vibe-coded his app to clear the browser and is upfront about the page sending data to Claude, linking to its retention policy. He\u2019s working on a version of the app in which nothing a user types is stored by AI, even briefly, and a separate version that would let users route everything through their own LLM rather than his Claude instance.<\/p>\n<\/div>\n

\n

While Rothblum has thought of building a broader lobbying intelligence tool, he says that if he does start working with more sensitive data, he intends to shell out four to five figures to pay an actual security engineer to review his code.\u201dI\u2019m happy with open-source stuff and I\u2019m happy with ephemeral stuff, but everything else kind of scares me,\u201d he says.<\/p>\n<\/div>\n

\n

It is ideal to have a human expert review code, but Cable says that\u2019s becoming a bottleneck. The open question, he says, is what the world looks like when most code ships without any human reading it and how we secure that world.<\/p>\n<\/div>\n

\n

For now, the answer for the rest of us is smaller and more within reach: Vibe-code the app of your dreams, but think through what data the app is storing and has access to and what could go wrong. Ask it to build it with security in mind, and run code reviews after each change, including the patches the AI writes itself. Pay extra close attention before you move it from your own device into the cloud or give it access to any sensitive data or accounts. The difference between a fun project and a horror story starts with knowing what questions to ask.<\/p>\n<\/div>\n

Follow topics and authors<\/strong> from this story to see more like this in your personalized homepage feed and to receive email updates.<\/span><\/p>\n