Software security was built around human development.
People wrote, reviewed and deployed code. Now machines are taking over.
In a recent paper, Anthropic reports that more than 80% of the code merged into its production codebase is authored by their AI model, Claude.
The same capabilities that make developers more productive are changing the economics of cyberattacks.
While adversaries still define the objective, machines can generate the payloads, test variants, adapt code to different environments and repeat the process at a velocity that security programs can’t match.
Speed is Marginalizing Security Controls
Most enterprise software security workflows assume there is time for review. Code is written, scanned, tested, approved and deployed. If something suspicious happens later, security teams investigate and respond.
That model breaks down when software moves from prompt to execution in minutes.
AI-generated code can become a script, dependency, automation job or infrastructure change almost immediately. While development agents can modify files, resolve packages and run commands.
Human reviewers are no longer in the loop.
Attackers can use the same mechanics to generate exploits, test evasion techniques and adjust payload behavior for different targets. This creates more variation with fewer stable indicators for defenders to recognize.
While AI-assisted analysis can improve triage, it still often produces probability, not policy. At machine speed, “probably suspicious” is not good enough.
Machines Change The Attack Model
Human attackers are not disappearing. But more of the attack chain is becoming machine-executed.
AI can automate reconnaissance, accelerate vulnerability discovery, generate exploit code, rewrite payloads and adapt command sequences to the target environment. But most defensive measures are designed around human constraints: reused infrastructure, shortcuts and trackable patterns. These don’t apply to machine attacks.
A machine-generated payload may not match a known signature or have an established reputation. It may be created, used briefly and discarded. But AI malware must still interact with the target environment to achieve its objective. Its behavior cannot conceal its intent, since it must access resources and change the environment in ways that advance the attack.
What malicious code is capable of doing is the more durable security signal.
Security Needs to Ask A Different Question
Software supply chain security has improved, but much of it still validates the artifact’s properties before execution rather than governing execution itself.
SBOMs, signing and provenance give security teams greater confidence in a code’s composition, origin and build history. But knowing where software came from does not reveal what it will do when it runs.
Software can pass each of those checks and still create risk. Even an artifact produced through a legitimate build process may violate policy at runtime, while an AI-generated script may complete its intended task in a way that exposes data or systems. As a result, a clean dependency list is not proof of safe behavior.
Post-Execution Detection Is Too Late
Detection and response remain essential, but they intervene after risk has entered the environment. By the time suspicious behavior is visible, software may have accessed secrets, changed system state, opened network connections or created persistence.
AI compresses that window. Code can be generated, modified and deployed faster than humans can review it. Waiting for post-execution evidence gives attackers too much room to operate.
We need to shift the decision point left. Instead of asking, “Can we contain this software if it behaves badly?” the question should be, “Should this behavior be permitted to execute in the first place?”
That does not mean replacing existing controls, but rather changing where the decisive security gate sits.
Zero Trust for Code
Zero Trust changed enterprise security by rejecting implicit trust. Users, devices, sessions and access requests are not trusted simply because they appear familiar. They must be verified against policy.
Software execution needs the same level of verification.
Code should not be trusted solely because it came from a known repository, was signed by a recognized publisher, passed through a build pipeline or has not been seen exhibiting malicious behavior before. Those are useful indicators, but they are not conclusive.
Zero Trust for Code addresses this problem. Before software runs, its expected behavior should be evaluated against policy. If the behavior is acceptable, execution can proceed. If not, the artifact should be blocked, restricted, isolated or escalated for review.
Organizations can start by mapping every path through which code enters the environment or executes with meaningful privilege. This includes formal development channels such as repositories, open-ttachments, downloaded files, macros, browser extensions, endpoint installers, third-party integrations and scripts introduced through AI or automation tools
Then identify where those paths rely on inherited trust. If execution is allowed because software came from an approvedious history, the control is incomplete. Behavior still has to be evaluated before the artifact is allowed to run
As AI takes on more of the work of creating legitimate and malicious code, enterprises can no longer assume that code which clears existing checks should be allowed to run. Execution must become a deliberate security decision.
We’ve listed the best internet security suites for PCs, Macs and mobile devices.
This article was produced as part ofTechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here:https://www.techradar.com/pro/perspectives-how-to-submit
