Review Python worker startup imports before the script body

Freeze one already trusted worker

A fictional preprocessing service uses interpreter P-A to run reviewed script S-A for job J-A. S-A produces a short plain-text summary from separately authorized input I-A. It uses only its admitted standard-library dependencies, with no sibling-package search requirement. These are symbolic identities, not inspected programs or filesystem paths.

Approving P-A’s filename and passing an argument array does not describe everything Python may select during initialization. This guide addresses that narrower startup decision. It does not replace the process permission and resource review or the dependency-selection review.

Both official bodies inspected identify Python 3.15.2 documentation. No installed interpreter or host configuration was inspected. The profile permits only direct invocation of a fixed ordinary script by an independently trusted interpreter. Module-mode discovery, wrappers, virtual environments, embedding, zip applications and other implementations are excluded.

Separate the five switch decisions

The command-line reference documents ordinary script-directory prepending. It distinguishes -E, which ignores PYTHON* environment variables; -P, which suppresses the potentially unsafe prepend; and -s, which omits the user site-packages directory. -I implies those three, but not -S. The separate -S option disables importing site and its site-dependent path manipulations.

The selected application plan combines -I with -S, rather than asking a caller to assemble a convenient subset. That is a strict plan for this worker, not a universal launch recommendation. S-A’s compatibility with the selected plan still requires independent evidence; a script that depends on an excluded startup behavior does not receive an automatic weaker rerun.

Keep the effective entry point and complete permitted argument plan under trusted control. An attractive flag in an earlier review is insufficient if an adapter changes the invocation before launch. No caller may add a startup option or change the script identity to repair a failed job.

Do not confuse user-site exclusion with no site hooks

The site reference describes automatic initialization, including site-packages processing and sitecustomize; usercustomize depends on enabled user-site support. Its current 3.15 behavior includes .start entry points. Deprecated .pth import lines can still execute, except when a matching .start file supersedes them. These startup paths are not contingent on the worker using a particular package.

Therefore an isolated-only review leaves a separate automatic-site question. This profile chooses no automatic site initialization rather than approving unknown system-site hooks. It also requires an independently admitted immutable interpreter and runtime tree. The switch does not authenticate that tree or establish its installation provenance.

The same reference explains that under -S, merely importing site does not perform the usual additions, while an explicit site.main() can trigger them. Our trusted-script policy excludes explicitly re-enabling site initialization or adding site directories. This is a code-review requirement, not a claim that a flag forbids all later imports or customization.

Use an admission ledger with a useful positive

A reviewer needs a release decision more specific than “Python is isolated.” Record these invented associations without constructing a launch command:

PROPOSED_UNRUN — fixed worker bootstrap ledger
Interpreter/build: P-A / independently admitted revision B-A
Runtime tree: T-A / admitted, immutable and complete
Entry point: ordinary reviewed script S-A / revision R-A
Dependencies: admitted standard-library subset; no sibling discovery
Startup plan: -I together with -S; no caller-selected additions
Job/input: current J-A authority and authorized I-A
Next stage: separate bounded process execution review

The conditional positive preserves a useful task: the already reviewed summary script remains eligible under the declared bootstrap plan. Before any real launch, the actual interpreter/build, runtime tree, script, adapter and supported invocation must match this ledger. Those checks are unimplemented here. Missing evidence keeps the plan on hold.

Current input rights, operating-system permissions and input, execution and output bounds are independent prerequisites. A complete startup ledger cannot override them. It also cannot establish that the summary is correct, complete or suitable for model context.

Challenge the plan with eight inert cards

Each failure names its gate. It does not establish maliciousness or demonstrate that a rejected configuration would exploit anything. The cards are review aids, not interpreter test results.

Limit the startup claim and the evidence

A future implementation must preserve admitted code and configuration through use. An earlier digest list without ownership and lifecycle evidence does not prove that later initialization uses the same tree. This worksheet supplies no race-control implementation or operating-system loader contract.

It also establishes no filesystem or network isolation, absence of earlier runtime code, protection from arbitrary scripts, process prohibition or resource ceiling. Later trusted code can still perform actions permitted by its own implementation and operating-system authority. Keep descriptor inheritance, dependency provenance and result admission as separate records.

For these proposed cases, no Python worker, startup flag, import path, site hook, environment or host fixture was inspected or executed. No candidate interpreter was launched or module imported. Ordinary documentation reads and editorial file handling are separate operations.

Boundary is a prelaunch model router with planned request-path checks, not a shipped Python bootstrap verifier. Its synthetic action exercise and existing mock evidence do not validate this runtime profile or demonstrate worker containment.