A weakness that looks convincing in one file can vanish once you see the whole application. Luke Potter explains how the Swarm keeps an AI lead separate from a proven finding, and why the practitioner always makes the final call.
A suspected vulnerability can look convincing inside one source file and disappear when you understand how the rest of the application uses it.
The reverse happens too: code that looks reasonable in isolation can become dangerous when another part of the application supplies an unexpected value or relies on a missing check.
That is one of the practical problems we are working through as we develop agentic vulnerability research at CovertSwarm. We want to give the Swarm useful technical leads to investigate. Doing that requires an agent to follow relationships through code and recognize where its understanding is incomplete.
Recent development testing gave us a clear example. Local analysis of individual files looked encouraging.
Results across repositories were inconsistent, with the agent struggling to connect relevant files. Development has focused on JavaScript and TypeScript, and on working with focused sections of a codebase to improve that understanding.
That is an engineering problem worth talking about openly. A good result on one file gives you a reason to keep developing. Repository-level work asks more of the system.
Consider a hypothetical application where a request enters through one file, passes through a shared helper, and reaches a sensitive operation elsewhere. A check may happen before the helper is called.
Alternatively, two callers may use the same helper with different assumptions about who has already checked the input.
To assess a possible weakness, someone has to connect those pieces.
Where does the input originate? What happens to it along the way? Which checks apply on the route being examined? Can execution reach the operation under those conditions?
Missing a file can change the answer. The agent might overlook a control and report a problem that is already prevented. It might assume a check applies to every caller and miss a route where it does not.
Both errors can come from an incomplete view of the same code.
That is why input size is a poor stand-in for analysis quality. More source code helps only if the system can make the relevant connections. A smaller, focused section can make a particular question easier to investigate, while still leaving dependencies that need to be examined elsewhere.
For a practitioner, the useful output is a candidate issue with a technical basis they can investigate. The important next step is to establish whether the suspected behavior exists and what conditions it depends on.
I want that review to be specific.
Can we identify the relevant code path? Does the explanation account for the checks around it? Which assumptions need confirmation?
If a candidate rests on a caller behaving in a particular way, we need to inspect that caller rather than allowing the explanation to stand in for evidence.
The operator’s next job is to test that explanation against the code and the application’s behavior. An agent suggesting a weakness and a practitioner demonstrating its significance are different points in the investigation. Keeping that distinction clear makes the research more useful.
It also helps us decide what to improve. If a candidate fails because the agent missed a relevant file, that points towards a context problem. If it read the relevant code but misunderstood a condition, the explanation needs a different kind of scrutiny.
Treating both simply as a wrong answer would hide useful information from the development team.
Alongside the source-code work, our agentic research tooling has helped identify potential ways to investigate newly disclosed vulnerabilities. Practitioners have then developed methods for checking potential exposure.
The contribution is a starting point that an experienced researcher can take forward and test.
That experience also gives the development work a useful direction. The repository-level gap tells us where to focus: relationships between files, the assumptions made along a code path, and whether the analysis holds up on re-examination.
Those are concrete problems for the team to improve, and useful boundaries for practitioners to understand.
The benefit we are building towards is practical: give experienced researchers better starting points for difficult code investigations. Within Constant Cyber Attack, that capability can contribute to examining the routes that matter to a customer’s objective.
The progress that interests me is an agent helping the Swarm make a technically defensible judgment about the code in front of them.
An external attack surface gives an investigator plenty to look at. Domains, addresses, open services, and technology fingerprints can all be useful. The difficult decision is where to spend the next hour, and how what you discover should change that decision.
We have been developing an agentic workflow at CovertSwarm to help the Swarm work through that problem.
It moves from external discovery into deeper investigation, carrying observations and candidate issues forward as the work develops. Early trials have identified vulnerabilities. The engineering work continues around the quality of the investigation and the evidence needed to support its conclusions.
This is where agents become particularly interesting to me. They can contribute to a sequence of decisions, provided the workflow gives them a useful basis for each one.
The workflow starts with observations about the external surface, including domains, addresses, ports, and apparent technology stacks. Standardized discovery provides a starting dataset.
The next job is to relate those observations across assets and decide which warrant closer examination.
Deeper investigation includes fingerprinting, analysis of client-side JavaScript, and checks for specific vulnerabilities. Each can change the working picture. A technology assumption made early in discovery may need revisiting when an individual endpoint behaves differently.
Consider a hypothetical application whose main pages suggest one technology stack, while another endpoint appears to be served by a different component.
Carrying the first assumption through every subsequent check would risk overlooking that difference. The investigator needs to update the hypothesis and decide whether the new observation justifies a different line of inquiry.
Our development work retains observations alongside leads that remain unproven or have been refuted. That gives the investigation context as it progresses. Practitioners can also direct their own inquiries at the collected information, bringing their knowledge of the customer and the assessment objective to the next decision.
One recent engineering lesson came from looking closely at the agent’s activity. We found it repeatedly parsing the same client-side JavaScript across multiple assets. It was doing work, but revisiting identical material was getting in the way of useful progress. The team corrected that duplication.
That is a more useful development signal than simply knowing a run completed. It tells us something about how the agent uses the information already available to it.
Similar questions apply throughout the workflow: did discovery establish what we think it established? Was an asset fingerprinted properly? Has a candidate actually been investigated, or merely mentioned again?
Making a run easier to inspect also changed how it worked. In instrumented tests, the reporting requirements and checks became a bottleneck. We are working through how to preserve useful evidence without letting the measurement process dominate the investigation.
The balance matters. We need enough visibility to understand and improve an investigation, while keeping the agent focused on the question it is supposed to answer.
A possible issue belongs in the investigation before it necessarily belongs in a customer’s findings. Our development work deliberately sets a high threshold for promoting a lead to a validated vulnerability.
That threshold directs attention towards the evidence.
What behavior was observed? What remains assumed? Does the result support the conclusion being drawn?
Further validation work is part of this project’s development; a promising lead must remain uncertain until the supporting work is done.
The intended direction is practical exposure, such as an opportunity for initial access or sensitive-information disclosure, within authorized scope. The operator then needs to judge how that exposure relates to the customer’s business objective and what the team should examine next.
For the Swarm, the benefit we are building towards is an investigation they can pick up, challenge, and direct using the context accumulated so far.
For the customer, the value should appear in the quality of the questions pursued and the conclusions supported.
That is what makes the engineering exciting: each useful observation can change where the investigation goes, and skilled people have better material to base that decision on.
A research agent can start with accurate information about a business and still produce an assessment idea an operator cannot use.
The weakness may sit in an assumption added along the way: what a role involves, why a change matters, or which activities an assessment permits.
That has become a useful engineering problem in one of our development projects at CovertSwarm. We have been building and trialing an agentic workflow that researches an organization, proposes possible assessment ideas, then subjects those ideas to criticism and refinement.
The early demonstrations and trials have given us a practical way to examine how research becomes a usable assessment idea.
The interesting part is how the information changes as it moves through that process, and whether an experienced practitioner can examine those changes.
The research brings together company and industry context, recent business activity, hiring information, and professional roles.
Sources and references remain available in the research output so that the practitioner can return to the material behind a suggestion.
That matters because a source and an inference do different jobs. A business announcement might establish that an organization is expanding. The suggestion that this creates a particular security concern requires further reasoning.
A useful workflow lets the reviewer challenge that reasoning rather than accepting the announcement as proof of the concern.
Take a hypothetical organization opening a new office. Its published information might suggest that responsibilities are being distributed across locations. An agent could use that context to propose examining how an existing business process works between those locations.
Before taking that forward, the practitioner needs to check whether the inferred arrangement exists and whether the proposed work aligns with the agreed objective.
The reference gives them somewhere to start. It does not settle those questions. Several sources may repeat the same announcement, for example.
A reviewer needs to recognize that repetition rather than mistake it for independent support. Keeping the source material accessible makes that kind of challenge possible.
After research, the workflow generates multiple candidate ideas. It applies AI critique, uses that feedback to refine the candidates, and scores and ranks the resulting suggestions.
Having a distinct criticism stage gives the development team something specific to examine.
Did the criticism identify a weak assumption? Did the revised idea actually address it? Did the revision introduce another dependency that the research does not support?
Those are useful questions when changing prompts or comparing configurations. They also make clear why a polished final paragraph is an incomplete way to judge the workflow.
We have already seen a practical limitation in early trials: suggestions can depend on activities practitioners cannot use. An idea may be coherent in its own terms and still be unsuitable for the assessment. That failure belongs in the development work, because relevance and permission are separate questions.
The critique stage can help examine a proposal. We envision the operator bringing the customer context and authorized scope to the decision about taking it forward.
One observation from the early work was particularly useful. An experienced practitioner saw value in a candidate that the AI had ranked lower. They recognized relevance that the ranking had missed.
That gives us a concrete requirement to preserve as the work develops: the ordering should help someone review the options while leaving them able to inspect alternatives and pursue their own line of inquiry.
Otherwise, a ranking can quietly narrow the investigation around the system’s preferences.
There is a cost to consider here. More candidates mean more material to review. Better generation needs better criticism and useful supporting evidence, or we simply shift the effort to checking suggestions. Wider testing and refinement help establish that balance.
For the Swarm, the intended benefit is a better starting point for an investigation: research they can check, ideas they can challenge, and enough context to make their own decision.
In Constant Cyber Attack, that should help direct authorized work toward the customer’s objective. The engineering is worthwhile when it improves that decision, including when the right decision is to reject the suggestion.
When Your IDE Becomes An Insider: Testing Agentic Dev Tools Against Indirect Prompt Injection
Agentic development tools don’t need to bypass your firewall. They’re already inside. And if an attacker can control what they read, they can control what they…
CovertSwarm named a Sample Vendor for Agentic Red Teaming in the Gartner® Emerging Tech Impact Radar: Preemptive Cybersecurity
The question for security leaders is who’s in charge of the agents that test their defenses. We think it should be ethical hackers. That’s how we’re…
CovertSwarm launches RAID: Our red team AI division
CovertSwarm COO Luke Potter announces RAID, our Red Team AI Division, and why real adversaries made it non-negotiable.