The apps your staff built last month
need the same care as the software you bought.

In February 2026, researchers at Wiz looked at Moltbook, a social network for AI agents whose founder had built it with AI. “I just had a vision for the technical architecture, and AI made it a reality,” he had written. A key sitting in the site’s own JavaScript gave anyone who opened the page read and write access to its entire database. Inside were 1.5 million API tokens, 35,000 email addresses and thousands of private messages, some holding plaintext OpenAI keys. The database was missing one setting, row-level security, and the key that was meant to be harmless became the key to everything.

I tell this story to clients because the same thing is now being built inside their companies, at a smaller scale and with more sensitive data. A sales manager builds a quote calculator in Lovable over a weekend. Someone in HR asks Claude for an onboarding tracker and puts it online so new hires can fill it in. A finance assistant connects an expense spreadsheet to an agent that reads receipts from email. All three are useful, all three work, and none of them passed through IT. I think this is mostly good news. It also means most companies now run software nobody has listed, tested or owns.

170

Of 1,645 Lovable apps scanned, the number whose databases anyone could read, in a scan by Matt Palmer, published May 2025.

1 in 5

Organizations that reported a breach caused by shadow AI, per IBM, July 2025.

1 in 6

Cloud environments using MCP that expose at least one MCP server to the internet, per Wiz, July 2026.

The defaults are open, and the builder rarely knows

The pattern behind most of these leaks is boring, which is why it repeats. AI app builders often put the data in a hosted database such as Supabase or Firebase and talk to it straight from the browser. That is safe only when the database checks, row by row, who is allowed to see what. Supabase’s documentation is direct about it: “Enable RLS on every table in an exposed schema.” Firebase warns that with open rules “anyone who guesses your project ID can steal, modify, or delete the data.” A person who has never heard of row-level security will not switch it on, and the app works fine without it, right up to the day someone looks.

People have looked. In March 2025 the developer Matt Palmer scanned 1,645 apps built with Lovable and found 170 where the database gave out data it should have protected: names, phone numbers, subscriptions, payment details and API keys. The issue was registered as CVE-2025-48757. In October 2025 the security company Escape ran a passive scan of more than 5,600 public apps built with Lovable, Base44, Create.xyz, Bolt and similar tools. It found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 cases of exposed personal data, including medical records and bank account numbers, and called its numbers a conservative baseline.

The code itself is part of it too. Veracode tested code from more than 100 language models in July 2025 and reported that 45% of the samples “failed security tests and introduced OWASP Top 10 security vulnerabilities into the code.” A professional developer reviews and catches some of that. The sales manager with the quote calculator will not, and should not have to.

The platforms are responding. Lovable now offers automated penetration testing, and the builders keep improving their defaults. That helps with the apps people make on those platforms from now on. It does nothing for the apps already running, the ones built in Cursor or Claude and deployed somewhere else, or the ones whose maker has since left the company.

Agents add a second problem: they act

An app that leaks data is bad. An agent that can be steered is a different kind of risk, because it holds keys and uses them. In July 2025, an AI coding agent on Replit deleted the production database of an app that Jason Lemkin, the founder of SaaStr, was building, during a code freeze, then told him a rollback would not work. He recovered the data by hand. Fortune reported the CEO’s response.

Unacceptable and should never be possibleAmjad Masad, CEO of Replit, quoted by Fortune, July 2025

Nobody attacked that database. The agent had production access and nothing stood between its decision and the delete. Replit promised to separate development and production databases automatically. Internal agents built by staff rarely have that separation, because the person setting them up connects the account they already have, which is usually their own, with all its rights.

Add outside input and it gets worse. I wrote about this at length in an earlier note: any text an agent reads can give it orders, and Simon Willison’s lethal trifecta names the dangerous combination as “access to your private data,” “exposure to untrusted content” and “the ability to externally communicate in a way that could be used to steal your data.” The expense agent from my opening example has all three: it reads receipts from strangers, it can see the finance spreadsheet, and it can send email. OWASP lists prompt injection first and excessive agency sixth in its Top 10 for LLM applications, and in December 2025 published a separate Top 10 for Agentic Applications. Two years ago neither list existed.

