4-byte cache poisoning exposes AI agent supply-chain blind spots

At a glance

What this is: This analysis shows how Python cache poisoning can let malicious .pyc artefacts alter execution, creating blind spots in supply-chain controls and AI agent environments.

Why it matters: It matters because practitioners cannot treat build-time review, repository scanning, or agent guardrails as complete if runtime cache artefacts remain outside governance.

Context

Python bytecode caches are a normal performance feature, but they become a governance gap when teams assume build artefacts and runtime artefacts are controlled in the same way. The risk becomes sharper in AI agent workflows because code execution may happen across automated pipelines, ephemeral environments, and delegated tool use.

The core problem is not just Python internals. It is that security teams often inspect source, dependencies, and packages while leaving cache files and other generated artefacts outside the trust model. In supply-chain terms, that creates a path where tampering can survive the very controls meant to detect it.

Key questions

Q: What breaks when Python cache files are not treated as trusted execution artefacts?

A: Source review and repository scanning stop being reliable indicators of what will actually run. An attacker who can influence cache creation or replacement can steer execution through a layer that defenders often ignore, which turns a normal optimisation feature into a supply-chain attack surface.

Q: Why do Python cache poisoning attacks matter more in AI agent pipelines?

A: AI agent pipelines combine delegated execution, tool use, and ephemeral environments, so a poisoned cache can alter behaviour after approval has already happened. That makes the risk broader than a single script because the compromised artefact can shape follow-on actions in an automated workflow.

Q: What signs suggest cache integrity controls are failing?

A: Look for runtime artefacts that are created outside controlled build stages, reused across tasks, or executed without provenance records. If scanners focus only on source and packages while bytecode appears and disappears in ephemeral locations, the environment is probably trusting generated state too much.

Q: How should teams govern runtime artefacts in supply chains and agents?

A: Treat every executable artefact as part of the supply chain and require provenance, integrity checks, and environment separation before execution. The key decision is not whether the file is temporary, but whether it can influence trusted behaviour without being revalidated.

Technical breakdown

How Python .pyc cache poisoning changes the trust boundary

Python stores compiled bytecode in .pyc files so later executions can skip recompilation. If an attacker can influence how those cache files are created, located, or reused, the runtime may execute code that does not match the reviewed source. Hash-based validation helps only when the hash mode is enforced consistently and the cache path is controlled. The important security point is that bytecode caches are not merely performance artefacts. They are executable trust artefacts, and any gap in their lifecycle becomes a supply-chain problem.

Practical implication: Treat .pyc files as governed execution artefacts, not disposable cache, and control where they can be created and reused.

Why scanners and code review can miss cache-based tampering

Static review usually focuses on source files, dependency manifests, and package signatures. Cache poisoning sits outside that lens because the malicious change can land after review or in a runtime-generated file that scanners do not inspect. In modern CI/CD and agentic workflows, that gap widens because artefacts may be created dynamically in ephemeral environments. The result is a trust mismatch: the organisation verifies one object, then executes another. That is a classic supply-chain blind spot, even when the source repository itself looks clean.

Practical implication: Extend scanning and integrity checks beyond source code to runtime-generated artefacts and ephemeral execution paths.

Why AI agent supply chains are especially exposed

AI agents often combine code execution, tool calls, and third-party libraries inside orchestrated workflows. That means a poisoned cache file can influence not just a single script but a larger delegated action chain. When the agent is trusted to fetch, run, or transform code, the cache layer becomes part of the identity and execution boundary. The security issue is therefore broader than Python alone: it is about whether agent supply chains treat generated artefacts as part of the system's authenticated state. If they do not, integrity controls are incomplete by design.

Practical implication: Bind AI agent execution to integrity checks that cover generated artefacts, not just signed code and approved dependencies.

Threat narrative

Attacker objective: The attacker wants malicious code to run through a trusted execution path without being caught by source-level review or package scanning.

1. Entry occurs when an attacker can influence Python bytecode cache handling so a malicious .pyc file is written or reused instead of the expected compiled artefact.
2. Credential or trust abuse follows when scanners, review gates, or runtime assumptions treat the poisoned cache as legitimate execution state.
3. Impact is code execution through a runtime artefact that bypasses ordinary source review, which can be amplified inside AI agent supply chains.

Breaches seen in the wild

