Poisoned Python bytecode exposes a hidden supply-chain trust gap

At a glance

What this is: This is an analysis of Python .pyc cache poisoning, showing how unchecked-hash bytecode can run malicious code while evading source-based review and scanners.

Why it matters: It matters to IAM and security teams because AI agents, build pipelines, and software delivery paths increasingly rely on trusted artifacts whose identity and integrity are not always verified at runtime.

👉 Read ActiveFence's analysis of poisoned Python bytecode and cache poisoning

Context

Python bytecode caches create a trust gap when teams assume the readable source is the executable truth. In reality, the interpreter can run cached .pyc files directly, which means review, diffing, and many scanners can miss what actually executes if the cache has been altered.

That gap becomes more dangerous when code is packaged into CI/CD outputs, wheels, containers, or AI agent skill bundles. Any environment that treats runtime artifacts as passive build by-products instead of executable inputs inherits a hidden integrity problem, and that is now a common pattern rather than an edge case.

Key questions

Q: What breaks when Python caches are trusted more than source code?

A: The security model breaks because review, diffing, and source-based scanners no longer describe what actually runs. If a .pyc cache is poisoned or marked unchecked, Python can execute attacker-controlled bytecode while the visible .py file still looks harmless. That creates silent execution risk in builds, packages, and agent skill bundles.

Q: Why do cached Python artifacts matter in AI and automation environments?

A: AI agents and automation pipelines often consume reusable bundles, dependencies, and helper modules without deep human review at runtime. If those bundles include trusted caches, the execution path can inherit hidden code that bypasses source inspection. That turns a packaging decision into a privilege and integrity decision for the agent.

Q: How do security teams know if Python bytecode is outside its intended boundary?

A: Look for prebuilt .pyc files in repositories, wheels, container layers, and skill bundles, then verify whether the interpreter is allowed to accept hash-based caches without rechecking them. Any runtime that loads cached bytecode from an untrusted build path should be treated as potentially compromised until the artifact chain is verified.

Q: Should organisations allow AI skills to ship with compiled caches?

A: No, not when the skill can influence code execution or tool use. Compile at deploy time from source, strip caches from distribution packages, and validate the runtime artefact before the agent inherits any privileges. Otherwise, a small hidden payload can survive ordinary review and become an execution path.

Technical breakdown

How Python .pyc validation can be bypassed

Python stores compiled bytecode in .pyc files so repeated imports can skip recompilation. The interpreter uses a small header to decide whether the cache is still valid, and in hash-based modes it can either verify the source on each import or trust the cached bytecode without rechecking it. The problem is not compilation itself. It is that a single flag byte can tell Python to stop validating the relationship between source and bytecode, allowing stale or altered cache content to execute silently.

Practical implication: security teams should treat cached bytecode as executable and enforce runtime validation on any environment that loads Python from trusted artifacts.

Why source review and static scanners miss poisoned caches

Human review and most static tools inspect the .py file, while Python executes the .pyc if a cache is present and trusted. That creates a split-brain condition where the reviewed source and the executed code can diverge. Signature scanners also struggle because marshalled bytecode does not present normal source tokens or an AST. A poisoned cache can therefore survive both human and machine inspection, especially when it is embedded in a package or build output that appears legitimate at the source level.

Practical implication: add cache inspection and cache stripping to dependency review, not just source scanning.

Why AI agent skill bundles widen the exposure

AI agent skill packs and similar reusable code bundles are especially exposed because they are often small, trusted by default, and rarely audited with the same rigor as a package from a public registry. If those bundles carry prebuilt caches, the runtime may execute hidden logic even when the accompanying source looks benign. This is a supply-chain integrity issue, but it also becomes an identity problem when agents inherit tools and execution privileges from these bundles without separate attestation of what will actually run.

Practical implication: require source-only deployment for AI skills and verify runtime artifacts before agents inherit any privileged tool access.

Threat narrative

Attacker objective: The attacker wants hidden code execution inside a trusted Python workload while leaving the reviewed source looking harmless.

1. Entry occurs when a poisoned .pyc cache is inserted into a repository, wheel, container layer, or AI agent skill bundle that downstream systems trust.
2. Escalation happens when Python imports the unchecked cache and executes attacker-controlled bytecode instead of revalidating the source.
3. Impact is silent code execution that bypasses source review, scanner detection, and reviewer expectations while preserving the appearance of legitimate module behaviour.

NHI Mgmt Group analysis

