Evaluate security controls for AI sandbox platforms
Evaluate AI sandbox platforms using explicit security acceptance criteria, and map Polyaxon capabilities to application and Kubernetes controls.
A sandbox platform should be evaluated against the code and data it will actually handle. A trusted engineer debugging a training job and a public application executing arbitrary customer code do not have the same threat model.
Start with an acceptance checklist, then require evidence for each item. Polyaxon can make workload configuration and evaluation results repeatable, but a platform label is not proof that every security requirement is satisfied.
Define the allowed execution
Write down who supplies the program, what data it receives, which external systems it can reach, and what happens when it misbehaves.
For example, an internal analysis assistant may receive sanitized CSV files and return aggregate reports. It may not need a package registry, cloud credentials, or write access to source datasets. That is a much smaller execution surface than a general-purpose coding workspace.
Use Polyaxon components to represent reviewed environment profiles. Keep the profile revision with every acceptance run so a later configuration change cannot quietly invalidate the result.
Ask for evidence at each boundary
| Boundary | Acceptance question | Evidence to retain |
|---|---|---|
| Identity | Can one user access another user's workspace? | Authorized and denied access outcomes |
| Credentials | Which secrets reach the executed program? | Reviewed connection and identity configuration |
| Compute | Can the workload request forbidden host access? | Admission decisions and resolved Pod configuration |
| Network | Can it reach only approved destinations? | Egress policy and controlled connectivity results |
| Resources | What limits CPU, memory, duration, and output? | Runtime configuration and bounded failure behavior |
| State | What remains after termination or reassignment? | Cleanup and reconstruction results |
Run these checks only in an authorized evaluation environment with synthetic data. The goal is to establish the boundary, not to probe unrelated infrastructure.
Separate configuration from enforcement
A sandbox-enabled Polyaxon service exposes commands and files inside its main container. Its effective privileges come from the workload, mounted connections, Kubernetes identity, and runtime configuration.
Scheduling presets are useful defaults. They do not replace admission rules that reject prohibited settings. Likewise, an authenticated service proxy does not restrict the destinations an in-container process can contact.
Review network access and connections with the platform team. If the required threat model needs a stronger kernel or VM boundary, evaluate a compatible hardened execution design rather than assuming the sandbox plugin provides it.
Include failure and operational access
Ask what happens when the client disconnects, a process exceeds its deadline, the node is replaced, or the artifact collector cannot finish. A safe failure should be observable and should not silently widen permissions.
Include administrator and support access in the review. Debugging procedures, retained logs, and copied workspace files can expose data even when the normal request path is tightly controlled.
Record outcomes with Polyaxon tracking and preserve sanitized evidence as artifacts. A pass should identify the deployment, runtime, policy, and component versions that were evaluated.
Make the decision conditional and reviewable
Approve a defined workload profile, not an unlimited promise that a platform is “secure.” Document unsupported use cases and the changes that require reevaluation: a new image, broader network access, a different tenant model, or additional credentials.
This gives procurement and engineering the same decision record. Polyaxon supplies a repeatable execution and evidence workflow; the acceptance criteria establish whether the complete deployment fits your security requirements.