Last updated August 2026

Vibe coding is already changing how work gets done inside companies, even regulated ones.

We've reaped the benefits of vibe coding internally, but we also see it across our customer base. At Fortuna Health, for example, the CEO built a Slack bot that aggregates 142 Medicaid news sources. The COO built a tool to extract obligations from legal contracts. The chief of staff built a CRM in Notion, and none of those projects relied on an engineering team.

Fortuna, in particular, has a sensible rule for deciding at what point a project must move into the normal engineering process: if it touches PHI or member records, it gets pull-request review, security scanning, and the controls appropriate for production software. If not, then vibe code away.

That's a good policy to have (considering many companies have no policy at all), but it covers only one part of the broader security framework.

Data sensitivity tells you what may be exposed if an application is compromised. Network position tells you what an attacker can reach after compromising it. Those are totally separate questions, but they both need to be addressed before anything should ship, whether it's internal or customer-facing.

A contract-tracking app with no PHI could still be a useful foothold if it's publicly reachable or shares network access with production systems. And an application that handles sensitive data can be operated quite safely when access and connectivity are deliberately constrained.

The relevant question is not simply, "Does this tool handle sensitive data?" It's also: "What can this tool reach if it's compromised?"

Security checklists miss the network

Do a Google search for "vibe coding security" today, and the top results, Checkmarx, the Cloud Security Alliance, and Wiz, are all offering advice that's focused on securing the application itself (with one notable exception):

• Authentication and authorization

• Secret management

• Dependency scanning

• SSO and role-based access control

• Code review and vulnerability testing

Those controls are obviously also important, since they reduce the chance that an attacker gets in. RBAC determines who can log into an application; it doesn't determine whether the application is reachable from an untrusted network. SSO improves identity controls; it doesn't prevent a compromised service from making connections to other systems. Dependency scanning may find known vulnerabilities; it doesn't change the impact of an unknown vulnerability in an application that can reach everything else in the environment.

None of this addresses the network the application actually runs on. By contrast, Rob Fuller's Day-Zero Normal brief, circulated widely among CISOs this year, ranks network and identity segmentation as a "critical" priority for 2026, up from "medium" in the pre-AI era. That's the peer consensus among the people running security programs, but it’s not (so far) been reflected in the advice actually written for teams building the applications themselves.

How this actually plays out

Here's the exploit chain in its simplest form.

A team builds an internal tool on a vibe-coding platform: a dashboard, a contract parser, something meant for five people to use. It goes live on a public URL because that's the platform default, and nobody thinks to change it, since the tool feels internal and low-stakes. An attacker (commonly an automated scanner working at internet scale rather than a person) finds it. The tool will usually have some authentication in front of it, so getting in still requires a real vulnerability: a flaw in that authentication logic that code review didn't catch, or a vulnerability in a library dependency, privilege escalation or remote code execution, that doesn't require authentication to exploit at all.

That's the inbound boundary failing.

What happens next depends entirely on the outbound boundary: what can this application reach from where it's running? If it sits on the same network as the production database, holds a set of cloud credentials, or can call other internal services without restriction, then a low-value tool becomes a path into everything of actual value. If it can't reach any of that, the same compromise is a contained, boring incident.

Two boundaries, two different jobs

Every application has two network boundaries that matter, and they call for different fixes.

Inbound is who and what can reach the application from outside it: the boundary that determines whether an attacker, or an automated scanner, can get in at all.

Outbound is what the application can reach once something is running on it, whether that’s legitimate traffic or an attacker who just got in. This is the boundary that determines how far a compromise spreads.

Access control, RBAC, and SSO all assume someone comes through the front door: they authenticate, and their role determines what they're allowed to do from there. None of that applies to an attacker who skips the front door by exploiting a vulnerability instead of logging in. At that point there's no role to check. What they can reach is a network question, not a permissions question.

Locking down inbound access

For an internal tool, inbound is the easier problem to solve, but it's also the one people tend to skip.

WIRED reported in May 2026 that RedAccess scanned thousands of apps built on Lovable, Replit, Base44, and Netlify and found more than 5,000 with no authentication or private network at all. Roughly 40% of those exposed real data, including a hospital staffing schedule with physician PII in one case. The Hacker News, covering the same research, made the same argument we’re making here: reachability, not data sensitivity, is the signal to check first.

Metabase, one of the most widely deployed open-source BI tools, disclosed a critical, unauthenticated RCE in 2023 with a CVSS score of 9.8. Thousands of internet-facing instances were still vulnerable a week after disclosure, and OX Security found it still exploitable against thousands of deployments as of March 2026 (three years after the patch shipped). Metabase's own guidance for teams that couldn't patch immediately was an inbound fix: restrict the endpoint, put it behind an allowlist or a private network.

