Machine-Speed Security Needs Context, Validation and Governed AI Actions
Security teams face a widening gap between the speed of vulnerability discovery and the pace of repair. The figures presented here put the average enterprise patching window at 32 to 43 days, while the mean time to exploit is 10 hours. AI can help close that gap, but faster detection alone won't protect production systems. The harder engineering problem is getting an automated system to judge a finding in its actual environment, make a safe change and show why that change is justified.
That was the central argument in a discussion at TechCrunch Disrupt: security at machine speed requires AI to accelerate the repair as well as the search. The proposal depends on a controlled system around the models, with clear permissions, application and infrastructure context, and repeatable validation.
Why severity queues miss chained attacks
Conventional security workflows often sort findings by individual severity and route them through manual triage. That can leave long queues of lower-rated issues awaiting attention. An attacker, however, can combine weaknesses that look modest in isolation into a path with serious consequences.
Consider the example described in the discussion: a cross-site scripting flaw, a session cookie hijack and a database leak are each recorded as medium-severity findings. Connected into an attack chain, the script provides a route into a browser, the stolen cookie allows the attacker to act as an authenticated user, and that access can lead to production data with full read privileges. The risk emerges from the relationship between findings and the systems they touch.
That changes what effective triage needs to do. A useful system must map the path between a weakness and sensitive resources, account for controls that could interrupt the path, and assess business impact. A queue based only on the standalone severity labels may not capture that picture.
Finding bugs is ahead of fixing them
Tests run on CyberGym reportedly reached 95 percent precision when identifying complex bugs that depend on a sequence of events. That result suggests models can be effective at uncovering issues whose causes span multiple steps. But the same discussion describes a much less reliable remediation stage: more than 98 percent of the time, frontier models refused remediation prompts, with built-in safeguards classifying 76–99 percent of direct prompts containing vulnerability code as false positives.
When models did attempt a change, the reported results still raised concerns. Fifty-five percent of patches fixed the primary issue while missing a secondary point, and 40 percent broke production code. Those figures point to a gap between producing a plausible patch and delivering a safe, complete repair. A prompt by itself doesn't provide the controls or evidence needed to close that gap.
The practical implication is that detection and remediation need separate checks. A finding should be validated in the context of the application, and a proposed fix should be tested against the exploit and the surrounding code before it is treated as complete.
A workflow built around evidence
The proposed system combines several models with a five-stage process: reconnaissance, threat modeling, vulnerability hunting, validation and remediation. Each stage contributes a defined result, while a shared state and durable records let agents hand off evidence and decisions without relying on a conversational history as the system of record.
The execution environment matters as much as the model. The design calls for a zero-egress microVM with no internet access and no IAM role, started fresh for each invocation. Static analysis forms the first validation layer; dynamic security testing runs inside the sandbox as the second. A finding should not be closed until the system can demonstrate that the relevant trigger works.
Context is another core input. The system is meant to combine details about infrastructure, applications and business priorities, so it can distinguish an exposed path to a sensitive resource from a flaw with limited reach. The stated CyberGym results show generic model accuracy at around 65 percent, rising to 90 percent with infrastructure context and 95 percent after adding business context. These results make the case that environment knowledge can materially change the quality of automated judgments.
Three roles, each with a bounded job
The workflow assigns three kinds of work to separate agents. A prioritization agent acts like a threat intelligence analyst: it searches the context graph, measures proximity to critical assets, classifies findings and weighs business impact. Its job is to establish which issues deserve attention and why.
A validation agent takes the perspective of a red team operator. It traces attack paths, estimates the blast radius and checks for compensating controls. Its output is one of three states: exploitable, inconclusive or not exploitable. That format makes uncertainty visible instead of forcing every finding into a yes-or-no answer.
The remediation agent works from a proven exploit and takes the role of a security engineer. It aims to correct the underlying pattern across the relevant code, rather than changing a single line while leaving the same weakness elsewhere. The deliverable includes a sandbox test suite alongside a pull request, so reviewers can inspect both the proposed change and evidence of its behavior.
Context and policy make autonomy governable
Infrastructure context is intended to rest on five capabilities: formally verifying network paths for reachability; using automated reasoning to test whether IAM policies grant unintended access; blocking public cloud access by default; keeping a real-time inventory of resources and configuration changes; and mathematically proving security correctness at scale. Together, these capabilities give agents a clearer view of what is reachable and what a change could affect.
Trust also depends on how each action is authorized. The described four-gate chain begins with IAM scoping and Cedar policies. IAM keeps an agent within its assigned boundaries, while Cedar determines which tools it may use on which resources and under which conditions. Those decisions are deterministic policy checks rather than judgments delegated to another model.
Next come input checks, including schema validation and account binding. A fail-closed audit records each action before execution; if that audit fails, the action doesn't proceed. Finally, a credential broker issues access scoped to one action and one resource, with a 15-minute time to live.
Containment continues inside the sandbox: there are no internet connections or service endpoints, and task memory is destroyed when the work ends. The system also assigns different autonomy levels to different actions. The examples allow 80 percent autonomy for removing unused permissions, 60 percent for tightening security groups and 20 percent for modifying IAM roles. Deleting resources remains a human-only action.
Decisions are expected to include evidence and a confidence score, with model judgment kept distinct from deterministic calculations. Full W3C tracing and 90-day retention provide an audit trail. Taken together, these controls frame autonomy as a set of scoped actions that can be inspected, rather than an open-ended model call.
The engineering test is the repair
Wrapping a model in an interface can produce a convincing demonstration, but the operational test is whether the system consistently understands a vulnerability in its environment and supports a verified response. That calls for richer context, isolated execution, repeatable tests, fine-grained permissions and records that explain what happened.
Security scanners already identify many events. The remaining work is connecting those findings to real attack paths, proving which ones matter, and delivering repairs that hold up in production. Machine-speed security will depend on whether organizations can make that full loop faster while keeping every action bounded and its evidence available for review.
