GitHub Security Lab has published a concrete example of agentic security research moving beyond general-purpose code review. Using its open-source GitHub Security Lab Taskflow Agent and a set of reusable audit taskflows, the team says it found and reported 24 vulnerabilities in Android applications.
The system is not presented as a fully autonomous security researcher. Instead, GitHub breaks an audit into explicit steps, uses structured prompts to guide models through those steps, repeats some analyses to reduce misses, and then relies on security researchers to validate the results. The Taskflow Agent itself is an MCP-enabled multi-agent framework with a declarative YAML grammar, while the companion SecLab Taskflows repository contains practical audit workflows and supporting tools.
That distinction matters. The material change is not simply that a language model can inspect source code. GitHub has turned parts of an expert audit method into a repeatable workflow that can be versioned, shared and run against new repositories.
Taskflows make the security method explicit
GitHub’s Android audit separates the work into narrower tasks. One task identifies mobile entry points, while another asks the model to consider Android-specific vulnerability classes around those entry points. The article describes repeated runs and both constrained and broader prompts so that obvious issues are less likely to be missed while the model can still search for less predictable logic flaws.
This makes the workflow itself an important artifact. A security researcher can review the sequence of tasks, the prompts and the tools instead of treating the model as a black box. The companion repository also allows teams to run the taskflows in a Codespace or locally, although GitHub notes that the workflows can take substantial time and generate many model requests.
For Aipolix, the architectural implication is that agentic security quality increasingly depends on orchestration, not only model capability. A stronger model may improve individual steps, but the decomposition of the investigation, the evidence passed between steps and the validation process determine how useful the overall system becomes.
GitHub reports 24 Android vulnerabilities
In its September 28 disclosure, GitHub Security Lab says the taskflows had found and reported 24 Android vulnerabilities at the time of writing. The article gives examples involving exported Android activities, WebView behavior and cross-application interactions. GitHub argues that the method can uncover logic vulnerabilities rather than only generic pattern-matching issues.
The result is operationally interesting because the workflow is reusable. Security teams can encode an audit strategy once, refine it and apply it to another target. That is different from asking a coding assistant to “find vulnerabilities” in a single prompt.
The public repositories also make the approach inspectable. The Taskflow Agent uses YAML-defined workflows and can connect to tools through MCP. The SecLab Taskflows repository provides examples for auditing and other security research tasks. This does not prove that the same vulnerability yield will transfer to other codebases, but it gives practitioners an implementation they can examine instead of only a benchmark claim.
Human review remains the control boundary
GitHub is explicit about the limitations. The models sometimes report low-severity issues that are not practically exploitable, and they can estimate severity incorrectly because they miss mitigating behavior elsewhere in an application. GitHub describes cases where creating a proof of concept or debugging the original program is necessary to determine whether a finding is real.
That means “24 vulnerabilities” should not be read as evidence that the agent can replace an experienced security researcher. The disclosure comes from GitHub Security Lab itself, and this Research run did not independently reproduce the findings.
The workflow also has cost and access constraints. GitHub says running the taskflows may involve many tool calls, can take hours on larger repositories and currently relies by default on GitHub Copilot access. Those constraints matter for teams considering continuous use across many projects.
The stronger conclusion is narrower: structured agent workflows can make parts of vulnerability research reproducible and scalable, but the final security decision still depends on verification.
The reusable asset is the investigation process
The most important design lesson is that the durable asset may be the taskflow rather than the model output. A taskflow can capture how a researcher scopes an audit, which attack surfaces receive special attention, which tools are invoked and when evidence must be checked again.
That creates a new engineering surface for application security. Teams can version security workflows, review changes to prompts and tools, compare results across model versions and add organization-specific checks without rebuilding an entire security product.
It also creates new governance questions. A taskflow can consume source code, invoke external tools and generate expensive model traffic. Teams need to control credentials, tool permissions, data handling and the provenance of findings. GitHub’s repository even warns that the provided agent container is a deployment convenience rather than a security boundary.
Aipolix’s conclusion is that this work is significant because it makes an expert security process programmable. The model remains important, but the more transferable innovation is the combination of explicit task decomposition, tool use, reusable audit logic and human verification.