AgentJail can fail open: read the boundary before trusting the shield
AgentJail puts deterministic checks between a coding agent and the machine it can modify. That is useful, especially when a session can run shell commands, call MCP tools, reach the network, and inherit developer credentials. It is also easy to read the product name as a stronger promise than the implementation makes.
The project's own documentation is unusually direct about that gap. Its opt-in PATH shim runs the real agent unshielded if the shield binary is missing. Unsupported operating systems also run without the kernel sandbox after printing a warning. The new credential broker can keep secrets out of command-line arguments and storage logs, but credentials delivered into a session remain readable by that session.
The controls overlap, but none turns the session into a sealed cell.
The hook makes decisions before tools run
The AgentJail repository supports Claude Code, Codex, and Cursor. A local hook normalizes tool activity, sends a policy request to a persistent daemon, and evaluates Rego rules with Open Policy Agent. The result is allow, ask, or deny.
Default examples block reads of sensitive paths, destructive shell patterns, unknown MCP servers, forced pushes, and piped installers. Custom rules can cover project-specific commands. AgentJail's site reports roughly 8 milliseconds of median policy latency, but that is a project measurement rather than an independent benchmark.
Hooks are precise and reviewable. They are not a complete process boundary. A missed adapter, direct subprocess, absolute-path launch, broken hook configuration, or unsupported tool surface can escape that layer. AgentJail adds an operating-system sandbox for this reason.
Continue's read-only permission model has the same review problem: a friendly mode name does not tell you which execution paths remain available. Security review has to follow the actual call path.
The shield means different things on Linux and macOS
The project's sandbox documentation describes two back ends. Linux uses Landlock, an allowlist-oriented Linux Security Module. The working directory and temporary directory can be writable, system paths are mostly read-only, and sensitive home subdirectories are excluded. Once applied, Landlock restrictions cannot be removed by the process or its children.
macOS uses Apple's Seatbelt profiles. AgentJail's profile is allow-by-default with explicit denials for sensitive reads and writes. That is a different security posture from the Linux allowlist, even when the CLI presents both as the shield.
Linux needs kernel 5.13 or newer for Landlock. The documentation says truncate(2) is covered only with Landlock ABI v3, available from Linux 6.2. Network connection control through Landlock requires kernel 6.7 or newer. On older kernels, AgentJail applies filesystem restrictions and warns that Landlock is not restricting network egress.
Windows and other unsupported platforms get the clearest fallback: the shield warns and launches the agent without a sandbox, while the tool hook remains active. A warning in a terminal log is not a containment boundary.
Per-host network control is not the basic default
AgentJail can route agent traffic through a local tunnel or proxy and enforce a host allowlist. Direct shield launches do not automatically get the strongest network posture. The documentation says per-host egress is opt-in, and the default without the proxy is port-level access on HTTP and HTTPS ports.
That default has a concrete cloud risk. Port-only filtering cannot distinguish a package registry from a cloud instance metadata address. AgentJail probes for reachable metadata services at launch; its standard behavior is to warn and record an audit event. The --audit-strict option refuses to launch when the documentation's critical findings are present. Version 1.6.0 also added --require-tunnel and AGENTJAIL_REQUIRE_TUNNEL=1, which refuse fallback when a run depends on transparent-tunnel enforcement, according to the release notes.
The macOS distribution has another boundary. The v1.6.0 CLI release does not package, install, activate, or approve the separately built Network Extension. Teams should not infer tunnel availability from the CLI version alone.
The credential broker protects delivery, not authority
Version 1.6.0 added provider-neutral credentials. Users store a credential under an exact ID, optionally add non-secret labels and tags, and deliver it to a session through named environment variables or private files. The release rejects bindings that could replace PATH, dynamic loaders, proxy controls, TLS trust, shell startup, module paths, or SSH-agent state.
The accepted generic-credentials design record draws the remaining boundary plainly: static material is readable by the sandboxed agent. It is available to the selected session, not confined to one executable. Labels such as read-only-prod describe user intent; AgentJail does not verify the permissions behind them.
Provider IAM or RBAC remains the authority boundary. Give the session a credential that can do only the intended job, even if the broker stores and cleans it up correctly. The same warning applies to SSH-agent delegation: every process in the session may request signatures from every identity loaded in the delegated agent, without host or repository restrictions. Use a dedicated, narrowly authorized identity.
A deployment checklist that matches the boundaries
Start in monitor mode and inspect the decisions before enforcing custom rules. Then test the exact launch path developers will use, including IDE wrappers, shell profiles, absolute-path invocations, and non-interactive jobs. A green hook test does not prove the kernel sandbox or network tunnel is active.
For production-connected work:
- Require the tunnel when host-level egress control is part of the claim.
- Use strict audit refusal on cloud hosts instead of accepting metadata warnings.
- Verify the kernel and Landlock ABI on every Linux runner.
- Issue narrow, short-lived provider credentials; do not treat credential names as verified policy.
- Test failure by removing the shield binary, stopping the daemon, and launching through every supported wrapper. Record whether each layer denies, warns, or continues.
Our least-privilege checklist covers the upstream design work: separating read, write, execute, network, and credential capabilities before a tool is handed to an agent.
AgentJail v1.6.0 is moving quickly, and its documentation exposes the limits operators need to test. Record which hook, sandbox, tunnel, and credential controls were active for each protected launch. If the record contains only a product name and a green hook event, the containment claim is incomplete.
