You install a coding agent and point it at a repo. Which files can it read, and what stops it?
For some setups the honest answer is "everything your user can." The harness gives you control points, but the boundary and the policy are yours.
A note on method. I read the current documentation of two open-source agent projects, OpenHands and the Strands Agents Python SDK, plus a harness-engineering survey. Every factual statement below carries a marker like `` that maps to one of those three sources. Where I give an opinion or a reading of a README, I say so. I do not call any project "safer" than another, because I found no comparison made on equal terms.
1. The default question: where does the agent run?
Start with the most uncomfortable line in the OpenHands README. It documents that running the agent without a sandbox gives it full access to the host filesystem.
What matters is where the code runs in that mode. Without a sandbox, the OpenHands agent-server runs directly on the host machine rather than in a container.
Fine for a throwaway laptop. A very different choice on a developer machine that holds SSH keys, cloud credentials and ten other repositories. I'd settle the run mode before the first task, not after the first surprise.
A cheap habit: in your own wrapper, print the run mode at the start of every task and stop if it is not the one you expect.
2. Docker helps, but only as far as you mount
OpenHands can run each new conversation in its own Docker container, with its own Agent Server and tools. That narrows what one conversation can break.
The catch is the mount. In the Docker sandbox option, the agent can access any project under PROJECTS_PATH, a host directory the user chooses. The container is only as narrow as the directory you hand it.
Here is the difference, as an illustration of the idea rather than a copy of any official setup:
`bash
Narrow: one project only. The narrow path is the whole point: one task, one repo.
export PROJECTS_PATH="$HOME/work/payments-service"
Broad: every project you have ever cloned (commented out so this block is safe to paste)
export PROJECTS_PATH="$HOME/work"
`
With the second value, a task about one service can reach every other repository under that directory, because the documented behaviour is access to any project under the path.
3. The control plane sits outside the sandbox
Isolating where the agent executes does not harden the service around it. Per-conversation Docker isolation in OpenHands does not sandbox the whole Canvas or automation service. Treat that service as its own system to harden.
For internet-facing installs, OpenHands points readers to its self-hosting guide for security hardening, and the project is MIT licensed. I did not open that guide, so read it yourself before exposing an install.
4. What Strands gives you: control points, not a policy
The Strands Agents SDK takes a different shape. Its README lists a set of control points. I group them by the job they do:
- Observe. Hooks let you intercept any step to log it, validate it or redirect it.
- Limit. Guardrails catch mistakes before they run. Lifecycle controls include turn limits, token budgets, cancellation and stop reasons.
- Recover. Steering handlers let agents correct themselves instead of failing silently.
My opinion on order: set the limits first, then add hooks so you can see what the limits catch.
A single create_harness() call in Python, or createHarness() in TypeScript, returns an optimized agent, in the README's words. The SDK is Apache-2.0 licensed.
These are mechanisms. My reading of the README excerpt is that it states no default policy, so what to block, what budget to set and what to log would fall to whoever deploys it; check the repository before relying on that.
The README excerpt I used shows no hook example, so for working code, go to the repository.
5. What the survey says is still open
The harness-engineering survey gives an outside view. It says it covers 110+ papers and 23+ deployed systems, and identifies nine open challenges.
Security and sandboxing is challenge number one. The survey attributes 15–35% frontier-model container escape rates to a benchmark it calls SandboxEscapeBench, and I saw that figure only second-hand, so treat it as the survey's claim.
The survey's advice is blunt: treat sandboxing as a hard requirement and apply defense-in-depth. It also lists a harness-specific threat model, covering tool hijacking, context poisoning and agent impersonation, as future work.
For anyone planning multi-agent setups, one more line stands out. The survey says Byzantine fault tolerance remains unsolved for adversarial multi-agent settings. The term comes from the problem of getting generals who communicate only by messenger to agree on a plan when some may be traitors, per Lamport, Shostak and Pease.
6. What I would ask for before a pilot
This section is my opinion, not a sourced finding. If I were setting a baseline for coding agents in a company, I would ask for these before the first pilot:
- Sandbox on by default, with the run mode checked in tooling, so nobody discovers the host-level mode by accident.
- Narrow mounts: one project per task, so one mistake stays small.
- The control plane treated as its own system to harden, separate from the execution sandbox, since the sandbox does not cover it.
- Budgets and turn limits set explicitly, so a runaway task stops.
- Hooks that log every step, so you can see what happened.
- Human approval for high-stakes steps, so a person owns the risky calls.
The last items line up with the survey's governance layer, which covers security constraints, human handoff points, HITL policy, audit trails and compliance enforcement. Separately, in its section on multi-agent fault tolerance, the survey recommends gating high-stakes coordination on human approval.
Each item is cheap to check before a pilot and expensive to retrofit. Ask each team to show, not describe, the run mode, the mount, the budget and the log. If any of the four is "we will look into it", the pilot is not ready. None of this needs a particular product; it needs someone to own the answers, hence the question below.
Draw the boundary before the agent runs. Which boundary do you enforce today for coding agents, and who owns it on your team?
Top comments (2)
Item 2 is the one I keep coming back to for agents that drive a GUI instead of a repo: there the screen is the mount, and a container doesn't narrow it. Did the survey cover computer-use agents at all, or are they outside its 23 systems?
One thing we learned building Auten (a computer-use MCP server): pin each saved login to the site it was first used on, and keep the command that re-pins it behind the client's shell permissions. Otherwise the pin is only as strong as the agent's shell access.
“The screen is the mount” is a sharper way to put it than anything in my post.
To your question: not as deployed systems. The survey lists computer-use environments (OSWorld, BrowserGym) only as evaluation infrastructure, not production harnesses. That looks like a real gap.
And agreed on login pinning. If the agent’s shell can re-pin the credential, the pin isn’t a boundary.
How do you handle the screen itself? Do you limit which apps or windows the agent can see, or is it all-or-nothing today?