Block-on-deny is the simplest control to design and the hardest control to keep alive — the half-life inside a productive engineering organization is roughly two quarters.
Why Block-by-Default Matters Now
Every wave of endpoint security has produced the same fight. The control vendor ships a tool that says “no” by default. The security team rolls it out. Engineering revolts within two quarters. The tool gets reconfigured to log-only, then gets ripped out at the next contract renewal. We have been here with antivirus signature updates, with DLP, with first-generation EDR, and we are heading there again with agent governance.
The reason matters. Block-by-default is not wrong on principle — it is the cleanest enforcement model in compliance terms. The problem is that it converts every false positive into a productivity outage, and the false-positive rate on novel agent behavior is, at this point in the cycle, structurally high. A single Aider run that gets terminated mid-refactor turns into a Slack thread, then a security ticket, then a steering-committee item, then a procurement decision.
| Metric | Block-on-deny tools | Copy-on-write tools |
|---|---|---|
| Mean time to first major user complaint | Within the first month | Multiple months |
| Two-quarter retention (still in enforcing mode at +180 days) | Minority of rollouts survive | Majority remain in enforcing mode |
| Audit-committee defensibility | High initially, weak after rollback | Steady through political reviews |
| Engineering reaction (rough sample) | Strongly negative | Neutral to mildly positive |
The Historical Analogue: DLP and EDR Rollouts That Engineering Revolted Against
The cycle is consistent enough that it is almost a law. The block-on-deny tool ships, the security team is happy with the dashboard, and somewhere between week six and week ten the productivity friction becomes the only thing the CIO is hearing about.
| Era | Tool class | What was blocked | How it ended |
|---|---|---|---|
| 2010–2013 | First-gen DLP (Symantec, Forcepoint) | Email attachments, USB writes | Rolled back to monitor-only or replaced |
| 2014–2017 | App whitelisting (Bit9-style) | Unsigned binaries, dev-tool installs | Carved out for engineering populations |
| 2017–2020 | Legacy AV pivoting to EDR | False-positive process kills | Replaced by CrowdStrike, SentinelOne, Defender |
| 2021–2024 | Browser isolation, hard CASB | Direct uploads to consumer SaaS | Demoted to monitoring on most fleets |
| 2024–now | Block-on-deny prompt guardrails | Borderline prompts, paste flows | Showing the same trajectory inside 90 days |
Every one of these cycles ended with a softer, more selective enforcement model. The pattern is not about security maturity — it is about the political economy of saying “no” to engineering inside a productive company. The control either survives by getting more surgical or it gets removed.
The Two-Quarter Decay Pattern
Inside any block-on-deny rollout, the decay path is predictable enough to forecast. From our signature pipeline, we have observed the same arc on multiple agent-governance pilots in the last six months:
- Weeks 1–4: the dashboard looks great. The security team cites blocked actions in steering reviews. False-positive rate is reported but qualified. Engineering has not fully ramped on the new agent workflows yet.
- Weeks 5–10: the first revolt. A senior engineer’s Cursor session is killed mid-refactor. A finance analyst’s Claude Desktop summary task is terminated on a sensitivity-tagged file. The tickets escalate. The CIO asks the CISO if there is a softer mode.
- Weeks 11–18: the pragmatic reconfiguration. Block-mode quietly becomes log-mode for the largest user populations. The dashboard now reports “would have blocked” counts instead of actual blocks. Compliance notices the control is no longer enforcing.
- Weeks 19–26: the rip-out conversation. At contract renewal, the tool is positioned as either redundant (because the dashboard is monitor-only now) or as a friction point (because the carved-out populations cover the seats that mattered). The procurement decision goes to a different architecture.
The half-life of block-on-deny on a productive engineering fleet is roughly two quarters. Any program betting its control plane on this enforcement model is, in effect, accepting that timeline.
What Copy-on-Write Does Differently
Copy-on-write reframes the enforcement question. Instead of refusing the action, the agent’s write hits a kernel-managed shadow space. The user keeps the productive flow. The security team keeps the audit trail. The destructive blast radius is contained without an outage.
Survivability = (Productivity Preserved × Audit Quality) ÷ (False-Positive Cost × User-Visible Friction)
| Architectural choice | Block-on-deny | Copy-on-write |
|---|---|---|
| What happens to a flagged action | Action terminated | Action commits to shadow; original untouched |
| User-visible behavior | Error, workflow halt | Action appears to succeed; review queue populated |
| Audit posture | Deny logged, no artifact to review | Full action tree captured, replayable |
| Recovery from a false positive | Manual unblock, escalation chain | None needed — the original is intact |
| Political review survivability | Two quarters | Multiple years (DLP follows this pattern when set to forensic-only) |
The bet is not that block-on-deny is wrong. It is that hard blocks belong in a narrower, kernel-managed scope — the action class whose blast radius is irreversible — while the broader surface uses agent firewall policy in copy-on-write mode.
What This Architecture Is and Isn’t
| Copy-on-write is | Copy-on-write is not |
|---|---|
| A way to keep enforcement deployed past the political half-life | A weakening of the policy itself |
| The model already accepted by tracked-changes in Word, branches in Git, and snapshot DLP | A novel security primitive |
| Compatible with kernel-scope policy primitives | A substitute for hard blocks on truly irreversible actions |
| The enforcement layer that lets the rest of agent governance stay alive | A way to claim coverage you don’t have — every shadowed action still needs review |
The question is not block versus monitor. It is which class of action belongs in which mode, and the architecture has to be expressive enough to encode both.
What CISOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Audit current block-on-deny controls on agent activity for two-quarter survival probability | Honest map of what will get rolled back | 1 week |
| 2 | Classify policy decisions into reversible vs irreversible by blast radius | Policy taxonomy aligned to the architecture | 1 week |
| 3 | Pilot copy-on-write enforcement on the reversible class for the most engineering-heavy team | Working proof on a real population | 4–6 weeks |
| 4 | Reserve hard blocks for irreversible actions only (mass delete, exfil, credential write) | A control plane that survives political review | 2–4 weeks |
The Bottom Line
The pattern is consistent across two decades of endpoint security: block-on-deny rollouts that touch productive engineering workflows have a half-life of about two quarters. The right reading of that history is not that enforcement is unwinnable — it is that the architecture has to match what an organization can actually keep deployed. Copy-on-write at the kernel scope is the model that survives, because it preserves the flow while making the action reviewable. Hard blocks belong on a smaller, well-defined class of irreversible actions where the trade-off is explicit and the population accepts it. Agent security programs that ignore the political half-life are buying a control they will not own at next year’s renewal.
If your team is sizing this for the next quarter, request a working session. We will walk through your environment, audit your current block-on-deny posture, and scope a copy-on-write pilot for the reversible class of agent actions. 90 minutes.