---
title: "Check your coding agent's security work"
fixMetaTitle: "Verify agent security work"
slug: check-your-coding-agents-security-work
severity: medium
category: AI
summary: "A coding agent saying your app is secured is a report, not proof. Ask it to list its findings and ask before changes, then check the work yourself."
platforms:
  - Claude Code
  - Replit
  - Lovable
  - Bolt
  - Supabase
updated: "2026-10-29"
published: "2026-10-23"
related:
  - security-checklist-for-ai-client-work
  - supabase-tables-without-rls
  - supabase-views-bypass-rls
  - secret-keys-in-the-frontend
  - unbounded-llm-spend
  - replit-secrets-and-access
securityClaim: true
---

When you ask Claude Code, Replit, Lovable, or Bolt to "secure my app", the reply tells you what the agent looked at and changed. It is a useful report. It is not proof that the app is safe. Ask the agent to list its findings and to ask before it changes anything. Then check a few things yourself.

The tool makers say the same about their own tools. Replit's [security scan levels](https://docs.replit.com/features/security/security-scan-levels) page says: "No scan guarantees that your app is secure." Lovable's [security overview](https://docs.lovable.dev/features/security) says its tools "help identify common security issues, but they cannot guarantee complete security." That is not a reason to stop using them. It is a reason to check the result.

## Does "secured" mean the app is safe?

Not on its own. An agent can only report on what it checked. Replit's [shared responsibility model](https://docs.replit.com/features/security/shared-responsibility-model) lists code review, "Verifying correctness, security, and licensing of Agent output, including third-party dependencies it introduces", as your part. It also says "Agent produces working code, but “working” and “correct” are different things." Claude Code's [security page](https://code.claude.com/docs/en/security) says "You’re responsible for reviewing proposed code and commands for safety before approval."

So treat the agent's summary as a list of things to confirm. The prompt below asks for that list in a form you can check, and asks the agent to wait for you before it edits code or touches the database.

## Agent prompt

```text
Review this app's security. Do not change any code, run any command, or touch the database yet.

1. List what you checked and what you did not check.
2. For each finding, give the file or table, what is wrong, how sure you are, and the fix you propose.
3. List every table and view in the public schema. Say whether row level security is on for each table, what each policy allows, and whether each view sets security_invoker.
4. List every API key and secret the app uses and where each one is read. Say whether a secret key, a service_role key, or an AI provider key can reach the browser. Do not print key values.
5. Say whether AI provider calls run on the server, require a signed-in user, and have a per-user limit.
6. Do not tell me the app is secure. Tell me what you found and what is still unchecked.

Stop after the list. Ask me before you edit a file, run a command, run SQL, or change anything in the database, and ask again before each change.
```

## How to check

1. Run the [Supabase exposure checker](/tools/supabase-rls-checker) against the live app. It runs in your browser and shows what the anon key can read. Compare that with what the agent said is protected.
2. Open Security Advisor in the Supabase dashboard. Supabase's [advisors](https://supabase.com/docs/guides/observability/advisors) flag issues "such as elevated error rates, misconfigured RLS policies, or missing indexes." Any security finding the agent did not mention goes back to the agent as a question.
3. Check views in `public`. A view that should respect row level security needs `security_invoker`. The query is in [Do Supabase views bypass RLS?](/issues/supabase-views-bypass-rls)
4. Open the live site, view source, and search the JavaScript for `sb_secret_`, `service_role`, and your AI provider's key prefix. See [Secret keys shipped in the frontend](/issues/secret-keys-in-the-frontend).
5. Open your AI provider's billing or limits page and confirm a spend limit is set. See [No cap on LLM API spend](/issues/unbounded-llm-spend).
6. If the agent created new tables, check their grants with [Supabase's Oct 30 change: new tables aren't exposed automatically](/issues/supabase-data-api-grants).

## How to fix

### Claude Code

Claude Code's [security page](https://code.claude.com/docs/en/security) says Manual mode "starts with read-only permissions" and asks you first when it needs to edit files or run commands. Stay in that mode for a security pass, paste the prompt above, and read each proposed change before you approve it. The same page says "You’re responsible for reviewing proposed code and commands for safety before approval."

### Replit

Replit's [scan levels page](https://docs.replit.com/features/security/security-scan-levels) describes three scan levels, from dependency checks to a test of your live app. Level 1 runs dependency and package checks. Level 2 adds an Agent review of your source code. Level 3 adds a black-box test of your live Preview. The page says "A clean dependency scan does not mean your own code has no vulnerabilities," and "A passing publish check is not a guarantee that your application code has no vulnerabilities."

Use a scan as one input, then run the [checks in the full guide](/issues/check-your-coding-agents-security-work). Replit's [shared responsibility model](https://docs.replit.com/features/security/shared-responsibility-model) asks you to "Read what it wrote, especially around authentication, data handling, and anything that crosses a trust boundary." The [Agent overview](https://docs.replit.com/features/agent/overview) says Agent "creates checkpoints as it works, so you can roll back to any previous state." More Replit guides are on the [Replit page](/platforms/replit).

### Lovable

Lovable's [security overview](https://docs.lovable.dev/features/security) describes two built-in scans. The Quick scan runs automatically every time you publish. The Deep scan reviews your application code, and the page says it "does not run automatically as you work." Run the Deep scan from the project Security view before you publish.

The same page says you can ask Lovable for a conversational security review by prompting, and that the review uses credits. Use the prompt above for that review, so Lovable lists findings before it changes anything. Lovable's page also says its tools "do not replace a thorough security review."

### Bolt

Bolt's [database security settings](https://support.bolt.new/bolt-cloud/database/security) page says its Security page "checks only your database, not your whole project", using the same database checks as Supabase's Security Advisor. One warning, RLS Policy Always True, means a policy has no conditions that limit who can access a row. The page says that warning "is acceptable only if you’re comfortable with every visitor being able to change or delete that data."

Before you click Ask Bolt to fix, paste the prompt above so Bolt lists the policy changes first. Then read who each new policy lets in.

### Supabase

Supabase's [advisors](https://supabase.com/docs/guides/observability/advisors) run from Security Advisor in the dashboard. Open it after the agent finishes and compare its list with the agent's. Then confirm the basics yourself. Supabase's [Row Level Security guide](https://supabase.com/docs/guides/database/postgres/row-level-security) says "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." The [API keys guide](https://supabase.com/docs/guides/getting-started/api-keys) says "A secret key bypasses every Row Level Security policy you have."

## FAQ

### My agent says the app is secure. Is that enough?

No. It is a useful summary of what the agent checked. Replit says no scan guarantees that an app is secure, and Lovable says its tools cannot guarantee complete security. Run the checks on this page, or ask someone to review the app.

### Why ask the agent to wait before it changes the database?

So you can read each change before it runs. A policy decides who can read and change your data. Bolt's database security page says that if you haven't asked Bolt to add sign-in, "Bolt might write policies that allow any visitor to view, add, change, and delete the data in your database." Reading the change first is how you catch a policy like that.

### What if I can't do these checks myself?

Hand the list to someone who can. [/help](/help) lists agencies whose own public pages offer paid security or production-readiness work. If someone built the app for you, the [Security checklist for AI client work](/issues/security-checklist-for-ai-client-work) covers what they should hand over.

## Sources

- [Replit: Security scan levels](https://docs.replit.com/features/security/security-scan-levels)
- [Replit shared responsibility model](https://docs.replit.com/features/security/shared-responsibility-model)
- [Replit Agent overview](https://docs.replit.com/features/agent/overview)
- [Lovable security overview](https://docs.lovable.dev/features/security)
- [Bolt: Database security settings](https://support.bolt.new/bolt-cloud/database/security)
- [Claude Code security](https://code.claude.com/docs/en/security)
- [Supabase advisors](https://supabase.com/docs/guides/observability/advisors)
- [Supabase Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [Supabase API keys](https://supabase.com/docs/guides/getting-started/api-keys)