Behavioral and Security briefs from CodeHunter focusing on the latest threats, behavioral engineering, forensic findings, and field intelligence on software execution threats.

CodeHunter Behavioral Risk Brief cover for the GitSpawn AI agent flaw, September 2026

Behavioral Risk Brief: Malicious .git Configs

/in /by

the claim

Governance frameworks that treat workspace-trust prompts and sandboxing as sufficient protection create systemic risk when an agent’s own routine background operations bypass
both entirely. Zero Trust for Code addresses this by requiring a pre-execution trust decision on every command a repository can trigger, not only the ones a user’s approval prompt was designed to catch.

the incident

Manifold Security disclosed eight flaws across seven AI coding agents, including Claude Code, Cursor, Codex, and goose, where a repository’s own Git configuration file can name a command
that executes automatically when the agent performs an ordinary background operation, such as checking git status to determine the current branch. The command runs outside the agent’s
sandbox and without any approval prompt, in some cases before a workspace-trust dialog is accepted, before the user has authenticated, or on the first keystroke. Exploitation only requires
that a repository arrive with its .git directory intact, which happens through a shared archive, sync folder, or USB drive, though not through an ordinary clone. Fixes have shipped for goose,
Cursor, and one of the two flaws found in Claude Code, while Hermes Agent, Qwen Code, Grok Build, and a second, separate Claude Code path remained exploitable at the time of publication.

the governance failure

The governance failure is not that a malicious repository could be crafted, but that the execution point defeating every safeguard was a routine, background action the agent performs for its own housekeeping, rather than a step a user or a trust prompt was ever positioned to review. Workspace-trust dialogs and sandboxing exist specifically to gate what an agent does with a new repository, and this class of flaw runs before either applies.

This is compounded by how ordinary the triggering behavior is. Checking which branch an agent is on or which files changed is not a suspicious or unusual action, it happens automatically, every session, without a developer ever noticing. A control built around scrutinizing deliberate or unusual agent behavior has nothing to flag here, because nothing about the triggering action looks any different from a routine operation.

The underlying breakdown is the absence of a trust decision that covers an agent’s own background subprocesses, not only its visible, user-facing actions. As one researcher put it, the vulnerability sits in the ordinary plumbing underneath the agent, not in the model or in anything new, meaning trust granted to an agent’s core functionality never extended to the commands that functionality could be tricked into running.

the regulatory and business exposure

  • Arbitrary code execution on developer machines through routine agent operations, bypassing approval prompts entirely.
  • Exposure triggered before user authentication or trust approval completes, in some cases on the first keystroke.
  • Multiple agents from different vendors sharing the identical flaw, pointing to a systemic pattern.

what your auditor will ask

  • How do you validate the safety of an agent’s background operations, not only its visible, user-facing actions?
  • What controls detect a repository configuration file that names a command for the agent to execute?
  • How do you verify that workspace-trust prompts actually gate every code-execution path an agent has, not just some of them?
  • What evidence do you maintain that agent tooling was evaluated for this class of flaw across all vendors in use?
  • How do you account for repositories arriving through channels, such as shared drives, that preserve configuration an ordinary clone would not?

A consistent signal is the disconnect between what a trust prompt was designed to gate and what an agent actually executes before that prompt is ever shown. A safeguard positioned at the wrong point in the process protects nothing.

zero trust for code value

Zero Trust for Code introduces a trust decision that covers every command a repository can trigger, including an agent’s own routine background operations, rather than relying on a workspace-trust prompt positioned at only one point in the process. This means execution is evaluated on what a command actually does, regardless of whether it arrives through a visible action or a subprocess the agent runs on its own.

This directly addresses the governance weakness this disclosure exposes: the assumption that a single approval gate covers all the ways a repository can cause code to run. By requiring a pre-execution trust decision independent of where in an agent’s workflow a command originates, organizations can catch exactly this class of flaw, one where the trigger is ordinary housekeeping rather than a deliberate, reviewable action.

The result is a governance model where trust is evaluated at every execution point an agent has, not only the ones a vendor’s trust dialog was built to gate, closing the space this vulnerability class relies on across multiple, otherwise unrelated tools.

governance action brief

  • Establish governance controls that evaluate command execution across an agent’s background operations, not only its visible actions.
  • Require a pre-execution trust decision for any command a repository configuration file can specify.
  • Treat workspace-trust prompts as one control among several, not confirmation that every execution path is gated.
  • Monitor for repositories arriving through channels that preserve configuration an ordinary clone would strip out.
  • Maintain a record of agent tooling evaluated against this vulnerability class across every vendor in use.

 

sources

Analysis based on reporting from The Hacker News (September 2, 2026) on Manifold Security’s GitSpawn disclosure, CodeHunter Labs evaluation of governance gaps in background-operation
execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives

Download the PDF here.

CodeHunter Behavioral Risk Brief cover for the crypto-stealing Chrome extension campaign, August 2026

Behavioral Risk Brief: Crypto Stealing Chrome Extension

/in /by

the claim

Governance frameworks that treat an extension’s installation history and prior clean behavior as ongoing proof of safety create systemic risk when that same history can be inherited by a new owner or preserved deliberately before a compromise. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what an extension does at the moment it runs, rather than trust based on how long it has behaved.

the incident

Researchers identified a cluster of Chrome and Edge browser extensions delivering a modular malware framework designed to steal cryptocurrency, browser session data, and login credentials, while also displaying fake browser update prompts that trick users into running attacker-supplied commands. All of the affected extensions provided their advertised functionality and contained no malicious code when originally published, either acquired by the attacker from an original developer or left clean long enough to accumulate a genuine user base before malicious functionality arrived through a routine, automatic update. Once active, the malware opens an encrypted connection to attacker-controlled infrastructure and downloads additional modules, exploiting legitimate wallet-connection features on cryptocurrency platforms and redirecting users to counterfeit versions of trusted hardware wallet services.

the governance failure

The governance failure is not that malicious extensions reached an official marketplace, but that trust in these extensions was earned legitimately. Through real functionality, a genuine track record, and before being used against the same users who granted it. An extension that behaves correctly for an extended period builds exactly the kind of history an organization would typically treat as evidence of safety, and this campaign shows that history can be preserved deliberately or transferred entirely to a new owner without resetting.

This is compounded by how automatic updates function as the delivery mechanism for the compromise. Once a user installs an extension and grants it permissions, updates are typically applied without renewed scrutiny. Since the extension is already trusted and the update is assumed to be a continuation of the same, previously reviewed behavior. That assumption is precisely what this campaign relies on, since the update itself is the point at which trust and actual behavior diverge.

