Skip to main content

ARCH-25 process-family governance and truthful posture

ARCH-25 generalizes the safeguards introduced for process.run before Tyrum adds another process tool. The native runtime remains the only conversation-turn executor; child programs remain ordinary governed tools.

Quick orientation​

Fail-closed process-family governance​

The reserved process.* and tool.process.* families classify as executable process tools by default. The centrally defined read-only handle-tool allowlist is empty in ARCH-25. A future ID therefore receives stronger governance until a later decision explicitly classifies it otherwise.

Every executable process tool requires its own exact literal tools.allow entry and its own exact execution-profile allow entry. Default allow mode, wildcards, bundles, tiers, and compatibility selectors do not enable executable process tools. Deny rules and shared-state restrictions still win.

Untrusted driving provenance applies untrusted_shell_requires_approval to the whole executable process family. Every executable process tool must also register a full canonical match-target builder. An unregistered builder returns a deterministic unconfigured match target, is removed from effective exposure, and receives an attributable policy deny. It never falls through to a bare tool ID or throws through turn and execution callers. The serialized process.run match-target bytes remain byte-compatible with ARCH-24.

Process evidence read boundary​

Process metadata is identified by one shared structured-evidence predicate used by redaction and model rendering. The discriminator selects stricter handling; it never grants trust.

Genuine and forged process evidence is parsed as a structured JSON envelope, bounded, secret-redacted, tagged untrusted, and sanitized at the model boundary. Malformed model-visible evidence fails closed to a bounded error envelope, while malformed raw provenance remains available only as a redacted, bounded forensic record. Persisted process evidence, when replayed, can safely receive the same idempotent sanitizer, including prompt-injection and delimiter neutralization.

Separate confinement posture​

toolrunner.hardeningProfile describes ToolRunner execution. The independent deployment key process.requiredConfinement accepts baseline (the default) or hardened; changing toolrunner.hardeningProfile never changes the process requirement.

The current local runner reports backend local_spawn with applied confinement baseline. Hardened process confinement is unavailable, with the explicit reason that local spawn does not enforce it. When process.requiredConfinement is hardened, process.run is absent from effective exposure and its executor fails with required_process_confinement_unavailable. It never falls back to baseline execution.

The public /status wire field hardening_profile remains required and continues to describe ToolRunner hardening. Additive process posture fields are process_backend, process_confinement_applied, process_confinement_available, and process_required_confinement; an unavailable requirement may also include process_confinement_unavailable_reason. Prompt text uses the more explicit toolrunner_hardening_profile name.

Local cwd checks, minimal environment projection, and process-group signalling do not provide filesystem, network, resource, syscall, identity, or daemon-escape confinement. No local-spawn path may report hardened.

Deferred sequence​

  • ARCH-26 delivers supervisor-owned durable local background lifecycle tools.
  • ARCH-27 delivers governed specialist CLI skill and configuration guidance.
  • ARCH-28 delivers explicit-target managed-node process execution.
  • ARCH-29 delivers a probed, enforceable confinement backend for a named supported deployment.

ARCH-25 adds no lifecycle tool, durable process state, specialist integration, managed-node execution, confinement backend, or alternate turn executor.