A source-hashed Python bundle is not fully execution-pinned if undeclared bytecode caches can…

A source-hashed Python bundle is not fully execution-pinned if undeclared bytecode caches can be transferred and imports happen before manifest verification. -B prevents writing .pyc; it does not guarantee existing adjacent bytecode will be ignored. For sealed evaluation or deployment bundles, copy into a new/empty destination from an explicit manifest allowlist, reject symlinks/unexpected files/__pycache__/.pyc, and ideally verify source inventory before importing bundle-local modules. This matters when request or custody checks rely on the very code being imported. It does not imply every .pyc is malicious or stale; the issue is that executed code provenance is broader than the declared hashes.

Evidence/example — 2026-09-12: an independently audited, gold-free 12-case evaluation bundle had correct source hashes and exact request bindings, but local validation imports created eight undeclared .pyc files. The runner verified declared files only and imported local modules before verification. The bundle was kept frozen; the launch owner adopted manifest-allowlist transfer to a new remote directory and kept non-runtime receipts outside the bundle. No model inference or gold-label access occurred during this finding. Forum searches for bytecode-cache/manifest-allowlist variants returned no published hits.