Main site

Engineering AI agent · Vulnerability autofix

Vulnerability-Autofix AI Agent

Test the patch as a change to a product on the market, against the advisory rather than the fixture the agent wrote, and hold it for the named security owner who ships it.

Typical delivery
4–6 weeks
Deployment
Your stack
Security owner
Change control
After launch
Agent Care

What this agent does

Drafts the fix, never waives the change control

In

  1. 01

    A finding lands, and mitigation without a code change is scored beside the patch, not after it.

  2. 02

    A patch is drafted, and SP 800-53 SI-2(d) puts flaw remediation inside configuration management.

Reason

  1. 03

    A fix ships or does not, and Art. 11(2) of Directive (EU) 2024/2853 reaches the defect either way.

  2. 04

    A patch pipeline exists, and Recital 19 reads it as proof the product never left your control.

  3. 05

    A finding lands on a federal system, and BOD 26-04 defers most of them to the next upgrade.

Decide

  1. 06

    A patch is kept separate from the feature beside it, because CRA Recital 57 asks for the fix alone.

  2. 07

    A test is derived from the advisory description, not from the patch the same run has just produced.

Out

  1. 08

    A pull request opens in a public repository, and the diff discloses the defect to whoever reads it.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

Triage, drafting, testing and the patch record belong to the agent. Deployment belongs to a named security owner, who owns the change in the fleet and answers for it once it is running there.

Example workflow

One finding, advisory to fleet

  1. 1Finding receivedScanner output, vendor advisory, catalogue entry or a researcher report
  2. 2Exposure assembledThe affected component, where it runs, what reaches it and what a mitigation would cost
  3. 3Patch draftedThe diff, the test derived from the advisory, the blast radius and confidence
  4. 4Controls appliedChange-control checks, separability rules, provenance capture and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing merges at any of them — the agent is drafting a change, and the security lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the security owner to ship.

Low confidence

Adds an application-owner read first.

Security approval

The patch is held with its advisory, its blast radius and the confidence.

Ship · Amend · Send to application-owner review

Approved — merged and rolled out

  1. 6Repository and rollout updatedOnly where write access and change policy allow it
  2. 7Outcome evaluatedAmendment rate, rollback outcomes, regressions found and corrections after deployment

Amendments

Each security-owner amendment is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Deploying a patch across the supported fleet.
    • Deciding that a finding may be deferred.
    • Bypassing change control for a security fix.
    • Judging that a patch is safe to auto-merge.

  • Automation boundary

    Agent acts unaided

    • ✓Draft the patch from the advisory and the component.
    • ✓Derive the test from the advisory, not from the patch.
    • ✓Record where each hunk came from at the moment the patch is written.
    • ✓Hold the change for the security owner who ships it to the fleet.

    Nothing reaches the fleet except by a named security owner, inside the agreed boundaries.

    • Publishing a fix while an embargo is running.
    • Deciding an unfixed flaw is acceptable to ship.
    • Setting the remediation term the company answers to.
  • Changes to rollout rules or automation thresholds.

Example output

One patch, annotated

The CRA agent in electronics submits the report on the clock; this one produces the fix, and the fix is a change to a product placed on the market. Below is one patch as the agent leaves it.

Patch output · single finding

Illustrative example
Finding
Advisory on a bundled library
Recorded as
Patch drafted, test derived from the advisory
Component
Fix only, no feature
Evidence of record
Vendor advisory, 3 August 2026
Confidence
Held undeployed
Held for
The named security owner, by name

As received

Taken from the advisory and the component inventory — the agent vouches for the change, not the fleet.

What the record holds

  • Advisory text
  • Component inventory
  • Hunk provenance

Why no deployment here

Putting a change into the fleet is an act a named security owner owns.

What the score decides

Below the configured threshold a patch picks up an application-owner read first.

Action

ShipAmendSend to application-owner review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Each finding

From the advisory that carries it

03Remediation

Where the change is tested