Metabase shows what happens when patching is slow. Anthropic's own Frontier Red Team recently showed the opposite failure mode: patching that's fast enough by any normal standard, and still not fast enough for AI. Given a public patch diff for 18 Firefox vulnerabilities and 21 Windows kernel bugs, their newest model turned nearly half of the Firefox patches and the large majority of the Windows ones into working exploits, the first one in under an hour, at roughly $2,000 per exploit. The full set of Windows exploits was done faster than the standard 11-day window most fleets take to roll out a forced-reboot patch. The patch-gap problem used to run on a scale of weeks; now it runs on a scale of hours, and no organization's patch cadence is built for that.

For an internal application, the fix is straightforward: put it behind zero-trust access instead of the open internet. Twingate and Tailscale are what we see Aptible customers reach for. Setup takes an afternoon. There's no feature you lose and no workflow you break for the five people who are actually supposed to use the tool. Airtight and nearly free is a rare combination for a security control, which is what makes it inexcusable to skip.

Customer-facing applications don't get this option. Customers connect from any IP, so there's no zero-trust network to drop in front of them the way there is for something internal-only. You either have to be very confident in your outbound restrictions, or you have to invest much more heavily in security review. Neither is as simple as the fix above, and there isn't a clean substitute for either one.

Locking down outbound access

Outbound is the harder problem, because it has to hold even after inbound has already failed, whether that's a customer-facing app that has to stay open, an internal tool nobody locked down in time, or a zero-day nobody's patched yet.

OpenAI's own agents showed what an unrestricted outbound boundary costs (at one of the more extreme ends of the spectrum, this summer. During a security evaluation, a swarm of agents chained a series of unrelated bugs, broke out of their intended sandbox, and compromised Hugging Face's internal infrastructure. Once one of those agents had outbound network access, an unrelated company's misconfigured endpoint became part of its available attack surface. That company had no relationship to OpenAI or Hugging Face at all. There was a door open, and an agent found it. Nobody decided the agents should be able to reach that endpoint. That's just what happens when something is reachable outbound and nobody made the explicit call to restrict it.

The same logic applies at the scale of a single vibe-coded app. A deny-by-default outbound policy (where a workload can only reach the specific services it needs and nothing else) breaks this failure mode before it starts. It's also what makes customer-facing apps survive at all; a compromise there should only reach that application's own database and the services it strictly requires. It should not provide access to internal admin tools, unrelated customer environments, broad infrastructure credentials, or any other database in the account.

A practical policy for vibe-coded tools

Organizations adopting vibe coding don’t need to ban it or route every small workflow through a full product-development process. They just need clear deployment defaults for both boundaries.

Inbound:

• Internal tools go behind zero-trust access or a narrow, network-level allowlist. Twingate and Tailscale are common choices for the former. Either works as long as the restriction sits at the network layer, before a request ever reaches the application.

• Customer-facing applications don't get an inbound fix. There's no gate to put in front of traffic that has to come from anywhere. For a vibe-coded application in particular, you must lean on outbound restrictions and security review.

Outbound:

• Deny-by-default egress. A workload should only be able to reach the services it needs, and nothing else.

• Least-privilege credentials. Production database credentials carry the same risk whether the application was written by a senior engineer, generated by an AI tool, or assembled by an operations team.

Both:

• Treat data sensitivity and network position as separate approvals. A tool may be allowed to skip the PHI review while still requiring infrastructure review because of where it runs or what it can reach.

• Make isolation a deployment default, not an incident response. Decide this before you ship, not after a CVE forces the question.

Here’s a good way to think about your vibe-coding policy: sensitive-data rules determine when software needs deeper engineering scrutiny, while network controls determine how much damage a compromised application can do. Those are complementary controls, and teams need both.

If you only act on one line in this piece, it should be implementing a zero-trust access tool like Twingate or Tailscale. Locking down an internal tool's network access is the one that's both airtight and nearly free, and there's no good reason left to still be skipping it.

Wrapping up

Aptible has an obvious point of view here: we build infrastructure for organizations that need strong security defaults. But the underlying recommendation does not depend on a particular platform. If your company is enabling more people to build and deploy software, give them a safe path to do it: private access for internal tools, strict segmentation for public applications, and credentials scoped to the smallest possible blast radius.

That's how you get the speed benefits of vibe coding without quietly expanding the reach of every future vulnerability.

__

*See how Aptible handles this by default, or look at how we think about securing agentic AI if agents are already part of your stack.*