Vulnerability Management , AI/ML , AI benefits/risks , Government security , Security Operations Operating at the speed of the adversary April 27, 2026 Share By Dr. Darren Death In my previous article, " AI Vulnerability Discovery and the Case for Systems Security Engineering ", I argued that AI-driven vulnerability discovery turns secure system design into an engineering requirement. NIST SP 800-160 established that framework in 2016, and it was updated in Revision 1 in 2022 . The framework has been available for years, but many organizations did not operationalize systems security engineering in their delivery model because functionality, speed, and legacy architecture pressures dominated implementation decisions. AI-driven vulnerability discovery has changed the risk calculation. Systems that were built to work, but not engineered to be secure, now carry an active and growing liability. That article addressed how systems should be built. This one addresses how organizations must operate from where they actually are, which for most is not a clean, well-architected starting point but rather decades of accumulated technical decisions that were never evaluated through a security engineering lens. The threat environment is not waiting for organizations to complete a multi-year architecture transformation. The operational response must begin now, with the systems, the infrastructure, and the technical debt that currently exist. This is the second in a series of articles examining the security implications of AI-driven vulnerability discovery. The first addressed the engineering foundation. This one addresses the operational reality. The operational starting point Most organizations are not operating from the kind of engineered security architecture that NIST 800-160 describes. They are operating environments assembled over years or decades through implementation decisions that were made to deliver capability, not to preserve a coherent security architecture. Flat network segments remain because they were easier to deploy and maintain. Trust relationships between systems remain broader than they should be because they were never revisited after initial implementation. Internet-facing services persist because accessibility was treated as a default requirement rather than a security decision. Organizations will need to adopt measures such as zero trust , VulnOps, and AI-augmented defense within environments that were not designed to support them. AI-driven vulnerability discovery and exploitation are advancing at a pace that will not wait for organizations to resolve their technical debt before it is used against them. The speed at which adversaries will operate against these environments is unlike anything the industry has faced, and organizations that delay operational improvements while planning ideal architectures will find that the threat arrived before the plan was complete. Rethinking internet exposure One of the most consequential and most overlooked operational decisions an organization makes is what it exposes to the internet. For much of the past two decades, the default trajectory has been toward greater connectivity. Remote access, API-driven integrations, publicly accessible management interfaces, and the general expectation that services should be reachable from anywhere have collectively expanded the internet-facing attack surface of most organizations well beyond what their mission requirements actually demand. Cloud and SaaS adoption have accelerated this trend in ways that are not always visible to the organizations involved. Cloud platforms make it remarkably easy to publish services, and the shared responsibility model can create a false sense of security in which organizations assume the platform provider is handling protections that are in fact the customer's responsibility. Misconfigurations, overly permissive default settings, and storage or API endpoints left publicly accessible without deliberate intent are common findings across cloud environments. Compounding this, most organizations have not resourced their security programs to adequately protect the internet-facing footprint they have accumulated. The attack surface has grown incrementally over years, but the staffing, tooling, and monitoring required to defend it have not kept pace. In an environment where AI can enumerate an organization's external attack surface and probe it for exploitable flaws at machine speed, the cost of unnecessary internet exposure has changed materially. Every service that is accessible from the internet is a service that an adversary's AI can reach, analyze, and attempt to exploit without needing to first establish a foothold inside the network. The decision about what to expose is no longer a convenience or performance question. It is a security architecture decision with direct risk consequences. Organizations should be evaluating their internet-facing footprint with significantly more rigor than most currently apply. This means asking, for each externally accessible service, whether internet exposure is required by the mission or whether it exists because it was the path of least resistance during deployment. Services that do not need to be internet-facing should not be. The more nuanced problem is services that organizations believe are adequately controlled but are in practice far more exposed than assumed, such as enterprise collaboration platforms that are accessible from any device on any network, despite the organization having conditional access and zero-trust capabilities available to restrict them. There are also environments where any endpoint, managed or unmanaged, can download the full contents of a file repository or upload to it without restriction, while the organization reports data-loss-prevention controls as being in place. These are missing controls that organizations have either not recognized as gaps or have reported as addressed when they are not effectively implemented. This is not an argument against cloud adoption or against internet-connected services. It is an argument that the decision to expose a service to the internet should be a deliberate, documented security decision with an associated risk assessment, not an inherited default. In the current threat environment, every unnecessary point of internet exposure is an unnecessary point of AI-addressable attack surface. Accelerating zero-trust adoption Zero trust has been discussed extensively across the industry, and the concept is well understood in principle. The practical challenge is that most organizations have implemented it partially, inconsistently, or not at all. The gap between zero trust as a strategic direction and zero trust as an operational reality is significant in most environments, and the current threat landscape makes closing that gap substantially more urgent. The core premise of zero trust — that no user, device, or network location should be implicitly trusted — directly addresses the conditions that AI-driven attacks exploit. When an adversary can discover and exploit a vulnerability in a few hours, the architecture's ability to limit what that exploit achieves determines whether the result is a contained event or a broader compromise. Flat networks with implicit trust allow lateral movement. Over-privileged service accounts provide escalation paths. Systems that authenticate at the perimeter but not between internal components allow an attacker who gains any foothold to traverse the environment with minimal additional effort. For organizations with significant technical debt, implementing zero trust is not a single initiative. It is a sustained effort to systematically reduce implicit trust across the environment. The practical starting points are well established. Network segmentation limits the blast radius of any single compromise. Identity-based access controls, applied consistently to both human users and service accounts, replace location-based trust assumptions. Phishing-resistant multi-factor authentication reduces the effectiveness of credential-based attacks. Egress filtering constrains the ability of compromised systems to communicate with external command infrastructure. Privilege reduction across service accounts and administrative access limits what an attacker can do after initial access. None of these measures are new. What has changed is the urgency. When vulnerability discovery and exploitation operate at machine speed, the architectural controls that were always advisable become the controls that determine whether the organization can contain an incident or whether it escalates beyond containment. Organizations that have been treating zero trust as a multi-year roadmap item need to evaluate which elements can be accelerated, because the threat timeline against which they are operating has compressed. Establishing vulnerability operations VulnOps was described by Heather Adkins, Gadi Evron, and Bruce Schneier in an October 2025 CSO essay as an operating model for continuous vulnerability discovery and response in an AI-accelerated environment. The concept is useful because it frames vulnerability discovery as a standing operational capability applied across proprietary code, third-party dependencies, infrastructure configurations, and acquired software, rather than as a periodic assessment activity. AI systems have demonstrated the ability to accelerate vulnerability identification and exploit development enough that organizations should assume adversaries will increasingly compress discovery-to-exploit timelines. If the organization is not applying that level of analysis to its own systems, adversaries will. The difference between finding issues proactively and responding after external exploitation attempts is the difference between planned remediation and incident response. Traditional vulnerability management processes were not designed for such a pace. Building a VulnOps capabil