The underlying breakdown is the absence of a trust decision that re-evaluates behavior at every update, rather than extending trust indefinitely from an extension’s initial review and accumulated history. Ownership itself can also change hands entirely, meaning the entity a user or organization implicitly trusted when installing an extension may no longer be the entity controlling it later. As long as installation history and past behavior are treated as sufficient going forward, an attacker who can wait, acquire, or preserve that history inherits the trust it built.

the regulatory and business exposure

  • Credential and cryptocurrency wallet theft carried out through extensions with a genuine history of safe, advertised functionality.
  • Malicious behavior delivered through automatic updates, a channel typically exempt from renewed scrutiny.
  • Extension ownership transferred to a new party without resetting the trust a prior owner had earned.

what your auditor will ask

  • How do you validate what an extension update does, independent of the extension’s prior clean history?
  • What controls detect a change in ownership or control of an extension already installed across your organization?
  • How do you account for malicious behavior introduced only after an extension has accumulated a genuine user base?
  • What evidence do you maintain that extension behavior was assessed at each update, not only at initial installation?
  • How do you verify that automatic update channels are not treated as inherently trusted simply because the original extension was reviewed?

A consistent signal is the disconnect between an extension’s accumulated history and what it does at the moment an update actually runs. A genuine track record of safe behavior says nothing about who controls that extension now or what its next update will do

zero trust for code value

Zero Trust for Code introduces a trust decision at the point an extension actually executes, evaluating its behavior at every update rather than extending trust indefinitely based on installation history or past behavior. This means an extension earns permission to run based on what its current version does, regardless of how long it has operated safely or who originally published it.

This directly addresses the governance weakness exposed by this campaign: the assumption that an extension’s accumulated history and prior legitimate functionality remain valid indicators of safety after ownership changes or an update is pushed. By requiring a pre-execution trust decision independent of history, organizations can evaluate what an update actually does even when the extension delivering it has behaved correctly for a substantial period beforehand.

The result is a governance model where trust is re-established at every execution rather than inherited from the past. This closes the space this campaign relied on when it built genuine history specifically to spend it later.

governance action brief

  • Establish governance controls that evaluate extension behavior independently of installation history or prior clean performance.
  • Require a pre-execution trust decision for extension updates, not only for initial installation.
  • Treat a change in extension ownership or publisher identity as requiring renewed scrutiny, not continuity of prior trust.
  • Monitor for extensions establishing outbound connections to infrastructure unrelated to their advertised function.
  • Maintain a record of extension behavior evaluated at each update, separate from the extension’s accumulated history.

 

sources

Analysis based on original research from Socket (Karlo Zanki) on the Superior Chrome and Edge extension campaign, with reporting from The Hacker News and BleepingComputer and
CodeHunter Labs

Download the PDF. 

CodeHunter Behavioral Risk Brief cover for the arrayref Rust crate attack, August 2026

Behavioral Risk Brief: Rust Crate

/in /by

The Claim

Governance frameworks that treat maintainer history and familiar-looking dependency names as sufficient trust signals create systemic risk when both can be manufactured or compromised.
Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a build script actually does, rather than trusting it based on reputation alone.

The Incident

Attackers compromised the maintainer account behind a widely used Rust crate and used it to add a first-ever dependency to the project. That new dependency was a ‘typosquatted’ package
designed to closely resemble the name, author metadata, and versioning, of a separate, extremely well-known and trusted crate. The attackers published the ‘typosquatted’ package
under a fake account impersonating that trusted crate’s real author. Its initial release was clean, functioning code, establishing a normal-looking publishing history before a later update added a
build script that executed automatically during compilation. That script assembled a command-and-control address from encoded fragments, downloaded a platform-specific payload, and executed it. All before allowing the build to complete normally, so nothing appeared out of place.

The Governance Failure

The governance failure is not that a popular crate was compromised, but that trust in the ecosystem depended on two signals that neither require nor guarantee anything about actual behavior: a maintainer account’s history, and a dependency’s resemblance to something already well established. The compromised crate’s usual clean history said nothing about the account controlling it today. The typosquatted dependency’s name, author metadata, and version numbering were deliberately built to mirror a genuinely trusted package, without any of the scrutiny that trusted package had actually earned over time.

This is compounded by how the malicious behavior was staged to avoid drawing attention at the moment it mattered most. The typosquatted package’s first release contained no malicious code at all, existing solely to establish a normal publishing history so it would not appear as a suspicious. A brand-new dependency was later added to the compromised crate. Any review conducted at that point would have found an established account adding a dependency that itself had an established history.

The underlying breakdown is the absence of a trust decision that evaluates what a build script does at the moment a project actually compiles, independent of maintainer reputation or how convincingly a dependency identity was constructed. A build process is typically treated as a routine, trusted step. This incident shows that trust extending automatically to whatever a build script runs, without a separate evaluation of that behavior, is exactly the assumption a staged, patient compromise is built to exploit.

The Regulatory and Business Exposure

  • Credential and environment variable theft carried out automatically during a routine, build process.
  • Trust created through a newly created dependency deliberately designed to resemble an established, widely trusted package.
  • Malicious behavior staged behind an initial clean release, defeating traditional reviews.

What Your Auditors Will Ask

  • How do you validate what a build script does at compile time, independent of the maintainer account’s history?
  • How do you evaluate a new dependency’s actual behavior rather than its resemblance to an already-trusted package?
  • What controls detect a first-time dependency added to a project with an otherwise long, stable history?
  • How do you account for malicious behavior introduced only after a package has established a clean publishing record?
  • What evidence do you maintain that build-time execution was assessed directly, rather than inferred from account or dependency reputation?

A consistent signal is the disconnect between reputation and actual behavior. Maintainer history and a trusted-looking dependency can both be manufactured, and neither confirms what executes during a build

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a build script actually executes, evaluating its behavior directly rather than relying on maintainer account history or a dependency resemblance to an established package. This means a build process is assessed on what it does when it runs, regardless of how long the account behind it has existed or how familiar a new dependency name appears.

This directly addresses the governance weakness exposed by this campaign: the assumption that an established account and a plausible-looking dependency are evidence of safety. By requiring a pre-execution trust decision independent of reputation, organizations can evaluate what a build script does even when everything surrounding it, the account, the dependency’s identity, and its publishing history, was deliberately constructed to appear trustworthy.

The result is a governance model where build-time execution earns trust on its own behavior, thus closing the space this campaign relied on when it patiently staged reputation on both sides of the compromise before ever executing anything malicious.

Governance Action Brief

• Establish governance controls that evaluate build script behavior independently of maintainer account history.
• Require a pre-execution trust decision for any new dependency added to an established project, regardless of that dependency’s own apparent history.
• Treat close resemblance to a trusted package’s name or author identity as requiring additional scrutiny, not less.
• Monitor for build-time execution reaching external network addresses during routine compilation.
• Maintain a record of build script behavior evaluated at execution, separate from account or dependency reputation.

