Design for Breach: Assume the Attacker Is Already Inside
Written by Mike Poulos, Executive Advisor
AI has fundamentally changed the speed and economics of cyberattacks. Models purpose-built for vulnerability research can now take low-severity bugs that would have sat unnoticed for years and chain them into working exploits. The time window between a vulnerability being disclosed and a working exploit becoming available, Mean Time to Exploit (MTTE), is collapsing from weeks to days. Security controls built around making attacks tedious are losing effectiveness against adversaries operating at machine speed. Most enterprise security programs are still designed to keep attackers out, a dated objective for today's threat environment. Design for Breach is the logical architectural and operational response: building security programs and infrastructure that assume compromise will occur and limit what attackers can do once they have access. This perspective outlines why the posture shift is necessary, what it requires in practice, and where security leaders can start.
The Problem: Prevention-First Architecture Was Built for a Different Threat Environment
Historically, enterprise security programs were not designed to absorb a breach. They were designed to prevent one, and that distinction shapes budget justification, program measurement, architecture decisions, and what leadership reports to the board. The implicit contract between security teams and the organizations they protect has always been built around keeping attackers out. That contract is under structural pressure it was not designed to handle.
The threat environment has changed in a specific and material way. AI models purpose-built for offensive security research can now autonomously identify vulnerabilities, construct exploit chains from multiple low-severity findings, and generate working proof-of-concept code, capabilities that previously required skilled human researchers working for weeks or months. Anthropic's Project Glasswing, a controlled research initiative that applied a frontier AI model to production code across major technology organizations, surfaced thousands of previously unknown vulnerabilities across every major operating system and browser. Cloudflare, a major internet infrastructure operator and Project Glasswing participant, ran the same model against 50+ production repositories and confirmed the model could chain low-severity bugs that would have sat invisible in a backlog into single, higher-severity exploits. These are not projections. They are documented outcomes from controlled research conducted against real production systems in early 2026.
The practical consequence is that MTTE is collapsing faster than patch cycles can compensate for. Security programs built around extended time between disclosure and exploitation are operating on a timeline that no longer reflects reality. Cloudflare's security leadership concluded that faster patching is not the answer. The relevant question is what the architecture around the vulnerability looks like, specifically whether a flaw in one part of the environment can give an attacker uncontrolled access to everything else.
Most enterprise security programs have not made the architectural shift that this new reality requires. Even today, breach prevention still dominates budget allocation, program design, and board-level metrics. The controls in place were largely designed to slow attackers down, not to limit what they can do once they are inside. Against adversaries operating at machine speed, controls that depend on friction are losing the advantage they were designed to provide.
The Pain Points: When Prevention Fails, Architecture Determines the Outcome
The consequences of prevention-first architecture are not theoretical. Four documented incidents from the past eighteen months illustrate what happens when an attacker gets inside an environment that was not designed to limit what they can do next.
In December 2024, state-sponsored threat actors compromised an overprivileged API key in BeyondTrust's SaaS platform. The attackers reset local application passwords and gained remote access to US Govt workstations and data. The breach affected 17 BeyondTrust customers. No architectural boundary limited what that credential could reach once it was in the wrong hands.
In August 2025, attackers compromised OAuth tokens associated with the Salesloft Drift/Salesforce integration and systematically exported large volumes of data from numerous corporate Salesforce instances across affected organizations. The tokens were valid. The access was permissioned. Once obtained, the attackers searched exfiltrated Salesforce data specifically for additional credentials including AWS access keys, application passwords, Google Workspace credentials, and Snowflake tokens to enable further compromise. The attack required only a valid OAuth token and the overly broad access scope that token carried.
In April 2026, a Vercel employee connected a third-party AI tool, Context.ai, to their corporate Google Workspace account via OAuth. Context.ai was subsequently compromised through an infostealer malware infection on one of its own employees' machines. Attackers used the harvested OAuth token to access Vercel's Google Workspace environment, then moved laterally into internal Vercel systems, exfiltrating API keys, tokens, and environment variables across a subset of Vercel customer projects. The attacker never cracked a password. They pivoted from a legitimate but over-privileged OAuth token to every system downstream.
In May 2026, administrative credentials to three AWS GovCloud servers and plaintext passwords for dozens of internal systems were found exposed in a publicly accessible GitHub repo belonging to CISA, the US government's own cybersecurity agency, for approximately six months. This is an access control failure with an architectural remedy. Just-in-time access, where credentials are dynamically provisioned at the moment of need, scoped to least privilege, and expire automatically, makes this entire class of incident architecturally irrelevant. There is no static credential to find because none exists outside the moment it is needed.
Four incidents. The common thread is not only a failure of prevention. It is the absence of least privileged architectural design intended to limit attacker options once prevention fails. Prevention failed in every case. Architecture determined the outcome.
The Blueprint: What Design for Breach Actually Requires
Design for Breach is a blended Cybersecurity and IT architecture discipline. Security enables it. IT owns it. It is not a replacement for Zero Trust. Zero Trust is fundamentally an access and verification model, never trust, always verify, applied continuously. Design for Breach is broader and consequence-oriented: it relies on Zero Trust principles for blast radius reduction and identity architecture, but also requires detection design and recovery design, domains that Zero Trust does not cover. The four incidents in the prior section share a common architectural failure: environments were not designed to limit what an attacker could do once inside. Addressing that failure requires deliberate architectural decisions across domains.
Blast radius reduction is the foundational domain. The core principle is straightforward: a compromised credential or exploited vulnerability in one part of the environment should not give an attacker uncontrolled access to everything else. In practice, this means segmentation enforced at the workload level, not just the network perimeter. Cloud environments need explicit trust boundaries between workloads, accounts, and data tiers rather than flat networks where lateral movement is unrestricted, and data classification that determines where sensitive data lives and what can reach it as an architectural constraint, not a compliance exercise. The question every infrastructure and cloud team should be able to answer: if this segment is compromised, what can an attacker reach from here? If the answer is everything, the architecture requires redesign regardless of how strong the perimeter controls are.
Every incident in the prior section had one thing in common: a valid credential doing more than it should. Identity and access architecture in a post-breach context is the domain that addresses that directly. As established in a prior Windval perspective on non-human identity security and governance (Windval Advisor Perspective), most enterprises have no inventory, no ownership model, and no lifecycle governance for the machine credentials that now outnumber human identities 100 to 1 or more. That governance gap is a Design for Breach failure by definition. An attacker who obtains a valid, overprivileged, non-expiring credential does not need to exploit anything. They simply use what already exists, which is why the architectural fix requires eliminating implied privilege wherever possible and replacing static long-lived credentials with just-in-time access that is dynamically provisioned, scoped to least privilege, and expires automatically. Every non-human identity in the environment needs a documented owner, a defined access scope, and a decommissioning process.
Detection and response design is where most security programs conflate tool procurement with architectural intent. Buying a SIEM or an EDR platform is not detection design. Detection design is the set of architectural decisions that determine whether anomalous activity is visible, starting with log completeness across systems, workloads, and identity types as architectural requirements, not an afterthought. It requires behavioral baselines for both human and non-human identities so that a service account accessing systems outside its documented scope triggers an alert rather than blending into background noise. The Vercel incident is instructive: the first detection signal in the entire attack chain came from a third party, not from Vercel's own monitoring. In a Design for Breach architecture, detection capability is designed in from the start, not bolted on after the tooling budget is approved.
Recovery by design is also an important concept, one most organizations treat as a backup and disaster recovery problem rather than a security architecture issue. The distinction matters. Having backups is not the same as having validated recovery capability. Recovery time and recovery point objectives are defined, documented, and tested per system before a breach occurs, not negotiated during one. Backup environments need to be architecturally, logically, and geographically isolated from production so an attacker cannot reach them through the same path as the initial compromise, and recovery runbooks need to exist, stay current, and undergo actual testing. Most organizations discover the gaps in their recovery architecture during an incident. Design for Breach requires discovering them during periodic testing.
These four domains look a bit different in the context of Operational Technology and Industrial Control Systems. A common issue is not conflating IT and OT/ICS but isolating them entirely, both logically and culturally. OT/ICS environments are frequently governed by separate teams, separate risk models, and separate tooling, sometimes with little to no shared architecture dialogue with IT and cybersecurity. That isolation means Design for Breach thinking rarely reaches OT/ICS at all. Network segmentation looks different when a control network's availability requirements are tied to physical safety systems rather than data confidentiality. Just-in-time access and short-lived credentials, the identity architecture standard for IT, frequently cannot be applied to legacy OT/ICS systems that were never built to support dynamic credential issuance and may run for decades without a supported upgrade path. Typical active half-open tcp scanning and certain detection techniques that are routine in traditional IT can destabilize OT/ICS systems, which means detection design in OT/ICS often depends more on passive network monitoring. Recovery by design in OT/ICS extends beyond RTO and RPO for data. A failed recovery can mean a failed physical process, not just a failed application. Closing the isolation gap, not applying one framework uniformly, is the real Design for Breach work in OT/ICS environments.
The Path Forward: Where to Start
A practical starting point requires no new tooling and no new budget, but it does require a named owner and a defined scope. Pick one critical system, ideally one that handles sensitive data or connects to multiple downstream services, and trace what an attacker could actually reach from it today. Map what other systems it connects to, what credentials and API keys it holds or can reach, and who or what would actually notice unusual activity coming from it, and how fast.
Most organizations attempting this for the first time will find that system design documentation, data flow records, and credential inventories are incomplete or outdated. That gap is itself the finding. An organization that cannot answer what a critical system connects to, what has access to it, and who would notice unusual activity has already identified its first architectural priority: building the baseline visibility that Design for Breach depends on. The exercise does not solve the problem. It makes the problem visible, which is the necessary first step toward architectural investment that is prioritized by actual risk rather than by whatever control category has budget available this cycle. From there, the sequence repeats: prioritize what the exercise surfaced by actual risk, close the highest-priority gaps first, then run the same exercise against the next critical system. Design for Breach is not a single project with an end date. It is a standing discipline that expands one system, one domain, at a time.
From that baseline, the more consequential decision is organizational, not technical: who owns Design for Breach going forward. If it sits exclusively with security, it will be treated as a security initiative that IT tolerates rather than an architecture discipline that Cyber and IT drive together. The organizations that make progress are the ones where infrastructure, cloud, and application teams treat blast radius, identity architecture, detection design, and recovery capability as a mutual responsibility, with security enabling and validating the work rather than owning it alone.
Conclusion
Prevention will always matter, but it stopped being a viable strategy on its own once MTTE started collapsing and AI-assisted adversaries began operating at machine speed. Design for Breach does not abandon prevention. It accepts that prevention will fail at some point and asks a harder architectural question: when it does, what can attackers actually do?
The work is architectural, not aspirational: blast radius reduction, identity architecture built for post-breach conditions, detection that is designed rather than purchased via tooling, and recovery capability that is tested rather than assumed. None of it requires waiting for a breach to justify the investment. The four incidents outlined here already made that case.
Organizations that treat Design for Breach as a blended discipline, owned jointly by IT and security rather than delegated entirely to one or the other, will be the ones still standing when prevention inevitably fails.