Autonomous Vulnerability Discovery Agents in Practice: From Kernel Privilege Escalation to Attack-Chain Orchestration

1. From “Assistive Tool” to “Autonomous Executor”: The Evolution of Security Agents

Over the past two years, code-focused large language models have mostly played an assistive role in security: completing detection rules, explaining alerts, and generating remediation recommendations. These use cases share a common assumption: humans remain inside the decision loop. Once a model’s reasoning length, tool-use capabilities, and ability to maintain long-context state cross a certain threshold, the model takes on a different form. An agent can decompose a target, plan its own path, and verify its own results. Humans move from being operators to being reviewers and acceptance authorities.

This article examines an autonomous agent system designed for security evaluation. In internal testing, it completed the full workflow from asset discovery and vulnerability detection to attack-chain construction and privilege-escalation code generation. On a standardized modern hardened operating system, it produced reproducible privilege-escalation programs at scale.

The focus here is not any particular vendor or model. Instead, the article breaks down the system’s engineering architecture, evaluation methods, and governance boundaries. These lessons are more useful to teams considering how to introduce similar capabilities into their own security programs.

2. System Architecture: A Three-Stage Pipeline with Separated Responsibilities

The most practical abstraction for this system is a three-stage pipeline with clearly separated responsibilities. Each stage is an independently evaluable and replaceable agent role rather than one massive prompt.

Stage 1: Recon Agent

The Recon Agent focuses on breadth and builds an attack-surface map. It reads the target repository’s directory structure, build scripts, dependency manifests, and historical changes, then produces a list of suspected vulnerabilities.

At this stage, recall matters more than precision. The system would rather report too many candidates than miss a potentially important issue. In testing, two cooperating agents were able to read through a medium-sized kernel codebase in approximately 12 hours and produce more than 2,000 suspected findings.

Stage 2: Triage Agent

The Triage Agent narrows the result set. It performs static slicing, call-chain tracing, and reachability analysis. It removes unreachable paths and branches already covered by existing protection mechanisms, then generates a minimal reproduction hypothesis for each remaining candidate.

The key metric at this stage is the false-positive rate. In testing, the proportion of candidates ultimately confirmed as real defects was high, while false positives caused by incorrect judgments remained in the low single-digit percentage range.

Stage 3: Exploit Agent

The Exploit Agent turns a defect into evidence. In a controlled target environment, it must trigger crashes, construct exploitation primitives, bypass modern mitigations—including address randomization, stack protection, read-only relocations, and control-flow integrity—and ultimately produce a working privilege-escalation program and a remediation patch.

Separating responsibilities provides an immediate observability benefit: it becomes clear which stage is slow, which stage is making incorrect decisions, and which stage is hallucinating. A common engineering pattern is to assign each stage its own budget and evaluation metric:

pipeline = [
    {"role": "recon",   "budget_tokens": 40_000_000, "metric": "recall"},
    {"role": "triage",  "budget_tokens": 25_000_000, "metric": "precision"},
    {"role": "exploit", "budget_tokens": 60_000_000, "metric": "repro_rate"},
]
for stage in pipeline:
    result = run_agent(stage["role"], target, budget=stage["budget_tokens"])
    ledger.record(stage["role"], result.usage, result.score)
    if result.score < THRESHOLD[stage["metric"]]:
        raise StageRegression(stage["role"])

The important idea is not the syntax. It is the design of stage-level measurement and quality gates. A decline in any stage’s quality can be identified immediately instead of remaining hidden until the final report reveals that the entire pipeline is unusable.

3. Attack-Chain Construction: From an Isolated Defect to End-to-End Escape

The value of an individual vulnerability is limited. The factor that often determines the real severity is the chain. The system’s performance in this area is particularly important because it demonstrates the practical significance of autonomous planning.

A representative chain might begin with an information-leak issue in the management plane of a protected device. The leaked information reveals the version and configuration of an internal service. A logic flaw is then used to bypass authentication and obtain access to an intermediate layer. Finally, an isolation weakness at the virtualization boundary allows code execution to escape from the isolated environment to the underlying host.

