Secure AI agent runtime execution with Polyaxon

When an agent generates a program during a user request, its behavior cannot be fully reviewed before deployment. The execution platform needs a repeatable way to assign that program a workspace, identity, compute budget, and lifetime. Polyaxon provides those workflow building blocks through jobs, services, presets, connections, and tracked runs.

A useful design separates a trusted controller from the operation that executes generated code. The controller authorizes the task and selects a reviewed execution component. The Polyaxon run performs the bounded work and returns artifacts. The application decides whether those artifacts are eligible for use in a later action.

For a repository repair agent, that means the execution run can produce a patch and test output without also receiving the credential that merges the patch into the production branch.

Give each execution a documented contract

Define the operation's expected inputs and outputs before adding model autonomy. Inputs might include a repository revision, a task manifest, and a fixture dataset. Outputs might include a patch, an execution report, and a structured result identifying success or failure.

Package the wrapper as a versioned component. The wrapper is your code: it validates paths, starts the selected program, collects results, and returns a meaningful exit status. Keeping it in a component makes changes to the execution procedure reviewable alongside changes to the agent.

Use the jobs runtime for work with a defined end. Use a service or sandbox-enabled run when the agent needs an interactive session. Choose the lifetime to match the task rather than leaving every execution environment running indefinitely.

Bound the resources and lifetime of the run

The following preset gives an existing execution job a Kubernetes identity, resource budget, and deadline:

runPatch:
  environment:
    serviceAccountName: agent-execution
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
      runAsNonRoot: true
  container:
    resources:
      requests:
        cpu: "1"
        memory: 1Gi
      limits:
        cpu: "2"
        memory: 2Gi
termination:
  timeout: 600
  maxRetries: 0

The service account must exist, and the image must support the selected user. Apply the preset when submitting your reviewed wrapper:

polyaxon run -p coding-agent -f execute-task.yaml -f presets/bounded-execution.yaml

Polyaxon's termination settings control the operation deadline and failed-operation retries. They do not set a model-provider token budget or a maximum number of tool calls. Implement those counters in the controller or tool gateway, and log them with the run.

Avoid automatic retries for operations with external side effects until the tool supports idempotency and state reconciliation. Stopping a run does not undo a request already accepted by a remote service.

Select credentials after authorizing the task

Use connections to supply only the repository, storage, or service access required by the execution. For jobs, Polyaxon checks that referenced connections are accessible to the project and the submitting user before resolving them. The trusted controller should select the connection configuration from authenticated application state. A model-generated request should not select arbitrary credentials.

Kubernetes permissions come from the selected workload service account. Polyaxon API permissions come from the identity submitting the run. Review both, including the permissions needed by configured initializers and sidecars.

Treat any credential readable by generated code as exposed to that code. For actions that need stronger mediation, keep the credential in a separate application service and authorize each requested action there. A named connection helps distribute configuration; it is not a per-request authorization proxy.

Build the boundary into the compute environment

Use Polyaxon presets to distribute the approved security context and placement settings. Enforce non-bypassable requirements through Kubernetes admission and the runtime configuration. For untrusted submissions, assess whether hardened containers provide sufficient isolation or whether the workload needs a stronger runtime or separate cluster.

Commercial queues let the platform route execution to designated compute agents and limit concurrency and resource consumption. They help separate execution classes operationally, while the destination's networking, storage, and node policies supply containment.

Outbound access follows the cluster and deployment policies described in the sandbox network guide. Explicitly account for package downloads, model APIs, private services, and metadata endpoints. Image scanning alone does not cover dependencies installed during an interactive session.

Preserve evidence at the task boundary

Collect the wrapper's command results, redacted tool decisions, resource measurements, and generated artifacts under the Polyaxon run. The platform's tracking API can log application metrics and reports; kernel or process security events require instrumentation from your runtime monitoring system.

Correlate that evidence with the component version, image digest, task identifier, and policy revision. Use run lineage to inspect tracked inputs and outputs before promoting a patch or starting a downstream job.

Finally, qualify the complete execution setup with representative failures: denied data access, unexpected network requests, timeouts, interrupted writes, and cleanup errors. Preserve the report as a run artifact. Runtime security then becomes a repeatable Polyaxon workflow that evolves with the agent, its execution component, and the infrastructure running it.