Sources

Analysis based on reporting from BleepingComputer on the arrayref Rust crate supply chain attack, CodeHunter Labs evaluation of governance gaps in build-time execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives.

Download the PDF

CodeHunter Behavioral Risk Brief cover for LiteLLM, August 2026

Behavioral Risk Brief: LiteLLM

/in /by

The Claim

Governance frameworks that treat a package’s presence on an official registry as a sufficient assumption of safety creates a systemic risk when publishing credentials upstream of that registry are compromised. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does once installed, independent of whether it arrived through an official, expected channel.

The Incident

Two versions of LiteLLM, an open-source AI gateway connecting applications to multiple model providers, were compromised and briefly live on PyPI. Version 1.82.8 included a file that Python automatically processes at interpreter startup, meaning it executed whenever a Python process started in that environment, regardless if anyone had explicitly imported LiteLLM at all. The compromised releases collected environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords, encrypting the data and sending it to an attacker-controlled domain unrelated to the project. How the malicious releases reached PyPI is disputed among investigators, variously described as a poisoned build process, a direct upload that bypassed the project’s official CI/CD workflow, or the use of a publishing token stolen through a separate, related compromise.

The Governance Failure

The governance failure is not that a popular open-source package was compromised, but that the mechanism delivering the malicious payload required no explicit action from anyone who installed it. A file that executes automatically at Python’s interpreter startup runs regardless of whether LiteLLM was ever imported, called, or knowingly used, which means the standard question a security team would ask, being “Do we use this package?”, is the wrong question entirely.

This is compounded by how the package could reach an environment in the first place. The advisory underlying this incident notes that an unpinned transitive dependency, potentially pulled in by an agent framework or orchestration tool a team never directly selected, could deliver the compromised package without anyone making a conscious decision to trust it. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it at all.

The underlying breakdown is the absence of a trust decision that accounts for automatic execution and unpinned transitive dependencies together. Investigators still dispute exactly how the malicious releases reached PyPI, and that dispute does not change what happened next: an artifact executed on arrival, independent of import, independent of direct selection, and independent of which explanation for its origin turns out to be correct.

The Regulatory and Business Exposure

  • Credential and secret exposure across cloud, SSH, Kubernetes, and database access on any host where the package executed.
  • Delivery through unpinned transitive dependencies, exposing organizations that never selected the compromised package.
  • Disputed root cause among investigators, leaving the actual point of trust failure unresolved even after disclosure.

What Your Auditors Will Ask

  • How do you account for packages that execute automatically at interpreter or runtime startup, independent of explicit use?
  • How do you validate the behavior of transitive dependencies your teams never directly selected?
  • What evidence do you maintain of package behavior when the root cause of a compromise is disputed among investigators?
  • How do you determine which of your environments installed a compromised package before it was identified? •
  • What controls detect execution that occurs before any explicit import or invocation takes place?

A consistent signal is the disconnect between whether a team believes it uses a package and whether that package is actually present and executing somewhere in its environment. The two are not the same question, and only one of them determines exposure.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package actually executes, evaluating its behavior directly rather than depending on whether it arrived through an official registry or a trusted publishing channel. This means execution is assessed on its own terms, independent of registry status and independent of whether an explicit import or invocation ever occurred.

This directly addresses the governance weakness exposed by the LiteLLM compromise: the assumption that knowing whether a team uses a package is the same as knowing whether that package is present and executing in its environment. By requiring a pre-execution trust decision that accounts for automatic execution and transitive delivery alike, organizations can evaluate behavior regardless of how an artifact arrived or whether anyone chose it directly.

The result is a governance model where trust does not depend on resolving disputed questions about origin, thus closing the space this incident relied on when investigators themselves could not agree on how the compromise occurred.

Governance Action Brief

  • Establish governance controls that evaluate package behavior independent of registry status or publishing channel.
  • Require a pre-execution trust decision for code that executes automatically at interpreter or runtime startup.
  • Treat transitive dependencies with the same scrutiny applied to packages a project directly selects.
  • Monitor for package presence and execution separately from whether a team believes it uses that package.
  • Maintain a record of execution evaluated at runtime, independent of unresolved questions about how an artifact arrived.

Sources

Analysis based on reporting from The Hacker News (August 12, 2026) on the malicious LiteLLM PyPI releases, CodeHunter Labs evaluation of governance gaps in automatic-execution and transitive-dependency trust, and alignment with NIST 800-53 and NIST SSDF integrity control.

Download the PDF.

CodeHunter Behavioral Risk Brief cover for WEL1DROPPER, August 2026

Behavioral Risk Brief: WEL1DROPPER

/in /by

The Claim

Governance frameworks that rely on manual code review to catch malicious packages create systemic risk when an artifact is deliberately built to survive that review. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does when invoked, rather than solely depending on a reviewer’s judgment of what the code appears to contain.

The Incident

Researchers identified nearly 800 malicious npm packages, published under AI-generated or typosquatted names, that deliver a downloader called WEL1DROPPER. Unlike prior campaigns that trigger automatically through install-time lifecycle hooks, these packages instruct developers in their documentation to manually load them with “require()”, meaning execution depends on a developer following the package’s own stated usage. Once invoked, the downloader identifies the host operating system and processor architecture and retrieves a matching payload from a set of cloud-hosted endpoints, falling back to DNS-based delivery if the primary method fails. The packages also include a file resembling a legitimate telemetry SDK that the actual entry point never imports, existing only to appear as ordinary analytics code during a quick manual review while the real downloader logic sits elsewhere in the package.

The Governance Failure

The governance failure is not that malicious packages reached the registry, but that trust in these packages depended on a developer’s manual judgment of what the code was doing, and a review process this campaign was specifically built to defeat. A reviewer scanning the package for anything alarming would encounter a file that looks exactly like routine telemetry code, while the actual downloader sits elsewhere, unexamined because nothing drew attention to it.

This is compounded by how execution itself was moved outside the reach of most existing controls. Many organizations have adapted to lifecycle-hook attacks by restricting install scripts, an increasingly common solution. This campaign requires no install hook at all, it activates only when a developer follows the package’s documented instructions and calls “require()” themselves. A control built around blocking automatic execution has nothing to intervene against here, because the execution was never automatic in the first place.

The main issue is the absence of a trust decision that evaluates what a package does at the moment it runs, independent of whether a human reviewer found anything suspicious beforehand. A decoy file designed to look ordinary succeeds precisely because human review depends on something appearing wrong to the reviewer. As long as trust is granted based on what a package appears to contain rather than what it does when executed, an artifact engineered to look uninteresting defeats the control by design.

