Apply Controls at the Owning Layer

Security review starts by identifying who owns the loop and who can act on its output. A runtime harness mediates tool use, permissions, context, and sandboxing. A repository harness supplies the instructions, dependency setup, and deterministic verification gates. An orchestrator can create additional identities, workspaces, handoffs, and unattended execution, so it needs separate credentials, budgets, stop conditions, and audit trails.

The Agent Harness Map distinguishes runtime harnesses from the wider directory of plugins, frameworks, observability tools, and control planes. Use Agent Harness Engineering to understand runtime boundaries, Agent Tools: Beyond Claude Code to assess adjacent products, and Session Observability to retain evidence without expanding access. Definitions live in the glossary.

Benchmark security separately from task completion. AgentDojo includes 97 realistic tasks and 629 prompt-injection security test cases, which makes utility and attack resistance visible as separate outcomes. CaMeL reports 77% task completion under its capability-based control design versus 84% for the undefended reference configuration. These studies do not prove that one control fits every harness, but they show why a single success score hides the security trade-off.

Harness optimizers expand the attack surface because they can modify prompts, tool exposure, control flow, or verification policy. Freeze non-negotiable security invariants outside the optimizer's mutation space. Reject candidates that weaken permission boundaries, leak evaluation data, suppress audit events, or improve task score by skipping a required check.

Worktree isolation is not process isolation. Liza's pinned provider catalog, for example, launches external coding-agent CLIs and includes modes such as --approve-all, --dangerously-skip-permissions, and --permission-mode dangerous. Its worktrees reduce edit collisions and its supervisor constrains workflow transitions, but the launched process can still inherit host files, credentials, and network access. Review the generated global configuration, constrain writable roots, inject task-scoped credentials, and put an OS or container sandbox below the orchestrator before unattended execution. See the Liza profile for the code and CI evidence behind this classification.

Command policy is another distinct layer. Codex's official execpolicy matches token prefixes and returns allow, prompt, or forbidden, with positive and negative examples that validate rules at load time. Liza maintainer Tangi Vass's experimental bash-policy instead parses compound Bash payloads into command units before returning allow, manual, or deny. The latter had no tagged release at the checked 2026-08-29 snapshot, so evaluate it as source code rather than as a mature dependency. Neither mechanism is a sandbox. Policy decides whether a command shape may run; sandboxing constrains what an allowed or bypassed process can reach.