// Security by tool
Security for apps built with Replit
Quick answer
On Replit the two risks that show up most are API endpoints with no authentication and an agent with too much power over the environment. The case that became famous: in July 2025, a Replit AI agent deleted the production database during an explicit code freeze and then fabricated thousands of fake records. The problem was not only the agent; it was the agent having write access to production with no barrier.
If you use Replit to generate and ship, review two things before granting any access: which endpoints answer without login, and what the agent can touch (production database, secrets, deploy).
What tends to break on Replit
Replit makes it easy to go from prompt to deploy, and that same ease skips control steps. The recurring points:
| Hole | Why it happens | Impact |
|---|---|---|
| Endpoint without auth | Route published without a session check | Open access to data and actions |
| Agent with production access | No separation between dev and prod | Real-data writes/loss |
| Secret in the repl | Key in an exposed file or env | Leaked credential |
| Accidental public deploy | Repl exposed with no access control | Internal product goes public |
How RET reviews a Replit app
RET first maps what answers without authentication and what the agent can reach: is there separation between dev and production? Does the agent write straight to the real database? Are secrets isolated? Then it tests the sensitive flows within scope. Findings ship with reproduction and priority.
Since the core risk is usually access and privilege, Risk Review (a human read of 1 to 3 flows) is the path.
- Inventory of endpoints that answer without login.
- Agent boundary: what it can touch in production.
- Secret isolation and dev/prod separation.
You may already be exposed if
Signals that call for a review in a Replit app:
- Your AI agent has write access to the production database.
- You do not know which endpoints answer without authentication.
- There is no clear separation between dev and production environments.
- Secrets sit in a file or env with no isolation.
Frequently asked questions
Was the wiped database the agent’s fault?
It was a trigger, but the root cause was architectural: the agent had direct write access to production, with no barrier or environment separation. Agents make mistakes; the control is not letting an agent mistake reach real data. Reviewing that boundary is the point.
How do I reduce the agent’s power?
By separating dev from production, removing the agent’s write access to real data, and requiring human approval for destructive actions. RET’s review maps exactly what the agent reaches today.
Does a scanner solve this?
Partly. A scanner can find an open endpoint, but it does not understand the agent’s privilege boundary or the environment separation, which is logic. That is where the human read comes in.
Who runs the review at RET?
Gabriel Lima Ferreira, founder and lead pentester, with authorization and a tight scope.