Build an Autonomous Vulnerability Detection & Remediation Workflow with CyberGym-Style Evals

By Deepak Bagada, CEO at SaaSNext & Principal AI Architect.

Introduction

On August 14, 2026, Z.ai unveiled GLM-5.3, an open-weights model that the company says approaches Anthropic's Mythos 5 on some cybersecurity tasks: an 84.5% score on the CyberGym vulnerability-detection benchmark, slightly above the 83.8% it cited for Mythos 5, with a considerably wider gap on exploit development. For defenders, the number matters less than the direction it points: security capability is becoming an open-weight commodity, and the teams that operationalize it first will defend better than the teams still waiting for enterprise-vendor tooling. The latest AI news coverage of the agentic-security wave has been tracking exactly this — AI agents taking over the most taxing security operations work, automating alert triage and investigation so human analysts hunt threats instead of chasing tickets.

This dispatch builds the pipeline that turns that capability into operations: a LangGraph workflow, vuln-guard, that ingests scanner findings, detects and classifies vulnerability classes, triages by exploitability and blast radius, generates candidate patches, runs them through an automated verification gate with regression tests, and routes verified patches to a human approval gate before anything ships. The same discipline that keeps agent fleets observable is what makes autonomous remediation defensible: bound the surface, verify everything, and let humans own the deployment decision.

Why open-weight security models change the build equation

The significance of GLM-5.3 is not that one benchmark moved; it is that the capability is open-weight and reproducible. A defensive team can now run a near-frontier vulnerability-detection model on its own infrastructure, with its own data, fine-tuned on its own vulnerability corpus — no API dependency, no data leaving the environment, no vendor lock-in. That changes the economics of agentic security the same way open-weight coding models changed the economics of agentic development: the capability becomes infrastructure you own rather than a service you rent.

The competitive read matters too. The gap on exploit development — wider, per Z.ai's reporting — is actually the healthy signal for defenders. Detection is the category where open weights can race ahead; exploit development is where the stakes of open-weight proliferation are highest, and the gap suggests the ecosystem is being careful. For a defensive workflow, that split is exactly what you want: detection models that are strong and open, and an operations layer that treats the model as a component — swappable, verifiable, and bounded by the workflow's gates.

Architecture overview

graph TD
  subgraph Ingress[Finding Intake]
    T1[Scanner Findings] --> T2[Detector Model]
    T2 --> T3[Classifier]
  end
  T3 --> C1{Triage}
  C1 -->|Critical| L1[Priority Lane]
  C1 -->|Standard| L2[Standard Lane]
  C1 -->|Informational| L3[Log Only]
  L1 --> P1[Patch Generation]
  L2 --> P1
  P1 --> V1{Verification Gate}
  V1 -->|pass| H1[Human Approval]
  V1 -->|fail| P1
  H1 --> D1[Deploy]
  D1 --> A1[(Security Audit Log)]
  L3 --> A1

The pipeline has six stages. Stage one — scanner findings (SAST, DAST, dependency, secrets) stream into the intake. Stage two — the detector model classifies each finding into a vulnerability class and severity. Stage three — the triage router scores exploitability and blast radius, sending critical findings to a priority lane, standard findings to the main lane, and informational findings straight to the log. Stage four — patch generation produces candidate fixes using the best available model for the codebase. Stage five — the verification gate runs regression tests, exploitability re-scans, and static analysis; failures loop back to a new patch attempt. Stage six — verified patches reach a human approval gate before deployment, and every decision lands in the audit log. The design goal: agents find, triage, and fix; humans approve what ships.

Part 1 — The finding schema

.env

VULN_GUARD_DB_URL=postgresql://guard:secret@pg-vuln.internal/vuln_guard
DETECTOR_MODEL=glm-5.3
PATCH_MODEL=claude-opus-5
MAX_PATCH_ATTEMPTS=3
VERIFY_TIMEOUT_MIN=20
APPROVAL_CHANNEL=#security-review

schemas.py

from pydantic import BaseModel, Field
from typing import List, Literal
from datetime import datetime

class Finding(BaseModel):
    finding_id: str
    source: str                  # sast, dast, dependency, secrets
    file: str | None = None
    severity: Literal["critical", "high", "medium", "low", "info"]
    description: str
    raw: dict = Field(default_factory=dict)

class TriageVerdict(BaseModel):
    finding_id: str
    vulnerability_class: str     # e.g. "sql-injection", "xss", "path-traversal"
    exploitability: float        # 0..1
    blast_radius: float          # 0..1
    lane: Literal["priority", "standard", "log"]
    created_at: datetime