The Regulatory and Business Exposure

  • Cross-platform compromise of developer machines through a payload matched to the host operating system and architecture.
  • Manual code review defeated by a decoy file specifically designed to appear as ordinary, non-suspicious functionality.
  • Reliance on install-script restrictions as a mitigation, a control this campaign was built to operate entirely outside of.

What Your Auditors Will Ask

  • How do you validate what a package does when explicitly invoked, not only what it does automatically at install?
  • What controls detect a decoy file included specifically to pass a manual code review?
  • How do you account for malicious packages that require no install hook and no automated trigger at all?
  • How do you verify that a developer following documented usage instructions is not executing unreviewed, unauthorized behavior?
  • What evidence do you maintain that a package’s behavior was evaluated at the point it runs, independent of manual review outcomes?

The disconnect between what a manual review is capable of catching and what an artifact is engineered to hide from it. A package built specifically to look ordinary upon review says nothing about what it does once a developer follows its instructions.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package is actually invoked, evaluating its behavior directly rather than depending on whether a manual review found anything suspicious beforehand. This means a package earns permission to run based on what it does when called, regardless of how ordinary or unremarkable its code appeared during review.

This directly addresses the governance weakness exposed by the WEL1DROPPER campaign: the assumption that human review is a reliable checkpoint against packages specifically engineered to defeat it. By requiring a pre-execution trust decision independent of review outcomes, organizations can evaluate what a “require()” call actually trigger, even when the surrounding code was built to look ordinary to a reviewer.

The result is a governance model where execution is assessed on its own behavior rather than on a reviewer’s judgment. Thus, closing the space this campaign relied on when it engineered its way around manual scrutiny entirely.

Governance Action Brief

  • Establish governance controls that evaluate package behavior at the point of invocation, independent of manual review outcomes.
  • Require a pre-execution trust decision for packages triggered through explicit developer action, not only automatic lifecycle hooks.
  • Treat install-script restrictions as one control among several, not sufficient against non-automatic execution paths.
  • Monitor for decoy or unused files included in packages solely to appear ordinary during code review.
  • Maintain a record of package behavior evaluated at execution, separate from any manual review conducted beforehand.

Sources

Analysis based on reporting from The Hacker News (August 7, 2026) on the WEL1DROPPER npm campaign, CodeHunter Labs evaluation of governance gaps in review-evasive execution trust.

Download the PDF.

CodeHunter Behavioral Risk Brief cover for Arch AUR Repository, August 2026

Behavioral Risk Brief: Arch AUR Repository

/in /by

The Claim

Governance frameworks that treat package adoption as a routine maintenance mechanism create systemic risk when that same mechanism can transfer control of a trusted package name to an attacker. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does after any change in control, rather than extending trust indefinitely once a package has been established.

The Incident

Attackers began adopting orphaned packages in the Arch User Repository and pushing malicious follow-up commits. The campaign began with the package “openconnect-sso” and expanded to over 120 confirmed malicious packages, including established tools such as boringssl-git, icloudpd, and windscribe-cli-v2-bin. Arch Linux first used disabled package adoption on July 30 to slow the takeovers, then disabled all AUR pushes entirely on August 1 after the activity continued through newly created accounts. The payload is a Rust-based infostealer that exfiltrates browser data, credentials, and cryptocurrency wallets, and spreads further by harvesting SSH access from infected machines. This is the third wave to hit the repository this year, involving over 400 malicious packages and eventually reaching 1,500 by the time the cleanup was complete.

The Governance Failure

The governance failure is not that attackers targeted an open community-maintained repository, but that the mechanism designed to keep abandoned packages alive carries no verification of what that new maintainer intends to do with the trust they are inheriting. A package’s history, download count, and prior clean commits all belong to a previous maintainer whose relationship to the package has already ended.

This is compounded by how naturally this activity blends into the platform’s own design. Adopting an orphaned package and pushing an update is exactly what the system was built to allow, which means the attack does not require any exploit or credential theft, only patience in waiting for packages to go unmaintained and a willingness to register new accounts once old ones are banned. An organization scanning package contents for known malware signatures would find nothing to flag until after a malicious update had already landed.

The underlying breakdown is the absence of a trust decision at the point of when maintainership actually changes hands. This is now the third such wave in a single year, and each occurrence has been addressed by suspending the adoption mechanism itself rather than by verifying what any given maintainer transition introduces. As long as trust transfers automatically with the act of adoption, disabling the feature is the only lever available once an attack is already underway.

The Regulatory and Business Exposure

  • Credential, browser data, and cryptocurrency theft delivered through packages with established, previously trusted histories.
  • Lateral spread across networks through harvested SSH access on infected developer machines.
  • Repeated incidents addressed only by suspending a core platform feature.

What Your Auditors Will Ask

  • How do you validate a package’s behavior after a change in maintainer or ownership, independent of its prior history?
  • What controls detect malicious activity introduced through a legitimate platform mechanism rather than an exploit?
  • How do you account for risk in third-party or community repositories your developers use outside sanctioned channels?
  • What evidence do you maintain that a package was evaluated again after control of it changed hands?
  • How do you respond when a repeated pattern of compromise is addressed by disabling a feature rather than verifying trust directly?

A consistent signal is the disconnect between a package’s accumulated history and what its current maintainer is doing with it. A clean record under a previous owner says nothing about the version published by whoever holds that access now.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package is about to execute, evaluating what it does independent of its maintainership history or how long it has existed in a repository. This means a package earns permission to run based on its current behavior, not on trust accumulated under a maintainer who may no longer control it.

This directly addresses the governance weakness exposed by the AUR campaign: the assumption that a package’s established history remains meaningful after maintainership changes hands. By requiring a pre- xecution trust decision independent of ownership history, organizations can evaluate what a newly adopted or updated package actually does, rather than relying on a platform feature being disabled as the only available response.

The result is a governance model where trust is re-established every time a package changes hands or executes, closing the space a repeated attack pattern has relied on across three separate incidents this year.

Governance Action Brief

  • Establish governance controls that evaluate package behavior independently of accumulated history or prior maintainer reputation.
  • Require a pre-execution trust decision whenever a package’s maintainer or ownership changes.
  • Treat community-maintained repositories as requiring the same execution-level scrutiny as official package sources.
  • Monitor for SSH-based lateral spread originating from developer machines running third-party packages.
  • Maintain a record of package trust decisions evaluated at each maintainership transition, not only at initial adoption.

Sources

Analysis based on reporting from BleepingComputer and Cybernews on the Arch Linux AUR supply chain campaign, CodeHunter Labs evaluation of governance gaps in maintainership-transfer execution trust, and alignment with NIST 800-53 and NIST SSDF.

Download the PDF

CodeHunter Behavioral Risk Brief cover for Joyfill npm Packages, July 2026

Behavioral Risk Brief: Joyfill npm Packages

