Ken Ammon is CEO of CodeHunter, a serial entrepreneur who exited OPĀQ and NetSec, and former U.S. Air Force captain at the NSA.gettyEnterprise security is built on a flawed assumption that we can recognize malicious software before it executes. For years, that worked. Malware was reused, observable and slow to evolve. That is no longer the case.That’s because today’s threats are shaped by automation and industrialized attack pipelines. Our defensive architecture, meanwhile, is still based on outdated principles. The result is a widening gap between how attacks operate and how security systems make decisions.​Simply put, our traditional post-execution approach to security has a timing problem. ​AI Is Driving Mutation​Signature-based and reputation-based systems depend on prior observation. They require reuse, pattern stability or shared infrastructure. Even behavioral detection models frequently rely on correlating runtime activity with known malicious techniques or previously observed campaigns.That approach assumes that threats will resemble something we have seen before, but modern malware increasingly does not. Automation frameworks now generate polymorphic variants at scale, while AI-assisted tooling can modify strings, control flow or packing routines in seconds. Payloads can be regenerated just-in-time for a specific target, and code that appears once may never appear again.​The observable surface of malware—its hash, its static indicators, even portions of its execution path—has become disposable. In this environment, “known-bad” becomes a lagging signal. Detection depends on history, but attackers have moved on and are designing for rapid mutation.When defenders rely on recognition and attackers design artifacts to be single-use, the advantage shifts.​Shifting From Appearance To Intent ​While malware appearance has become fluid, its purpose has not. Malicious software must still accomplish objectives: Establish persistence, escalate privileges, modify system state, move laterally, exfiltrate data or disrupt operations. These behaviors are the reason the code exists. Code can mutate endlessly in structure, but it cannot achieve its goal without performing certain categories of action.​Yet most detection systems still focus heavily on appearance. Even advanced sandboxes and runtime detection tools frequently ask: Does this resemble known malicious activity? That question implicitly depends on pattern similarity.If the core question shifts from “Have we seen this before?” to “What is this designed to do?” the defensive model changes. The decision no longer depends on external validation but on evaluating behavior against policy before execution is trusted.​This creates a fundamentally different decision point, and reframes security from pattern recognition to intent evaluation. This shift—from recognizing patterns to evaluating intent before execution—aligns with the zero trust model. Rather than extending trust based on origin, signatures or prior observation, this approach treats every software artifact as untrusted until its behavior is evaluated against policy.The Shrinking Mitigation WindowCompounding the mismatch is a second issue: compression of attack timelines. In many environments, lateral movement and data access can occur soon after initial execution. Automation has reduced dwell time between foothold and impact, with attackers not waiting for defenders to analyze logs.At the same time, security workflows remain largely post-execution. Telemetry is collected, alerts are generated, analysts triage, correlation occurs and containment follows. By the time a high-confidence alert reaches a SOC queue, the artifact has already executed. Persistence may already be established and credentials and sensitive data accessed. Detection is doing exactly what it was designed to do. but the moment of decision may be too late.Controls, including EDR, XDR, SIEM, sandboxing and threat intelligence, are important, yet incidents can still begin with an execution event that was not prevented. Detect-and-respond has become a recovery strategy to contain damage and support investigation and remediation, but it does not prevent attacks from executing.None of this suggests that detection is obsolete. Visibility remains foundational and incident response will always matter. But detection models that only trigger after execution are positioned downstream of the trust decision.​ When evaluation occurs only after execution, the organization has implicitly accepted risk at the moment of trust.​Moving Trust Upstream ​To defend against AI-based threats, security leaders need to move the decision point and extend zero trust principles to software. Instead of relying exclusively on runtime telemetry, organizations must assess software behavior before it executes or propagates. That includes internally developed code, third-party packages, automation scripts, build artifacts and binaries acquired from trusted sources.​​​Applying zero trust to software starts with changing the default assumption. No artifact should be trusted simply because it came from a known vendor, a signed package, an internal repository or an approved build process. SBOMs, signing and provenance remain important, but they do not answer the operational question that matters most: what is this code capable of doing?Security teams should begin by identifying the software artifacts that create the most risk: third-party packages, containers, scripts, CI/CD outputs, automation tools and binaries entering production environments. For those artifacts, establish policies that evaluate behavior before execution, including privilege use, persistence, network activity, file modification, data access and lateral movement potential.Finally, connect prevention and detection. Pre-execution analysis should gate high-risk behavior, while runtime telemetry confirms what actually happened and feeds policy improvement. The goal is not to replace detection, but to move the first trust decision upstream.Detection becomes part of a layered model in which pre-execution behavioral analysis evaluates intent, policy violations and operational risk before trust is granted. Runtime detection remains in place as a safety net and incident response continues as an essential capability, but prevention becomes a more secure frontline of defense. ​​AI has changed not just how attacks are generated, but how quickly they execute. That shift forces a reevaluation of where trust decisions occur. If software is trusted before its behavior is understood, prevention is no longer part of the control model. You need to move that decision upstream, where intent can be evaluated, risk can be assessed and execution can be controlled before any damage occurs.Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?