.jpg "French government announces €655m AI investment for public services")
Investor enthusiasm for AI has fueled expectations that it will dramatically improve software development, automation, and cybersecurity operations.
AI has already changed how software is built, how attacks are generated, and how quickly both move through enterprises. It has also raised expectations for defenders: faster analysis, better prioritization, and more automated decision-making.
However, when both attackers and developers operate at machine speed, prevention depends less on smarter predictions and more on clear, enforceable decisions grounded in intent.
Probabilistic Security Is Not Enough
Most security tools, especially those incorporating machine learning or large language models, are probabilistic by design. They generate likelihoods: this file is probably malicious, this behavior is likely suspicious, this activity has a high likelihood of being an attack.
This works well for triage and investigation. It helps analysts sift through noise, prioritize alerts, and identify patterns that would otherwise be missed. However, those strengths do not necessarily translate into reliable enforcement decisions.
A probabilistic system may not always provide the level of certainty required to determine whether a software artifact should execute in a production environment.
Attackers are now generating single-use polymorphic code. Developers, meanwhile, increasingly rely on automation, open-source dependencies, and AI-generated components that move through pipelines without human review. In both cases, the volume and velocity of software exceed the limits of human judgment and the reliability of probabilistic scoring.
The result is often a gap between identifying risk and preventing it.
If security decisions cannot be made with sufficient confidence at the moment of execution, they must be grounded in something more stable than probability and enforced before code runs. This is the foundation of a Zero Trust for Code approach, where software is not trusted to run until its behavior is evaluated against policy.
The Need for Explainable Security Controls
As software becomes more autonomous, security decisions must also be more precise and reliable. It is no longer enough to detect anomalies or assign risk scores. Decisions must be explainable, repeatable, and auditable. Security teams need to understand why an artifact was allowed or blocked, whether the same artifact would produce the same outcome tomorrow, and whether that decision can be defended in a compliance or incident review context.
Probabilistic models struggle with all three. This does not mean probabilistic systems are ineffective. Many modern security programs combine predictive analytics with policy-based controls, using each where it is most effective.
Even small variations in input or model state can produce different outputs. That variability is acceptable when assisting analysts, but not when determining whether code is allowed to run in a regulated environment. This risk becomes more pronounced in software supply chains, where trust decisions affect not just one system, but downstream dependencies, production environments, and customer data.
Recent incidents have made this clear. In the LiteLLM supply chain compromise, a widely used Python package was briefly modified to harvest credentials and establish persistence in developer environments. The malicious versions were available for only a few hours, but that was enough.
The failure was not detection, but timing and trust. By the time alerts could be generated, the code had already executed, secrets had been exposed, and persistence mechanisms were in place. A probabilistic model might flag that behavior after the fact, but it cannot reverse the execution decision.
None of this diminishes AI’s value in security. It excels at identifying patterns across large datasets, correlating signals, accelerating investigations, supporting root-cause analysis, and reducing manual workloads.
Used correctly, AI can significantly improve visibility and response, and help analysts understand what code might do. But it should not be the final authority on whether that code is allowed to execute. That responsibility requires deterministic, policy-driven controls.
Moving From Detection to Prevention
Instead of asking whether something is likely malicious, deterministic behavioral intent analysis asks what a piece of software is capable of doing and whether that behavior complies with policy.
AI-generated malware can mutate endlessly, changing hashes, strings, and structure on demand, but its intent does not change at the same rate as its appearance. That’s because it cannot achieve its objective without performing certain categories of action, such as accessing sensitive data, modifying system state, establishing persistence, or communicating externally. Those behavioral objectives often remain consistent even when the underlying code changes.
This is the operational core of Zero Trust for Code: evaluating what software is capable of before execution and enforcing a consistent policy decision. By analyzing behavior before execution, organizations can allow software that aligns with policy, block software that violates defined constraints, and isolate or escalate cases that require further review.
Most importantly, these decisions are designed to be consistent. When evaluated against the same policies and conditions, software artifacts should produce predictable outcomes that can be reviewed and audited. That consistency is what enables reliable prevention. It also changes the role of security controls. Instead of reacting to execution events, they become gatekeepers of execution itself.
AI is not just improving attacks; it is compressing timelines. Autonomous systems can ingest dependencies, deploy services, and initiate actions without human intervention. In this environment, prevention must happen before execution, not after.
Zero Trust for Code emphasizes policy-based enforcement alongside predictive analysis, making security decisions based on whether a software artifact should be allowed to run at all. In the process, it turns execution into a policy-driven control point.
As AI accelerates software creation and deployment, organizations will need security models that can keep pace without sacrificing accountability. The future is unlikely to be a choice between AI and deterministic controls, but rather a combination of intelligent analysis and enforceable policy that allows organizations to move quickly while maintaining trust.
