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.
A finding lands, and mitigation without a code change is scored beside the patch, not after it.
02
A patch is drafted, and SP 800-53 SI-2(d) puts flaw remediation inside configuration management.
Reason
03
A fix ships or does not, and Art. 11(2) of Directive (EU) 2024/2853 reaches the defect either way.
04
A patch pipeline exists, and Recital 19 reads it as proof the product never left your control.
05
A finding lands on a federal system, and BOD 26-04 defers most of them to the next upgrade.
Decide
06
A patch is kept separate from the feature beside it, because CRA Recital 57 asks for the fix alone.
07
A test is derived from the advisory description, not from the patch the same run has just produced.
Out
08
A pull request opens in a public repository, and the diff discloses the defect to whoever reads it.
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
AgentHuman
1Finding receivedScanner output, vendor advisory, catalogue entry or a researcher report
2Exposure assembledThe affected component, where it runs, what reaches it and what a mitigation would cost
3Patch draftedThe diff, the test derived from the advisory, the blast radius and confidence
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▼
6Repository and rollout updatedOnly where write access and change policy allow it
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 required8 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 boundaryAgent 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 findingIllustrative example
Finding
Recorded as
Component
Evidence of record
Confidence
Held for
Advisory on a bundled library
Patch drafted, test derived from the advisory
Fix only, no feature
Vendor advisory, 3 August 2026
Held undeployed
The named security owner, by name
As receivedTaken from the advisory and the component inventory — the agent vouches for the change, not the fleet.
What the record holdsAdvisory textComponent inventoryHunk provenance
Why no deployment herePutting a change into the fleet is an act a named security owner owns.
ActionShipAmendSend to application-owner review
What the score decidesBelow the configured threshold a patch picks up an application-owner read first.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Each findingFrom 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.
04Build 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.
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 aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Findings in vendored code
9.2%
3.7×
Review
Patches touching shared config
6.5%
2.6×
Review
Kernel and driver components
4.1%
1.6×
Watch
Single-service application code
2.1%
0.8×
Normal
Bar: owner-amendment-rate lift vs. application-code baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises in one finding class.
02Diagnose
The change that went round every control the company owns, because it was a security fix, is worked back until one cause is left.
03Improve
Each change ships numbered, and the findings behind it are attached.
04Verify
A single red patch case is enough to hold the rollout.
05Learn
The case is retained, and the remediation rules are amended in the same commit.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Remediation-workflow discovery and the boundary work.
02Scanner, advisory and forge assessment.
03Change-control and patch-separability rule mapping.
04Finding ingestion.
05Patch drafting and advisory binding.
06Confidence scoring and flag routing.
07Security approval workflow.
08Repository and rollout integration.
09Patch and regression cases.
10Guardrails and rollout controls.
11Patch-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 priceConfirmed after discovery based on integrations, workflow complexity, finding volume, approval controls and deployment requirements.
Separate from buildBuild 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.
You bringWe build with it
01Your estate and the advisories it answers to→Finding ingestion and component mappingWeek 1
02Representative findings and their components→Patch baseline, advisory binding and the provenance recordWeek 2
03Your change-control and separability policy→Change-control and patch-separability rule mappingWeek 1
04Access to relevant APIs, feeds or exports→Scanner, advisory and repository assessment, then integration setupWeek 2
05Patches you would not want reviewed→Regression cases and the evaluation roundWeek 4
06What no patch may bypass→Confidence scoring, flag routing, guardrails and rollout controlsWeek 3
07A named security owner to ship patches→Security approval workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Remediation workflow discovery, change-control mapping and the automation boundaryW2Source integration and the patch baselineW3Patch workflow, confidence logic and rollout controlsW4Evaluation suite, regression cases and failure-mode testingW5Repository integration, pilot findings and targeted correctionsW6One remediation cycle run under the security owner, then Agent Care handover
Reading the bandA bar spans the weeks its own work is named in, and the fifth week is doubled by design.
At the end of W6Once the patch record validates, Agent Care assumes the agent.
DurationSix-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.