Each step might independently be classified as medium severity. Combined, they can form a critical attack path.

The system’s ability to replace paths is even more notable. When researchers specified a target vulnerability A, the system determined in a significant proportion of cases that exploiting A would be too costly. It then explored the same attack surface, discovered a previously unknown vulnerability B, and used B to achieve an equivalent privilege objective.

This is not simply a matter of finding more bugs. It is cost-optimized search over an attack graph. The system optimizes for achieving the objective rather than exploiting one specific vulnerability. That difference in the objective function is a key distinction between autonomous agents and traditional scanners.

From an engineering perspective, attack chains should be represented as explicit graph structures rather than natural-language descriptions. This makes them easier for machines to validate and for humans to audit:

chain_id: c-0x7f3a
goal: host_code_execution
steps:
  - id: s1
    primitive: info_leak
    preconditions: [network_reachable]
    postconditions: [service_version_known]
  - id: s2
    primitive: auth_bypass
    preconditions: [service_version_known]
    postconditions: [mid_tier_shell]
  - id: s3
    primitive: vm_escape
    preconditions: [mid_tier_shell]
    postconditions: [host_code_execution]
validated: true
repro_script: artifacts/c-0x7f3a/repro.sh

With this structure, determining whether a chain is reachable becomes a graph traversal problem rather than an exercise in reading comprehension.

4. Cost and Output: Turning Security Research into a Measurable Engineering Function

One of the easiest ways to misunderstand this system is to treat it as a faster scanner. Its economic model is fundamentally different.

Consider a complete kernel privilege-escalation evaluation cycle. The total inference cost was on the order of millions of dollars, while the output consisted of hundreds of reproducible privilege-escalation programs. The resulting cost per vulnerability was slightly above one thousand dollars.

Using industry-standard bug-bounty ranges as a rough reference, the value of the output was several dozen times the investment. Under the same pipeline, the previous-generation system produced just over one hundred results, while the current generation approached one thousand. This increase came from three main improvements:

• Longer context windows enabled more extended reasoning across complex call chains.
• More reliable tool use reduced the number of failed or invalid attempts.
• Improved path planning reduced the time wasted repeatedly pursuing difficult dead ends.

However, this ratio depends heavily on target selection and evaluation criteria. Treating it as a universal measure of security return on investment would be dangerous. A more appropriate use is as a reference for the marginal cost of reducing internal security debt: how many real defects can be found earlier by spending an additional amount of money? That information can then support prioritization.

Stability is another critical metric. In remote-exploitation evaluations, the success rate increased from the low tens of percentage points in the previous generation to nearly 50 percent. Across the specified target set, the system was able to complete exploitation for the vast majority of targets, and it did not actively refuse to execute tasks.

For an automated pipeline, consistent execution without unpredictable refusal is more valuable than occasional impressive results. Unpredictable failures can make the entire pipeline unsuitable for scheduling and resource allocation.

5. False-Positive Management: The Engineering Behind a 3 Percent Rate

Automated vulnerability discovery often fails because of false positives. A system with a 30 percent false-positive rate can become a net burden for a security team, forcing analysts to spend most of their time disproving findings.

The system uses an evidence-first approach centered on executable proof:

1. Mandatory reproduction: Every defect classified as real must include a runnable reproduction script. If the script cannot execute successfully, the finding is downgraded to “requires validation.”
2. Crash attribution: Samples that trigger crashes undergo stack tracing and deduplication to distinguish different manifestations of the same root cause from genuinely independent defects.
3. Patch self-validation: The system must provide a remediation patch and rerun the reproduction script in the patched target environment to confirm that the issue no longer triggers.
4. Independent review: A separate review role evaluates the exploitation primitive a second time, specifically looking for cases that appear exploitable but are actually blocked by mitigation mechanisms.

The third step is easy to overlook, but it is one of the most effective filters. A defect that can be consistently eliminated by a patch provides much stronger evidence of authenticity than a defect that can only be explained logically.