MCP servers are software you installed without noticing

The Model Context Protocol is how assistants like Claude, ChatGPT and Copilot connect to other tools. It is a good standard and we use it on almost every project. It also means that every connector someone adds is a piece of third-party software running with their access, and very few companies keep a list of them.

The incidents so far show the range. In September 2025, an npm package called postmark-mcp, which imitated the email company Postmark’s MCP server, shipped fifteen clean versions and then, in version 1.0.16, started copying every email it sent to the attacker. Postmark’s warning, reported by The Register, said the package “secretly BCC’d emails to an external server.” In July 2025, JFrog disclosed CVE-2025-6514 in mcp-remote, a widely used helper for connecting to remote MCP servers, rated 9.6 out of 10: connecting to a malicious server could run code on the user’s machine. Docker counted more than 437,000 downloads of the package.

Then there are servers left open on purpose or by accident. In July 2025, Knostic found 1,862 MCP servers reachable from the internet and checked 119 of them by hand: “All 119 servers granted access to internal tool listings without authentication.” A year later, Wiz reported that about one in six cloud environments using MCP exposed at least one server, and that about 42% of the exposed servers returned real data when a tool was called by an anonymous visitor.

None of this is a reason to avoid MCP. It is a reason to treat each connector like any other software that touches company data: know it is there, know who installed it, pin the version, and give it the narrowest access that does the job.

The rules already cover tools you built yourself

Regulation is not why I would do any of this, but it points the same way. Under the EU AI Act, a company that uses an AI system is a deployer, and since 2 February 2025 Article 4 asks deployers to take measures for their staff’s AI literacy. When an internal tool starts screening applicants or allocating work, it can fall under the high-risk uses in Annex III, with duties for oversight and logging that apply from 2 December 2027. And GDPR Article 32 has asked for years for “a process for regularly testing, assessing and evaluating the effectiveness” of the measures that protect personal data. An onboarding tracker full of passport scans is covered whether IT built it or not.

What to do this quarter

None of this calls for a ban. Companies that ban AI building push it into personal accounts, where nobody sees it. What works is a short list of habits, and most of them fit in one quarter.

1. Make the list. Ask every team which tools they built or connected, and check the traces these apps leave: projects in Lovable, Bolt, Replit and Vercel, Supabase and Firebase accounts on company cards, OAuth grants in Google or Microsoft, automation accounts, MCP connectors in the assistants people use. Give every item an owner.

2. Test the ones that hold real data first. For each app with customer, staff or finance data: can the database be read without signing in, are there keys in the page source, does every page and route check who is asking, can one user see another’s records. Each of these takes minutes to check once you know where to look.

3. Rotate every key that was ever in a page, a repository or a chat. Assume it has been copied. Move keys into the server settings or a secret store.

4. Move the keepers into company accounts. Apps that matter should live in workspaces the company owns, sign people in with company accounts, and survive their maker leaving. Switch off the ones nobody uses, after telling their maker.

5. Give agents their own identities and a person on the risky steps. No agent should run on an employee’s full login or an admin key. Sends, payments, deletions and permission changes wait for a human click. If an agent has all three parts of the trifecta, remove one.

6. Keep a list of MCP connectors and pin their versions. Prefer servers published by the vendor whose system they connect to. Never expose one to the internet without authentication.

7. Write a one-page rule and a starter project. Which tools staff may build with, which data needs IT first, where keys go, and a template that already has sign-in and row-level security switched on, so the safe way is also the quick way.

8. Do it again next month. People keep building, and that is the point. A monthly look at what is new costs little and keeps any new hole short-lived.

If you want help with any of it, the Internal Apps Sweep does points one to four and seven in two weeks, and our security page lists the rest of what we do and how we handle your data while we do it.