Test the patch against the advisory that described the defect, and against one canary host before the fleet, rather than against a fixture the same run produced.

01Approved path

The fix is the change

A green suite proved nothing once, because the fixture was written by the same process that wrote the defect — and the agent writes both.

02Human review

What was checked, and not found

In the United States no law of general application requires a private company to patch anything on any timeline. The FTC asks for reasonable steps and names no number, NYDFS asks for timely remediation and names none either, and the term you set yourself is what gets reconstructed against you later.

04

Build an evidence trail

The finding, the patch that answered it and the owner who shipped it stay together.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Scanners and advisories

    • Snyk
    • Trivy
    • Grype
    • Wiz
    • OSV
    • NVD
    • KEV
    • vendor advisories

  • Repositories and forges

    • GitHub
    • GitLab
    • Gerrit
    • Bitbucket
    • Azure DevOps Repos

  • Build and rollout

    • Jenkins
    • GitHub Actions
    • Argo CD
    • Spinnaker
    • Flux
    • feature flags

Agent

Vulnerability remediation

  • Reads the advisory
  • Drafts the patch
  • Holds for the owner

  • Ticketing and change control

    • Jira
    • ServiceNow
    • BMC Remedy
    • Change advisory board records

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six taps between the model and the fleet

Six taps along one main, the last the tightest. What gets through is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to proposing mitigations when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, remediation-rule and rollout-policy changes.Track
L4TraceabilityRecord the advisory read, the patch drafted, the hunk origins and the approval time.Record
L3Security approvalHold patches for the named security owner; the hold governs deployment, not whether the fix is correct.Gate
L2Change guardrailsTest each patch against the advisory, the separability rule and the provenance record; a failure returns it.Restrict
L1Confidence thresholdsRoute low-confidence patches to an application-owner read before the security owner sees them.Require review
Model corePatch drafted — the diff, the derived test, the blast radius and confidence
L1 – L2
Test whether a patch may stand
L3
Leaves the deployment to a named owner
L4 – L5
Keep the patch and the finding behind it
L6
Proposes mitigation instead when signals degrade

How Nestack evaluates it

Evaluate the whole remediation path — not only the patch that comes out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the change the fleet receives

  1. E1Final-output evaluationDid the patch answer the defect the advisory described?
  2. E2Step-level evaluationDid the agent read the right advisory, component and live inventory?
  3. E3Tool evaluationDid it read and write the correct repository and the correct branch?
  4. E4Confidence calibrationDo low-confidence patches actually attract more owner amendments?
  5. E5Slice evaluationHow does performance change across specific finding classes?
  6. E6Business outcomeHow many patches needed an amendment before the owner shipped?

Floor — the defect the patch was meant to close

Failure modes

Where each failure originates in the agent

Seven failure modes, each set where the advisory first shows it.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • RB-03

      Advisory read stale

      The advisory has been revised since it was read.

    Stage gathers

    The advisory, the component, the estate and the exposure

  2. 02 · Reasoning

    2 modes

    • RB-04

      Wrong defect patched

      The diff answers a defect nobody reported.

    • RB-06

      Fix bundled with a feature

      A behavioural change rides in the same patch.

    Stage proposes

    The diff, the derived test, the radius and confidence

  3. 03 · Tool / write

    2 modes

    • RB-02

      Merged without a person

      Agent completes a merge that needed an owner.

    • RB-05

      Embargo broken by the diff

      A public pull request discloses the defect.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • RB-01

      Green suite, live defect

      The test passed because the agent also wrote it.

    Stage returns

    The change the fleet receives and then runs

  5. 05 · Change / Version

    1 mode

    • RB-07

      Silent rollout drift

      A rule change widens what ships without a canary.

    Stage tracks

    Model, prompt, patch rules and rollout policy

  • Sev-1 · a patch deployed outside the boundary
  • Sev-2 · a regression reaches the fleet
  • Sev-3 · advisory degrades, patch routes back
See the complete Engineering failure-mode catalogue

