Review the trust boundary for LLM-generated code
Review the trust boundary for LLM-generated code before execution, mapping permissions, trusted controllers, output handling, and promotion controls in Polyaxon.
Before connecting generated code to a sandbox, ask what that program can do with the permissions already present. The largest risk may be an ordinary credential or writable mount, not an exotic escape technique.
Review the complete trust boundary. In Polyaxon, the sandbox interface gives access inside a service; the surrounding workload and infrastructure determine the authority of that access.
Draw the boundary around the untrusted program
Identify the trusted controller, model response, execution service, evaluator, and output collector. Mark every credential and data path that crosses between them.
For an analysis task, the generated program may need one sanitized input file and a writable report directory. It does not necessarily need the controller's Polyaxon token, provider key, or database connection.
Use sandbox connection guidance to review what is mounted. Automatic platform authentication, explicitly attached connections, and Kubernetes identity are separate sources of authority.
Review ordinary misuse before exceptional attacks
A program can cause harm without leaving its container if it can read a sensitive file, call an allowed-but-overprivileged API, overwrite shared state, or produce an enormous output.
Create a small boundary worksheet:
| Granted capability | Why it is needed | How misuse is limited |
|---|---|---|
| Input read access | Perform the calculation | Minimized session-specific bundle |
| Workspace write access | Produce report files | Dedicated path and output limits |
| External API access | Approved tool operation | Scoped credential and server authorization |
| Execution time | Complete the task | Command deadline and service lifetime |
Remove permissions with no concrete purpose. Document the remaining risks instead of assuming the word “sandbox” resolves them.
Keep policy outside the candidate's control
The controller should validate ownership, operation choice, and input references before dispatch. Mandatory cluster restrictions should be enforced through the deployment's admission and network controls.
Presets can establish consistent defaults, but a default is not an enforcement mechanism. Review the resolved workload, including environment settings, mounts, and identities.
For higher-risk workloads, evaluate whether the deployed runtime supplies the required isolation. The Polyaxon sandbox plugin does not itself create a separate VM or kernel.
Treat results as untrusted until checked
A successful exit code does not establish that the output is safe or correct. Check schema, size, expected file paths, and sensitive content before returning results to the model or a user.
An independent evaluator should inspect the candidate's behavior using controlled fixtures. Keep those fixtures and the evaluator implementation outside the candidate's writable environment.
Persist approved evidence with artifact tracking. Do not copy the entire workspace by default; retained data should serve a defined review or recovery need.
Separate execution permission from release permission
Authorization to run an experiment does not imply authorization to merge a patch, publish a package, or deploy a service.
Keep release credentials in a trusted promotion workflow. Bind its decision to the exact candidate and evaluation evidence, as described in code qualification.
A clear trust review turns an ambiguous “run code safely” requirement into explicit decisions: what enters, what authority is available, what may leave, and who can approve the next action.