TL;DR - The thread that topped r/sysadmin this week, "User vibe coded enterprise apps", has around 530 upvotes and 223 comments, and every one of them recognises the pattern: staff building working apps with AI in an afternoon and asking for near-privileged access to your tenant, unable to say where the data will live or what it will encrypt with. This is not the 2019 version where someone bought a SaaS subscription, and the response is not a ban. What you need to do: run a 30-minute discovery pass across finance, cloud consents and DNS, ask every submitted app three questions about data, auth and ownership, and give staff a sanctioned path with guardrails, because the unofficial path is already in production.
By The Numbers
| Item | Value |
|---|---|
| "User vibe coded enterprise apps" (r/sysadmin) | Posted 5 November 2026, ~530 upvotes, 223 comments |
| Top comment's verdict | 369 points: "It is the new excel macro nightmare." |
| What the poster keeps seeing | Apps that are "only simple automations" but ask for near-privileged access to the tenant |
| What the builders cannot answer | What encryption it uses, where the data is stored, that it's linking to external APIs |
| The earlier warning shot | "Shadow vibe coder in my department", ~1,700 upvotes, four months ago: customer data on a personal Supabase account |
| Your discovery budget | 30 minutes for the first pass, one conversation per app after that |
I spent longer than I should have in an r/sysadmin thread this week, which is usually a sign the industry has hit one of its recurring nerves. The title was "User vibe coded enterprise apps", and the poster's complaint was specific enough to be useful: user after user bringing them vibe-coded AI apps, often simple automations, all asking for near-privileged access to the tenant. They cannot say what encryption the app uses. They cannot say where the data will be stored. Half of them do not realise the thing is linking to external APIs at all.
223 comments later, nobody in the thread had a clean answer, because the honest answer is that this wave cannot be blocked, only discovered and shaped. That is what this piece is: a discovery audit you can run this week, and the three questions every submitted app has to answer.
Let me walk you through what changed, where these apps are hiding, and how to get ahead of the next one before it has your customer data in it.
The new excel macro nightmare
The top comment, 369 points, called it the new excel macro nightmare, and it is the right frame. Every IT department older than fifteen years remembers the era of VBA macros built by finance staff, sharing workbooks full of customer figures, running on a machine nobody backs up, maintained by someone who has since left. The business loved them. IT was never asked.
What changed is the size of what they can build. A macro automates a spreadsheet. An afternoon with an AI coding tool produces a web app with a login screen, a database and a webhook into your CRM, hosted on the builder's own domain. The r/sysadmin poster who wrote the earlier companion thread four months ago, about 1,700 upvotes' worth of horrified agreement, found exactly that: a freelance junior dev vibe-coding a webapp for three months, customer data and private contracts emailed to him and loaded straight into a personal Supabase account, a repo wired to push to production, and when asked where all the customer data was stored, he had to go and check. The CEO's response to the IT manager raising it: you were busy, let it go.
That last line is the actual risk. Not the tool. A CEO who has decided discovery is somebody else's problem.
What is different from the shadow IT we already had
I wrote about traditional shadow IT earlier this year, and the diagnosis then was procurement: departments buying SaaS on a credit card, outside the security review. The controls for that world are well understood. Inventory the spend, block the cards, negotiate with the vendor.
Vibe-coded apps break two of those assumptions at once.
The app is not a vendor product, it is your own data with a login screen. There is no vendor to audit, no SOC 2 to request, no contract to terminate. The builder often cannot describe the data flow because they did not design one; the AI did, and the default it chose is wherever the free tier lives.
The access request looks legitimate. The poster's users are asking for near-privileged tenant access so their automation can do its job. Refusing looks like IT obstructing a business need that would take a competent developer a day. Granting it hands production-grade access to software with no owner, no tests and no one on call.
The autonomous-agent posts I have written over the last couple of months describe what happens when these things misbehave at runtime: an agent probing web apps it should not touch, another deleting a TV season and failing the restore. This piece is the earlier stage of the same pipeline. If discovery never happens, those posts are your incident report.
Where to look: the 30-minute discovery pass
You are not trying to be exhaustive. You are trying to find the first three apps, because they will lead you to the pattern.
- Finance, first, because money leaves a trail. Ask what AI subscriptions and app-building platforms the company pays for and what individuals expense. One commenter in the older thread described the working version of this: the company account for Claude, ChatGPT and similar is managed centrally, precisely so someone can see who is building. If finance cannot name the tools being paid for, that is your finding in itself.
- Cloud and tenant consents. In your Microsoft 365 or Google tenant, look at OAuth app consents and API permissions granted in the last 90 days. Apps asking for near-privileged access are visible here, and this is where the r/sysadmin poster's users are quietly turning up.
- DNS and hosting, for what finance missed. The four-month-old thread's app lived on the builder's own domain with a free-tier database attached. Registrars and cloud consoles in your org's name, personal domains pointing at business data, and unknown services in front of your data are all greppable in an afternoon.
- Ask in the open, once. A short note to team leads: if someone on your team has built or is using an AI-built tool for work data, reply with what it does. Staff hide unapproved things; they usually stop hiding them the moment approval is cheap.
Thirty minutes gets you a list. The list is the deliverable, because you cannot govern what nobody has found.
The three questions every submitted app answers
Once an app surfaces, whether it arrives as a formal request or a sighting, it gets asked the same three questions. Not a security review, just answers:
- Where does the data live, exactly? Region, provider, account. "On Supabase" is an answer; "I'm not sure, I'd have to check" is also an answer, and it is the one that ends the conversation politely.
- Who can get to it, and what happens when someone leaves? Access list, authentication, and what happens to the app when its builder goes on leave or resigns. The freelance-dev thread's answer to ownership was effectively nobody, and that is the failure mode.
- What does it connect to, and does it need to? External APIs, webhooks, CRM and mail integrations. The original poster's builders did not know they were linking to external APIs at all. Knowing is the minimum bar.
An app that can answer all three gets a conversation about guardrails. An app that cannot answer them is, for now, a conversation with the builder's manager about data movement. Both outcomes are progress; neither requires a ban.
Give them the sanctioned path, or the unsanctioned one stays in production
Discovery without a replacement just teaches people to hide better. The comments on the older thread sketched the working pattern, and it is boringly sensible: IT runs a sanctioned staging environment with single sign-on and deny-by-default network access, staff deploy their experiments there, deploys are visible through the platform's own API, and anyone can build anything as long as it lands somewhere IT can see it. Another commenter maintains an AGENTS.MD file of sensible defaults so the tools inherit the guardrails without anyone having to argue each time.
None of that requires permission from a vendor or a budget line. It requires someone deciding that IT's job has shifted from gatekeeping to platform: fewer "no"s, more "deploy it here instead".
Why this could be good
The instinct is to read this whole wave as decay, and I do not think that is honest. Every app in that thread started as someone trying to get a real job done: the procurement person who needed a form, the IT manager who wanted an audit trail, the overworked admin automating a REST API call nobody had time for. The demand was always there; it used to stop at a spreadsheet because that was the ceiling of what a non-developer could build. The ceiling moved.
An IT department that answers the wave with discovery, three plain questions and a sanctioned place to deploy gets something it rarely had in the macro era: visibility into which workflows actually run the business. You could not get that list from finance in 2015. You can now, and the list is more accurate than the process documentation.
What to do this week
- Run the 30-minute pass: finance subscriptions, tenant OAuth consents, DNS and hosting. Write down what you find, even if it is three things.
- Send the open ask to team leads, approval cheap, hiding expensive.
- Adopt the three questions as the official intake for any AI-built tool touching company data. Data location, access and ownership, integrations.
- Stand up or name the sanctioned path. Even if it starts as one shared staging account with SSO and logging, a visible alternative beats a policy against an invisible reality.
- Brief one leadership sentence: "Staff are building apps on company data. We can discover them, or read about them later." The CEO in the four-month-old thread chose option two.
- Revisit in 90 days. This wave moves quarterly. Calendar it now.
Key Takeaways
- The pattern is confirmed at scale: "User vibe coded enterprise apps" hit ~530 upvotes and 223 comments on 5 November, with the top comment calling it the new excel macro nightmare.
- The builders cannot answer data questions, and that is the finding, not the insult: apps asking for near-privileged tenant access from people who do not know where the data will live.
- Discovery beats prohibition. Finance trails, tenant OAuth consents and DNS give you the first list in 30 minutes; an open, cheap approval process gets you the rest.
- Three questions per app: where does the data live, who can reach it and who owns it when the builder leaves, what does it connect to.
- Give staff somewhere sanctioned to deploy, or the unsanctioned path stays the path of least resistance.
FAQ
Is banning AI-built apps a viable answer? No, and the threads are full of why. The build is happening on personal accounts and personal time whether you allow it or not. A ban without discovery just moves it further out of view while the data keeps flowing to wherever the free tier lives.
How is this different from the shadow IT problem we already handle? Old shadow IT was bought; this is built. There is no vendor to audit and no contract to end, and the access requests come disguised as legitimate business need. The controls that work on procurement do not reach an app on someone's personal Supabase.
What is the fastest place to look if I only have ten minutes? Tenant OAuth consents. Apps that were granted near-privileged access in the last 90 days are exactly what the r/sysadmin poster is describing, and the list takes minutes to pull.
Do I need a formal citizen-developer policy before I do any of this? No. Start with discovery and the three questions. Policy can follow the first three conversations; waiting for policy is how the four-month-old thread's app reached three months of production data first.
How do I handle the CEO who says "just let them build"? Do not argue the tool, argue the visibility. One line: we can discover what they are building and where the data lives, or we can find out when it leaks. Discovery is the compliant version of "let them build", and it is the version that survives an audit.
Where does this sit relative to AI agent security? It is the front end of the same problem. My earlier pieces cover what happens when agents run unsupervised: least privilege, sandboxing, token budgets. Discovery is what decides whether those controls ever get applied to the apps your staff have already shipped.
My Take
The thing I keep coming back to from that thread is how ordinary it is. There is no nation-state behind it and no zero-day involved. People who cannot answer "where is the data stored" are putting customer records into apps they asked a model to write, and the organisation finds out via a forum post or an audit, whichever comes first.
The profession has been here before with macros, with spreadsheets, with the credit-card SaaS era, and the answer every time was the same uncomfortable one: you do not get to opt out of discovering what your own company runs on. The tools changed. The obligation did not.
Thirty minutes this week: consents, subscriptions, DNS. Three questions after that. One sanctioned place to deploy. The apps are being built either way; the only variable is whether you can see them.
Mathew Clark Founder, SecureInSeconds Currently: pulling the OAuth consent list, because apparently that is a Friday activity now Drafted with AI assistance - read, verified, and fixed by a human.
Further Reading
- r/sysadmin: User vibe coded enterprise apps - this week's thread, ~530 upvotes and 223 comments
- r/sysadmin: Shadow vibe coder in my department - the four-month-old companion thread, ~1,700 upvotes, with the personal-Supabase incident
- The shadow IT problem, still - the procurement-era version of this piece and why the controls differ
- An AI agent deleted an entire TV season and the restore failed - least privilege for anything with an app, including the ones staff build
- Your AI agent runs as you - why near-privileged access requests from new tools deserve a second look
- Autonomous AI agents probing web apps - what unsupervised building looks like from the outside
- Nvidia OpenShell and sandboxing AI agents - the runtime controls that discovery makes possible
