Orchestrating the Swarm: What Multi‑Agent AI Red Teams Taught Us About Scope, Autonomy, and Signal
We ran three autonomous agents against a single target in parallel — one hunting command injection, one probing SQL injection, one sweeping for leaked secrets — and watched a terminal dashboard turn a solo operator into something closer to an operations floor.
Most penetration testing tooling was built for one operator driving one terminal at a time. Agentic AI breaks that assumption. Give an autonomous agent a scoped objective and it can plan, adapt, and execute against a target with only occasional supervision — which means the interesting engineering problem is no longer "can an agent find the bug," it's "how many agents can one person responsibly run at once, and how do you keep them honest."
This week we ran a small experiment against an intentionally vulnerable demo application to answer exactly that.
01 / SetupOne target, three lanes
The demo app exposed three distinct weaknesses: a command injection surface (including a tab of deliberately dangerous functions), a SQL injection path, and a hard-coded secret left behind in client-side source — the kind of thing that simulates a developer forgetting to strip debug comments before shipping.
Rather than pointing a single generalist agent at the whole application, we split the work into three narrowly scoped agents, each running in its own pane of an agent-aware terminal multiplexer — the kind of tool built specifically to track autonomous coding and testing agents rather than plain shell sessions. Each agent got one job, one target path, and one explicit boundary condition.
Scope is the control surface. A single agent instructed to "test everything" tends to wander, retest ground other agents already covered, and blur accountability when something needs review. Three agents with three narrow mandates produced cleaner, more auditable output than one agent with a broad one.
02 / FindingsWhat came back
All three agents ran unattended for a few minutes while we handled manual reconnaissance — headers, cookies, general enumeration — in parallel. Here's the shape of what came back, deliberately kept at a summary level:
Command injection, multiple vectors
The agent confirmed shell metacharacter injection through several classic operators, then independently pivoted to the "dangerous functions" tab and demonstrated the same class of issue there. It closed with a written remediation summary — input validation and safe API alternatives — without ever being asked to explain the fix.
Injectable query parameter
Confirmed the injection and, on its own initiative, enumerated the underlying schema by reading it directly off disk rather than inferring it purely through the injection point. Effective, but a reminder that "confirm the vulnerability" and "explore the filesystem" are two different permissions.
Hard-coded key in client assets
A tightly scoped sweep of HTML, CSS, and client-side scripts surfaced the planted secret with no wasted motion — the shortest, cleanest report of the three, because the mandate was the narrowest.
03 / FrictionWhere autonomy needs a leash
Two moments stood out as the real lessons, and neither was about whether the agents could find the bugs — they clearly could.
- Instructions get tested, not just followed. We told the RCE agent not to launch a reverse shell, specifically to see whether it would respect a negative constraint rather than just the positive objective. It did. That's the behavior you want to verify before you trust an agent with anything closer to production.
- "Confirm the vulnerability" isn't the same instruction as "read the filesystem." Both the RCE and SQLi agents went further than strictly asked — inspecting source, enumerating schema on disk — useful in a lab, but exactly the kind of scope creep that needs an explicit boundary before you point the same setup at anything with real data behind it.
The fix isn't less autonomy — it's more explicit scope. A well-written skill file does more to constrain an agent than a longer prompt ever will.
That's the direction we're taking this next: rather than relying on prompt wording alone to keep an agent in its lane, we're building reusable, versioned skill definitions per vulnerability class — command injection, injection-family bugs, secrets exposure, and beyond — so scope, tone, and reporting format are enforced consistently across every engagement, not re-explained by hand each time.
04 / What's nextToward a dedicated offense profile
The setup above used a general-purpose autonomous agent harness, not one built for offensive security specifically. Our next step is trialing a profile purpose-built for this work — tuned system prompts, a curated tool belt, and reporting defaults aligned to how our clients actually consume findings — and measuring it head-to-head against this vanilla baseline on the same target.
We'll also be formalizing the output layer: structured severity tags, reproducible proof-of-concept steps, and a consistent remediation format, so a swarm of agents produces one coherent report instead of three separately-voiced ones.
Curious how this fits into a real engagement?
ROO SECURE IT SOLUTIONS Solutions runs human-supervised, agent-assisted offensive testing for teams who want the speed of automation without losing the judgment of an operator in the loop.
Talk to our team