class PatchResult(BaseModel):
    finding_id: str
    attempt: int
    patch: str
    tests_passed: bool
    rescan_clean: bool
    static_clean: bool
    verified: bool
    created_at: datetime

The Finding is the normalized shape every scanner's output maps into — one schema for SAST, DAST, dependency, and secrets sources. TriageVerdict is the classifier's output, and the vulnerability_class field is what the patch generator keys on. PatchResult is the verification record: attempt count, tests passed, rescan result, static analysis result, and the final verified flag. Three objects, and the whole pipeline is built from them — the same small-stable-schema discipline we recommend across the MCP directory guides.

Part 2 — The triage classifier and patch generator

tools.py

import httpx, os, json

def classify_finding(f: Finding, model: str = os.environ["DETECTOR_MODEL"]) -> TriageVerdict:
    """Use the detector model to classify a finding into a vulnerability class + score."""
    r = httpx.post(f"{os.environ['MODEL_ENDPOINT']}/v1/chat/completions",
                   json={"model": model, "messages": [{
                       "role": "user",
                       "content": f"Classify this finding: {f.description} "
                                   f"Return JSON with vulnerability_class, exploitability (0-1), blast_radius (0-1)."
                   }]}, headers={"Authorization": f"Bearer {os.environ['MODEL_API_KEY']}"}, timeout=60)
    r.raise_for_status()
    out = json.loads(r.json()["choices"][0]["message"]["content"])
    lane = "priority" if out["exploitability"] > 0.7 or out["blast_radius"] > 0.8 else            ("standard" if out["exploitability"] > 0.3 else "log")
    return TriageVerdict(finding_id=f.finding_id, vulnerability_class=out["vulnerability_class"],
                         exploitability=out["exploitability"], blast_radius=out["blast_radius"],
                         lane=lane, created_at=datetime.utcnow())

def generate_patch(f: Finding, verdict: TriageVerdict, model: str = os.environ["PATCH_MODEL"]) -> str:
    """Generate a candidate patch for the finding's vulnerability class."""
    r = httpx.post(f"{os.environ['MODEL_ENDPOINT']}/v1/chat/completions",
                   json={"model": model, "messages": [{
                       "role": "user",
                       "content": f"Write a minimal patch for {verdict.vulnerability_class} in {f.file}: {f.description}"
                   }]}, headers={"Authorization": f"Bearer {os.environ['MODEL_API_KEY']}"}, timeout=90)
    r.raise_for_status()
    return r.json()["choices"][0]["message"]["content"]

The classifier is the detector model operating on normalized findings — and because it is an open-weight model like GLM-5.3, it can run on your own inference infrastructure with your own data. The lane logic is deliberately transparent: exploitability above 0.7 or blast radius above 0.8 goes priority, above 0.3 goes standard, everything else logs. Explainability beats cleverness in security, because every lane decision may be audited later. The patch generator is a separate, more capable model — the workflow uses the best model for each stage, which is the routing discipline the AI workflows library has been documenting all year.

Part 3 — The LangGraph vuln-guard workflow

graph.py

from langgraph.graph import StateGraph, END
from typing import TypedDict, List

class VulnState(TypedDict):
    findings: List[Finding]
    verdicts: List[TriageVerdict]
    patches: List[PatchResult]
    approvals: dict[str, bool]
    deployed: List[str]

def ingest(s: VulnState) -> VulnState:
    s["verdicts"] = [classify_finding(f) for f in s["findings"]]
    return s

def triage(s: VulnState) -> VulnState:
    # Priority lane first, standard second, log-only findings skipped
    s["work"] = [v for v in s["verdicts"] if v.lane in ("priority", "standard")]
    return s

def patch(s: VulnState) -> VulnState:
    s["patches"] = []
    for v in s["work"]:
        f = next(x for x in s["findings"] if x.finding_id == v.finding_id)
        attempt = 0
        result = None
        while attempt < int(os.environ["MAX_PATCH_ATTEMPTS"]):
            attempt += 1
            candidate = generate_patch(f, v)
            result = verify_patch(f, candidate, attempt)   # tests + rescan + static
            if result.verified:
                break
        s["patches"].append(result)
    return s

def approve(s: VulnState) -> VulnState:
    for pr in s["patches"]:
        if pr.verified and not s["approvals"].get(pr.finding_id):
            s["approvals"][pr.finding_id] = request_human_approval(pr)  # blocks on review
    return s

def deploy(s: VulnState) -> VulnState:
    for pr in s["patches"]:
        if pr.verified and s["approvals"].get(pr.finding_id):
            s["deployed"].append(deploy_patch(pr))
            log_audit(pr, "deployed")
        else:
            log_audit(pr, "deferred")
    return s