Unchecked runtime artifacts create a source-of-truth failure: this attack works because teams assume reviewed source equals executed code. In Python, that assumption breaks as soon as a trusted cache is allowed to outrank the source file. The broader lesson applies to software supply chains and AI agent bundles alike: integrity controls must cover runtime artifacts, not just repository content. Practitioners should treat this as an executable trust problem, not a code review problem.

Python cache poisoning is a supply-chain issue with identity consequences: once a poisoned module is packaged into a build, the downstream consumer inherits an identity decision about whether to trust that artifact. That matters for NHI governance because AI agents and workload automation often consume code, skills, and dependencies without human review at execution time. In identity terms, the runtime artifact becomes a privileged non-human actor and needs attestation before it is allowed to act.

Source review alone is no longer a sufficient control boundary: this technique exposes a governance gap that many security programmes still leave open, namely the unchecked execution window between artifact creation and runtime validation. When cached bytecode can diverge from visible source, policy has to move closer to deployment and import time. Practitioners should align Python controls with secure build and release governance rather than treat caches as disposable files.

Runtime validation is the named control gap this attack exploits: the failure mode is not exotic malware, but the absence of mandatory cache validation and artifact hygiene. That is the same pattern security teams see in other supply-chain failures, where trusted intermediates persist after the original source has been reviewed. The practical conclusion is clear: if the runtime can execute it, the runtime must verify it.

AI agent ecosystems increase the blast radius of bytecode tampering: agent skills, automation bundles, and tool plugins create a wider audience for poisoned artifacts because they are frequently reused across environments. As these systems borrow from human IAM assumptions, the trust model becomes brittle unless every imported capability is treated as a governed non-human identity with a defined lifecycle. The field should expect more attacks at the package and artifact layer, not fewer.

What this signals

Cache integrity is becoming part of identity governance for software agents: as more AI systems inherit code, tools, and execution privileges, the question is no longer whether a bundle looks trusted but whether it can prove what will run. Teams should expect artifact attestation to become a control point alongside access review and secret handling, especially where agent skills are reused across environments.

The practical shift is toward runtime provenance, not just source provenance. That means build pipelines, package registries, and deployment gates need to treat compiled artifacts as governed assets and apply controls that resemble least privilege for execution paths, not only for human users or API credentials.

For practitioners

• Treat .pyc files as executable artifacts Block committed __pycache__ directories and scan build outputs for compiled bytecode before release. A clean source repository is not enough if the runtime can still import trusted caches.
• Force hash validation at runtime Run Python with --check-hash-based-pycs=always in security-sensitive environments so the interpreter validates hash-based caches even when a header claims otherwise.
• Deploy skills from source only Reject AI agent skill bundles, wheels, and tarballs that contain prebuilt caches, then compile them during deployment under controlled build conditions.
• Audit runtime artifacts alongside dependencies Extend SBOM, dependency review, and release checks to include cached bytecode, embedded scripts, and any packaged module that can execute without source reinspection.

Key takeaways

• A poisoned Python cache can run malicious bytecode while the reviewed source still appears harmless.
• The exposure is especially relevant for AI agent bundles, build pipelines, and packaged artifacts that are trusted by default.
• Security teams need runtime validation, cache hygiene, and source-only deployment controls to close the gap.

Key terms

• Pyc Cache Poisoning: A technique that alters Python compiled bytecode so the interpreter executes attacker-controlled logic instead of or alongside the visible source. It exploits the gap between source review and runtime execution, especially when hash-based validation is disabled or bypassed.
• Unchecked-Hash Mode: A Python .pyc validation mode in which the interpreter trusts cached bytecode without rechecking that it still matches the source. It is useful for performance and reproducible builds, but becomes dangerous when a cache can be replaced or tampered with.
• Runtime Artifact Integrity: The property that what a system executes is the same thing reviewers, scanners, and build controls approved. In software supply chains and AI bundles, integrity has to extend beyond source files to compiled caches, embedded scripts, and packaged payloads.
• Artifact Attestation: Evidence that a build output was produced by a trusted process and has not been altered before execution. It is a practical control for software and AI supply chains because it helps separate approved runtime inputs from files that merely look legitimate.

What's in the full article

ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:

• The exact .pyc header fields and flag bits that switch Python into unchecked-hash mode.
• A proof-of-concept builder that rewrites bytecode caches and demonstrates silent execution.
• Hex-level inspection output showing how the poisoned cache appears in practice.
• Practical safe-handling steps for wheels, tarballs, CI outputs, and AI skill bundles.

👉 ActiveFence's full post covers the byte-level exploit path, proof of concept, and defensive checks.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle thinking. It helps practitioners connect runtime trust decisions to broader identity and access controls.