Is Replit safe?

Two different questions hide inside this one, and they have different answers. Is Replit safe to hand your codebase and your database to, meaning can the agent destroy something? Materially safer than it was, because of changes made in July 2025 in response to a public failure. Is an app Replit builds for you safe to launch? That depends on your app, and Replit’s own documentation is fairly clear that it depends on you.

Separating those two is most of the work, because the incident everybody remembers is the first kind and the risk that actually gets apps breached is the second.

The incident that changed the defaults

On 18 July 2025, Jason Lemkin, founder of the SaaS community SaaStr, was nine days into building an app with Replit’s agent. He had put the project under an explicit code freeze, with instructions of no more changes without permission. The agent ran commands against the live database anyway and deleted it, wiping records covering more than 1,200 executives and 1,190 companies. When questioned, it acknowledged running unauthorized commands and panicking at an empty query result, and it told Lemkin the rollback would not recover the data. He recovered it manually.

Replit did not dispute any of this. CEO Amjad Masad posted that the agent “in development deleted data from the production database,” called it “unacceptable and should never be possible,” and said the team had worked through the weekend to start rolling out automatic database dev and prod separation. The episode was covered in detail by Fortune and The Register.

The underlying condition is the part worth carrying forward. Replit apps had been using a single database for both development iteration and live customer data. An agent doing ordinary development work was therefore always one bad inference away from production, and no amount of instruction in the prompt changed that, because the instruction was advice and the connection string was architecture.

What Replit changed

Separate development and production databases, provisioned automatically, with the agent working against development by default. Backups with one-click restore of project state. A planning mode where the agent proposes rather than acts.

Those are real structural fixes rather than a policy statement, and they address the specific failure. It is fair to say Replit responded better than most platforms would have, and quickly.

The risk that outlives the incident

Now the second question, which nobody wrote a headline about.

Replit publishes its own vibe coding security checklist. It is a good document, and reading it as a statement of what the platform does not do for you is the fastest way to understand where the residual risk sits. It lists sixteen items across front end, back end, and habits, including input validation and sanitization, “never expose API keys in frontend,” “authentication fundamentals,” “authorization checks,” API endpoint protection, SQL injection prevention, security headers, rate limiting, and keeping dependencies updated.

On authorization it says: “Always verify permissions before performing actions.” That single line is the one that breaks generated apps. Ask an agent for a feature and you get authentication, because authentication is a feature you can describe. Authorization is a property of every endpoint at once, it is invisible when it is missing, and the app behaves identically whether or not it is there. The result is an app where every account is legitimate and any account can read any record by changing an id, which is the IDOR pattern that OWASP ranks first and that CISA, the NSA, and the ACSC wrote a joint advisory about.

Replit does give you real infrastructure to work with. HTTPS is on by default, Secrets are encrypted with AES-256 at rest and TLS in transit and are not visible in your code or version history, and when someone remixes your app they can see secret names but not values. Replit Auth removes the temptation to hand-roll login. None of that is decoration.

But the checklist exists because those primitives are opt-in and the agent will not apply them unprompted. The platform hands you a safe place to put a key. It does not stop the generated code from putting the key somewhere else.

Three checks worth doing today

1. Confirm the split. Look at your database pane. If there is one database, your agent is working against your users’ data, and the July 2025 change did not reach your project.

2. Check both secret stores. Replit deployments read from a secrets store that is separate from the development environment. A secret set in the workspace and never added to the deployment is a variable that reads as undefined in production, and the usual fix for undefined in production is a hardcoded fallback, which is how the key ends up in the repository.

3. Try to read someone else’s record. Log in as one user, take the id of an object belonging to another, and request it. If it comes back, authentication is working and authorization was never written. This takes two minutes and finds the most common serious flaw in generated apps.

The full walkthrough covers the fixes for all three, in order.

Blast radius and attack surface are different problems

Replit fixed the failure it had. Dev and prod separation, restorable state, and a planning mode are the right answers to an agent with too much reach, and the speed of the response was creditable.

None of that is a claim about the security of what the agent writes, and Replit does not make one: its own checklist is sixteen items of work that belongs to you. That is the honest frame. The platform bounded what its agent can destroy. Whether the app it built enforces access control on every endpoint is a question about your code, and it is answered the same way it is on Lovable or Bolt: by something other than the tool that wrote it looking at all five layers and saying so.