How Lovable users wire gjalla in as their audit backend

Last month, a security researcher posted that they’d made a free Lovable account and immediately pulled down another user’s source code, database credentials, chat history, and customer data. Their words:

“This is not hacking. This is five API calls from a free account.” (@weezerOSINT, April 2026)

That was on top of CVE-2025-48757 from a year earlier, where Matt Palmer found 303 endpoints across 170 live Lovable projects with broken Supabase RLS. As he put it, the platform was giving builders “a false sense of security, failing to detect the misconfigurations that expose data.”

If you’re shipping on Lovable, you already feel the tension. The agent is fast. You ship in a weekend. But you’re one prompt away from publishing a Supabase table the whole internet can read. Harry Metcalfe summed up the user-side problem better than I could after testing it himself:

“They are, in short, a massive footgun for the uninitiated. You have to know to ask, and if you’re using Lovable to build your website in the first place, you probably don’t.”

The friend who turned us into an audit backend

A friend of mine isn’t an engineer. He built something real on Lovable, started getting traction, and then hit the same wall: he had no honest answer to “is this safe to leave running?” He didn’t want to learn Supabase RLS from a YouTube video, and he didn’t want to wait until something went wrong to find out.

He wired gjalla into Lovable as an MCP connector. Now his Lovable agent pulls our findings directly into the chat, and he asks it to fix them. That’s the loop this post is about.

What gjalla actually does in this setup

gjalla reads your repo and looks for things such as exposed keys, RLS gaps, and missing auth checks, the kinds of things that don’t show up until someone is already in your database. Connecting it to Lovable via MCP means your Lovable agent can read those findings as a tool call. No screenshotting, no copy-paste, no context-switching to a separate dashboard.

It’s not a release gate. It’s the second pair of eyes you don’t have.

Connecting it

You need a gjalla project pointed at your repo and one completed analysis run.

In Lovable:

1. Open Connectors
2. Under Chat connectors, pick Custom
3. Choose Gjalla
4. Paste your gjalla MCP URL (find it in your gjalla project settings)
5. Keep default auth, click Add, then Authorize

You’re granting read-only access to your gjalla project. Once it’s wired, confirm Get Findings shows up as an enabled tool.

Prompts that actually do work

First time through, ask for the inventory:

Pull the latest gjalla findings. List every one tagged security, sorted by severity, with the file and line.

Then triage:

Take the top three. For each, explain the risk in plain English, then show me the smallest change that fixes it.

The agent reads findings, proposes patches, and applies them in your repo. You re-run analysis to confirm the finding is gone, not just edited around.

Keeping findings honest

Stale findings are worse than none, because they give you cover to ship. Pick one:

• Per PR. The right default. Every change gets a fresh read before merge.
• On demand. Before a release, or after a big agent session that touched a lot.
• Weekly schedule. Background coverage so nothing rots in the corners.

If you’re early, run all three. The cost is low. The cost of finding out later is not.

What this won’t catch

It won’t catch a vulnerability in Lovable itself, like the BOLA bug that exposed every project created before November 2025. It won’t catch a logic flaw that looks fine to a static analyzer. It won’t replace someone you trust looking at your code before you put it in front of real users.

What it will do is surface the kinds of things a reviewer would recognize, before you ship. For most people building on Lovable, that’s the gap.