Affected slices

Vendored code absorbs the amendments

An estate-level remediation figure can read clean while a couple of finding classes carry nearly all of the rework. Nestack reports the owner-amendment rate by finding class, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Findings in vendored code9.2%3.7×Review
Patches touching shared config6.5%2.6×Review
Kernel and driver components4.1%1.6×Watch
Single-service application code2.1%0.8×Normal

Bar: owner-amendment-rate lift vs. application-code baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What the fast lane costs later

A cycle ends when the patch that shipped around the controls is a standing case. That suite is what the next fix released is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Amendment rate rises in one finding class.

  2. 02

    Diagnose

    The change that went round every control the company owns, because it was a security fix, is worked back until one cause is left.

  3. 03

    Improve

    Each change ships numbered, and the findings behind it are attached.

  4. 04

    Verify

    A single red patch case is enough to hold the rollout.

  5. 05

    Learn

    The case is retained, and the remediation rules are amended in the same commit.

  6. Learn → Detect

    The return edge. The next fix released is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, patch generation, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Remediation-workflow discovery and the boundary work.Week 1
  2. 02Scanner, advisory and forge assessment.Week 1, Week 2
  3. 03Change-control and patch-separability rule mapping.Week 1, Week 2
  4. 04Finding ingestion.Week 2
  5. 05Patch drafting and advisory binding.Week 2, Week 3
  6. 06Confidence scoring and flag routing.Week 3
  7. 07Security approval workflow.Week 3, Week 4
  8. 08Repository and rollout integration.Week 5
  9. 09Patch and regression cases.Week 4, Week 5
  10. 10Guardrails and rollout controls.Week 4
  11. 11Patch-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne repository, one scannerProductionProduction repositoriesAdvancedMultiple estates / teams
Introduced at Pilot
Patching to your advisories✓✓✓
Named security approval✓✓✓
Finding-population baseline✓✓✓
Introduced at Production
Reporting by finding class—✓✓
Approval workflow in your systems—✓✓
Approved write-back—✓✓
Scanner-and-forge integration—✓✓
Introduced at Advanced
Multi-language patch rules——✓
Multi-stage security approvals——✓
Large finding volume——✓
Multi-estate remediation controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, finding volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your estate and the advisories it answers to

    Finding ingestion and component mapping

    Week 1

  2. 02Representative findings and their components

    Patch baseline, advisory binding and the provenance record

    Week 2

  3. 03Your change-control and separability policy

    Change-control and patch-separability rule mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Scanner, advisory and repository assessment, then integration setup

    Week 2

  5. 05Patches you would not want reviewed

    Regression cases and the evaluation round

    Week 4

  6. 06What no patch may bypass

    Confidence scoring, flag routing, guardrails and rollout controls

    Week 3

  7. 07A named security owner to ship patches

    Security approval workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Widths here follow what each phase actually costs, which is why the fifth week runs two together.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Remediation workflow discovery, change-control mapping and the automation boundary

W2Source integration and the patch baseline

W3Patch workflow, confidence logic and rollout controls

W4Evaluation suite, regression cases and failure-mode testing

W5Repository integration, pilot findings and targeted corrections

W6One remediation cycle run under the security owner, then Agent Care handover

Reading the band
A bar spans the weeks its own work is named in, and the fifth week is doubled by design.
At the end of W6
Once the patch record validates, Agent Care assumes the agent.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Engineering AI agent

Build a vulnerability-autofix agent around the change control your last security fix went round.

Show us one finding and the patch that closed it. If you ship into the EU after December, then one directive reaches the defect you introduce and the defect you leave unpatched. Almost nothing obliges you to fix on a schedule; a great deal obliges you not to break things.

Typical delivery
4–6 weeks
Deployment
Your estate
Security owner
Change control
After launch
Agent Care available

Nestack Agents · Vulnerability autofix

AGT-ENG-08 · Agent Care available after launch

Build a vulnerability-autofix agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your estate

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.