Skip to main content

ToolRunner hardening and process confinement

Read this if: you need the concrete containment vocabulary Tyrum exposes to operators and the runtime.

Skip this if: you only need the broader safety model; start with Sandbox and Policy.

Go deeper: Turn Processing and Durable Coordination, Scaling and High Availability.

ToolRunner profile matrix​

ProfileWhat it promisesWhere the limit is
baselineConservative ToolRunner defaultsDoes not claim host-level process confinement
hardenedTighter ToolRunner container/job settings, narrower writable mounts, stricter privilege postureApplies only where the selected ToolRunner path enforces those controls

Purpose​

ToolRunner profiles and process confinement are separate posture concepts. Operators can require a known process posture without relabeling an unrelated execution backend.

Deployment semantics​

  • toolrunner.hardeningProfile maps into supported ToolRunner job or pod settings.
  • process.requiredConfinement independently accepts baseline (default) or hardened.
  • The current local_spawn process backend applies baseline only and reports hardened unavailable with an explicit reason.
  • Requiring hardened process confinement disables and rejects process.run; the runtime never falls back to local baseline spawn.

Observability​

  • /status reports sandbox.hardening_profile for ToolRunner compatibility and additive process posture fields.
  • Runtime context calls the ToolRunner field toolrunner_hardening_profile and reports process backend, applied confinement, availability, and requirement separately.
  • Diagnostics should show when profile-specific restrictions blocked execution.