Securing dangerous actions
rm -rf, a bank transfer, an email to the customer - who stops the agent, where, and what happens when nobody is watching?
Why this is hard
An agent with a shell can do anything the user can. That is the purpose - and the risk. So the fence has to stand in several places: before execution (does anyone ask?), around execution (does it run in a sandbox?) and at the borders (may it reach the network, files, money?). And it has to hold when no human is watching anymore, because the agent was started by cron or by a message.
The layers hang together: execution in tools & loop is where the fence must take effect. Guardrails are the rules checked there. And the MCP binding is the back door: a foreign server brings foreign tools the harness's rules were not written for. Reading the three separately misses the spot where they contradict each other.
From Pro: the matrix per challenge, all eleven topics with citations, and the architecture portrait of every harness. Freely visible are the six short portraits:
- OpenClaw - The multi-channel personal agent - a half-million-line estate of gateway, channels and tooling whose loop core shares its lineage with Pi.
- Hermes - Nous Research's Python harness - deterministic loop, a skill system, and an error path that escalates in stages instead of just giving up.
- Pi - The coding agent with a deliberately small core - every layer hand-built and kept readable, from the provider package to the session file.
- HybridClaw - The enterprise runtime - sandboxed execution, approvals, and credentials that travel through context as references instead of plain text.
- DeepSeek Harness - The plugin radical - “everything is a plugin” is meant literally here: providers, tools and the loop itself are modules on the Cordis core.
- NanoClaw - The minimalist - small enough to understand in full: the model layer moves behind the Claude Agent SDK, isolation into a container.