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. First posted on 7 October 2026, it was revised on 9 October.
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
Seven scanners admitted 94-100% of 100 attacked Python 3.11 skills. No stored finding identified concealed cache behaviour; any blocking flag counted as a defence.
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 checks detected 0/100 source-present substitutions; trusted reproduction and integrated validation each detected 100/100.
Fail closed has a compatibility price
Of 100 legitimate caches, trusted reproduction accepted 86 source/cache pairs without false positives and abstained on 14 sourceless fixtures. The fail-closed policy rejected those 14: a 14 per cent whole-cohort rejection rate.
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 advertised repository returned HTTP 404 during 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.
