Why Manual Remediation Cannot Survive the Mythos Era
Container security protects applications, images, registries, hosts, clusters, secrets, networks, and running workloads. See how teams can reduce container risk across the full development and deployment lifecycle.
Why Manual Remediation Cannot Survive the Mythos Era
A newly disclosed vulnerability usually enters an enterprise through a familiar sequence. A scanner finds it. An analyst reviews the result. A ticket is created. An owner is identified. The patch is tested, approved, scheduled, deployed, and checked.
Each step is reasonable. Together, they can take weeks.
That delay matters more in 2026 because artificial intelligence systems can search code, compare software changes, test vulnerable paths, and produce working exploit logic with far less human effort. The Mythos era is useful shorthand for that shift. It does not mean every attacker has the same capability. It describes a period when vulnerability discovery and exploit development can run at machine speed while enterprise remediation still moves through human queues.
43 days to finish patching. 31 minutes to produce a proof of concept.
Verizon reported that the median time to fully patch a vulnerability reached 43 days in 2025. Axios reported that Claude Mythos produced a Windows kernel proof of concept in 31 minutes during testing. Verizon also found that vulnerability exploitation accounted for 31 percent of breaches and became the leading initial entry point in its 2026 breach study.
Manual remediation was not built for that gap.
The workflow was built for a slower threat cycle
Traditional vulnerability management grew around scheduled scans, severity scores, tickets, maintenance windows, and periodic reports. It made sense when disclosures arrived more slowly and exploit work demanded specialist time.
Human review added control. Analysts removed false positives, owners tested compatibility, and change boards reduced outage risk. Those controls still matter, but the workflow is too slow.
A finding can pass through security, service management, infrastructure, application, and change teams. Context fades along the way. Reachability, exploitation, asset value, and compensating controls may become a score and a due date.
Every queue gives a finding another place to stall.
Mythos changes the operating math
Anthropic’s public research on Claude Mythos showed that an AI system could find and exploit previously unknown flaws across major operating systems and browsers. On one Firefox benchmark, the model produced 181 working exploits. In separate Windows kernel testing reported by Axios, it created eight distinct exploits, with the slowest completed in 5.7 hours.
Project Glasswing shows the volume problem. Anthropic scanned more than 1,000 open-source projects and generated 23,019 candidate findings. Human reviewers confirmed 1,094 high or severe flaws, while reporting, patch design, coordination, and deployment became the limiting steps.
Public vulnerability intake is rising too. FIRST projected 59,427 CVE records for 2026, then revised expectations toward 66,000 as machine-led discovery increased. SecurityWeek reported that NIST CVE submissions rose 263 percent from 2020 through 2025.
Many findings will be unreachable, duplicated, low impact, or blocked by existing controls. But each one creates a triage cost when humans must collect context, choose an owner, open a ticket, and track it to closure.
Discovery can scale through computation. Remediation still scales through calendars and headcount.
Human queues create an exposure gap
Triage consumes the response window
Severity alone does not tell a team what to fix first. Analysts need exploit evidence, internet reachability, asset function, privilege requirements, data sensitivity, and the state of existing controls.
Manual context gathering takes time. Backlogs can push teams toward broad deadlines that send effort toward low-risk assets while an exploitable path remains open elsewhere.
A better decision model ranks the exposure, not just the CVE.
Tickets split context from action
A ticket often becomes the main record after triage, but it does not maintain a live exposure model.
Ownership changes, servers become internet-facing, exploitation begins, and controls fail. A ticket may reflect none of it.
Security may know the affected package but not the business service. The application team may know the service but not the attack path.
Patch calendars move slower than attackers
Testing and maintenance windows protect availability, but a fixed calendar can turn an urgent fix into a planned delay.
Verizon found that only 26 percent of vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog were fully remediated in 2025. The median full-resolution time rose from 32 days to 43 days.
An AI-assisted attacker does not need to respect that schedule. A patch or advisory can reveal where a flaw sits, allowing automated analysis to compare versions and test exploit paths.
Manual checks create false closure
A closed ticket is an administrative event. It is not proof that exposure has ended.
A patch can fail on part of the fleet. A service may restart with an old image. A vulnerable package may remain in a container. Stolen credentials or planted web shells may survive after the update.
Verification needs machine evidence from the affected asset, followed by another assessment of reachability and attack paths.
Recent incidents show where the process fails
SmarterTools disclosed in 2026 that a ransomware intrusion began through one virtual machine that had not received a software update. An employee had created it outside the normal inventory process. The overlooked machine gave attackers a route into the office network and a quality-assurance environment, where 12 Windows servers were compromised.
The SharePoint ToolShell campaign in July 2025 showed how narrow the response window can become. Exploitation started before all affected versions had emergency fixes. Attackers installed web shells and stole cryptographic material, so teams had to patch, investigate, remove persistence, and rotate exposed secrets. Applying the update alone could not reverse an earlier compromise.
CitrixBleed 2 produced a similar race. SecurityWeek reported that at least 100 organizations were hacked after a fix became available, while thousands of systems remained exposed. CISA later gave federal agencies one day to apply the update.
Inventory gaps, ticket delay, fixed maintenance cycles, and weak verification give attackers time that defenders no longer have.
Automation must close the loop
The answer is not unattended patching across every production system. It is a remediation loop where machines handle repeatable work and people control decisions with material business impact.
An AI-assisted process can gather asset and exploit context, group duplicate findings, identify the likely owner, recommend an action, prepare a change, run tests, monitor deployment, and verify the result. Policy decides which actions proceed automatically and which require approval.
Low-risk endpoint updates, expired account removal, known configuration fixes, and reversible changes may fit an automated lane. Changes to revenue systems, identity infrastructure, operational technology, and safety-sensitive environments may require staged testing and named approval.
Research shows what may become practical. PATCHAGENT repaired more than 90 percent of 178 real-world vulnerabilities in a USENIX Security 2025 evaluation. VeriPort, described in a 2026 preprint, resolved 95.3 percent of 128 backport tasks and produced more than 5,000 verified patches across 169 high or severe CVEs.
The results came from controlled evaluations, not universal production deployments. They show why patch creation and verification belong in one workflow.
Commercial products are moving in a similar direction. Microsoft announced Security Copilot agents for work such as alert prioritization, phishing triage, and vulnerability monitoring. SecPod’s CVEM material frames discovery, prioritization, remediation, validation, and monitoring as one operating flow rather than separate scanner and ticket stages.
Full autonomy creates its own risk
Automation can spread a bad decision faster than a person can.
A faulty patch can interrupt a business service. A model can choose the wrong package, miss a dependency, or act on incomplete asset data. Broad administrative access can turn an agent error into a large outage. Regulated organizations may need approval records, separation of duties, and evidence that a change followed policy.
Safe automation needs boundaries. Each action should have an approved scope, a confidence threshold, a test plan, a rollback path, and an audit record. Agents should receive the minimum permissions needed for the task. High-impact changes should stop for human approval.
Human oversight should sit at judgment points rather than every mechanical step.
What security teams should change now
• Measure the full time from detection to verified repair, not ticket opening to ticket closure.
• Maintain a current asset record with ownership, business function, exposure status, and software data.
• Rank findings using exploitation, reachability, business impact, and control status.
• Create separate response lanes for routine fixes, urgent exploited flaws, and high-impact production changes.
• Automate evidence collection, owner assignment, testing, deployment checks, and rescanning.
• Require rollback plans and human approval for changes that can interrupt major services.
• Track failed deployments, reopened findings, unowned assets, and recurring vulnerabilities.
SecPod’s writing on vulnerability backlogs and remediation mandates makes a useful distinction. Finding more flaws does not reduce exposure. Programs should be judged by verified risk removed, not tickets created.
The operating model must change before the queue breaks
Manual remediation cannot match machine-scale discovery through greater effort alone. More analysts may help, but they do not remove the delays built into triage, routing, scheduling, deployment, and verification.
The workable model is neither fully manual nor fully autonomous. Machines should collect context, prepare changes, execute approved low-risk actions, and confirm results. People should set policy, handle exceptions, approve high-impact work, and accept business risk.
The Mythos era changes the cost and speed of exploit development. Security teams now need to change the cost and speed of remediation.




