Everyone can create software now. They're going to cook whether you like it or not.
At Swamp Club, everyone creates their own micro-apps: small, purpose-built tools made with an agent. Our CEO does. Our COO does. Finance has micro-apps for financial modelling, sales has analysis tools, and I have one for understanding the health of the platform. We describe what we need, point an agent at the problem, and iterate for an hour or two until the micro-app works. The micro-apps are ours; none of us have seen the code inside them, and we host and share them with each other.
We implement five rules to make it far safer:
- Assume malicious. Treat the code as untrusted.
- Keep authority somewhere boring. Make identity and ownership explicit; enforce permissions outside the micro-app.
- Contain the deployment. Make sure one broken micro-app means one broken micro-app.
- Minimum permissions are critical. Start with nothing, then allow only the data, services, and routes it needs.
- Limit its appetite. Put quotas at every shared layer it can touch.
Why do we take this stance?
Organisations think they are choosing whether people may build these so-called micro-apps. They are not. The tools are productive enough that people will route around a three-week approval process to demonstrate an idea before lunch. The micro-app moves onto a personal account, a laptop under a desk, or whichever hosting service accepted a credit card without asking awkward questions. Congratulations: shadow IT.
Melodramatic? The numbers disagree.
In a Microsoft-commissioned survey of 2,003 UK employees, 71% said they had used unapproved consumer AI at work and 51% were doing it every week. More than a quarter had no approved alternative. That study was published in late 2025. Frontier models are more capable in the second half of 2026, so the pressure to use them will only grow unless organisations provide a supported platform pattern.
The NCSC's guidance on shadow IT says this is rarely malicious. People are trying to do their jobs, and inadequate tools or slow processes push them outside the boundary. I would rather support the users and their tools. Bring a micro-app through a path we own and we can give it authentication, scoped data, telemetry, limits, an owner, and a kill switch.
The visible bit of the micro-apps is often impressive. That is precisely the problem. The page loads. The graph graphs. The filters filter. The demo is coherent, everyone is excited, and who wants to be the killjoy asking the sticky questions?
- Who can access it?
- Which data can it read?
- What did it log?
- <insert a thousand additional questions here>
The person directing it may never see the code creating those risks. They may not even know the risks have names. Ask whether they checked for IDORs and they may think you mean It Does Obviously Run, not whether everyone can read Bob's invoices.
Not every micro-app needs to be equally safe. Each needs to be safe enough for the authority it holds, and the organisation needs to be safe enough to run the lot.
Org chart pressure
An agent can give somebody a working micro-app over a weekend. It cannot give that micro-app years of production experience at the moment the prototype first loads.
In a Lovable case study, Nursa says its VP of Product built the working MVP for a new product over a weekend; the CEO saw it and pushed the approach across the company. Once a senior leader has a working demo and momentum, the infrastructure team stops reviewing a neutral experiment and starts explaining why the prototype that "already works" cannot have real data, users, and production access today.
Institutional authority quietly becomes technical trust, even though a senior title does not design an authentication boundary.
Your boss has authority. Their micro-app does not.
The answer is not to stop them and restore the engineering bottleneck. It is to separate freedom from authority: everyone may create micro-apps; nothing is trusted because of who created it.
What can you do about it?
The rules are not new. Least privilege and explicit trust boundaries have been standard security advice for decades; vibe-coded micro-apps make them a firm requirement. NIST 800-207 requires least privilege per resource and session. A micro-app is not trustworthy merely because it is internal, employee-built, or executive-requested. Identity must be explicit, authority narrow, and enforcement outside the micro-app.
NIST 800-207A says enforcement must be always invoked, non-bypassable, verifiable, and independent of the application code. That is zero-trust software: the vibe-coded micro-app cannot prove itself.
These 5 things really help.
1. Assume malicious
Treat the micro-app as if it will leak everything it reads, ignore role checks, expose credentials, execute arbitrary input, and keep retrying until either it or you are dead.
This is not an accusation. It is the only useful default when neither the author nor the model necessarily understands the implications of the code. Promises and a successful demo earn no platform credentials or shared runtime. Assume malice; insurance against accidental stupidity is included for free.
2. Authority lives somewhere boring
One option is to keep authentication outside the micro-app entirely. Put a deliberately maintained proxy in front of it. The proxy authenticates the person, controls access, strips client-supplied identity claims, and passes verified identity over a protected hop. No homemade user database, invented session format, or optimistic role=admin query parameter required.
That solves access to the micro-app, not access within it. A proxy can let Alice in; it cannot force the micro-app to hide Bob's records. Downstream services still need to enforce rights on every request through database grants, service credentials, network policy, and narrow APIs.
That is the pattern at Swamp Club. The proxy is one of the most protected things in the organisation; the micro-apps behind it emphatically are not. We concentrate assurance in one boundary every request must cross instead of recreating it in every Wednesday dashboard.
Identity can be passed through. Authority still has to be enforced elsewhere.
3. The deployment should define the blast radius
Give the micro-app its own small box: no privileged runtime, deployment credentials, shared filesystem, neighbouring micro-apps, or route around the authentication layer. The goal is boringly specific: if it breaks, only that micro-app breaks.
Internal tools too often share a forgotten service account, a long-lived VM full of scripts, or a namespace called internal containing everything nobody wanted to think about. A namespace alone is not a sandbox. Add least-privilege runtime permissions, restricted pods, default-deny networking, quotas, and stronger isolation where the risk warrants it.
The quality bar rises with the blast radius.
Not every tool needs the standards of a bank. Every tool needs boundaries honest about what happens when it is wrong.
4. Assume the pipe is hostile
Every connection out is an exfiltration path, a destructive operation, or a denial-of-service attack waiting for a bored while loop. Start with no pipes. Add one when the business requirement can name it precisely.
"Needs database access" is not precise. Which rows and columns? Read or write? For how long and at what volume? Give the micro-app a database-enforced read-only credential against a capacity-limited replica or purpose-built view, with connection and query limits. For services, expose the narrow operation rather than the entire internal API.
The micro-app never gets access to "the database" or "the network." It gets a capability: read these records, call this operation, reach this destination.
NIST's container security guide argues for segmented networks with few, well-defined interfaces. The standards are less sweary, but the conclusion is the same.
Grant explicit access, not ambient access.
5. Assume the noisiest neighbour in history
Vibe-coded micro-apps have a magnificent appetite. They open a database connection per request, pull a billion rows into memory, poll every hundred milliseconds, and retry impossible operations forever. None of this requires malice. It barely requires code.
CPU and memory limits are only the beginning. Limit concurrency, database connections, query duration, retries, bandwidth, storage, and calls into shared services. Kubernetes connects quotas and limits to noisy-neighbour protection, but a namespace quota cannot protect a database, API, or network. Put the limit at every shared layer the micro-app can touch.
A finance dashboard is allowed to become unusable. It is not allowed to make finance unusable with it.
What this looks like at Swamp Club
The architecture is intentionally lopsided. The trusted pieces are small, central, and deeply boring. Then the micro-app is allowed to be weird.
A team member reaches a micro-app through the admin proxy, which authenticates them and passes verified identity over a protected connection. The proxy is treated like critical infrastructure; the micro-app is treated like something an agent made on Thursday.
My operations micro-app helps me understand platform health and can inspect a local read-only copy of the Swamp Club source. It cannot modify that source or deploy Swamp Club. Live signals arrive through separately granted read access rather than the permissions I hold as Head of Platform. If the dashboard is unstable, I have an annoying dashboard. I do not have an unstable production service.
Help them build
The wrong response to a questionable micro-app is "That's lovely. Now delete it and submit a ticket like everybody else." Requiring a review, a dedicated team, and a quarterly roadmap will not put software creation back inside the software department. It will drive it underground.
Instead, ask "how can we run this safely?" Find out who needs it, which data and services it requires, and what happens if it breaks. Then help the builder put it behind authentication, inside a bounded deployment, with telemetry, resource limits, and narrow routes.
The supported path has to be easier than shadow IT, but it does not need death by Backstage. The user owns the micro-app; the platform team manages the bounds around it and the consequences it is allowed to cause.
Freedom to build does not grant authority. Zero-trust software keeps access and blast radius under controls the micro-app cannot alter.
Manage your boundary with Swamp. It integrates with the services around your micro-apps and handles whatever weird and wonderful infrastructure requirements they bring. Check it out at swamp-club.com.
Everyone can create software now. Some of it will be extraordinary. Quite a lot of it will be vibe-coded bullshit.
Build the boundary, then get out of the way.