• Ultralytics PyPI compromise 2024: A GitHub Actions injection and a leftover PyPI token let attackers publish four Ultralytics releases that installed a cryptominer.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime artefact governance is now part of supply-chain security. The article shows that trust boundaries cannot stop at source code, package metadata, or dependency review. In environments where Python bytecode is reused automatically, a generated artefact can become the execution path itself. Practitioners should treat cache files, build outputs, and ephemeral artefacts as governed assets, not implementation noise.

AI agent workflows magnify cache-poisoning risk because execution is delegated. When an agent fetches tools, runs code, or chains tasks across services, runtime artefacts can affect decisions and actions downstream. That makes the issue an identity and execution problem as much as a software problem, because the agent's trusted state includes more than the repository contents. Practitioners need to extend governance to every artefact that can influence agent behaviour.

Unchecked hash mode is a trust decision, not a technical convenience. If teams allow caching without clear integrity enforcement, they are accepting that compiled output may differ from reviewed source. That collapses the assumption that a clean repository equals safe execution. The practical conclusion is that runtime integrity controls must be explicit, measurable, and continuously enforced.

Supply-chain blind spots are often created by what teams do not classify as code. Cache files, generated bytecode, and temporary execution artefacts often fall outside standard security ownership. Once those assets can affect production behaviour, they belong in the same governance model as signed packages and privileged service accounts. Practitioners should close the gap between software assurance and runtime trust.

AI agent supply chains need artefact-level attestation. If the environment cannot prove that the object being executed is the object that was reviewed, the trust model is incomplete. That is especially true for automated systems that move faster than manual validation can track. Practitioners should demand evidence of artefact integrity across the full execution chain, not just at commit time.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Runtime artefact governance now sits alongside dependency governance. Security teams that only validate source and package signatures will keep missing the point if generated bytecode can change execution after review. The control question is no longer just what was approved, but what was allowed to become executable state.

AI agent supply chains need tighter provenance than traditional application pipelines. Once an agent can create, reuse, or pass along runtime artefacts, the organisation must know which environment produced each executable object and whether that object still matches its expected state.

Supply-chain blind spots widen when generated files escape ownership. The practical programme response is to classify cache files and other runtime artefacts as governed assets, then make their lifecycle visible to the same controls that already watch code and secrets.

For practitioners

• Govern bytecode caches as executable artefacts Inventory where .pyc files are created, stored, reused, and deleted, then classify them as part of the execution path rather than harmless temporary data.
• Enforce integrity checks on runtime-generated files Require validation controls for compiled output and other generated artefacts so execution cannot silently diverge from reviewed source.
• Tighten ephemeral environment handling Separate build, test, and runtime cache locations in CI/CD and agent workflows so one job cannot poison another task's execution state.
• Add artefact provenance to agent governance For AI agent pipelines, record which tool, job, or environment produced executable artefacts and refuse execution when provenance is missing.

Key takeaways

• Python cache poisoning matters because runtime artefacts can alter execution even when source review and package scanning look clean.
• The article shows a trust gap between what teams inspect and what actually runs, which becomes more dangerous in AI agent workflows.
• Closing the gap requires artefact-level governance, provenance, and integrity checks for generated files as well as source code.

Key terms

• Python Bytecode Cache: A Python bytecode cache is a compiled .pyc artefact that lets the interpreter reuse previously generated bytecode instead of recompiling source. It improves performance, but it also creates a trust boundary because the runtime may execute a cached object rather than the file a reviewer inspected.
• Queue Poisoning: Queue poisoning is the abuse of a shared request pipeline so that attacker-controlled bytes are processed as part of another user’s or another request’s traffic. It is dangerous because the attacker does not need direct code execution to influence what the back-end sees next.
• Verification Artefact: A verification artefact is any record created during identity proofing, including images, scores, approval notes, or vendor returns. These artefacts are valuable for audit and fraud review, but they also create privacy and breach risk if they are retained too long or exposed broadly.
• Model artefact provenance: Model artefact provenance is the chain of trust showing where a model file, tokenizer, metadata bundle, or derived package came from and whether it was modified. For autonomous and agentic deployments, provenance must cover the whole package, not just the neural weights.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that helps security teams extend trust boundaries beyond source code. It gives practitioners a practical foundation for governing identity and execution risks across modern digital systems.