What I mean is that the last ~15-20 years have been an era where exploits that affect roughly the entire Internet have been historically rare/hard. But in the mid to late 90's, remote and LPE exploits against big commercial Unixes dropped on BUGTRAQ every few weeks, early 2000's for Windows were that way also. Situations like the above *caused* OpenBSD to exist, privsep to be implemented into those daemons, and custom hardening to be implemented at sites. It caused the Trustworthy Computing Initiative at Microsoft because the situation was so dire. Today, a vocal and influential plurality of professionals in the field advocate "just patch faster" or "just rewrite the world in Rust" as security strategies, which are both oblivious to the architectural security engineering lessons from that era of planning for and containing security faults and failures. If increasingly powerful AI models are bringing us to another era where impactful exploits are common and easy, then I believe that those strategies aren't the right ones for vast majority of organizations to prioritize. "Just patch faster" is oblivious to the latent vulnerabilities that are now significantly easier to exploit and it's a race that the attacker has an easier time winning than the defender. "Just rewrite in Rust" causes functionality and security logic bugs fixed decades ago to be reimplemented (see uutils/coreutils). Neither give the defender more leverage than architectural approaches, IMHO, for the simple reason that each additional security boundary requires the attacker to have another exploitable vulnerability, and the probability of them achieving their objectives is the arithmetic product of the probabilities of exploitable vulnerabilities existing in each security boundary along the minimum length attack path. Lengthening that path decreases the end-to-end probability the most and is in the control of both organizations that build and those that deploy systems.