Governance Boundaries and Current Limitations
English | 中文
Approval, sandboxing, and audit are not one security switch
Governance begins by stating what each layer stops, records, and cannot stop. Calling several mechanisms “security” hides the real conditions for launch.
Tool policy, approval, and execution constraints narrow authority before action.
Local same-world confinement and remote execution have different trust premises.
Session events preserve facts but do not replace identity, retention, and compliance policy.
A six-layer governance model
Enterprise deployment must connect identity, Agent composition, tool decisions, execution environment, credentials, and session evidence. Each layer performs its own job; later audit cannot undo earlier unauthorized execution.
| Layer | What the current Harness provides | What deployment still provides |
|---|---|---|
| Identity and tenancy | Runtime identity for sessions, Agents, tools, and opaque ids | Enterprise SSO, tenant directory, roles, and offboarding |
| Agent composition | Presets, profiles, bundles, and scoped service resolution | Who may create, change, review, and publish compositions |
| Tool decision | Argument schemas, guards, approval, timeouts, and result events | Domain authorization, action tiers, approvers, and exception policy |
| Execution environment | File-effect policy, local providers, and an E2B POC | Network, process, device, container, and platform security baseline |
| Credentials | References separated from values, per-operation resolution, safe description | KMS/keyring, rotation, audit, and emergency revocation |
| Session evidence | Append-only events, persistence, projections, and format refusal | Retention, access control, redaction, export, and regulatory interpretation |
Approval: decide whether this action may run
The approval service creates approval/asked and approval/decided audit pairs around tool requests and supports per-session ask or never. ask executes only with an available answerer returning allow; missing answers, answerer failure, and never deny. The mechanism lives in the approval service.
Its boundary is specific: approval answers whether this tool call has human or policy authorization. It does not constrain what the implementation can access internally, and it does not prove the approver has final authority in the source business system. Domain tools still need caller identity and business authorization.
File policy and local sandboxing: constrain file effects
SandboxMode expresses file-effect policies such as read-only, workspace-write, and danger-full-access. Local backends share the Host filesystem and kernel, with different mechanisms on Linux, macOS, and Windows. A request that cannot enforce its mode must fail closed rather than run unconfined. See the sandbox service and local provider.
This seam expresses no network, process, syscall, device, or credential restriction. The Windows ACL backend constrains writes and reports partial enforcement; caller-readable files and network connections are outside that mechanism. read-only does not mean “the whole machine is read-only and offline.”
Remote execution: replace the complete execution world
The E2B composition places filesystem and subprocess providers in a remote Linux sandbox, separating process and file execution from the Host. It does not move the Harness process, model calls, session state, skills, protocol state, or SDK buffers; those remain in the Host. The current implementation is explicitly experimental POC; see the E2B composition.
Remote execution is closer to environmental isolation than local file policy, but image, network, secret injection, sandbox cleanup, partition recovery, and provider logging still need review. The current E2B POC does not support secrets in sandbox-default environment variables and supplies no Windows or network-partition fidelity layer.
Dynamic code: trusted extension, not a hostile-code security boundary
Code runtime, dynamic workflows, and self-modifying Cordis tools use workers or node:vm to isolate event-loop work, limit default globals, or shape APIs. Their trust premise is Bash-like; escaped scripts may recover process authority. The code runtime explicitly describes containment rather than a security boundary, and dynamic Cordis plugins can affect the live runtime through allowed services.
Use these capabilities only when models and scripts are inside the trust boundary. Third-party or adversarial code requires a separate process, container, microVM, or remote execution provider, with credentials and network restricted. Evidence: worker-thread code runtime, workflow worker, and dynamic Cordis tools.
Session logs: provide facts, not automatic compliance
The session log preserves model-visible messages, tool facts, policy changes, and lifecycle events. Persistence and projections let refresh, recovery, and multiple interfaces read the same sequence. Append rejects non-lossless JSON, while loading rejects unknown required events and unsupported formats instead of silently misreading them.
The log does not answer who may lawfully view it, how long it remains, which fields require redaction, or how an auditor receives it. Those belong to deployment storage, enterprise identity, data classification, and regulation. The Harness supplies the technical fact layer for an audit chain.
Current limitation register
| Topic | Current fact | Launch implication |
|---|---|---|
| Local sandbox | Shares Host filesystem and kernel; expresses file effects only | Add separate network, process, and device control |
| Windows ACL | Write restriction is partial; Everyone authority may remain | Do not treat it as complete OS isolation for high-sensitivity work |
| E2B | Experimental POC; state outside execution remains in the Host | Validate lifecycle, secrets, and failure recovery first |
| Dynamic workflow | No journal or resume; restart cannot continue a run | Work must be repeatable or handed to a durable workflow system |
| Worker/VM | Shapes APIs and isolates the event loop; does not contain hostile code | Untrusted code needs stronger isolation |
| ACP | Fresh sessions, baseline text, committed assistant text | Do not treat it as the complete Web session protocol |
| Subagent approval | Delegated child sessions are fixed to never | Work beyond inherited authority returns to the parent Agent |
Questions to ask in a launch review
Who decides which tools an Agent receives?
Separate the authors, reviewers, and publishers of presets, profiles, and bundles, and record the composition actually loaded in each environment. Prompt review alone does not cover plugin authority.
What exactly does one approval allow?
Approval copy should name the action, object, impact scope, and one-time semantics. The business system must still validate caller identity and idempotency.
What remains reachable outside the file sandbox?
Review network, process visibility, environment variables, devices, and caller-readable files per platform; these are not part of generic SandboxMode policy.
Which work recovers after a crash?
Sessions and continuable subagents have durable paths. Dynamic workflows and ordinary background jobs should not be assumed to survive a process restart.
Does the log contain material that should not be retained?
Classify user material, tool arguments, results, and diagnostics, then set storage retention, access, and redaction policy. Replayability does not justify indefinite retention.
Minimize the capability set, stop risky actions before execution, and preserve complete facts
Production governance requires all three: the Agent receives only task-relevant capabilities; irreversible actions meet policy or human control before execution; and authorized people can inspect what happened. None substitutes for another.
Evidence status: Confirmed against current source unless noted. Launch advice must be combined with the target enterprise's identity, network, data classification, and regulatory policy.