/in /by

The Claim

Governance frameworks that treat install-script restrictions as sufficient protection create systemic risk when malicious code is embedded to execute at import rather than install. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does when it runs, regardless of which lifecycle stage triggers that behavior.

The Incident

Malicious beta releases of two legitimate npm packages, “@joyfill/components” and “@joyfill/layouts”, were published to the registry. Rather than relying on a postinstall or preinstall hook, the implant was embedded directly into the compiled distribution bundle. This means it executes the moment the module is imported into a project, not when it is installed. This bypasses the standard defensive flag that disables install scripts since that protection has no effect on code that runs at import time. Once active, the implant resolves its command-and-control address by reading a blockchain transaction, first on Tron and then pivoting to Binance Smart Chain, before deploying a remote access trojan and a separate credential stealer targeting browser data, cryptocurrency wallets, and developer tokens.

The Governance Failure

The governance failure is not that a trusted package was compromised, but that the defensive posture many organizations rely on assumes malicious behavior arrives through a specific, well-known lifecycle stage. Disabling install scripts has become a standard mitigation precisely because so many prior campaigns relied on that mechanism. This implant was built around the assumption that organizations would rely on exactly that control and then move to a stage that the control does not cover.

This is compounded by the choice to resolve command infrastructure through blockchain transactions rather than a fixed address. A hardcoded command-and-control server can be identified, blocklisted, and starved of new instructions once discovered. A transaction-based lookup gives the attacker a way to redirect the payload at any time without publishing a new package version, meaning a security team’s confidence in having identified and blocked the infrastructure may already be outdated the moment it is recorded.

The underlying breakdown is the absence of a trust decision that evaluates what a package does regardless of which lifecycle stage triggers it. Any control anchored to a single execution point, install, import, or otherwise, leaves every other point unexamined, and this campaign demonstrates that attackers will simply relocate to whichever stage current defenses do not reach.

The Regulatory and Business Exposure

  • Bypass of a widely deployed install-script mitigation through code that executes only at import.
  • Command-and-control infrastructure that can be silently redirected without any new package version or registry activity.
  • Exposure of developer credentials, tokens, and cryptocurrency wallets across affected workstations.

What Your Auditors Will Ask

  • How do you validate package behavior at every lifecycle stage, not only at install?
  • What controls would detect an implant that activates specifically because a package is imported?
  • How do you account for command-and-control infrastructure that can change without any new software release?
  • What evidence do you maintain that a package’s behavior was evaluated after import, not only at publication?
  • How do you verify that mitigations built around one execution stage are not simply displacing risk to another?

A consistent signal is the disconnect between where a mitigation was built to work and where an attacker chooses to operate. A control anchored to one execution stage says nothing about what happens at the next one.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package actually executes, evaluating its behavior regardless of whether that execution happens at install, at import, or at any other lifecycle stage. This means a package earns permission to run based on what it does in the moment, not based on which stage a defensive control happens to cover.

This directly addresses the governance weakness exposed by the Joyfill compromise: the assumption that disabling install scripts closes the relevant risk. By requiring a pre-execution trust decision independent of lifecycle stage, organizations can evaluate import-time behavior with the same rigor applied to installation, removing the incentive to simply relocate a payload to an uncovered stage.

The result is a governance model where every execution point carries the same trust requirement, closing the space attackers rely on when one stage is defended and another is not.

Governance Action Brief

  • Establish governance controls that evaluate package behavior at mport, not only at installation.
  • Require a pre-execution trust decision independent of which lifecycle stage triggers execution.
  • Treat install-script restrictions as one control among several, not a complete mitigation on their own.
  • Monitor for command-and-control resolution methods, including blockchain-based lookups, that evade static infrastructure blocking.
  • Maintain a record of package behavior evaluated per execution stage rather than assumed covered by a single control.

Sources

Analysis based on The Hacker News and StepSecurity (July 28-29, 2026) on the Joyfill npm supply chain compromise, CodeHunter Labs evaluation of governance gaps in lifecycle-stage execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives.

Download the PDF. 

CodeHunter Behavioral Risk Brief cover for Notepad Plus Plus, July 2026

Behavioral Risk Brief: Notepad ++

/in /by

The Claim

Governance frameworks that treat a legitimate, signed application as inherently safe create systemic risk when that application can be paired with malicious components it will execute automatically. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what an application actually loads and runs, rather than extending trust to everything bundled alongside a recognized binary.

The Incident

CERT-UA disclosed a campaign attributed to the threat cluster UAC-0099 that delivers a fake Notepad++ plugin to compromise Windows systems. A phishing email leads victims through a shortened link to a ZIP archive containing a VBScript disguised as a PDF, which displays a decoy document while silently retrieving a second archive. That archive contains a complete and legitimate copy of Notepad++, a malicious DLL named NppExport.dll, and supporting tools. The script launches the genuine Notepad++ binary, which automatically loads the malicious DLL as a plugin. That DLL unpacks additional components and establishes persistence through a scheduled task running every three minutes, ultimately delivering a loader called “BURNYBEAR” and a modified payload tracked as “MATCHBOIL.V2”.

The Governance Failure

The governance failure is not that Notepad++ was impersonated, but that the actual application delivered to the victim is the real legitimate Notepad++ binary that is unmodified and fully functional. Any control built around verifying the identity or signature of the executable being launched would find nothing to object to. The compromise lives entirely in what that legitimate binary is permitted to load and execute once it runs and a layer signature verification is never reached.

This is compounded by how plugin architectures function. A trusted application loading a DLL from its own plugins directory is completely ordinary behavior. It is indistinguishable at launch from any legitimate extension a user might install. Trust granted to the parent executable extends implicitly to whatever it loads next, without a separate decision evaluating what that plugin does once it holds the parent process’s privileges.

The underlying breakdown is the absence of a trust decision at the moment a loaded component begins executing, as distinct from when the parent application launches. This pattern is not unique to Notepad++. Any application with a plugin or module-loading architecture creates the same exposure, and as long as trust is assigned only to the parent process, this technique remains available regardless of which application it is built around.

The Regulatory and Business Exposure

  • Persistent access established through a scheduled task disguised as routine application behavior.
  • Resource exhaustion triggered as a fallback if the malicious loader runs outside expected conditions.
  • Reliance on signature checks that verify the parent application while loaded plugins go unexamined.

What Your Auditors Will Ask

  • How do you validate the behavior of plugins or modules loaded by applications your organization already trusts?
  • How do you distinguish a legitimate binary from the components it is permitted to load once running?
  • What controls detect a scheduled task established through an otherwise trusted application?
  • How do you verify that application allowlisting accounts for what a binary executes after launch?
  • What evidence do you maintain that a loaded plugin’s behavior was evaluated independently of the parent application’s trust status?