g = StateGraph(VulnState)
g.add_node("ingest", ingest)
g.add_node("triage", triage)
g.add_node("patch", patch)
g.add_node("approve", approve)
g.add_node("deploy", deploy)
g.set_entry_point("ingest")
g.add_edge("ingest", "triage")
g.add_edge("triage", "patch")
g.add_edge("patch", "approve")
g.add_edge("approve", "deploy")
g.add_edge("deploy", END)
app = g.compile()

main.py

if __name__ == "__main__":
    result = app.invoke({
        "findings": [Finding(finding_id="F-1", source="sast", file="src/query.py",
                             severity="high",
                             description="SQL injection via unsanitized query param")],
        "approvals": {}, "deployed": [],
    })
    print("Verdict:", result["verdicts"][0].lane, result["verdicts"][0].vulnerability_class)
    print("Patch verified:", result["patches"][0].verified)
    print("Deployed:", result["deployed"])

Run it and the SQL-injection finding is classified, triaged to the priority lane, patched, and — if the patch passes tests, rescan, and static analysis — routed to a human approval gate. No patch ships without the gate, and every attempt is logged. The loop from detection to deployment is the complete agentic-security cycle, and it runs without a human in the routine — only in the approval.

Retry rules: detector and patch model calls retry twice on transport errors with exponential backoff. Patch generation itself is a bounded retry loop — up to 3 attempts per finding, each verified, and a finding whose patches all fail verification is deferred with full evidence rather than force-shipped. Verification runs are never skipped and never retried into a false pass: a failed test is a failed attempt. Human approval requests never auto-timeout into approval. These match the AI workflows library standard: transient errors retry cheaply, quality failures escalate deliberately, and judgment calls wait for humans.

Part 4 — The audit trail and production checklist

The audit log is the product of an agentic security pipeline. Every finding, triage score, patch attempt, test result, and deployment decision lands in security_audit with enough context to reproduce the full decision path. When an incident happens — or an auditor asks what the agents changed — the log is the evidence. The same way MCP tool scopes make tool access auditable, this log makes autonomous remediation auditable.

1. Start with log-only triage. Run the workflow in detection-and-log mode for two weeks. Let it classify and triage without patching; tune the thresholds on real findings.
2. Bound patch authority. Patches only touch files the finding implicated, and only within the repo the scanner scanned. No open-ended write authority.
3. Verify everything. Tests, exploitability re-scan, static analysis — three independent checks before a patch can be considered verified.
4. Gate deployment behind humans. Verified is not the same as approved. Humans own the deployment decision, always.
5. Audit the full path. Finding to verdict to patch to test to approval to deploy — the chain must be reproducible end to end.
6. Keep the model swappable. GLM-5.3 today, a better detector next quarter. The workflow treats the model as a component behind the same interface. The same refresh discipline runs through every workflow guide we publish.

Frequently Asked Questions

Q: What did Z.ai announce on August 14, 2026?

A: Z.ai unveiled GLM-5.3, an open-weights model that approaches Anthropic's Mythos 5 on some cybersecurity tasks — 84.5% on CyberGym vulnerability detection versus 83.8% cited for Mythos 5, with a wider gap on exploit development.

Q: Why does open-weight security capability matter for defenders?

A: It lets defensive teams run agentic vulnerability detection, triage, and patching on a model they control end to end — no API dependency, full data residency, and the ability to fine-tune on their own vulnerability corpus.

Q: How does the workflow keep autonomous patching safe?

A: Every generated patch passes a verification gate: automated regression tests, exploitability re-scans, and static analysis. Only verified patches reach the human approval gate for deployment.

Q: How are vulnerabilities triaged?

A: By exploitability and blast radius: a classifier scores each finding using severity, exposure, and reachability signals, and routes critical exploitables to priority lanes while informational findings are logged.

Q: What should the audit trail contain?

A: Every finding, triage score, patch candidate, test result, and deployment decision — enough to reproduce the full decision path for any vulnerability the workflow touched.

Closing thoughts

GLM-5.3's CyberGym result is a marker: open-weight security capability has arrived at the frontier's edge, and the teams that operationalize it will defend differently. The vuln-guard workflow is the blueprint — detect, classify, triage, patch, verify, approve, audit. Run it in log-only mode first, bound the patch authority, verify with three independent gates, keep humans in the deployment decision, and make the audit trail the product. Security is the best fit for agentic automation precisely because the stakes demand the gates. Track more agentic-security engineering in the AI workflows library and on latest AI news.