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.getty​The Shai-Hulud 2.0 supply chain attacks exposed a structural weakness in enterprise security: how organizations determine whether software should run in the first place.​Enterprise security has historically invested more heavily in detecting suspicious behavior after execution than in preventing untrusted code from executing in the first place.​ By the time alerts reach security teams, credentials may be exposed, and a breach could already be underway.​Rather than relying on traditional phishing or convincing developers to execute malware manually, the attackers compromised trusted software packages so malicious code executed automatically during dependency installation.​ As development workflows become increasingly automated, compromised software packages can be installed and executed with minimal human intervention. When malicious packages enter these workflows, the code may already be running before security systems have time to evaluate it.​This is driving increased interest in a "zero trust for code" approach that applies zero-trust principles to software execution by requiring behavior-based validation before code is allowed to run.​Why Security Decisions Must Move Upstream​Enterprise environments now process enormous volumes of executable artifacts every day. Code moves continuously through development pipelines as third-party packages are imported automatically, and containers and services are deployed across cloud infrastructure at machine speed.​Many of these actions are now being performed by autonomous coding assistants and agentic development tools. But that autonomy also changes the trust model. Software can now be downloaded, resolved and executed without human inspection.​This creates a new opportunity for attackers to exploit the trust assumptions of open-source ecosystems and automated development workflows at the same time. Malicious packages can appear legitimate long enough to be consumed by automated tooling, especially when those tools are designed to resolve dependencies quickly and move code through pipelines without pause.​The problem is compounded by speed.​Traditional security controls such as signature detection and reputation scoring depend on prior observation. By the time malicious artifacts are identified and cataloged, automated systems may already have downloaded the dependency, executed the loader and exposed sensitive credentials such as API tokens or cloud access keys.​Machine-speed development workflows are now colliding with human-speed security processes.​This is why modern enterprises increasingly need decision points upstream of execution, not just visibility downstream.​This shift reflects a broader move toward zero trust for code, where execution is treated as a gated decision rather than an assumed outcome.​Operationalizing Behavioral Intent​Behavioral intent analysis provides a practical way to introduce decision points earlier in the software life cycle. While traditional security models focus on identifying known malicious artifacts or detecting suspicious behavior after execution, behavioral intent analysis approaches the problem differently. Instead of asking whether code resembles known malware, it evaluates what the code can do.​This is the core mechanism behind a zero trust for code model, where behavioral intent becomes the basis for determining whether software is authorized to execute.​Intent analysis examines execution paths, system interactions, privilege use, network communication and persistence behavior to determine whether an artifact’s expected activity violates security policy or introduces unacceptable risk.​The distinction matters. That’s because detection models attempt to recognize malicious patterns. Intent analysis evaluates behavior before it occurs.​That capability becomes particularly important in environments where software is installed automatically. Autonomous development agents may download and execute packages within seconds. Evaluating an artifact’s behavioral profile before execution creates a meaningful opportunity to intervene.​In practice, behavioral intent analysis can operate across the environments where software enters and moves through an organization, including:​• Software development pipelines, where build artifacts are generated and promoted• CI/CD systems, where automated deployment workflows occur• Artifact repositories and package ingestion systems, where third-party software enters the environment• Runtime environments, where executables are launched​Evaluating intent at these stages allows security systems to make trust decisions before execution rather than after the damage is done. In a zero trust for code model, these decisions are not advisory. They are enforced to ensure only code aligned with policy is allowed to execute.​Turning Analysis Into Enforceable Controls​This architectural shift changes security outcomes by producing deterministic policy decisions that systems can enforce automatically, such as:​• Allow, when behavior aligns with operational policy• Block, when behavior violates defined security rules• Quarantine, when artifacts require containment before further analysis• Review, when human investigation is necessary before execution​This model transforms malware analysis from an investigation tool into a security control plane that dictates whether an artifact should run at all. Because the decisions are deterministic, the same artifact evaluated under the same policy produces the same outcome, supporting governance, compliance and auditability.​More importantly, these decisions occur before execution, where they can prevent damage rather than explain it.​Deterministic decisions also change the workload profile of security operations. When artifacts are evaluated before execution, many routine investigations disappear entirely. Security teams spend less time triaging ambiguous alerts and more time focusing on genuine threats. Upstream decisions also reduce “late discovery” incidents, where malicious activity is detected only after code has already executed inside production environments.​As an added benefit, this shift does not slow software delivery, but in many cases accelerates it by automating decisions that would otherwise require manual investigation.​In environments where software can be installed, modified and executed autonomously, the fundamental security question is no longer whether an artifact has been seen before. It is whether its behavior should be trusted to run.​Answering that question earlier restores threat prevention as a realistic objective.​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?