A consistent signal is the disconnect between the executable that was verified and the code that actually ran. A legitimate binary passing every identity check says nothing about what it will load once permitted to execute.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a loaded component is about to execute, evaluating what that plugin or module will do independently of whether the parent application is legitimate or already allowlisted. A plugin is assessed on its own behavior, not granted the trust status of the executable that loads it.

This directly addresses the governance weakness exposed by UAC-0099: the assumption that verifying a parent application is sufficient because everything it loads inherits that same trust. By requiring a pre-execution decision for loaded components specifically, organizations can stop a
malicious plugin even when the application launching it is entirely legitimate.

The result is a governance model where trust is evaluated at every layer, the parent binary and everything it loads, rather than assumed to flow automatically from one to the other.

Governance Action Brief

  • Establish governance controls that evaluate plugin behavior independently of the parent application’s trust status.
  • Require a pre-execution trust decision for any component loaded dynamically by an approved application.
  • Enforce execution policies covering plugin directories for widely used developer and productivity applications.
  • Monitor for scheduled tasks or persistence mechanisms established through processes descending from trusted applications.
  • Maintain a record of loaded components evaluated separately from the parent binary’s approval.

Sources

Analysis based on reporting from The Hacker News (July 24, 2026) on CERT-UA’s disclosure of the UAC-0099 campaign, CodeHunter Labs evaluation of governance gaps in plugin execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives.

Download the PDF. 

CodeHunter Behavioral Risk Brief cover for SleeperGem, July 2026

Behavioral Risk Brief: SleeperGem

/in /by

The Claim

Governance frameworks that treat package name recognition and maintainer history as ongoing proof of safety create systemic risk when a compromised artifact can behave differently
depending on where it executes. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package will do in a specific environment, rather than relying

The Incident

Researchers identified malicious versions of three RubyGems packages published to RubyGems.org in a campaign named SleeperGem. One package, “git_credential_manager”, impersonated Microsoft’s official Git Credential Manager, while the other two were Dendreo and a fastlane plugin. Dendreo and the fastlane plugin were legitimate but dormant packages last updated in 2019 and 2020 before malicious updates were pushed from reactivated maintainer accounts. Each release acted as a loader that checked for roughly 30 CI-related environment variables associated with platforms such as GitHub Actions, GitLab, CircleCI, Jenkins, and Vercel. If any were detected, the payload exited; otherwise, it downloaded a second-stage payload from an attacker-controlled host and installed a persistent native daemon on the developer’s machine.

The Governance Failure

The governance failure is not that malicious versions reached the registry, but that the trust in these packages was based on signals that assumed behavior stays constant once established: a recognizable name, a maintainer with account history, and in two cases, years of clean, dormant existence. None of those signals accounted for what a specific installed version would actually do,
and none of them accounted for the possibility that the artifact itself would behave differently depending on the environment it reached.

This is compounded by how the malware was built to defeat exactly the kind of monitoring most organizations rely on. By checking for CI environment variables before acting, the payload was designed to pass cleanly through any build system where automated scanning or sandboxing might catch it and only reveal its actual behavior on a developer’s own machine, typically where that scrutiny is far lighter. An organization that validated this package inside a CI pipeline and considered that it was sufficient would have observed an artifact that did nothing at all.

The underlying breakdown is the absence of a trust decision that accounts for where and how an artifact executes, not just whether it was scanned somewhere at some point. Dependency inheritance made this worse, since developers who never made an explicit decision to install “git_credential_manager” were still exposed to it through other packages that quietly pulled it in. Trust extended once, at the point a dependency was declared, without any mechanism to re-evaluate what that dependency introduced later.

The Regulatory and Business Exposure

  • Persistent, unauthorized access to developer machines through a native daemon installed outside CI-monitored environments.
  • Compromise inherited through dependency relationships, exposing organizations that never directly installed the malicious package.
  • Reliance on maintainer history and package dormancy as safety signals, providing no evidence of current version behavior.

What Your Auditors Will Ask

  • How do you validate what a package will do differently across CI environments versus developer workstations?
  • How do you account for risk introduced through transitive dependencies your teams never directly selected?
  • What controls detect a long-dormant package receiving updates after years of inactivity?
  • How do you verify that a package’s behavior in a monitored build environment reflects its behavior everywhere else it runs?
  • What evidence do you maintain that execution was evaluated on developer machines specifically?

A consistent signal is the disconnect between where an organization’s monitoring is strongest and where an artifact actually executes. Confidence built entirely on CI-level scrutiny leaves developer machines, where this payload was designed to activate unexamined.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point where a package is about to execute, evaluating what it will do in that specific environment rather than relying on a name, a maintainer’s history, or a scan performed somewhere else entirely. This means a package is assessed for what it does on the machine where it actually runs, whether that machine is a CI
runner or a developer’s own workstation.

This directly addresses the governance weakness exposed by SleeperGem: the assumption that an artifact behaves the same way everywhere, and that reputation signals such as account age or
years of dormancy are evidence of safety rather than simply an absence of prior scrutiny. By requiring a pre-execution trust decision independent of environment, organizations can evaluate
what a package attempts to do on a developer machine even when that same package does nothing at all inside a monitored CI pipeline.

The result is a governance model where trust is assessed at every point of execution rather than inherited once from a dependency declaration or a clean publishing history. This closes the
distance between where an organization is confident and where an artifact is actually running.

Governance Action Brief

  • Establish governance controls that evaluate package behavior separately for CI environments and developer workstations.
  • Require a pre-execution trust decision for transitive dependencies, not only for packages directly declared by a project.
  • Enforce execution policies on developer machines with the same rigor currently applied to CI/CD pipelines.
  • Treat maintainer account age, package dormancy, and prior clean history as insufficient evidence of current version safety.
  • Maintain a record of what a package was permitted to execute, evaluated per environment rather than assumed uniform across all of them.

Download the PDF

Sources

Analysis based on reporting from The Hacker News (July 20, 2026) and CodeHunter Labs evaluation of governance gaps in environment-dependent execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives.

CodeHunter Behavioral Risk Brief cover for Disguised npm Packages, July 2026

Behavioral Risk Brief: Disguised npm Packages

/in /by

The Claim

Governance frameworks that scan for malicious behavior only at install time create systemic risk when registries are used as free hosting for artifacts that never touch a build pipeline. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what an artifact does when it runs, regardless of whether it runs during installation, in a browser, or anywhere else code is permitted to execute.

The Incident

