Verify the Bytes Your Agent Will Run
Controlled preprint research, not a reported live campaign.
PyCache Trap pairs benign visible Python source with a different compiled cache that a compatible loader can select. Version 1 was submitted on 7 October 2026 at 07:10:11 UTC.
For a defender, the admission question should be concrete: which file can this runtime execute, and what proves that file was built from approved source?
Inspect the admission decision
In isolated Python 3.11 tests, 100 attacked skills faced seven scanners. Attack success meant no blocking flag; the reported range was 94 to 100 per cent, and none of the stored findings identified the concealed cache behaviour.
These are package-admission results, not a public compromise rate.
The distinction from instruction poisoning matters. BlackTree’s PackHallu coverage examined rule text that redirected dependency selection. The new operational decision comes after that review: approval needs evidence about the executable artefact selected by the supported runtime.
A valid header does not complete the review
Python 3.11’s import documentation explains that cached bytecode can be validated using source timestamps and sizes or source hashes, with checked and unchecked hash modes.
That mechanism helps Python decide whether it may use a cache. An admission process still needs its own evidence that the selected artefact belongs to the reviewed build.
Header consistency detected none of the 100 source-present substitutions; trusted reproduction and integrated validation detected all 100 in the authors’ test.
Fail closed has a compatibility price
Trusted reproduction checked 86 of 100 legitimate source and cache pairs without false positives in that checkable subset, then abstained on 14 sourceless fixtures. The deployed fail-closed policy rejected those 14, so its full legitimate cohort rejection rate was 14 per cent.
That split changes the deployment decision. A team that requires reviewable source can reject sourceless bytecode deliberately. A team that must accept it needs a different validation path and should record the remaining uncertainty rather than reporting a clean provenance result.
Make approval follow execution
BlackTree recommends applying these controls only where the interpreter and loader path are understood:
- Inventory bundled caches, import hooks and generated artefacts before admission.
- Prefer rebuilding bytecode from reviewed source in an isolated environment matched to the deployed interpreter.
- Bind the source hash, interpreter version, build process and resulting artefact hash in the approval record.
- Remove supplied caches when the workflow does not require them.
- Quarantine sourceless bytecode, custom loaders and unresolved imports for review.
- Record the file and loader selected during validation, then repeat the check after a Python, loader or package change.
- Keep first execution inside a sandbox with narrow files, credentials and outbound access.
These checks answer correspondence, not intent. A cache reproduced perfectly from dangerous source is still dangerous. Provenance therefore belongs beside source review, permissions, sandboxing and egress policy.
What remains uncertain
The fixed tests used Python 3.11, dummy secrets and synthetic targets. Sourceless custom loaders remained unresolved. The authors report no real users, production services or public platforms were attacked.
BlackTree has not independently reproduced the work. The paper links a code repository that returned HTTP 404 during this review.
The durable decision is to make runtime evidence part of admission. Where the validation path cannot resolve an artefact, the system should stop or request review instead of extending trust from a different representation.
