In brief: a cryptographically signed package can still be malicious if an attacker has compromised a legitimate build pipeline or its temporary identity. That means an AI agent must not be allowed to install software based on signature or provenance alone. The decision should be made before the install script runs and should separately verify the name, source, version, expected builder, package behavior, and environment permissions.
This material is intended for CTOs, engineering leaders, DevSecOps teams, and owners of AI coding agents. The scope includes npm, PyPI, and similar registries, CI/CD, and developer workstations. This article does not prove how common one technique is across all companies, does not replace investigation of a specific incident, and does not promise absolute supply chain protection.
Contents
- What happened in September 2026
- Why a signature is not the same as security
- How an AI agent changes the risk point
- What checks are needed before installation
- What exactly to verify in provenance
- The DOPUSK method
- How to configure allow, quarantine, and block modes
- How to run a pilot
- What metrics to collect
- What to do if an installation looks suspicious
- Limits of the evidence
- Frequently asked questions
- How AIrassvet helps embed dependency controls
- Conclusion
What happened in September 2026
On September 8, Google Threat Intelligence Group published AI Threat Tracker, based on Mandiant incident response data, group tracking, and Google platform defenses. The report describes UNC6780: since March 2026, the group has been attacking PyPI, npm, and Docker Hub, compromising developer accounts, and distributing trojanized packages and MCP server forks.
The trust-bypass mechanism is especially important. The DUSTMAKER malware extracted OIDC tokens from GitHub Actions runner memory and then published packages as a trusted publisher. According to GTIG, such versions received cryptographically valid SLSA Build 3 attestations and could pass an AI agent’s automated checks. The malware also hid commands in .claude/, .vscode/ and .cursor/, and it added prompt injection to JavaScript comments so that an LLM scanner would refuse to analyze the next code block.
The same report also shows a broader speed signal. A suspected financially motivated actor used an AI chat, a prompt, and a set of instructions to plan, build, and launch mass credential harvesting in under six hours . The framework handled scanning, error recovery, and IP rotation without manual intervention; later, the open C2 server displayed a dashboard for managing more than 23,800 collected secrets.
These numbers should not be turned into an average attack probability: GTIG does not disclose the full denominator of all investigations, and Google also sells security products. But the observation changes the engineering question. The important issue is not only “is the package signed,” but what trust boundary the signature covers and what can execute before the next check.
Why a signature is not the same as security
A signature, provenance, source approval, and behavioral safety answer different questions.
| Signal | What it confirms | What it does not confirm |
|---|---|---|
| hash | the received bytes match the expected ones | who created them and why |
| digital signature | the artifact is signed by a specific identity | that the identity was not compromised |
| build provenance | where, when, from what source, and with which builder the artifact was created | that the source and workflow were benign |
| source provenance and review | which source change process was followed | that runtime behavior is safe in your environment |
| sandbox analysis | what the package did in a test environment | that all behavioral branches were exercised |
| local policy | whether the package is acceptable for a specific project | that it is safe in general |
SLSA 1.2 defines provenance as verifiable information about where, when, and how a software artifact was produced. The Build Track increases trust in the build and its description, while the Source Track increases trust in the revision creation process. These are useful assurances, but the consumer still needs to know which builder, source, ref, parameters, and SLSA level to expect.
The OpenSSF analysis Mini Shai-Hulud: Where SLSA’s Boundaries Fall shows this boundary in a real incident. In May 2026, 84 artifacts across 42 packages @tanstack were compromised, and the spread affected more than 170 packages. The attestations were valid because the attacker obtained a legitimate OIDC token. They accurately recorded the observed build — the problem was inside the trusted pipeline.
Practical takeaway: provenance is proof of origin, not a certificate of good intentions. Even stricter builder isolation does not assess the meaning of the source code. The root of trust does not disappear; it moves into the build platform, source review rules, and consumer policy.
How an AI agent changes the risk point
A person usually sees the command pip install or a change to package.json before execution. An AI agent can read the README, choose a library, change the lockfile, and complete installation in a single cycle. If verification happens after the command, the install hook may already have accessed source code, environment variables, SSH keys, registry tokens, or cloud identity.
A prior study Understanding Security Risks of AI Agents’ Dependency Updates analyzed 117,062 dependency changes in pull requests across seven ecosystems. In the authors’ selected sample, agents chose known vulnerable versions more often than people did: 2.46% versus 1.64%; 36.8% of those agent choices required a major upgrade to fix, compared with 12.9% for human choices. This was a correlational study of real PRs, not a randomized experiment, so it does not prove the agent itself caused the difference.
Another preprint, Setup Complete, Now You Are Compromised , tested 12 scenarios across five classes on nine harness-and-model combinations. In the scenario with a vulnerable pinned version, all nine configurations installed it in every run — 0 of 30 preventions for each configuration. The model could identify the CVE after installation, but that was already too late to prevent it. A deterministic pre-install hook of about 400 lines checked the name, existence, age, source, hidden directives, configuration, and OSV before the command was run.
Both works are preliminary and do not measure production incidents. Their value is in a reproducible boundary: security is determined not only by the model, but by the combination of model + harness + environment permissions + enforcement timing.
What checks are needed before installation
The minimum gate must trigger before download-with-execution and before install/build hooks. It helps to separate checks by failure type.
| Check | Example rule | Decision when unknown |
|---|---|---|
| name | exact name from the approved manifest; protection against typo/slopsquatting | quarantine |
| registry | only the approved registry for the scope and project | block |
| version | lockfile/digest, no prohibited CVE, acceptable age | quarantine or block |
| provenance | expected builder, repository, workflow, ref, and SLSA level | block on mismatch |
| source control | protected branch, required review, linked commit/tag | quarantine |
| content | new install scripts, obfuscation, secrets, network access, shell | sandbox and manual decision |
| context | the package is needed for the stated task and allowed license | reject or ask a human |
| environment | installation without production secrets and write access | block until isolated |
OpenSSF in the article What Is a Dependency Firewall? recommends checking direct and transitive dependencies before execution, rather than relying only on nightly scanning. Signals include a new name or version, an unusual maintainer change, a new install script, an unexpected increase in size, a mismatch between the release and the original commit, obfuscation, and network calls.
No single rule is enough on its own. A package age of 24–72 hours can give threat intelligence time to detect a campaign, but it also delays an urgent security patch. An allowlist reduces the choice space, but it can preserve an already compromised version. A sandbox reduces impact, but it does not guarantee that a conditional payload will appear. That is why policy should combine multiple independent signals.
For adjacent control layers, useful materials include “AI Agent Skill Security” — on checking skills, plugins, and MCP components — and “AI Agent Harness” — on separating the model, runtime, tools, and evaluation harness.
What exactly to check in provenance
The check “attestation exists = true” is too weak. For each ecosystem package, you need an expected policy.
- Subject: the digest of the downloaded artifact matches the attestation.
- Source: the repository and commit/ref belong to the expected project.
- Builder: the approved builder and specific workflow are used.
- Parameters: build parameters do not expand the attack surface in an unexpected way.
- SLSA level: the stated level is actually assessed for the build platform, not inferred from the presence of a signature.
- Run outcome: publishing from a failed or cancelled workflow creates a separate alert.
- Source controls: branch protection, review, and identities match your policy.
- Consumer decision: the verification result is tied to the exact digest and specific environment, rather than trusting the package name indefinitely.
In the OpenSSF case study, malicious publications came from workflow runs with the status failure. A standard provenance check did not account for this, but matching the publish event to the run outcome could have detected the anomaly within minutes. This is an example of a signal that sits between formal attestation and operational monitoring.
The DOCA Method
We propose the DOCA method — an editorial synthesis of SLSA, OpenSSF, and GTIG observations, not a separate industry standard.
- D — dependency. Record the exact name, scope, registry, version or digest, direct/transitive role, and internal owner.
- O — origin. Verify the source, expected builder, workflow, ref, provenance, and source-review evidence; a valid but unexpected chain does not pass.
- C — pre-execution policy. Intercept package manager commands and manifest changes before install scripts run; define allow, quarantine, block, and exception in advance.
- A — constrained environment. Run unknown code without production secrets, signing identity, cloud permissions, or write access to core repositories; restrict the network and file system.
- D — behavioral signals. Look for obfuscation, shell/network/file access, new hooks, maintainer changes, a young release, a failed build with a publish event, and rebuilt artifact mismatches.
- C — quarantine and containment. Bind the decision to the digest, preserve the log, and provide for token revocation, runner/cache cleanup, lockfile rollback, and rebuild from a trusted source.
The method intentionally separates evidence from approval. A signature belongs in the “O” step, but the final decision belongs to “C” and depends on the environment in “A” and the signals in “D”.
How to configure allow, quarantine, and block modes
A single binary policy either slows development or lets too much through. It is more practical to assign a mode based on the combination of risk and evidence.
| Mode | When to use it | What the agent does |
|---|---|---|
| allow | digest is pinned, source/builder are expected, version was previously approved | installs in a constrained environment and logs it |
| quarantine | new release, new maintainer, new transitive dependency, incomplete provenance | downloads without executing, builds an SBOM, runs analysis, waits for a decision |
| block | unexpected registry, known malware/CVE per policy, provenance mismatch, hidden install hook | does not run the command, preserves evidence, and suggests a safe alternative |
| exception | urgent patch with measurable waiting risk | asks for the owner, limits TTL and scope, and schedules a recheck |
Human approval should not be a “continue everything” button. It is tied to the exact package digest, project, task, environment, and deadline. Changing any of these fields requires a new decision.
How to run a pilot
A pilot can be run on one repository without immediately blocking the whole team.
- Observation week. Log the agent’s requests to the package manager, manifest/lockfile diffs, registry, versions, and install scripts. Do not copy secrets into the log.
- Shadow policy. Calculate allow/quarantine/block, but do not stop commands; review false positives with platform and AppSec owners.
- Blocking the obvious. Block unexpected registries, known malware, nonexistent names, and digest/provenance mismatches.
- Quarantining the new. Add analysis of new versions, maintainer changes, source review, and sandbox behavior.
- Incident drill. Simulate a stolen publisher token, a publication from a failed workflow, and prompt injection in the README; measure detection, isolation, and revoke time.
- Scope expansion. Connect the next repositories only after a stable exception process and confirmed recovery.
Do not check only npm or PyPI on a laptop. The same gate is needed in CI, container builds, devcontainers, and agent sandboxes: bypassing it through another install point breaks a unified policy.
What metrics to collect
| Metric | How to calculate it | Why it matters |
|---|---|---|
| install requests | all agent and human requests to the package manager | baseline denominator |
| pre-execution block rate | blocks before the first executable hook / requests | distinguishes prevention from post-fact reporting |
| quarantine precision | confirmed risky / reviewed quarantines | shows policy noise |
| exception latency | time from request to limited decision | controls impact on delivery |
| provenance mismatch rate | unexpected source/builder/ref / verified packages | identifies chain drift |
| secret exposure window | from first execution to revoke/isolation | measures the possible blast radius |
| reproducible rebuild match | matching independent rebuilds / attempts | increases trust in the artifact |
| bypass attempts | installations outside approved points / all installations | checks enforcement completeness |
Do not combine them into a single "security score" without a predefined loss function. A zero share of blocks can mean a clean stream or a control that is not working; a high share can mean effective prevention or an unusable policy. The decision should be made based on a set of metrics and reviewed cases.
What to do if a suspicious installation is detected
If the package has already executed, removing the line from the manifest is not enough.
- Stop the agent session, CI job, and related runners; preserve logs and digest.
- Revoke OIDC, registry, GitHub, cloud, and API credentials available to the environment.
- Check workspace hooks, hidden IDE/agent directories, workflow files, caches, and startup configuration.
- Correlate the publish event, build run, commit, builder, and network calls.
- Rebuild the environment from a clean image and approved lockfile; do not rely on local uninstall alone.
- Find all projects and artifacts with the same digest, transitive version, or publisher identity.
- After containment, update the policy and repeat the exercise with the same vector.
This is a general engineering procedure, not a forensic recipe for every incident. In a real attack, scope and evidence preservation should be guided by the organization's incident response and legal requirements.
Evidence limitations
- GTIG reports real-world observations, but does not disclose the full dataset and denominators, and it is also a division of an AI and security products vendor.
- GTIG's wording about "SLSA Build 3 attestations" differs from OpenSSF's analysis of the May incident, where npm provenance was assessed as Build L2 and the platform did not meet L3 isolation requirements. This article does not mix those two episodes and does not treat the presence of an SLSA line as proof of level.
- Both academic studies are preprints. PR samples and lab scenarios do not provide the frequency of production compromises.
- A dependency firewall closes the installation point, but does not replace code review, SBOM, SCA, patching, endpoint protection, build isolation, and incident response.
- No Russian production data on the frequency of such attacks, the cost of controls, the impact on release speed, or ROI was observed.
Search volume, keyword difficulty, current rankings, traffic, CTR, backlinks, and AI citations also Unknown. The article describes a verifiable control architecture, not a forecast of SEO or business results.
Frequently asked questions
Is it enough to verify the package's digital signature?
No. A signature confirms the artifact's link to an identity, but the identity or pipeline may have been compromised. You need the expected source/builder/ref, source controls, content analysis, and local policy.
What is a dependency firewall for an AI agent?
It is a pre-installation control that intercepts the request to the package manager, checks the name, source, version, provenance, and policy, and allows, quarantines, or blocks the package before its code executes.
Why is post-install verification too late?
The install script may already have read secrets, modified the workspace, opened network access, or persisted in the agent configuration. A CVE notice after execution documents the risk, but does not prevent it.
Should an AI agent be prohibited from installing any dependencies?
Not necessarily. For known pinned digests, use allow; for new and not fully verified versions, use quarantine; for clear policy violations, use block; and for urgent exceptions, use limited approval with a TTL.
Does SLSA Build L3 solve the problem completely?
No. L3 strengthens build platform isolation and protects against a range of pipeline tampering attacks, but it does not determine whether the source code itself is trustworthy. Source Track, consumer policy, and runtime analysis are still needed.
What data should not be given to an agent installation environment?
By default, remove production secrets, long-lived registry/cloud tokens, signing identity, and broad write access to the repository. The exact set depends on the task and the company's threat model.
How AIrassvet helps build dependency controls
AIrassvet can help embed a safe execution path into an AI-agent project:
- define a single development process, its package managers, registries, agent tools, current permissions, and acceptance criteria;
- build an MVP with interception of install commands, policy for allow/quarantine/block, logging, and limited approvals;
- integrate the control with CI/CD, the container environment, and corporate systems without expanding the model's permissions;
- run scenario testing, launch, team training, and transfer of control ownership to the artifact owners.
The first step is to choose one repository, fix the installation baseline, dependency sources, constraints, and the acceptance criterion. Discuss the task.
Conclusion
Recent GTIG data shows that attackers are already using agentic pipelines, stealing publishing identities, and targeting AI coding environments. Formal signatures remain necessary, but they must be treated as limited evidence, not a universal sign of safety.
The practical order is: exact dependency → expected provenance → pre-execution policy → reduced environment → behavior signals → quarantine and impact control. An AI agent can select and install packages only when the organization can prove which exact artifact was allowed, why it passed the gate, and how damage is limited if something goes wrong.