Experiment: sandbox Coder Agents bash tool-call subprocesses with Coder Boundary (per-tool-call egress allowlist)

[ausbru87]

UPDATE - read the "REVISED APPROACH" comment first. Verification against the Coder Agents docs and reference/coder showed the correct, surgical target is the Coder Agents tool-call exec chokepoint (agent/agentproc/process.go:124), wrapping only the tool-call subprocess, NOT wrapping the whole workspace agent process. Wrapping the agent process (the original framing below) is fragile and risks the control-plane link; it is kept here as background. The agent-networking allowlist comment is still useful context. Implement the REVISED APPROACH.

---

Summary

The live firewalled template proves Coder Boundary (agent firewall) works for the Claude Code process: it runs boundary -- claude and enforces a default-deny HTTP(S) allowlist (landjail / Landlock). What it does not cover is the Coder agent process itself and anything else the agent spawns. This experiment is to build an agents-firewalled template variant that wraps the in-workspace Coder agent process with Boundary, and to determine whether that holds (egress is jailed and audited) or breaks the workspace (agent can't reach the control plane, SSH/port-forward/Tasks UI fail, etc.).

Hypothesis: wrapping the Coder agent process under Boundary will firewall all agent-spawned tool egress, but risks breaking the agent's own control-plane connectivity unless the allowlist and transport handling are correct.

This is a research/experiment task. Expect it may prove infeasible as-is; a clear negative result with evidence is an acceptable outcome.

Background: current working baseline (do not regress it)

• Live template firewalled (org coder, current version weary_ryan08), workspace austenplatform/firewall-test. It is identical to claude-code plus Boundary on the claude process only.
• Boundary wiring lives in the claude-code module (4.7.3) inputs:
  • enable_boundary = true makes the module launch boundary -- claude (via AgentAPI: agentapi server --type claude -- boundary -- claude ...).
  • use_boundary_directly = true, boundary_version = "latest" (currently boundary v0.9.0, installed at /usr/local/bin/boundary, MIT standalone binary, not the coder boundary subcommand).
  • The module passes no --allow / --jail-type flags, so the allowlist and jail type come only from ~/.config/coder_boundary/config.yaml.
• The allowlist is rendered from boundary.config.yaml.tftpl (adapted from the Red Hat Summit 2026 demo) via Terraform templatefile(), base64-written by the module pre_install_script. It allows dev.usgov.coderdemo.io (the AI Gateway egress), gitlab.usgov.coderdemo.io, api.anthropic.com, package registries, and test domains; npm is intentionally omitted as the demo DENY.
• Boundary v0.9.0 dropped config auto-discovery, so the template sets agent env BOUNDARY_CONFIG_FILE=/home/coder/.config/coder_boundary/config.yaml and BOUNDARY_JAIL_TYPE=landjail.
• The pod runs the Coder agent unwrapped: kubernetes_pod_v1.workspace container command is ["sh","-c", coder_agent.main.init_script]. Boundary only ever wraps claude, never the agent.
• Note: the firewalled template is currently live-only and not in git. Part of this task is to land the new template (and ideally the existing firewalled baseline) in the repo under coder-templates/.

Goal / acceptance criteria

See the REVISED APPROACH comment for the corrected, authoritative goal and acceptance criteria (sandbox only the Coder Agents tool-call subprocesses; keep the workspace agent healthy). The original goal below is retained as background.

Deliver an agents-firewalled template (new coder-templates/agents-firewalled/, committed) and a written result. Done = one of:

• SUCCESS: a workspace from the template comes up healthy (agent connected, web terminal + Tasks UI work, git clone to in-cluster GitLab works), AND agent-spawned egress to an off-allowlist domain is denied and audited in /tmp/boundary_logs and surfaces in the Grafana agent-firewall dashboard (uid agent-firewall). Capture a clean DENY and a short recording.
• DOCUMENTED NEGATIVE: a clear writeup of exactly what breaks (with logs), why (transport/connectivity analysis), and what would be required to make it work (e.g. allowlist additions, transport carve-outs, or a different wrapping point). Restore the cluster to the pre-experiment state.

Either way: do not regress the working firewalled template, and capture the boundary decision-log -> Loki -> dashboard path (the agent-firewall panels previously read zero; confirm allow/deny records actually reach Loki).

Environment and access

. ~/.config/usgov-coderdemo/env
export KUBECONFIG=/home/coder/demoenv-workspace/usgov-coderdemo/kubeconfig
export PATH="$HOME/.local/bin:$PATH"
unset CODER_URL CODER_SESSION_TOKEN CODER_AGENT_TOKEN   # ambient CODER_URL points at dev.coder.com; never target it
export CODER_URL=https://dev.usgov.coderdemo.io

• coder CLI session at ~/.config/coderv2/ is valid as admin. For curl: TOK=$(cat ~/.config/coderv2/session), header Coder-Session-Token: $TOK.
• Workspaces run in ns coder-workspaces (pods coder-<workspace-id>). Inspect with kubectl exec.
• Coder source to verify against: ~/demoenv-workspace/reference/coder (~2.34.1). Reference allowlist + bridge pattern: ~/demoenv-workspace/reference/demo-aigov-rhsummit-2026.

Guardrails

• Do not modify or rebuild the working firewalled or claude-code templates; add a new agents-firewalled template.
• Use a single dedicated test workspace; do not disrupt other users' workspaces.
• Never print secret values. Do not run gitlab-rails (memory constrained).
• Repo conventions: no emdash/endash/spaced-double-hyphen; commit type(scope): message with a real path scope; body ends with a line Generated by Coder Agents. Open a PR (don't push to main); PR discloses "Generated by Coder Agents, on behalf of @ausbru87". Pull --rebase before push; explicit refspec; no force-push.

Rollback

• Delete the test workspace and the agents-firewalled template version if the experiment fails: coder templates delete agents-firewalled --org coder (after deleting its workspaces). The firewalled baseline and all other templates remain untouched.

References

• Live baseline: firewalled template + austenplatform/firewall-test workspace (pod coder-7771f506-...).
• docs/architecture/agent-firewall-feasibility.md (WS-22), deploy/observability/dashboards-boundary.yaml (uid agent-firewall).
• Boundary: standalone boundary v0.9.0, MIT, /usr/local/bin/boundary, landjail/Landlock.
• Coder Agents architecture: coder.com/docs/ai-coder/agents.

---

Generated by Coder Agents, on behalf of @ausbru87.

[ausbru87]

Research findings: Coder agent networking + Boundary allowlist

Read-only investigation of the Coder source at reference/coder (v2.34.0-rc.0-706-g47a8c9572f, functionally ~2.34.1; confirm specifics against tag v2.34.1 if needed) plus the live boundary v0.9.0 in the firewall-test pod. This tells the pickup agent what to allowlist and, more importantly, what will actually make or break wrapping the agent.

TL;DR

• The allowlist is the easy part. The in-workspace Coder agent dials exactly ONE host for all control-plane function: the access URL dev.usgov.coderdemo.io over 443 (HTTPS + WSS). The existing firewalled allowlist already permits it. The experiment will NOT fail on the allowlist.
• The enforcement mechanics are the hard part. Boundary is an L7 HTTP(S) proxy + landjail (Landlock). It forces TCP through its proxy and hard-blocks any non-proxied TCP. So whether the agent survives depends on whether the agent's Go HTTP/WS client uses the HTTPS_PROXY boundary sets. Verify that first (Risk 1 below) before anything else.

What the agent talks to (where to look)

All control-plane traffic targets the access-URL host only:

What	Path (on access URL host)	Proto	Source
One-time agent binary download	/bin/coder-linux-${ARCH}	HTTPS	provisionersdk/scripts/bootstrap_linux.sh:13,88
Primary multiplexed tunnel (manifest, coordinate, DERP-map stream, stats, logs, lifecycle)	/api/v2/workspaceagents/me/rpc	WSS	codersdk/agentsdk/agentsdk.go:357,372; agent/agent.go:1090,1925,1989
Embedded DERP relay (tailnet data fallback)	/derp, /derp/latency-check	WSS/HTTPS	coderd/coderd.go:1069-1080; tailnet/derp.go:91-125
git ssh key / external-auth / reinit / logs / app-status	/api/v2/workspaceagents/me/*	HTTPS	codersdk/agentsdk/agentsdk.go:77,636,662,684,749,794

The agent makes no telemetry, update-check, or third-party calls by default. The only non-access-URL call is link-local 169.254.169.254 for cloud instance-identity auth, and only when CODER_AGENT_AUTH is aws/azure/google (this deployment uses token auth, so not used). SSH/port-forward/PTY/apps are inbound over the tailnet (inside /rpc+/derp), not agent egress. Wildcard *.usgov.coderdemo.io is used by browser clients, not the agent.

DERP / STUN / UDP behavior

• The agent's tailnet prefers direct P2P (UDP, via STUN) and falls back to DERP-relayed over HTTPS to the access URL. The embedded DERP relay lives at the access URL host:443 (cli/server.go:585-601, codersdk/deployment.go:2277-2316). Control channel and DERP fallback are the same host:port, so allowing the access URL keeps the agent fully functional even with zero UDP.
• Default STUN = Google stun.l.google.com:19302 + stun1-4 over UDP 19302 (codersdk/deployment.go:2323-2331, tailnet/derpmap.go:21-54). Used only for direct P2P.
• Blocking UDP/STUN costs only direct P2P (a latency/throughput optimization); everything keeps working relayed. /derp/latency-check exists for exactly the UDP-blocked case.

Boundary enforcement model (the real constraints)

Boundary v0.9.0 with BOUNDARY_JAIL_TYPE=landjail:

• It is an HTTP(S) CONNECT proxy on :8087 with TLS MITM (its own CA). The allowlist is evaluated at L7 (host/method/path). Child env is set to HTTP(S)_PROXY=http://localhost:8087 and SSL_CERT_FILE/CURL_CA_BUNDLE/NODE_EXTRA_CA_CERTS/GIT_SSL_CAINFO -> boundary CA.
• landjail = Landlock LSM, no netns/iptables, no added caps. Landlock restricts TCP connect: any non-proxy TCP connect is hard-denied at the syscall (not allowlist-evaluated). This is what forces cooperating clients through the proxy.
• UDP (STUN, WireGuard, DNS) is invisible to boundary and unrestricted (Landlock has no UDP hooks). So boundary gives NO control over the agent's UDP path; it just bypasses. DNS is unaffected under landjail (real cluster resolver).
• Allowlist syntax is L7 only: domain=, domain=*.sub, method=, path=. There is no port=/cidr=/protocol= -> you cannot express "allow UDP to host".

The risks this experiment must actually test (in priority order)

1. Does the agent's WSS/HTTPS client honor HTTPS_PROXY? (make-or-break.) The RPC dial uses c.SDK.HTTPClient.Transport (codersdk/agentsdk/agentsdk.go:~368), and the SDK client is built with HTTPClient: &http.Client{} (codersdk/client.go:121) -> nil Transport -> Go http.DefaultTransport, which DOES use http.ProxyFromEnvironment. So it should traverse the boundary proxy. But verify empirically: if any custom transport bypasses proxy env, Landlock will hard-block the agent's direct connect to :443 and the agent will never come up. Test: wrap, then check the workspace reaches Healthy and watch /tmp/boundary_logs for the agent's CONNECT to the access URL.
2. TLS MITM trust. The Go agent must trust boundary's CA. Go honors SSL_CERT_FILE/SSL_CERT_DIR (set by boundary) on Linux. Confirm the wrapped agent process inherits those env vars, or all its HTTPS fails with x509 errors.
3. Config/env bootstrap chicken-and-egg. BOUNDARY_CONFIG_FILE, BOUNDARY_JAIL_TYPE, and the rendered allowlist are currently provided via coder_env/the module pre_install_script, which run as/after the agent starts. If you wrap the agent itself, those do not exist yet. Provide the allowlist file + BOUNDARY_* + CA via pod env and a pre-exec step baked into the container command (e.g. write config then boundary -- sh -c "$init_script"), NOT coder_env.
4. Long-lived reconnecting WSS through an intercepting proxy is brittle (Upgrade handling, reconnect storms). Consider setting CODER_DERP_FORCE_WEBSOCKETS=true so DERP uses standard WSS framing a proxy handles cleanly. Note: coderd currently has neither CODER_BLOCK_DIRECT nor CODER_DERP_FORCE_WEBSOCKETS set (checked live).

Recommended allowlist + optional toggles

Allowlist (agent egress): domain=dev.usgov.coderdemo.io (mandatory; covers binary, /rpc, /derp, all me/*), domain=gitlab.usgov.coderdemo.io (git), domain=*.usgov.coderdemo.io (harmless; apps). All three are already in the firewalled config.

To make the egress story clean instead of relying on UDP silently slipping past boundary, set on coderd: CODER_BLOCK_DIRECT=true and/or CODER_DERP_SERVER_STUN_ADDRESSES=disable (codersdk/deployment.go:2323-2355, tailnet/derpmap.go:19-26). Then agents never attempt UDP/STUN and use DERP-over-HTTPS to the access URL exclusively, which boundary can see and allow. (Deployment-wide change, get sign-off.)

Honest caveat for the writeup

Boundary (landjail) is an L7 sandbox for short-lived agent CLIs, not a network firewall. Wrapping the long-running Coder agent mainly forces its HTTP(S) calls through the allowlist; it will NOT control the agent's UDP egress (STUN/WireGuard bypass entirely), and the agent's own intercepted, long-lived control WebSocket is the fragile point. If the real goal is controlled/audited egress for the agent, pair this with a Kubernetes NetworkPolicy / egress gateway. A clean documented negative ("agent control channel does/does not survive the intercepting proxy") is a valuable result here.

Consolidated file:line pointers

• Agent RPC dial + transport: codersdk/agentsdk/agentsdk.go:357,368,372; SDK client codersdk/client.go:121.
• Manifest/coordinate/DERP stream: agent/agent.go:1090,1265,1506-1534,1925,1989.
• Embedded DERP relay at access URL: cli/server.go:585-601; coderd/coderd.go:1069-1080; tailnet/derp.go:91-125.
• STUN defaults + DERP map build: codersdk/deployment.go:2277-2355; tailnet/derpmap.go:19-54,123-134.
• Block-direct toggle: codersdk/deployment.go:2345-2355; tailnet/conn.go:103-105,241,529-534.
• Bootstrap binary URL: provisionersdk/scripts/bootstrap_linux.sh:13,87-88.

---

Generated by Coder Agents, on behalf of @ausbru87.

[ausbru87]

REVISED APPROACH (supersedes the "wrap the whole agent process" framing in the description)

Verified against the Coder Agents docs (coder.com/docs/ai-coder/agents) and the reference/coder source. The goal, restated: when Coder Agents (the server-side agent loop, NOT Coder Tasks) issues a bash tool call that runs curl <off-allowlist> in the workspace, it should be blocked with a 403, exactly like wrapping Claude Code in landjail, without breaking the workspace coder agent or its control-plane link. We can do this far more surgically than wrapping the whole agent.

Architecture (docs + code agree)

• The agent loop runs in the control plane; the workspace has no AI harness, no LLM keys. Tool calls execute by connecting to the workspace over the existing workspace (tailnet) connection. (docs: coder.com/docs/ai-coder/agents)
• Harness is server-side: coderd/x/chatd (loop in coderd/x/chatd/chatloop/). The bash tool is the execute tool, coderd/x/chatd/chattool/execute.go ("Execute a shell command in the workspace. Runs under sh -c").
• IMPORTANT correction to my earlier note: the tool-call exec path is distinct from SSH / the web terminal. It does NOT go through agentssh; it uses a dedicated workspace-agent HTTP API over the tailnet:

control plane (chatd)
  coderd/x/chatd/chattool/execute.go:208   conn.StartProcess(ctx, {Command, Env, WorkDir, Background})
  codersdk/workspacesdk/agentconn.go:1164  POST /api/v0/processes/start   (over tailnet)
workspace coder agent
  agent/api.go:34                          r.Mount("/api/v0/processes", processAPI.Routes())
  agent/agentproc/api.go:89                manager.start(req, chatID)
  agent/agentproc/process.go:124           cmd := execer.CommandContext(ctx, "sh", "-c", req.Command)   <-- CHOKEPOINT
  agent/agentproc/process.go:168           cmd.Start()

• This agentproc.manager.start path is used only by chatd process tools (execute, process_*). SSH, PTY, and the web terminal do not flow through it. So we can jail tool calls only (better than the "jail both" tension I raised earlier; that tension does not actually apply here).
• The spawned sh -c is a direct child of the coder agent process (procSysProcAttr sets only Setpgid, agent/agentproc/proc_other.go:14). A Landlock/boundary jail applied to that child governs the tool command and all its descendants.
• Wrapping a child process does NOT affect the agent's own control-plane connection (that is the agent's in-process Go HTTP/WSS, not a subprocess). This is why this approach avoids every control-plane risk from the prior comment.

Recommended implementation: wrap the tool-call command at the chokepoint

Minimal change at agent/agentproc/process.go:124: when an opt-in flag is set, build the command as boundary -- sh -c <req.Command> instead of sh -c <req.Command>, and pass the egress allowlist to boundary via env (the request already plumbs req.Env into cmd.Env at process.go:159-161, and the execute tool already injects env at chattool/execute.go:120-124).

• Precedent for the exact pattern: agentexec.Execer already rewrites commands to coder agent-exec [--coder-nice/-oom] -- <cmd> when CODER_PROC_PRIO_MGMT is set (agent/agentexec/exec.go:95-118). Boundary wrapping is the same <wrapper> -- <cmd> shape, just scoped to agentproc tool calls.
• Gate it behind an env/flag the workspace template can set (e.g. CODER_CHAT_TOOL_BOUNDARY=1 plus BOUNDARY_CONFIG_FILE / BOUNDARY_JAIL_TYPE=landjail), so only agent-dedicated templates opt in. Linux-only; guard by GOOS and boundary availability (agent/agentproc/proc_windows.go differs).

Why not template-only

There is no existing template/env "command prefix" knob for tool-call exec, and tool calls run sh -c directly (no login/interactive shell), so .bashrc/alias/BASH_ENV wrappers will NOT catch them. Options:

• BEST: the small agentproc code change above (a coder/coder patch; ship a patched agent or upstream it as a feature). Scopes the jail to exactly the Coder Agents tool calls.
• NOT RECOMMENDED template-only hack: shim sh earlier in the agent PATH to exec boundary -- /bin/sh "$@". This also jails the agent's OWN sh uses (startup script, metadata scripts like coder stat), which is fragile and can break the workspace. Only consider for a throwaway proof, with the allowlist permitting whatever startup/metadata need.

Allowlist for this scope

For the tool-call jail, allow what legitimate agent work needs and deny the rest (the demo DENY): domain=dev.usgov.coderdemo.io (Coder access URL / AI Gateway), domain=gitlab.usgov.coderdemo.io (git), plus any package registries the agent's tasks require. An off-allowlist curl (e.g. registry.npmjs.org or arbitrary internet) then returns a boundary 403, exactly like the Claude Code landjail does today. Note boundary only filters HTTP(S); raw non-proxied TCP from a tool is hard-denied by Landlock and UDP bypasses, same semantics as the existing firewalled template.

Acceptance criteria (revised)

1. A Coder Agents bash tool call to an allowed host succeeds; a tool call to an off-allowlist host is DENIED (boundary 403) and audited in /tmp/boundary_logs + the Grafana agent-firewall dashboard.
2. The workspace coder agent stays healthy throughout (control plane, web terminal, metadata, Tasks all unaffected) because only tool-call subprocesses are jailed.
3. Deliver the patch (or patched agent build) + the opt-in template, and document the exact flag/env.

Pointers

• chatd / tools: coderd/x/chatd/chatd.go:7900-7960, coderd/x/chatd/chattool/execute.go:66-124,144,208.
• transport: codersdk/workspacesdk/agentconn.go:1161-1164,1244.
• chokepoint: agent/agentproc/process.go:124,159-161,168; routes agent/agentproc/api.go:55-61,89; agent/api.go:34.
• wrapper precedent: agent/agentexec/exec.go:46-118.

---

Generated by Coder Agents, on behalf of @ausbru87.