iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Zero Trust can be extended to code by making execution conditional on whether a program’s behavior and privileges fit an explicit policy—not just whether the code came from a trusted source or passed a scan. Ken Ammon proposed this approach in TechRadar Pro on August 18, 2026. It is a case for adding behavior checks to existing security controls, not an established universal standard or a replacement for them.
What is AI malware?
“AI malware” can mean malicious software created or modified with help from AI, or malware designed to attack AI systems. Those are different problems. NIST’s March 2025 report, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, organizes attacks against machine-learning systems; it is not an estimate of how common AI-created malware is.
Ammon’s argument concerns the possibility that AI tools make it easier to generate or alter code and then move it into use quickly. His article does not establish how prevalent AI-generated malware is, or quantify whether attackers are now faster than defenders. The practical security question is narrower: can an organization decide what code is allowed to do before it runs, and contain it if its behavior falls outside that policy?
How does AI-generated code change cybersecurity?
AI coding tools can produce code, revise it, and connect it to development workflows. Ammon argues that this can compress the time available for review, scanning, testing, approval, and deployment, while making it easier to vary code. That is a reason to examine where code executes and what authority it receives, not evidence that every AI-generated change is malicious or that established checks no longer matter.
#1 Best Overall
The broader developer supply chain already has risks independent of AI. In a May 28, 2026 advisory, CISA described a malicious Nx Console VS Code extension distributed through automatic update and a separate campaign that injected malicious GitHub Actions workflows to harvest secrets, credentials, and tokens. The advisory does not attribute either campaign to AI. It does show why organizations need to account for extensions, workflow files, credentials, and automated updates—not only code in application repositories.
Can Zero Trust be applied to code?
Yes, as a proposed extension of Zero Trust principles. In a Zero Trust Architecture, access to resources is authorized deliberately rather than granted solely because a user or device is inside a trusted network. NIST’s SP 1800-35, published in June 2025, provides practical enterprise Zero Trust implementation examples consistent with SP 800-207. NIST reports that the NCCoE collaborated with 24 organizations to build 19 example implementations. That guide supports the broader architecture; it does not define a standardized “Zero Trust for Code” control.
Applied to software execution, the idea is to evaluate what a program is expected and permitted to do, then make a policy decision before allowing it to run or access sensitive resources. A trusted author, signature, repository, or dependency list can provide useful evidence, but none alone proves that a program’s runtime behavior is safe. The behavior-policy proposal complements checks on identity, origin, composition, and vulnerabilities.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteHow the controls differ
| Control | Primary question | When it helps | What it does not establish by itself |
|---|---|---|---|
| Identity and access controls | Who or what is requesting access, and to which resource? | When a user, service, or agent requests permission | That code using authorized access will behave safely |
| Signatures and provenance | Where did an artifact come from, and has it changed? | When validating origin and integrity | That the artifact’s behavior is permitted |
| SBOMs | Which components are included? | When assessing software composition and supply-chain risk | That components or the assembled program will behave safely at runtime |
| Scanning, review, and testing | Are known issues or unsafe patterns detectable before release? | During development and release checks | That every runtime action will match policy in every environment |
| Code behavior policy | Is this execution and its requested behavior permitted? | Before execution or access to protected resources, with monitoring afterward | That the policy is complete, correctly configured, or a substitute for other controls |
Are SBOMs enough to keep software safe?
No. An SBOM is an inventory of software components: it helps an organization understand what is in a product and make risk-informed supply-chain decisions. CISA and G7 partners’ May 12, 2026 guidance describes AI-specific SBOM elements as additions to general SBOM elements, and calls them non-exhaustive and non-mandatory. An SBOM can help identify a vulnerable or unwanted component, but it does not show every action the software will take when it runs.
That limitation is not a reason to discard SBOMs, signatures, provenance, scanning, review, or testing. Each answers a different question. A safer approach combines those forms of evidence with explicit decisions about execution, privileges, and access to sensitive resources.
How should companies secure AI coding agents and CI/CD pipelines?
Begin by mapping how code enters the organization and where it can execute. Include repositories and dependencies, editor extensions, scripts, build systems, CI/CD workflows, containers, and deployed services. Then apply the following controls to the paths that matter:
- Map trust and execution paths. Record which tools, people, agents, and workflows can introduce or run code, and what credentials or systems each can reach. Include automatic updates and third-party extensions in the inventory.
- Define allowed behavior and privilege. Specify which resources a process may access and what actions it may take. Use the least privilege needed for the task, and make exceptions explicit rather than treating repository membership or a successful build as blanket approval.
- Constrain AI-agent autonomy. Limit agent access to sensitive data and critical systems, use strong identity management, and retain human oversight for consequential actions. CISA’s May 1, 2026 guidance on agentic AI services identifies privilege escalation, emergent behavior, and accountability gaps among the risks, and recommends bounded autonomy and access, layered defenses, threat modeling, continuous monitoring, and regular security assessments.
- Protect pipeline configuration and secrets. Monitor workflow-file changes and contributor activity, pin trusted versions, and limit package sources. These measures align with CISA’s May 2026 supply-chain advisory. If a compromise is suspected, investigate relevant logs and affected machines, then rotate credentials and tokens that may have been exposed.
- Evaluate behavior before execution where feasible. Add a policy check for whether the code’s expected actions and requested privileges are permitted. Route uncertain or exceptional cases to review or isolation instead of granting broad access by default. This is the execution-policy proposal Ammon advocates; implementation details depend on the organization’s systems and controls.
- Monitor and reassess. Observe execution and access events, review policy exceptions, and update threat models and controls as tools and workflows change. Monitoring helps identify activity that preventive checks missed; it does not replace careful access design.
What are the limits of Zero Trust for code?
A behavior policy is only as useful as its coverage and quality. Organizations need to know which execution paths are covered, what the policy permits, how exceptions are approved, and whether decisions can be reviewed later. A control that covers a deployed application but misses developer extensions, scripts, or CI/CD workflows leaves important parts of the software lifecycle outside its reach.
Nor should an execution check be treated as a guarantee that malicious behavior will always be detected or that benign code will never be blocked. Code can be complex, context-dependent, and difficult to classify in advance. That makes layered safeguards—including scoped credentials, review or isolation for uncertain cases, and monitoring—important alongside any behavior-based policy.
Best Value
Zero Trust for code is therefore best understood as a policy direction: make permission to execute or access resources deliberate, and base that decision on more than origin or composition alone. NIST’s Zero Trust implementation guide supplies a foundation for access architecture, while the execution-policy proposal adds a distinct question about software behavior.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