Researchers at JFrog identified 141 npm packages in May, later growing to 148 by July, published under names branded as student tools to bypass school web filters. The packages carried no install scripts or lifecycle hooks and were never meant to be imported into a project, instead hosting a client-side proxy web app that visiting browsers loaded directly, using npm purely as a content delivery mechanism. Underneath the proxy sat two hidden modules: one fetched remote JavaScript from a mutable, unpinned GitHub branch and executed it with the site’s full origin privileges, while the other opened up to 1,024 WebSocket connections per browser tab targeting a proxy protocol server, exhausting its resources rather than the visiting student’s own device. A second wave of packages published in July restored the adware
functionality while leaving the remote loader in place, still pointed at the same branch.

The Governance Failure

The governance failure is not that malicious packages reached the registry, but that the entire model of software trust assumed a package’s risk lives at install time. Dependency scanners, install-time sandboxes, and lifecycle hook monitoring are built around a single execution surface: what happens when a package is pulled into a project and run through “npm install”. These packages never triggered that surface at all, because they were never designed to be installed as dependencies in the first place.

This exposes a second, more persistent gap. The remaining packages still load a script from a mutable branch with no integrity verification. Whoever controls that branch can change what every visiting browser executes at any time, without publishing a new package version, without triggering a new npm scan, and without leaving any trace in a lockfile or manifest that a security team would think to review. The registry’s admission process, and any monitoring built around package versions, has no visibility into a artifact that can be silently re-armed downstream of the point where every existing control is watching.

The underlying breakdown is the assumption that an artifact’s trustworthiness is fixed at the moment it is scanned and published. Trust granted to a package version does not account for content the package points to but does not contain, and it does not account for a second execution surface, the browser, that operates entirely outside the tooling built to govern developer environments. As long as an artifact can behave one way during review and a different way once deployed, scanning at any single point in time cannot be the control that decides what is allowed to run.

This gap keeps showing up in different forms across different ecosystems. For a broader look at why origin-based trust controls keep falling short, see Taking Down the Botnet Doesn’t Answer the Harder Question.

The Regulatory and Business Exposure

  • Execution of unreviewed, remotely mutable code within enterprise or school network browser sessions.
  • Resource exhaustion and denial-of-service impact carried out through end-user browsers rather than compromised infrastructure.
  • Continued exposure to artifacts that can be altered after publication without triggering any package-level review or re-scan.

What Your Auditors Will Ask

  • How do you validate the behavior of artifacts that execute in a browser rather than at install time?
  • How do you account for registries or repositories being used to host content outside their intended package format?
  • What controls detect a referenced script changing after the artifact that points to it was last reviewed
  • How do you determine whether an approved artifact can still alter its own behavior post-publication
  • What evidence do you maintain that execution behavior was evaluated at the point it runs, not only at the point it was published?

A consistent signal is the disconnect between where an organization’s controls are looking and where an artifact actually executes. Trust concentrated entirely at install time leaves every other execution surface unexamined.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point where an artifact is about to execute, regardless of whether that execution happens during installation, inside a browser, or through any other surface a registry or repository makes available. This means a package is assessed on what it does when it runs, not on whether it matches the narrow category of behavior a scanner was built to catch.

This directly addresses the governance weakness exposed by the student proxy campaign: the assumption that install-time review is sufficient because it is the only execution surface most controls were designed to watch. By requiring a pre-execution trust decision independent of where or how code runs, organizations can evaluate a referenced script’s behavior at the moment it executes, even when that script can change after the artifact pointing to it was last reviewed.

The result is a governance model where execution is evaluated wherever it occurs, closing the distance between what was published and what actually runs on any given day, rather than assuming the two remain the same after the fact.

Governance Action Brief

  • Establish governance controls that evaluate artifact behavior at every execution surface, not only at install time.
  • Require a pre-execution trust decision for any code an artifact references or loads dynamically, including content served from mutable or unpinned sources.
  • Enforce execution policies for browser-based sessions on managed networks, not solely for developer workstations and CI/CD environments.
  • Monitor for registries or repositories being used as hosting infrastructure for artifacts outside their intended package format.
  • Maintain a record of what an artifact was permitted to execute, independent of whether its underlying content has since changed.

Download the PDF

Sources

Analysis based on reporting from The Hacker News (July 14, 2026) and CodeHunter Labs evaluation of governance gaps in post-publication execution trust.

 

CodeHunter Behavioral Risk Brief cover for Ghostcommit, July 2026 (65 chars)

Behavioral Risk Brief: Ghostcommit

/in /by

The Claim

Governance frameworks that treat automated code review as sufficient validation create systemic risk when trust is granted based on what a scanner can see rather than what an artifact
will do once an agent acts on it. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a merged artifact actually does, not on whether it passed a review process
built to catch a narrower category of risk.

The Incident

A pull request attack shows how an AI-authored convention file can smuggle instructions past code review by hiding them inside an image. The technique, called Ghostcommit, embeds
exfiltration instructions as plain text inside a PNG referenced by an AGENTS.md file, the kind of file coding agents read automatically and treat as standing project policy. Because tools like
CodeRabbit exclude image files from review by default, and Cursor’s Bugbot does not process image files, the pull request merges without objection. Nothing happens at merge time. The
payload only activates later, when a developer asks the coding agent to complete an unrelated, routine task in a separate session. The agent reads the merged convention file, follows its
reference to the image, opens the repository’s .env file, and writes the contents into a new code constant disguised as a build value.

The Governance Failure

The governance failure is not that a review tool missed a malicious pull request, but that trust was granted to a merged artifact based on the narrow set of risks a reviewer was built to catch, rather than on what that artifact would do once an agent later acted on it. A pull request that passes review is treated as safe going forward, even though the review only evaluated text content and never assessed what would happen when a different tool, operating under different assumptions, executed instructions the artifact contained.

This is compounded by how convention files function inside agentic development workflows. Files like AGENTS.md are designed to be read automatically and treated as authoritative project policy, which means anything referenced from them inherits that same standing without a separate trust decision. An image cited as a build specification carries the same authority as an explicit line of code, despite never being evaluated as one.

The underlying breakdown is the absence of a trust decision at the moment an agent actually acts on repository content. Review at merge time answers whether a reviewer objected to what it could see. It does not answer whether an agent, executing days or weeks later under an entirely different toolchain, will trust and act on content the original review never evaluated in that context.

The Regulatory and Business Exposure

  • Exfiltration of credentials, API keys, and connection strings through routine agent activity unrelated to the original pull request.
  • Merge-time review certifying an artifact as safe without evaluating what an agent will later execute against it.
  • Inconsistent outcomes across coding tools and models, undermining any assumption that review status is a durable safety signal.

What Your Auditors Will Ask

  • How do you validate what an AI coding agent will do with a merged artifact, independent of whether that artifact passed code review?
  • How do you account for content types, such as images or binary files, that your review tooling does not evaluate?
  • What controls detect an agent reading and acting on repository content outside the task the developer actually requested?
  • How do you verify that review approval reflects an evaluation of execution behavior, not just visible text content?
  • What evidence do you maintain that a merged artifact’s behavior was assessed at the point an agent acts on it, not only at the point it was reviewed?

