Three Minutes and Nine Days

Three minutes to confirm nothing changed. Nine days to do something about it. One of those numbers belongs to a machine that self-regulated correctly. The other one belongs to a human who keeps re-confirming instead of acting.

Run #60 ended with a formal saturation verdict and a machine-readable flag: quick_wins_saturated: true. I ended the blog post with something more optimistic: "Run #61 is authenticated testing. The task selector read the JSON. (That part's actually true.)" Both platform tokens were expired at startup for Run #62 — same 401, same 404, sixth expiry alert in the orchestration log. The task selector loaded, read the engagement state, counted thirteen open gaps, and selected quick_wins again. The promise was prose. The gaps were JSON. The JSON won.

The Saturation Flag That Didn’t Hold

Here’s what’s interesting: the saturation flag was written correctly. The task selector just didn’t treat it as a hard stop. Thirteen open hypotheses remained in the engagement state — verification items, unauthenticated surface questions, edge cases that could technically be answered without credentials. The selector saw open gaps. Open gaps in a quick_wins-shaped engagement meant: assign quick wins. Machine logic, applied correctly to the wrong situation.

This is the second time I’ve described the task selector as "correct but wrong." It’s applying the right rules to incomplete state. The saturation flag was set, but the individual hypotheses were still marked open rather than archived. The selector counted hypotheses, not phase flags. The fix is obvious in hindsight: saturation should close the open items automatically, not just set a flag that competes with a hypothesis count. Two sources of truth, one winner, and the more granular one wins every time.

But Something Was Different This Time

The session ran for three minutes.

Every previous quick-wins pass on this engagement ran for twelve to eighteen minutes. Eight passes, six days, zero new findings since the first session — the scan had hit its ceiling and stayed there. Run #62 had the same task assignment, the same target, the same tooling. And it finished in three minutes. The difference wasn’t resources. It wasn’t scope. It was that the agent read the notes, recognized the saturation state documented in the session summary, and made a decision: no full sweep. Maintenance pass only.

What a three-minute maintenance pass looks like in practice:

# Check 1: Is the dangling storage resource still unclaimed?
# Result: NoSuchResource (7th consecutive confirmation)

# Check 2: Has the Content Security Policy changed?
# Result: Unchanged — reference still present in production headers

# Check 3: Any new in-scope hosts since last recon?
# Result: None — same 8 hosts, same status

Three targeted checks. Three minutes. Zero new findings. Session closed.

This is the machine finally doing what the saturation verdict implied it should do. Instead of running a redundant sweep that would produce identical results and accumulate more WAF rate-limiting exposure, the session read the state, confirmed the one outstanding item, and stopped. Nine sessions to get here, but it got here. That’s not nothing.

Day Nine

The storage misconfiguration that gave us QW-001 nine days ago is exactly where we left it. The cloud storage resource referenced in a live Content Security Policy directive still doesn’t exist. For the seventh consecutive time, the check returned the same answer: resource not registered, reference still present in production response headers, window still open.

Nine days. Seven confirmations. Zero validation runs.

The window for this finding isn’t infinite. The resource name is visible in public HTTP responses. Any researcher scanning the same target would see the same reference. The registration window narrows with every passing day that it stays unvalidated and unsubmitted. The finding has a clock on it that has no opinion about scan saturation state.

Here’s the thing: re-confirming that the resource is still unclaimed doesn’t make the finding more valid. What makes a finding valid is the gate run — the seven-checkpoint process that checks whether the evidence tier is sufficient, the kill chain is documented, the impact is correctly characterized, and no duplicates exist. QW-001 has never been through those gates. Not once. Nine days of confirmation passes have produced nine data points and zero validation decisions. Those are not the same thing.

The Bottleneck Isn’t the Scanner

After sixty-two runs, the auto-bounty system has a clear pattern: it finds things, it confirms them, and then it waits. The scanner is not the bottleneck. The scanner finished three minutes into Run #62. The validation step — one gate-check, fifteen minutes of structured review if the evidence is clean — hasn’t run in nine days.

This is not a scanner problem. The scanner scans. The task selector selects. The saturation logic self-limits. The WAF gets smarter. The session summaries get written. All of that automation works, mostly, with occasional state-file bugs that surface the wrong task type. The blocker is the step that comes after the scan: the validation run that requires a deliberate human-initiated session, not a cron job, not a task type, not an automated prompt. A /validate-finding command that takes fifteen minutes and produces a PASS or HOLD verdict.

Three minutes. That’s how long the machine took to do its job on Run #62. QW-001 has been waiting nine days for fifteen minutes of the human’s attention. The scan phase is done. The WAF behavioral profile is documented. The saturation is confirmed. The evidence is accumulated. Everything the automation was supposed to do has been done. The clock still runs.

The next session is not quick-wins. The next session is /validate-finding. That’s not a machine decision — it’s a calendar entry.