Ghosts in the machine: AI malware shows why it is time to extend Zero Trust
to code

Date:
Tue, 18 Aug 2026 10:41:24 +0000

Description:
AI-generated malware is outpacing human-centered security controls, find out how enterprises can fight back.

FULL STORY ======================================================================Copy link Facebook X Whatsapp Reddit Pinterest Flipboard Threads Email Share this article 0 Join the conversation Follow us Add us as a preferred source on Google Newsletter Subscribe to our newsletter 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. Latest Videos From TechRadar Watch full video here: Ken Ammon Social Links Navigation

CEO of CodeHunter. 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 cant match. You may like In the age of AI-based threats, zero-trust is no longer enough Rethinking defense in the wake of OpenClaw attacks 81% of teams ship broken code: Mythos made that inexcusable 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. Are you a pro? Subscribe to our newsletter Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed! Contact me with news and offers from other Future brands Receive email from us on behalf of our trusted partners or sponsors By submitting your information you agree to the Terms & Conditions and Privacy Policy and are aged 16 or over.

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. What to read next AI code security risk: The need for a smarter layer between detection and remediation AI agents are inside the enterprise are your security foundations ready for them? Why cybersecurity must evolve for the
age of AI agents

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 dont 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 artifacts 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-source packages, containers and CI/CD pipelines, as well as email attachments, 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 approved source, was signed, passed through a build process or has no malicious 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 of TechRadar 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



======================================================================
Link to news story: https://www.techradar.com/pro/ghosts-in-the-machine-ai-malware-shows-why-it-is -time-to-extend-zero-trust-to-code


--- Mystic BBS v1.12 A49 (Linux/64)
* Origin: tqwNet Technology News (1337:1/100)