seclab-taskflows packages example AI agent taskflows and custom MCP servers for auditing source code, triaging issues, and finding vulnerabilities in web, Android, and iOS projects.

seclab-taskflows is the companion repository to the experimental seclab-taskflow-agent maintained by the GitHub Security Lab, and it represents one of the more serious attempts to structure AI agents around a real security workflow: auditing source code for vulnerabilities and triaging the resulting issues. The repo is written in Python, carries an MIT license, and sits at 83 stars at the time of writing — modest numbers, but appropriate for what is fundamentally a research artifact and a set of examples rather than a polished product. What you actually get is a library of taskflows plus the custom MCP servers needed to execute them, which together turn the agent framework into something concretely useful.

The concept worth understanding first is the taskflow itself. Rather than prompting a generic chat model and hoping for the best, a taskflow encodes a repeatable multi-step procedure — collect entry points, classify components, analyze data flow, check findings against advisories — that the agent executes against a target repository. The canonical demo in the README is a GHSA variant analysis: it takes an advisory ID (GHSA-c944-cv5f-hpvr affecting github/cmark-gfm) and looks for similar vulnerability patterns in code. This is variant analysis, one of the highest-value activities in defensive vulnerability research, because most real-world bugs arrive as families rather than isolated instances.

The quick-start path is deliberately frictionless. You open a GitHub Codespace on the repository, wait for the (.venv) prompt to appear, and invoke the agent as a Python module with python -m seclab_taskflow_agent, passing the taskflow path via -t and parameters via repeated -g flags. For full audits there is a wrapper script, ./scripts/audit/run_audit.sh, demonstrated against juice-shop/juice-shop — a deliberately vulnerable training application that is the standard sandbox target for this kind of work. The README is refreshingly honest about cost: auditing taskflows can run for several hours on larger projects and make a lot of AI requests, which can be expensive under default Copilot billing.

Architecturally, the interesting part is the separation between the agent (separate repo) and this repository's taskflows and MCP servers. The MCP servers handle persistence and intermediate state: MEMCACHE_STATE_DIR caches intermediate data, DATA_DIR lets the servers store intermediate results, and LOG_DIR collects server logs, all configurable through a .env file in the repo root. If none are set, folders are created automatically using platformdirs. This is a sensible design — the agent remains stateless and swappable while the taskflow infrastructure owns the data model.

Model flexibility is handled through environment variables. By default the taskflows call the Copilot API at https://api.githubcopilot.com, but you can point AI_API_ENDPOINT and AI_API_TOKEN at a different provider entirely, which matters for teams with strict data-handling requirements or existing LLM contracts. A GH_TOKEN is also required for GitHub API interactions such as fetching repository content or creating issues, so the agent operates with whatever scope you grant that token — worth scoping carefully even in authorized use.

The sandboxing story deserves explicit credit. The README recommends running taskflows in a sandboxed environment and offers two paths: GitHub Codespaces for convenience, or the run_seclab_agent.sh script which runs a Docker container of the agent. Container images come from ghcr.io/githubsecuritylab/ under the mutable latest tag, and the README includes a practical warning about stale local caches — you may need docker rmi on the cached images to guarantee you're running current code. This attention to isolation reflects the reality that agentic frameworks executing against arbitrary source should never run bare on a workstation.

Mobile support is the most technically detailed section of the README. The audit workflow recognizes Android, iOS, and cross-platform applications alongside web apps and libraries. Entry-point collection records exported Android components, deep links, URL schemes, Universal Links, app extensions, and WebView JavaScript bridges, including permissions, export status, and input filters. That inventory is exactly what a mobile security engineer would build by hand during a first-pass assessment, which suggests the taskflows were designed by people who have done the manual version of this work. Mobile metadata lands in a mobile_entry_point table, and existing context databases gain a nullable application.is_mobile_app column via migration rather than destructive schema changes — a small detail that indicates care about backward compatibility. Both mobile entry-point taskflows use a container-backed source-access toolbox and therefore require Docker.

The output side is pragmatic rather than flashy. Results are written to an SQLite database that opens automatically in a viewer when a run finishes, with the key table named audit_result. Crucially, that table has a has_vulnerability column with checkmarks marking the rows most likely to be genuine vulnerabilities — an explicit triage signal that acknowledges the false-positive problem inherent in AI-assisted analysis. The --advisory and -m options apply to mobile runs as well, and subdirectory README.md files document per-taskflow requirements.

Where does this fit in an authorized workflow? The obvious niche is first-pass automated auditing of codebases you own or are contracted to assess, followed by human review of the flagged rows. The GHSA variant analysis flow is arguably the strongest single use case: after a public advisory drops, running variant analysis across your dependencies or monorepo is a legitimate and often urgent defensive activity. The heavy runtime and API cost mean it is not a per-commit CI check today; it is closer to a scheduled or event-triggered deep scan. Anyone evaluating it should budget for AI_API_TOKEN usage and expect long wall-clock times on large repositories.

There are caveats a professional should weigh. The project is explicitly experimental — the GitHub Security Lab frames it as a way to experiment with AI agents for security purposes, and the mutable latest tags plus evolving agent repo mean reproducibility is not guaranteed. Requirements are Python >= 3.11 for local execution and Docker for container-backed taskflows. The README directs feedback to GitHub issues and welcomes pull requests under its CONTRIBUTING.md, with CODEOWNERS and SUPPORT.md present, which are good signals for an early-stage project even if the topics list is empty.

Taken as a whole, seclab-taskflows is less a tool you deploy and more a reference architecture you learn from. The combination of declarative taskflows, MCP-mediated state, swappable AI backends, containerized execution, and SQLite-backed triage output sketches a sensible blueprint for how agentic security automation should be built — with explicit cost warnings, sandboxing defaults, and honest handling of uncertainty in results. For defenders and authorized assessors experimenting with AI-assisted auditing, it is one of the more credible starting points currently published.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Related coverage

• Automating asset discovery and supply chain vulnerability triage with dddd


• Automating vulnerability intelligence workflows with the VulnCheck CLI


• Inside slowmist Knowledge-Base: a curated map of blockchain security research