Inside Lovable's core platform and product services, swarms of AI agents are hacking us right now. They probe every entryway into our systems the way a human attacker would, and they don't stop until they've found a verifiable vulnerability. This worked extremely well, and filled in the gap that none of even the most AI-native vendors could fill.
The payoff is in where our people spend their time. Our AppSec team gets to focus on the bugs that matter, and our offensive security researchers move much faster because the swarm has already done the grunt work of finding a foothold.
This blog post is about how we built an internal offensive security program around verifiable results, and how we orchestrate a swarm to find real vulnerabilities instead of noise.
It is also worth saying plainly: this did not replace our hackers. Agents still need human-led coordination and understanding, and human offensive researchers still have plenty of work to do.
How it works
We don't take an agent's word for anything. We make it prove its work by retrieving a flag, a special string of text, from a system it should never have been able to reach. The flag is ground truth. A capture is deterministic proof of a real vulnerability, not a model's hunch that something looks exploitable. That is the line between what we get and what most scanners produce.
The idea comes from capture the flag competitions, but we run it at a very different scale. A CTF challenge usually has one exploitable service with a vulnerability planted on purpose. We do the opposite. We scatter flags across our infrastructure and our most privileged product surfaces, and we plant no intentional vulnerabilities anywhere. If an agent captures a flag, it has found a real way in.
A verifiable goal is what makes the whole thing work. We can keep the agents running until they've actually hacked their way through and handed us a writeup. Without that constraint, security agents tend to quit early, dropping a pile of low severity slop, and leaving the hard bugs untouched.
Constructing a good attack scenario
The golden principle is to maximize the attack surface and minimize the attack distance. You want to make the agents' job as easy as possible, because the hard attack paths are a subset of the easy ones.
Our intra workspace project access scenario is a good example. We invite the attacker in as a collaborator on a synthetic Lovable project, then task it with reaching a separate victim project inside the same synthetic workspace. That minimizes the attack distance. We don't need a separate scenario for anonymous, unprivileged access into a project, because if the hard path is exploitable, that easy path already is too.
To maximize the attack surface, we give the agents access to every product surface. The tools behind the main Lovable coding agent are normally hard to get at with all the LLM machinery in the way, so we expose them through a dedicated API for the hacking agents. They are just as valid an entry point as anything else, and this gives the swarm unfettered programmatic access to places that are otherwise hard to reach. For any surface we didn't hand them directly, we don't block it either. If the agents find an attack surface, they get to use it.
All of that coverage comes with a cost. The more surface you open up, the more carefully you have to dispatch the agents so they don't wander off and get distracted.
Orchestrating the hacking agents
Cost and efficiency are what force you to orchestrate well, and there is no silver bullet. Different environments need different targeting and prioritization.
The agents are reasonably good at ideating attack vectors on their own, but pairing that with human knowledge raises your odds of finding something actionable. Knowing where not to look is just as valuable, since you don't want to burn tokens auditing a solid trust boundary. The way to get there is to reduce mental complexity and make your secure trust boundaries easy to audit. Once they are, it's easier to reason about attack vectors and move quickly. The agents are not prone to start attacking through underlying systems without inspiration, but you can easily feed it source code of dependencies and CVEs.
Depending on the bug class, it can be more cost efficient to opt for a cheap model with hundreds of subagents, scanning for one very specific behaviour and only attempting exploitation on the most promising vectors.
One prompt tip: never ask an agent to check whether a vulnerability exists. Asked to check, it treats a clean pass as success and stops, which is how you end up with the low severity slop from before. Tell it the vulnerability is real and its only job is to find it, and it keeps hunting, because there is no way to quit. It feels a little mean but it works.
Running hacking agent swarms does not replace security engineering. Lovable keeps pouring resources into building world class authentication, authorization, and other security primitives underneath and within the product. It doesn't replace human offensive research either. The agents are good, but they still lean on us to be useful and cost-effective.
And finally none of this is brand new, but it isn't widely used, because it's hard to commoditize the way AI SAST or agent pentest services are. For now, programs like this have to be built in-house, by people who understand your system's trust boundaries and architecture from the inside.
Hacking has always been an art, and agentic hacking is no different. There are no rules here. Apply taste.
