# When Your Security System's Rulebook Becomes the Attack


There's a particular kind of breach that leaves almost no trace. No CVE, no exploit code, no malware signature. The attacker fires nothing. They just read your documentation — and wait.


## Eight Weeks, Zero Exploits, Full Compromise


Picture an autonomous defensive system sitting at your network edge. It's doing everything right. Each decision cycle evaluates evidence correctly. It stays beneath its authority ceiling. Every action gets logged. Your auditors love it.


Now picture an adversary who spent an afternoon reading your product's governance whitepaper.


Over eight weeks, they run short bursts of low-grade probing — nothing that triggers a breach alert, nothing that looks wrong on any single day. Each burst pushes the autonomous system into a supervised fallback state, where a human must approve before it can act aggressively. The system then crawls back toward autonomy, slowly, by design — because that's what the recovery protocol says. The adversary waits for the crawl, probes again, and knocks it back down.


At the end of eight weeks, the system has drifted permanently into supervised mode. The adversary never breached the system. They just made it useless.


This scenario, outlined this week by independent security researcher Burak Oktenli in Dark Reading, is more than a thought experiment. It describes a structural flaw in how we're building autonomous security — one that explains why confidence in these tools is collapsing far faster than the hype cycle would predict.


## The Governance Paradox


Oktenli points to a striking figure: organizations willing to rely on autonomous penetration testing dropped from 29% to 9% in a single year, according to Cobalt's 2026 data. The standard read is that the technology overpromised. Oktenli's read is more precise, and more troubling.


When organizations deploy autonomous security systems, they do the responsible thing. They write rules. Authority ceilings. Recovery protocols. Audit logging. They publish these in standards documents, certification submissions, and product sheets — because governance requires transparency, procurement requires documentation, and regulators require accountability.


The moment those rules are published, they stop being only your safeguards. They become your attacker's playbook.


This isn't paranoia. It's the same dynamic that makes published cryptographic standards useful and targetable simultaneously. When you tell the world that your system recovers slowly from alert states because aggressive recovery creates its own risks — which is true, and defensible — you've also told the world exactly how to hold your system in a degraded state indefinitely.


## Recovery Asymmetry: The Cheap Side of the Equation


The specific mechanism Oktenli describes is worth naming precisely, because it's going to matter: recovery asymmetry.


By design, security systems fail fast and recover slowly. Fast failure is a feature — when something looks wrong, you want the system to step back immediately. Slow recovery is also a feature — you don't want a system charging back to full autonomy after a false alarm. Both design choices are correct in isolation.


Together, they create an attack surface that costs the adversary almost nothing to exploit. The probing is cheap. The recovery is free — your own infrastructure is doing it. And the endgame isn't a breach in the traditional sense; it's a security system that has been rendered human-dependent without anyone realizing it was targeted.


This is relevant beyond autonomous defense. The same asymmetry exists in incident response workflows, in SIEMs tuned to avoid alert fatigue, in threat detection systems calibrated to reduce false positives. Anywhere a system has published rules about when it steps back and how it returns — that's attack surface.


## What Traditional Threat Modeling Misses


Conventional threat modeling asks: what can an attacker do to my assets? It models exploits against data, systems, users.


The attack Oktenli describes targets the security system's *behavior* — specifically, its documented, certified, auditable behavior. The threat model needs to include: what happens if an adversary reads my governance documentation and optimizes against my state transitions?


This isn't a fringe concern. AI security products are increasingly subject to formal certification regimes. Large enterprises demand published behavioral specifications before procurement. Regulatory frameworks require documented autonomous decision boundaries. Every one of these legitimate governance requirements is simultaneously a detailed map of how the system can be manipulated.


The field hasn't caught up. Threat modeling for behavioral exploitation of published protocols is not yet standard practice. Most organizations can tell you their system's MTTR. Few have modeled what happens if an adversary deliberately extends it.


## HackWire Analysis


This piece deserves wider circulation than it's getting, because Oktenli is pointing at something the broader AI security conversation has almost entirely missed.


The collapse in autonomous pentesting confidence — 29% to 9% in twelve months — is being read as a hype correction. It's probably also a signal from practitioners who've noticed, intuitively if not articulately, that their published behavioral specs are liabilities. Organizations are pulling back not just because autonomous tools underperformed, but because the more they relied on them, the more attack surface they created through documentation alone.


Compare this to the supply chain attacks of 2020-2021. SolarWinds worked in part because defenders trusted the source — trusted the system behaving exactly as designed. What Oktenli is describing is the next iteration: attackers trusting your governance documentation more than you do, then weaponizing your system's designed behavior as the attack vector.


For defenders, the practical implication runs counter to everything compliance culture demands. The more you document autonomous system behavior, the more attackers can optimize against it. That's not an argument against documentation — auditors will not accept that tradeoff — but it is an argument for adversarial review of governance artifacts as a distinct security practice. Before you publish how your system recovers, someone should ask: what does an attacker do with that information?


Healthcare and critical infrastructure operators deserve particular mention here. Their autonomous systems face regulatory documentation requirements that are especially detailed, and their tolerance for degraded-autonomy states is especially low. A system forced into permanent supervised mode at a hospital doesn't just annoy analysts — it creates response delays that have real consequences.


The threat model needs to expand. Behavioral exploitation of published protocols is not theoretical. It's cheap, it's quiet, and it leaves almost nothing in the logs.


— HackWire Editorial


## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)