Contain generated code with Kubernetes runtime controls

Generated code changes the program a workload executes from one request to the next. A reviewed image is still important, but it does not establish that every script subsequently run inside that image is safe.

Use defense in depth around the execution environment. Polyaxon provides workload configuration and run visibility; Kubernetes and the selected runtime supply the underlying containment controls.

Understand the boundary being used

A sandbox-enabled Polyaxon service executes commands in its main container. Enabling the plugin does not create a separate kernel or turn an ordinary container into a hardware-backed isolation environment.

Document which workloads may share nodes and what level of trust they have. If the risk assessment requires stronger separation, choose and validate compatible infrastructure before enabling those workloads.

Avoid absolute promises that any one isolation mechanism makes escape impossible. Runtime patching, configuration, and incident response remain necessary.

Enforce a restricted workload profile

Kubernetes Pod Security Standards describe restrictions including non-root execution, limited capabilities, seccomp configuration, and prohibitions on dangerous host access. Apply the appropriate policy through admission, rather than relying only on authors to copy a safe example.

Use Polyaxon environment settings and container configuration to express the intended workload profile. Review all injected containers and mounts as well as the main program.

A scheduling preset is useful for reuse, but enforcement must reject prohibited overrides. Keep runtime and node updates under the platform team's normal maintenance process.

Limit what remains reachable

Remove unnecessary credentials, host mounts, shared writable volumes, and elevated Kubernetes identity. A process that already has a powerful cloud token may not need a container escape to access valuable systems.

Use scoped connections and keep provider or platform credentials in a trusted controller where possible.

Restrict network access through a compatible networking implementation. Kubernetes NetworkPolicy requires support from the deployed network plugin; a policy object alone does not establish enforcement.

Network restrictions complement the runtime boundary. They do not repair a vulnerable kernel, and they must be evaluated against the application's legitimate destinations.

Preserve operational evidence

Record the image digest, resolved workload configuration, execution run UUID, command outcome, and relevant external security-event references.

Use Polyaxon logs and artifacts to connect an application request to the execution context. Host-level threat detection and response require the security tools deployed in your infrastructure; ordinary resource metrics are not a substitute.

If an incident occurs, coordinate stopping the workload, revoking credentials, preserving approved evidence, and examining affected infrastructure. Stopping a service does not undo external changes.

Reevaluate the profile as the workload changes

A new dependency, broader network permission, or additional mount can change the boundary even when the agent prompt stays the same. Include those changes in the review process.

Exercise authorized boundary checks using synthetic data and retain the configuration version with the results. Keep the candidate program away from the evaluator and release credentials.

The objective is to reduce both the opportunity for misuse and the impact of a failure. Polyaxon makes the execution context manageable; the complete infrastructure design determines how well generated code is contained.