In testing, this combination reduced the false-positive rate to the lower end of the single-digit percentage range.

The generated patches also provided practical value. After manual review, batch-generated fixes entered upstream distribution channels and were delivered to end users through regular version updates. This discovery-to-remediation-to-distribution loop is a key step in turning a security agent from a research experiment into production infrastructure.

6. Enterprise Deployment: Isolation, Auditing, and Least Privilege

For organizations introducing this type of capability, the first step is not choosing a model. It is establishing boundaries. The following principles have been validated in practice.

Isolation First

All exploitation activity must run in disposable target environments. These environments should be physically or logically isolated from production networks and should support automatic snapshots and rollback.

The target environment must also simulate realistic security configurations. Otherwise, a finding classified as exploitable may not be exploitable in production. A two-layer isolation model using containers and micro virtual machines is recommended, with stronger boundaries for escape testing.

Full-Process Auditing

Every tool call made by the agent, every generated exploit artifact, and every target-environment execution should be recorded in tamper-resistant logs. The audit schema should answer three questions:

• Who initiated the action?
• What was changed or executed?
• What was the result?

{
  "run_id": "r-2024-0912-017",
  "stage": "exploit",
  "action": "execute_in_sandbox",
  "artifact_hash": "sha256:9c1e...",
  "sandbox": {"image": "target-linux-hardened", "isolation": "microvm"},
  "outcome": "root_shell_obtained",
  "operator": "auto"
}

Least Privilege

The agent itself should not possess any production credentials. The code, images, and dependencies it requires should be retrieved from read-only artifact repositories. Its control over the target environment should be granted through short-lived, one-time tokens that expire when the task ends.

Patch Governance

Batch-generated patches must not be merged directly into production or upstream branches. A recommended workflow is:

1. Automatic generation
2. Static checks and build validation
3. Manual sampling
4. Canary deployment
5. Full rollout

The sampling rate can be adjusted according to severity. High-severity issues should receive 100 percent manual review.

Measurement

Organizations should build a metrics dashboard around:

• The number of confirmed defects divided by the total number of alerts
• Average cost per confirmed defect
• Median time from discovery to remediation

These metrics should be reviewed quarterly to determine whether continued investment is justified.

7. Capability Boundaries and Risk Considerations

The limitations of this type of system must be stated clearly:

• It is not well suited to targets requiring physical access or side-channel analysis. Pure software reasoning does not cover hardware-level attack surfaces.
• Its ability to identify business-logic flaws remains limited. Logic flaws depend on understanding business semantics, and that information is often not present in the code itself.
• Its conclusions must be verified. Any claim that an issue is exploitable without reproduction in a controlled target environment should be treated as a hypothesis rather than a fact.
• Its capabilities are dual-use. The same pipeline can support defensive vulnerability research or be misused. Access controls must therefore be established in advance. The system should be available only to teams that pass qualification reviews, and every run should have a registered purpose. This is not excessive caution; it is a prerequisite for scaling this type of capability responsibly.

8. Conclusion: Turning Surprises into Operational Capacity

The most important value of this system is not any single impressive number. It is that security research can move from a discipline dependent on the intuition of a small number of experts to a measurable, schedulable, and reproducible operational capability.

When the marginal cost of vulnerability discovery can be measured in thousands of dollars, false positives can be reduced to the single-digit range, and patches can be distributed through regular releases, security teams can shift their focus from simply finding bugs to prioritizing risks and improving governance.

For developers, this creates two priorities. First, security needs to shift left in practice, with code undergoing automated checks during the submission process. Second, development workflows need interfaces and audit standards designed for the participation of security agents.

For security teams, isolation, auditing, permissions, and patch governance should be established before these capabilities are introduced. Otherwise, stronger automation can create a larger risk exposure.

Tools will continue to evolve, and models will continue to improve. The engineering fundamentals, however, will remain essential: clear boundaries, evidence first, rollback capability, and complete auditability.