Defense in Depth: How Replit Secures Every Layer of the Vibe Coding Stack
Vibe coding is changing how software gets built. But as AI agents write more of our code, the question security teams are asking has shifted from "Can AI build this?" to "Can I trust what AI builds?".
At Replit, we believe the answer has to be yes, not through blind faith, but through architecture. Every layer of the Replit infrastructure where customer code runs, from the development sandbox to the production deployment, is designed with defense in depth. The Replit platform itself, our control plane, is also implemented with these principles in mind. No single control is the last line of defense. Every layer assumes the one above it might fail.
This post is a detailed walkthrough of how we think about security across the stack, written for the people who need to evaluate it: CISOs, security engineers, and teams considering Replit for production workloads.
Zero Trust as a Foundation
Replit adheres to Zero Trust Architecture principles across our internal infrastructure. Concretely, that means:
- Trust, but verify. Authentication and authorization are enforced between all internal services using short-lived tokens. No service implicitly trusts another simply because it shares a network boundary.
- Principle of least privilege. Access to data is restricted by default. Services and users are granted the minimum permissions necessary to perform their function.
- Segmentation. Access boundaries are drawn tightly. We segment access as aggressively as possible to limit blast radius in the event of a compromise. mTLS secures the network path of the most crucial sets of services and restrict access to APIs to only be available over secure channels, isolated to the service pairs that should communicate.
We apply these principles throughout our infrastructure to shape how our systems communicate. When you consistently act like this over years, it compounds into the building safer systems by default.
Isolated Cloud Sandboxes
Replit has run cloud sandboxes since 2016. Every user's development environment runs in its own isolated sandbox: anything that happens inside it only affects that sandbox, and it is protected from outside influence.
Under the hood, Replit sandboxes are built on Linux containers hardened with seccomp-bpf and several additional layers of system hardening. We continuously monitor for kernel exploits and maintain an aggressive patching cadence. Linux containers are not a perfect isolation boundary (we're transparent about that) but our layered hardening means that in practice, our sandboxing and hardening layers are designed to prevent cross-tenant interference. In the history of the platform, we’ve only been aware of a single kernel exploit that has affected Replit, and no users were impacted thanks to the defense in depth paired together with swift incident response.
We're also currently rolling out a replacement of our entire container-based infrastructure with microVMs, which provide a significantly better level of isolation thanks to there being no shared kernel. This is an investment in making an already strong isolation story even stronger. Some users already have this and there will be a separate announcement when this is fully out for everyone.
Structural Separation of Frontend and Backend
Because Replit runs full cloud sandboxes, applications built on Replit naturally follow industry best practices: a separate frontend and backend. This structural separation makes Replit-built applications significantly more robust against the class of vulnerabilities that plague other vibe coding tools; tools that rely almost exclusively on Row Level Security for access control.
To be clear: RLS is an excellent mechanism for defense in depth in PostgreSQL applications, and we use it ourselves internally. But RLS works best when paired with a proper backend that can perform authorization checks with full context, not as the sole access control layer sitting directly behind a client-side application.
Supply Chain Protection with Determinate Nix
Replit sandboxes use Determinate Nix as their package manager. This keeps the Nix installation and all third-party packages and dependencies in your application up to date and free of known vulnerable versions. Determinate handles the hard problem of ensuring that the software supply chain underneath your application is continuously patched.
Full Separation of Development and Production
Replit provides isolation between development and production environments. This goes beyond the typical "separate compute" approach: we extend the same separation to the database layer.
We implement forkable databases using the same snapshot technology that powers our filesystem storage. This means every application gets an independent development database that can be forked, rolled back, and iterated on without any risk to production data. The same technology scales to millions of databases and preserves every revision of the development database.
This separation prevents a class of catastrophic accidents where a production database is accidentally modified during development, the kind of incident that has publicly affected even experienced founders.
Continuous Backups and Append-Only Git
Every filesystem at Replit is backed up at least daily. This same backup mechanism also protects development databases, providing a consistent recovery point for all user data.
Beyond filesystem backups, every Replit application uses git as a normal part of Agent-driven development. But we go further: each sandbox runs a container sidecar with a full git remote that is append-only. Even if the .git directory inside your application is accidentally deleted, the complete history is always recoverable from the sidecar. This is an approach that helps recover development work even if the worst happens.
Scoped Data Access by Default
By default, applications on Replit cannot access data in other applications. Cross-application data access requires explicitly opting in through Connectors or Data Connectors. Granting permissions is straightforward, but the default posture of no access means reduced data surface area and fewer accidental exposures.
Transparent Secret Proxying
For connectors, we're moving toward a model where application code never has access to passwords or secrets at all. Instead, connections are transparently proxied through a sidecar service with no persistent storage. This sidecar injects the necessary HTTPS Authorization headers on the fly, so that application code never handles the underlying credentials, even by accident.
We apply the same technique to MCP integrations: the Agent never communicates directly with MCP servers. All traffic flows through a transparent proxy that adds OAuth headers without exposing them to the application context. In addition to protecting secrets, we scan MCP tool definitions and tool responses to detect and prevent several families of prompt injection attacks.
Built-In Authentication
To prevent the Agent from making common mistakes when implementing authentication, Replit provides a turnkey auth solution that removes whole families of bugs and exploits. This authentication layer is enterprise-grade and fully end-user customizable: applications inherit a battle-tested auth stack without the Agent having to implement one from scratch. You are still in control and can choose how it presents itself so that your brand is still well-represented.
Shift-Left Security During Development
While the Agent is building code, Replit continuously evaluates the produced code to catch potential security issues, bugs, and architectural mistakes in real time. This follows the Shift Left philosophy: identifying and addressing faults as early as possible in the development process, when they're cheapest and easiest to fix, rather than discovering them after deployment.
Pre-Publish Security Scanning
Before any application is published to production, Replit runs a full suite of security and privacy scans. We've deliberately built a scanning pipeline that goes beyond AI-powered analysis alone, since purely LLM-based safety programs have been shown to be insufficient for adequately protecting AI-built applications.
Replit's security center uses a combination of rule-based SAST/SCA scanning and LLM reasoning. Rule-based scanning excels at finding CVEs and supply chain attacks like the Shai-Hulud npm worm, while the recently-released Replit Security Agent is better at finding architectural flaws and logic errors. We've also partnered with Semgrep to further augment the categories of vulnerabilities we can detect. HoundDog helps find any privacy issues too.
Enterprise-Grade Production Infrastructure
Once published, Replit applications run on Google Cloud Platform infrastructure. We take a deliberately contrarian approach to tenant isolation compared to other providers: every single customer gets their own GCP Project, even free-tier users. This maximizes the isolation between deployments at the infrastructure level.
Applications run in Cloud Run with state-of-the-art sandboxing, and every deployment, regardless of tier, is protected by Google Cloud Armor for DDoS protection and Web Application Firewall (WAF) capabilities. This infrastructure was crucial in our mitigation of the React2Shell vulnerability.
Continuous pentesting
We have partnered with several companies over the years that provide penetration testing for both the Replit platform as well as the serving infrastructure that we use. HackerOne has managed our bug bounty program in addition to helping us do spot checks of new services just prior to releasing them. We also recently engaged with Trail of Bits to do a much more in-depth assessment of several Replit services.
We have also recently investing in AI red-teaming for our internal testing. Even though Replit doesn’t have access to Project Glasswing, we have seen great success with building an internal security-focused harness that continuously scans our source code, prioritizes potential findings, and validates them before involving engineers to address them. This effort has also guided some architecture changes to reduce the attack surface area.
Incident Response
Even though every layer of the system has been hardened to provide security robustness, security incidents can still happen. Sometimes, these incidents happen due to external influences or supply-chain attacks. At Replit, every single security incident is handled with urgency because users’ data is at stake. Trust is something that has to be earned over time, and can be easily lost by not going above and beyond.
Every incident is also a learning opportunity: every root cause that we find becomes a hardening effort so that the incident itself no longer repeats itself, but also fix any adjacent problems that were surfaced by the incident, and tighten up defenses in other parts of the stack.
Conclusion
No single layer is the whole story. Each one assumes the layer above it might fail. That's what defense in depth means, and it's the only way to earn the trust of teams that take security seriously.
If you're evaluating Replit for enterprise use and have questions about our security posture, we'd love to talk. Reach out to our sales team or read more about Replit for enterprise.
