Is Bolt safe? The platform is certified. Your app is not covered by that

When somebody asks whether Bolt is safe, they are usually asking two questions at once and getting the answer to the wrong one. The two have different answers, and only one of them is about Bolt.

Bolt the company runs a well-secured platform, and it publishes the receipts. The app Bolt generated for you is a separate object with a separate answer, and no certificate on the first covers the second.

What is actually certified?

From Bolt's own security page, and these are real and worth having:

• SOC 2 Type 2, plus GDPR and CCPA compliance
• An isolated WebContainer sandbox. Your project runs client-side, inside your own browser, not on shared infrastructure. That removes a whole category of risk before it exists.
• AES-256 at rest, TLS 1.2 or higher in transit
• Independent third-party assessors testing the platform annually, with pentest summaries available on request
• 24/7 monitoring with automated scanning and intrusion detection

Read that list again and notice what every item has in common. Each one describes Bolt's infrastructure. Not one of them describes your code.

That distinction is not a gotcha. It is how every platform works. AWS is certified to the eyeballs and still lets you leave an S3 bucket public.

Does Bolt secure the code it writes?

Partly, and more than most. This is where Bolt is genuinely ahead of its peers.

Bolt says it bakes security patterns into generation: Row Level Security "as far as the application allows", authentication patterns that hold up, parameterised queries, escaped output, and security constraints carried in the system prompts themselves. Guardrails at generation time are better than a scan afterwards, and that is a real design decision rather than marketing.

It also offers an automatic security review. Their FAQ describes it plainly: "Turn it on once and Bolt reviews every app before it goes live." When it finds something, one button analyses it, applies a fix, and publishes the secured version at no extra cost.

Since July 2026 the audit is also a button: hit Publish and choose Run security audit. Bolt says it is free and uses none of your tokens. According to Bolt's help page it reviews the whole project for who can see and change data, what the app makes public, how people sign in, ways the app can be misused (such as changing a price), the input it accepts, and keys or passwords in code or sent to browsers. It fixes most problems itself and lists what you have to change by hand.

That is a good feature. Two things about it matter for your app right now.

It only runs when you run it. "Turn it on once" means it is off until you do, and the publish-menu button only helps if you press it. If you have done neither, no audit has run on anything you shipped.

"As far as the application allows" is doing a lot of work in that RLS sentence. A generator can follow a pattern. It cannot know that in your app a team_id means shared access but a user_id means private, because you never told it, and the difference between those two is the entire security model of your app.

So what is left for you?

Bolt's audit now looks for several items on this list. Check them yourself anyway, for one reason: an automated review can find a missing check, but it cannot know which records each of your users is meant to see.

Who can see whose data. Change an id in a URL while logged in as a second account. If you can see the first account's records, you have found the flaw that matters most, and no platform certificate touches it.

API keys in the bundle. Bolt runs your project client-side. That is excellent for build-time isolation and completely unrelated to whether a key ended up in your shipped JavaScript. View source on your deployed app and search for sk-, key, secret and token.

Database grants. Bolt follows RLS best practice, but on Supabase, enabling RLS does not revoke the privileges granted when the table was created. That is Supabase's own documented behaviour and it is a separate step nobody runs. We wrote up how to test grants and policies.

Your paywall. If a premium feature is hidden with CSS rather than checked on the server, it is free to anyone who opens developer tools.

Business logic. Whether a discount code can be applied twice, whether a form can be replayed, whether an order total is calculated client-side. Bolt's audit looks for some of this, such as a price a user can change. The rules specific to what you built are still yours to test.

Is Bolt safer than the alternatives?

On the platform, yes. Its SOC 2 Type 2 certification puts it ahead of many tools in this category, several of which disclose almost nothing about their security practices at all.

On generated code it has caught up with the field: guardrails at generation time plus a free audit before publish, much like Lovable's free scans and the Agent scans on Replit's paid plans. On the thing an automated check cannot settle, what your app is meant to allow, it is level with everyone else.

The honest summary is that choosing Bolt was a good decision and it did not finish the job. It could not have.

What should I do this week?

Two things, and the order matters more than it looks. The first takes a minute and the second takes an evening.

Run the security audit from the publish menu, and switch on the automatic review so it runs every time. It is free and there is no argument against it.

Then test four things yourself. Make a second account and try to read the first one's data. View source and search for keys. Look at your Supabase grants, not just the RLS toggle. Call a premium endpoint as a free user.

If you want an independent second read of the code, that is what Sentrint is for. It scans the GitHub repository behind your app and returns each finding in plain English, with a fix prompt you can paste back into Bolt. A code scan, not a pentest. You can read a full sample report first, and the first scan is free with no card.

Either way, do the four checks. They take an evening and they cover the flaws that get people.