Part IX
Long dwell
Everything in this season so far has been about mechanism. This episode is about time, and it is the one that changes how you read incident data.
Ask a simple operational question: over what interval can your organization still link a cause to its effect?
Not "how long do we keep logs." That is a compliance answer. The real question is how long you retain enough correlatable state — logs that share identifiers, systems that still exist in the form they existed in, people who remember why a decision was made, build artifacts you could still reproduce. In most organizations that interval is somewhere between eighteen and thirty-six months, and it is bounded by three unglamorous processes: log rotation, platform migration, and staff turnover.
Call it the institutional detection horizon. It is not a security control and nobody owns it. It is an emergent property of ordinary operational hygiene.
The consequence
Your own housekeeping completes the attack
Here is the uncomfortable arithmetic. If the interval between an action and its consequence exceeds that horizon, then by the time the consequence is visible, the forensic state linking it to the cause is gone.
Not deleted by an adversary. Deleted by you, on schedule, for good reasons — the retention policy, the migration to a new platform, the engineer who left and took the context with them.
This is not a hypothetical property of exotic operations. It is the reason that supply-chain compromises get discovered by accident rather than by investigation, and it is the reason that when they are discovered, the question "how long has this been here" so often has no answer. The defender's own operational discipline is what makes the causal chain unrecoverable.
Two things follow, and both are actionable.
Detection strategies premised on eventual correlation have an expiry date that nobody wrote down. "We would catch it in retrospective analysis" is a claim with a time bound, and the bound is your horizon, and you probably do not know what it is.
Your horizon is measurable. Pick a real past incident. Try to reconstruct the causal chain today. Note where it breaks. That is your horizon, empirically, and the exercise takes an afternoon and is more informative than any tabletop I have run.
The attention economy
Novelty attracts scrutiny, so novelty is not where to look
Now the second resource that behaves like time: reviewer attention.
Review capacity is finite and it is not allocated uniformly. It concentrates where the artifact is novel, where the change is architecturally significant, where the reviewer's own expertise makes the material interesting. Boilerplate, build configuration, test fixtures, generated files, dependency manifests — these receive a fraction of the attention per line that the interesting code receives.
That allocation is rational. It is also a map.
The probability of rejection rises with novelty, so the optimal placement for something you do not want examined is the minimum-novelty region of the artifact. Build systems. Test fixtures. Configuration. The parts everyone scrolls past because they are boring, and they are boring because they are supposed to be.
The compression-library compromise that the industry spent 2024 absorbing is the canonical instance, and I want to be careful not to flatten it: that incident involved a multi-year social-engineering campaign against a burned-out maintainer and a payload placed in build machinery. It was not one clever trick. But the placement decision within it — the payload living in test data and build scripts rather than in reviewed source — is exactly this principle, and it worked for exactly this reason.
The defensive read is not "review everything equally," which is not achievable and would be a bad use of the capacity you have. It is narrower:
Review attention should be allocated by blast radius, not by interestingness. A three-line change to a build script that runs with elevated privileges deserves more scrutiny than a three-hundred-line refactor of business logic that runs in a sandbox. Almost no organization allocates this way, because the interesting change is the one people want to review.
The queue
What happens when generation outruns validation
There is a related structural problem that will get worse before it gets better, and it has a simple shape.
Any review process is a queue. Work arrives at some rate; capacity clears it at some rate. When the arrival rate exceeds the clearing rate, waiting time does not degrade gracefully — it diverges. That is not a model-specific result, it is general, and the qualitative consequence holds regardless of the arrival distribution.
Automated generation raises the arrival rate. It does not raise the clearing rate, because clearing requires exactly the kind of judgement that episode two identified as the non-accelerating half of defensive work.
Two effects, and the second one is the security-relevant one:
Volume
Maintainers and triage teams receive more submissions than they can evaluate. Bug bounty triage and open-source maintainer inboxes are already living this.
Service time
A submission that is nearly correct and highly plausible consumes far more reviewer time than one that is obviously wrong. The obviously wrong one is closed in a minute. The plausible one requires the reviewer to actually work the problem. As the fraction of plausible-but-wrong submissions rises, effective capacity falls even at constant volume.
So the pressure on review capacity is not just "more stuff." It is more stuff that is individually more expensive to dismiss. Any triage design that assumes a fixed cost per item is going to be surprised.
The leverage problem
The insider threat that volume-based detection cannot see
Last one, and it is the one I think is most under-appreciated in agentic deployments.
Insider-threat detection is built around volume. Bulk downloads. Mass queries. Off-hours access to unusual systems. Anomalous data movement. That model works because historically an insider's blast radius scaled with the volume of their own activity.
Concentrate directive authority over autonomous capacity and that relationship breaks. A single, fully credentialed, entirely non-anomalous instruction can redirect thousands of agent-hours. One command. Correct credentials. Normal working hours. Nothing to flag, because the volume signature of "direct a large fleet to do something" is indistinguishable from the volume signature of "direct a large fleet to do the normal thing."
The blast radius now scales with directed compute, and nothing in the detection stack measures directed compute.
The control that fits is structural rather than behavioural: multi-party authorization above a leverage threshold. Not for every instruction — for instructions whose scope exceeds some amount of directed capacity. It is the same reasoning that puts two people on a production database migration, applied to a resource nobody has yet learned to think of as a resource.
Monday
Four measurements, no new tooling
Take a real incident from eighteen months ago and try to reconstruct it now. Where the chain breaks is your number. Write it down and put it next to every detection strategy that assumes retrospective correlation.
Specifically: identify every file in your repositories that executes with elevated privilege during build or deploy. Those get mandatory senior review regardless of diff size. Most organizations have fewer than fifty such files and no policy distinguishing them.
If the average time-to-close is rising while volume is flat, your capacity is being consumed by plausible-but-wrong work and you will hit the divergence point without seeing it coming.
How much autonomous capacity can one credentialed instruction direct before it needs a second approver? You may not like the number you are currently running at, which is usually "unbounded."
Next episode takes the time dimension to its uncomfortable conclusion, in the one domain where the accumulated quantity we depend on has never been named as a quantity at all.