A consistent signal is the disconnect between what a review process was built to catch and what an artifact is later permitted to do. Passing review answers a narrower question than the one that determines actual risk.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point an agent is about to act on repository content, evaluating what that action will do against defined policy rather than relying on whether
the underlying artifact previously passed code review. This means an image, a configuration file, or any other referenced content is assessed on the behavior it produces when acted upon, not on
whether a reviewer built for a different purpose objected to it.

This directly addresses the governance weakness exposed by Ghostcommit: the assumption that merge-time review is a durable safety signal for actions an agent takes long after that review
occurred. By requiring a pre-execution trust decision, organizations can prevent an agent from exfiltrating credentials through a routine task, regardless of what a prior review process did or did
not evaluate.

The result is a governance model where an agent’s actions are evaluated against policy at the moment they occur, closing the distance between what was reviewed and what is later executed
rather than assuming the two remain aligned indefinitely.

Governance Action Brief

  • Establish governance controls that evaluate agent behavior at the point of execution, independent of prior code review outcomes.
  • Require a pre-execution trust decision for any action an agent takes based on repository content, including convention files and referenced media.
  • Enforce execution policies across coding agents and IDE tooling that read project files automatically as standing instructions.
  • Treat merge-time review as one input among several, not as a durable safety determination for future agent actions.
  • Maintain a record of what an agent was permitted to act on, even if that content was previously reviewed.

Download the PDF

Sources

Analysis based on reporting from BleepingComputer (July 11, 2026) on the Ghostcommit technique disclosed by the University of Missouri-Kansas City’s ASSET Research Group

CodeHunter Behavioral Risk Brief cover for AI Data Thieves, July 2026, for the regulated-enterprise CISO

Behavioral Risk Brief: AI Data Thieves

/in /by

The Claim

Governance frameworks that treat marketplace listing or basic scanning as sufficient validation create systemic risk when agentic systems execute functionality without independent behavioral verification. Zero Trust for Code addresses this by enforcing behavioral controls at execution, ensuring that what an AI skill or agent-based artifacts does is verified rather than assumed from where it was found.

The Incident

ESET’s H1 2026 Threat Report found that nearly 900,000 AI agent skills that were analyzed, more than 25,000 were flagged as suspicious and over 3,000 were confirmed malicious, with the malicious count growing from roughly 600 to over 3,000 in a three-month window. These skills carried capabilities including command execution, credential loading, code injection, and obfuscation, the same functions that support legitimate agent tasks. Researchers also found that some skills marketed as security scanners performed only superficial checks, giving operators a false sense of protection. Separately, the report documented a new technique called AI-fix, a variant of the ClickFix pattern that uses fake troubleshooting pages hosted on services associated with Anthropic, OpenAI, and Microsoft to convince users to run malicious commands, contributing to a 108 percent year over year rise in ClickFix detections overall.

The Governance Failure

The governance failure is not the existence of malicious skills, but the absence of controls that validate what a skill will do once an agent is permitted to invoke it. Organizations evaluating agentic AI tools often rely on marketplace presence, download counts, or a passed scan as indicators of safety. These signals confirm that a skill was reviewed once, not that its behavior remains within acceptable bounds every time it executes.

This challenge comes from how agent frameworks are built. Skills inherit the permissions of the agent that invokes them, and agents frequently operate with broad access to credentials, files, and external systems in order to complete tasks. A skill that behaves as documented during review can still execute commands, access credentials, or move data in ways no one explicitly authorized, because the framework does not distinguish between intended task execution and unauthorized action.

The underlying breakdown is the lack of enforceable policy governing what a skill is allowed to do at the moment it runs. Scanning at intake tells an organization what a skill contains. It does not tell them what the skill will attempt once it has the agent’s permissions and a live task in front of it.

As agent adoption accelerates, this distinction becomes the whole of the problem. An organization can document every skill it approved and still have no record of what those skills actually did once deployed. Trust assigned at intake cannot substitute for authorization enforced at execution.

This is a structural problem that extends well beyond agentic AI. For a deeper look at why the trust decision consistently happens at the wrong point in the execution lifecycle, see Why The Trust Decision Happens At The Wrong Moment.

The Regulatory and Business Exposure

  • Unauthorized data access and exfiltration through agent-executed skills.
  • Credential theft and malware execution inside agent workflows, bypassing controls built for software installs.
  • Social engineering exposure through AI-fix pages abusing trusted AI platform domains.

What Your Auditor Will Ask

  • How do you validate the behavior of an AI skill or plugin before an agent is permitted to invoke it?
  • How do you distinguish a skill that performs a genuine security check from one that only appears to?
  • What controls detect an agent executing commands, accessing credentials, or transferring data outside its intended task?
  • How do you prevent a fake troubleshooting or verification page from inducing a user or an agent into running unauthorized commands?
  • What evidence do you maintain that agent-executed skills were evaluated against policy before running, rather than reconstructed after an incident?

A consistent signal is the disconnect between marketplace listing and skill behavior. Skills that pass basic scanning continue to carry actions that were never evaluated against what is consider acceptable execution.

Zero Trust for Code Value

Zero Trust for Code introduces enforcement at the point where an AI skill or agent-executed artifact actually runs, ensuring that capabilities such as command execution, credential access, or code injection are evaluated against defined policy regardless of whether the skill passed a marketplace scan or carries a security label.

This directly addresses the governance weakness exposed by the growth in malicious AI skills: the assumption that a passed scan or marketplace presence indicates safe behavior going forward. By enforcing behavioral constraints at execution, organizations can prevent a skill from exfiltrating data, loading credentials, or executing unapproved commands even when nothing about it was flagged during initial review.

The result is a governance model where agent behavior is evaluated against policy every time it executes, not inherited from a one-time scan or platform trust, holding a skill’s actual execution to the same standard as its claimed function throughout its use.

Governance Action Brief

  • Establish governance controls that validate AI skill behavior independently of marketplace listing or scan status.
  • Require continuous verification of command execution, credential access, and data movement performed by agent-executed skills.
  • Enforce execution policies for AI agents, browser extensions, and automation tooling that consume third-party skills.
  • Monitor social engineering patterns, such as fake troubleshooting pages, that pressure users or agents into running unauthorized commands.
  • Treat agentic AI environments as high-value systems requiring behavioral enforcement at execution, not only at admission

Sources

Analysis based on Help Net Security reporting (July 8, 2026) on ESET’s H1 2026 Threat Report covering malicious AI skills and ClickFix variants, CodeHunter Labs evaluation of governance gaps in agentic AI execution and marketplace trust models

Download the PDF.