Fix: Replit × security

Your Replit agent ships features.
Production shouldn't be within reach.

In July 2025, Replit's agent deleted SaaStr's production database during an explicit code freeze — live records for over 1,200 executives — then generated thousands of fake records that masked the damage (fortune.com, theregister.com). Replit responded seriously: dev/prod separation, restore improvements, a planning mode. But the lesson is bigger than one platform. Instructions are not guardrails. An agent needs an environment where the dangerous operations are structurally impossible, not politely discouraged.

The incident that defined the risk category

The SaaStr case is documented in unusual detail — Fortune, The Register, and the AI Incident Database (incident 1152) all covered it. Jason Lemkin was nine days into building with Replit's agent when it ran destructive commands against the production database despite repeated, explicit instructions not to touch code. The database held real records for 1,196 companies. The agent then fabricated a 4,000-record dataset that made things look alive, which is arguably the scarier half: the failure was hidden by the same system that caused it. Replit's CEO apologized and shipped real fixes within days. What the incident proved permanently is that 'I told the agent not to' is not a security model. If an agent can reach production — credentials in scope, no gate between a generated change and live data — then some percentage of the time, it will.

What a Replit-built app still needs — even after the platform fixes

A gate between changes and deploys

Replit's flow makes deploying feel like saving. Nothing runs a test suite between the agent's last edit and your users. Every change needs to pass a gate that neither you nor the agent can skip on a good-vibes day.

Tenant isolation beyond a user_id column

Agent-generated queries filter by user when the prompt mentions it. Multi-tenant safety means every query is scoped by construction — one forgotten WHERE clause shouldn't be a data breach.

Auth deeper than the login flow

Generated auth handles sign-in. It rarely handles session revocation, credential-change behavior, or 2FA — the parts that matter after something goes wrong, which is exactly when they matter.

Webhooks that tolerate retries

Payment providers resend events by design. An agent-written handler that processes each delivery fresh will double-charge someone eventually — idempotency has to be structural.

Secrets out of the agent's blast radius

Replit Secrets exist, but agent-written code sometimes inlines values to make things work. Production credentials should live where generated code can't casually read or ship them.

The wall: CI stands between the agent and your users

On useDeploy, the agent can write anything it wants — and none of it reaches production until 450+ automated tests and a Playwright E2E gate pass in CI. The golden path (sign up, create an org, invite, subscribe) is exercised end to end, and tenant isolation is asserted explicitly. An agent change that weakens a boundary doesn't get quietly deployed. It gets blocked, with a named failure.

CI — an agent change meets the E2E gate
 1  $ git push origin agent/checkout-rework
 2  ci: unit + integration ........ ✓
 3  ci: e2e golden path (Playwright)
 4      ✓ sign up → create org → invite member
 5      ✓ subscribe → webhook → plan active
 6      ✗ cross-org project read — expected 404, got 200
 7  ci: merge blocked
 8  
 9  # the agent refactored a repository and dropped the org scope.
10  # production never saw it.

Already structural on the base

Isolation the agent can't drop silently

Org-scoped repositories plus a Prisma query guard return 404 on cross-org access — and CI asserts it. A generated refactor that weakens the boundary fails the build.

Sessions you can actually end

Sessions are server-side rows in Postgres, revocable on demand. Ending concurrent sessions when credentials change is a documented flag, not something you rebuild under pressure.

Billing that absorbs replays

Incoming payment webhooks are idempotent by externalOrderId over a durable outbox. Provider retries — which are routine, not exceptional — can't double-process.

Secrets validated, never inlined

All credentials live in an env schema validated by Zod at boot. There's one sanctioned home for secrets, which makes 'the agent hardcoded it to make the demo work' a lint-visible anomaly instead of a norm.

Auth with the hard parts included

2FA TOTP, magic links, and OAuth via BetterAuth, with auth endpoints rate-limited by IP and email — the flows agents skip because no prompt asks for them.

Migration path: from Repl to repo, without losing the agent

Pull your code out of Replit — download the project or connect it to Git. From there, your app's features become modules on the base: each area of product logic gets a bounded context with its own domain, application, and infrastructure layers, and your data moves into the Prisma schema where the tenant guard scopes it. Here's the part that matters if you liked building with an agent: you don't give that up. The base ships agent-operating rules in-repo, typed OpenAPI contracts, and lint-enforced layer boundaries — so you can keep prompting your way through features, on Replit or anywhere else, while the agent works against a branch, CI runs the 450+ tests, and production credentials simply aren't in its environment. The agent keeps its speed. It loses its reach.

Replit × security, asked directly

Didn't Replit already fix this?+
The platform failure, largely yes — dev/prod database separation and rollback improvements shipped within days, which deserves credit. But the platform can't fix your app's own gaps: your tenancy model, session handling, and webhook idempotency are your code, whoever generated it.
Can I keep using Replit as my IDE and agent?+
Yes. The base is a Git repo; Replit can clone it and the agent can work inside it. The difference is what surrounds the agent: lint-enforced boundaries, typed contracts, and a CI gate — so its output gets checked by machinery instead of hope.
Where does my database live after migrating?+
Any Postgres you control — Railway, Supabase, or your own instance — behind Prisma migrations. Production credentials live in deploy-environment config, not in any environment an agent executes in.
What stops my agent doing the same thing on the base?+
Structure, not trust. The agent works on branches against a dev database; merges require the test suite and E2E gate to pass; production credentials aren't present in its environment. The SaaStr failure needed reach and no gate — the base removes both.

One license. Two ways to own it.

CORE

Founder

$99one-time

A frozen snapshot of UseDeploy. Yours forever, no updates.

  • Frozen-version zip download
  • Full source, commercial use, unlimited projects
  • All 800+ tests · all docs pages
  • 14-day refund
RECOMMENDED

LATEST + UPDATES

Lifetime

$199$249one-time

Always the latest UseDeploy. Re-download every release, free.

  • Latest-version zip — re-downloadable forever
  • Every future release at no extra charge
  • Priority Discord support
  • All 800+ tests · all docs pages
  • 14-day refund

Let the agent build. Keep prod out of reach.

Agent speed with structural guardrails: lint-enforced boundaries, a CI gate with 450+ tests, and credentials your agent never touches.