Configure Python sandboxes for untrusted LLM code

Python generated by an LLM should receive no more authority than the task requires. A program that calculates an aggregate does not need a cloud administrator token, a host filesystem mount, or unrestricted access to neighboring services.

Polyaxon can run a Python workspace as a sandbox-enabled service. Configure the environment deliberately, and have the platform team enforce the mandatory restrictions outside the generated program.

Separate the trusted controller from the program

The controller authenticates the user, selects the input bundle, authorizes the operation, and communicates with Polyaxon. Keep its platform credentials and model-provider key outside the generated-code environment when possible.

Upload only the approved input files through the filesystem interface. Collect bounded outputs afterward, rather than giving every generated program access to the entire artifact store.

The following component-level settings disable automatic Polyaxon authentication and artifact-store injection:

plugins:
  sandbox: true
  auth: false
  mountArtifactsStore: false

They do not remove separately attached connections or Kubernetes identity. Review those with sandbox credential guidance.

Restrict the workload, not just Python imports

Use a reviewed image with the required dependencies already installed. Run as a non-root user and avoid unnecessary privileges.

This is an illustrative configuration fragment to merge into your service, not a complete component:

run:
  kind: service
  environment:
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
      runAsNonRoot: true
      fsGroup: 1000
  container:
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      seccompProfile:
        type: RuntimeDefault
    resources:
      requests:
        cpu: "1"
        memory: 1Gi
      limits:
        cpu: "2"
        memory: 2Gi

Validate compatibility with the selected image, sandbox support, and cluster policy. If using a read-only root filesystem, provide the writable paths required by Python and the execution tooling rather than assuming the change is transparent.

Environment configuration defines Pod-level settings; container security settings belong under run.container.

Make network and filesystem access explicit

Mount a session-scoped workspace instead of broad host paths or shared tenant directories. Configure egress in the cluster to match the allowed destinations described in sandbox network access.

Python's isolated mode can reduce dependence on user environment settings, but it is not an operating-system security boundary. Blocking a few imports or filtering suspicious source strings is also insufficient for arbitrary-code isolation.

If the threat model requires stronger separation than the deployed container runtime supplies, evaluate that infrastructure requirement before admitting hostile workloads.

Bound execution and inspect outputs

Use command deadlines and an absolute service timeout. Check exit status, timeout state, and truncation flags before interpreting results.

Keep evaluation logic outside the writable candidate workspace. Validate expected output schemas, sizes, and paths before saving reports or adding them to model context.

The secure design is a combination of narrow inputs, minimal workload authority, external enforcement, and independent evaluation. Polyaxon supplies the execution interface and run context; those surrounding controls determine what untrusted Python can actually do.