Inside Lovable's Own Swarm of AI Hacking Agents
Lovable runs an authorized programme where swarms of hacking agents attack its own live systems, and only a captured flag counts as proof of a vulnerability.
An authorized program, not open testing
Lovable built this programme to run against its own core platform and product services, with swarms of AI agents probing every entry point the way a human attacker would. According to Lovable's own writeup, the goal is to fill a gap that even AI-native security vendors could not close, and the company is explicit that this did not replace its human hackers: agents still need human-led coordination, and human offensive researchers still have plenty of work to do. This is an internal, authorized effort against Lovable's own systems, not a template for probing infrastructure a reader does not own or have permission to test.
Why a captured flag is the bar
Lovable does not take an agent's word that something is exploitable. Instead, an agent has to retrieve 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. The idea borrows from capture-the-flag competitions, but Lovable runs it differently: rather than planting one vulnerability on purpose the way a typical competition does, Lovable scatters flags across its infrastructure and its most privileged product surfaces without planting any intentional vulnerabilities anywhere. If an agent captures a flag, Lovable says, it has found a real way in.
Designing the attack scenarios
Lovable's guiding rule is to maximize the attack surface while minimizing the attack distance, since the harder attack paths are a subset of the easier ones. In its intra-workspace project access scenario, Lovable invites an attacking agent in as a collaborator on a synthetic project, then tasks it with reaching a separate victim project inside the same synthetic workspace. To maximize surface, Lovable gives the agents access to every product surface, including the tools behind its main coding agent, which it exposes through a dedicated API built specifically for the hacking agents, since those tools are normally hard to reach through the usual product interface.
How the swarm is run
Lovable says orchestration is where cost and efficiency pressure force careful design, and different environments need different targeting. Pairing the agents' own ability to ideate attack vectors with human knowledge raises the odds of finding something actionable, and reducing the complexity of trust boundaries makes them easier to audit and reason about. Depending on the bug class, Lovable says it can be more cost-efficient to run a cheap model across hundreds of narrowly targeted subagents scanning for one specific behavior, only attempting exploitation on the most promising leads.
The prompting trick that changes agent behavior
Lovable shares one specific prompting lesson: never ask an agent to check whether a vulnerability exists. Asked to check, an agent treats a clean pass as success and stops, producing low-severity noise. Telling the agent the vulnerability is real and its only job is to find it keeps it hunting, since there is no way to declare victory early.
What this does not replace
Lovable is direct that running these hacking swarms does not replace security engineering or human offensive research; the company keeps investing in authentication, authorization, and other security primitives underneath the product, and human researchers still do the follow-through work. Lovable also notes this approach is hard to commoditize the way generic AI security-scanning or pentest services are, so for now, programs like this have to be built in-house by people who understand a system's own trust boundaries and architecture.
Key facts
- Lovable's programme is an authorized internal effort against its own live core platform and product services, not third-party systems.
- Only a captured flag, a specific piece of text retrieved from a system the agent should not reach, counts as a confirmed vulnerability.
- No intentional vulnerabilities are planted; flags are scattered across real infrastructure and privileged surfaces instead.
- Lovable exposes the tools behind its main coding agent through a dedicated API built for the attacking agents.
- A key prompting rule: tell the agent the vulnerability is real and to find it, rather than asking it to check whether one exists.
What you can check before trying anything similar
If your own team wants to explore agent-driven offensive testing, the first check is authorization and scope: Lovable's programme only ever targets systems it owns, with flags planted by the company itself, never a system you do not control or lack permission to test. From there, Lovable's approach suggests starting by reducing the complexity of your own trust boundaries so they are easier to audit, deciding whether a scenario should minimize attack distance the way Lovable's intra-workspace example does, and testing the exact prompting difference between asking an agent to "check for" a vulnerability versus telling it one is confirmed and its job is only to find it.
Check your understanding
- Why does Lovable only count a captured flag, and not an agent's own claim, as proof of a vulnerability?
- What is the difference between a typical capture-the-flag competition and how Lovable scatters flags across its own systems?
- Why does Lovable say telling an agent a vulnerability is real works better than asking it to check whether one exists?