Frona, OpenClaw, and Hermes Agent all aim at the same thing: a personal, open-source AI agent that lives on your own infrastructure, talks across channels, runs tools, and learns over time. Where they diverge is how they get there. Frona is built around two principles that shape almost every feature: everything is sandboxed and policy-gated by default, and the user experience should feel like one product, not a bag of integrations.
Claims about OpenClaw and Hermes Agent on this page are based on their public documentation as of May 2026.
At a glance
| Frona | OpenClaw | Hermes Agent | |
|---|---|---|---|
| Open source | Yes | Yes | Yes |
| Backend | Rust + Next.js | Node/TypeScript | Python |
| Runs on your infra | Docker, Kubernetes | Local-first gateway, mobile companion apps | Local, Docker, SSH, Singularity, Modal, Daytona, Vercel Sandbox |
| Custom agents | Per-agent prompts, models, tools, policies | Per-channel agent routing | Isolated subagents (opt-in) |
| Multi-channel | Telegram, SMS (more on the way) | 25+ platforms | 18+ platforms |
| Skills / reusable knowledge | Skills system (built-in, shared, per-agent) | 100+ AgentSkills | Auto-generated skill docs from solved problems |
| MCP support | First-class, with bridge mode | Tool integrations | Built-in tool set |
| Memory | Per-user + per-agent + space context | Yes | Persistent + auto-generated |
| Sandbox unit | Per principal: sandboxed child process per CLI tool, MCP server, or app | Opt-in; when enabled, one Docker container per agent | One Docker container per Hermes process (when using a container backend) |
| Authorization model | One policy engine for tools, sandbox, channels, signals | Container hardening + scope config | Container hardening + dangerous-command blocklist |
| Vault integrations | 1Password, Bitwarden, HashiCorp Vault, KeePass, Keeper | Bring-your-own keys | Bring-your-own keys |
| SSO | OpenID Connect | DIY | DIY |
| Voice | Outbound calls via Twilio | Voice wake + talk mode (macOS/iOS/Android) | Text-to-speech |
| Apps | Agent-deployed sandboxed web apps with approval flow | Live Canvas with A2UI | DIY |
Security
This is where Frona is most different. The other two projects sandbox what they execute and isolate workspaces; Frona puts every actor (user, agent, MCP server, app, channel) behind a single policy engine and enforces it at the syscall level, without spinning up a container for each one.
One engine, sandboxed children, not containers per agent
Frona doesn't spin up containers per agent. The engine runs as a single process that spawns and manages sandboxed child processes for the work. Each CLI tool call, each MCP server, each app is its own Linux process with policy-driven syscall filtering applied to it. Frona handles the whole lifecycle: spawning, applying policies, issuing ephemeral tokens, monitoring resource limits, killing on policy violation, restarting MCP servers, cleaning up on shutdown. No Docker container per agent, no Docker daemon dependency, no per-agent image lifecycle for you to manage.
OpenClaw and Hermes both put work inside Docker containers, so each new agent or each new MCP server is also a piece of container infrastructure to manage.
| Frona | OpenClaw | Hermes Agent | |
|---|---|---|---|
| Sandbox unit | A sandboxed child process. Each CLI tool call, each MCP server, each app is its own Linux process with its own policies. | Sandbox is opt-in. When enabled, a Docker container holds the agent's tool execution; the default scope is one container per agent. The gateway runs on the host. | A Docker container (or Singularity / cloud equivalent) holding the agent's tool execution. One long-lived backend container per Hermes process. The local and ssh backends have no kernel sandbox. |
| Adding an agent | No new container. Just policies. | If sandbox is enabled, a new Docker container at first use. If sandbox is off, the agent runs on the host. | Each agent is its own profile, which runs as its own Hermes process. With a container backend, that's a new container per agent. |
| Adding a subagent | No new container. Subagents share the parent agent's policy and workspace. | Inside the parent agent's container | Inside the parent agent's process and backend container |
| Adding an MCP server | A new long-running sandboxed child process with its own per-server policies. | An stdio subprocess managed by the gateway; no dedicated MCP sandbox documented. | An stdio subprocess of the Hermes process; no dedicated MCP sandbox documented. |
| Per-task isolation | Default (per principal) | Sandbox itself is opt-in; when on, per-agent | Opt-in per task |
The infra cost difference, with 10 agents and 5 MCP servers:
- Frona: one engine process that spawns and manages a sandboxed child per running thing: one per MCP server, one per deployed app, and a fresh one per shell-tool call (spawned and reaped on demand).
- OpenClaw: if sandboxing is enabled (off by default), 10 Docker containers (one per agent) plus the OpenClaw gateway. MCP stdio subprocesses are managed by the gateway. Adding an agent means another container.
- Hermes Agent: each agent is its own profile / Hermes process. With a container backend, that's 10 Hermes containers, each with its own backend container. MCP stdio subprocesses are children of the Hermes process.
Same per-principal security guarantees in Frona, without the per-agent container baggage and on by default.
Unified policy engine
Every action an agent takes (calling a tool, delegating to another agent, reading a file, opening a network connection, receiving a message) is authorized through Frona's policy engine. Tool access and sandbox rules (read/write paths, network destinations, port binds) are written in the same language.
| Capability | Frona | OpenClaw | Hermes Agent |
|---|---|---|---|
| Enforcement | User-space application kernel (seccomp, ptrace) intercepting every syscall against the principal's policies | Sandbox is opt-in. When enabled: hardened Docker container per agent (seccomp, AppArmor, capability drops); optional Kata microVM. | Container backends only (Docker, Singularity, or cloud sandboxes); the local and ssh backends have no kernel-level sandbox. |
| Filesystem rules | Per-principal allow-list of read/write paths; supports virtual paths (user://, agent://) | Container filesystem; mount-level | Container filesystem; mount-level (where applicable) |
| Network rules | Per-principal allow-list of hosts, ports, CIDRs; forbid ... unless for inverted allow-lists | Container-level (no network by default) | Container / network-namespace level (where applicable) |
| Resource limits | Per-principal and global; offending process killed | Container limits | Backend-dependent |
| Startup verification | Server refuses to start if the sandbox can't be initialized | Sandbox is opt-in | Backend-dependent |
OpenClaw and Hermes both isolate execution at the workspace and process level, but neither exposes a unified policy language for cross-cutting decisions like "this agent can use the CLI tool only when delegated by the system agent", "this MCP server can only reach api.github.com:443", or "this channel only accepts inbound from these paired addresses". In Frona those are one-line policy rules. See Policies.
Dual LLM pattern
Inbound channel messages from external senders are untrusted input, exactly the surface where prompt-injection attacks land. Frona's channel dispatcher implements the Dual LLM Pattern so that a hostile message can never trick the responding agent into running tools or leaking data on its behalf.
Two roles, picked per-message by the policy engine:
- Quarantined LLM. Sees the untrusted content but runs with a restricted tool registry. It can only annotate the message (categorize it, extract signals) and end its task. It cannot reply, cannot delegate, cannot invoke general tools.
- Privileged LLM. Has the agent's normal tool registry and can reply, delegate, and act.
The dispatcher evaluates both receive_message and receive_signal for every inbound:
receive_message | receive_signal | Result |
|---|---|---|
| allow | allow | Privileged LLM (full inference, replies allowed) |
| deny | allow | Quarantined LLM (tag-only, no reply, restricted tools) |
| deny | deny | Discarded; no DB record, no broadcast, no inference |
This makes patterns like "this channel accepts SMS only from paired numbers, but bank alerts can still trigger 2FA capture even when the agent isn't allowed to reply" a policy decision rather than custom code.
OpenClaw and Hermes rely on workspace/container isolation and per-tool approval flows for prompt-injection defense. Neither documents a dispatcher that picks between a privileged and a quarantined LLM run per inbound message.
Principals and ephemeral tokens
Every request to the engine is authenticated as a typed principal: User, Agent, MCP server, App, or Channel. Cross-principal access is rejected at the wire: an MCP server can never act as a user, an agent can never impersonate another agent.
Sandboxed processes get ephemeral tokens scoped to exactly that process. The token expires when the process exits. Even if a sandboxed process leaks its token, the blast radius is bounded to its lifetime and its principal's policies. See Setting Up Authentication.
Vault integrations
Agents request access to credentials with explicit user approval, and the platform pulls values from your vault on every use. Five providers supported out of the box: 1Password, Bitwarden (including self-hosted), HashiCorp Vault, KeePass, Keeper Secrets Manager. Local credentials are encrypted at rest. See Managing Secrets & API Keys.
OpenClaw and Hermes Agent are typically configured with bring-your-own API keys placed directly in environment variables or config files, not pulled from a vault.
User experience
The other two projects are toolkits you assemble. Frona's UX goal is that the platform feels like a single product. You don't need to be a programmer, understand how Docker works, write firewall rules, or hand-edit complex config files. Channels, signals, MCP, and skills all funnel into the same chat surface and the same settings pages, and the system agent can write policies, install MCP servers, and connect channels for you when you ask.
One chat, many surfaces
Whether you're typing in the web UI, sending Telegram, or texting a paired SMS number, you're talking to the same agent in the same space, with the same memory and the same tools. Conversations from every channel show up in real time across devices over SSE. See Channels and Spaces.
Spaces and memory
Spaces group related conversations so an agent has the full background when you start a new chat. Memory is separate: facts about you and per-agent context that survive across all conversations, with periodic compaction so prompts stay efficient. Hermes Agent emphasizes long-running learning via auto-generated skill docs; Frona emphasizes a layered model (memory + space context + skills) you can inspect and edit in one place.
Signals: pause and resume on inbound
An agent can call await_signal to wait for a matching inbound (verification code, reply from a contact, class of message) and resume the conversation when something matches. Continuous signals turn this into long-running monitors with optional JSON-Schema-validated results. Hermes Agent has scheduled automations; OpenClaw has cron tooling. Neither documents a primitive for "pause this conversation until X arrives, then resume with the captured payload". See Signals.
MCP with bridge mode
Frona ships first-class support for Model Context Protocol servers: install from the public registry, configure credentials with vault bindings, sandbox each server independently. The default bridge mode advertises a single mcpctl CLI to the LLM instead of all MCP tools individually. On an agent with five MCP servers and 60+ tools, that replaces 60+ JSON schemas in every prompt with a single CLI definition plus a short server list, saving thousands of tokens per turn. See MCP.
The other two projects ship curated tool sets. Frona instead leans on the MCP ecosystem and treats your MCP servers as first-class, sandboxed citizens.
Skills
Skills are instruction packages (PDF processing, code review, spreadsheet analysis) that agents apply when relevant. They can be built-in, shared across all agents, or scoped to one agent. OpenClaw ships 100+ AgentSkills. Hermes Agent auto-writes skill docs from solved problems. Frona supports installable shared skills and per-agent restrictions, and you can disable skill access entirely for a tightly-scoped agent. See Skills.
Architecture
| Frona | OpenClaw | Hermes Agent | |
|---|---|---|---|
| Engine process | One Rust process | Node.js gateway + agent runtime | One Python process |
| Frontend | Next.js + Tailwind | Web UI + macOS menu bar + mobile nodes | Web dashboard (separate project) |
| Database | SurrealDB embedded | Local-first state | Varies by backend |
| Real-time | SSE | Gateway-driven | Backend-driven |
| Inference | Multi-provider with fallbacks | Multi-provider with fallbacks | Multi-provider with fallbacks |
When to pick which
There's room for all three. Pick:
- Frona if you want security and a finished product, not a kit. Every tool call, channel message, and sandbox decision goes through one policy engine. Credentials are vault-backed, sandboxes are per-principal, SSO is built in, and MCP servers are first-class. You don't write auth glue, harden containers, hand-roll vault integrations, or stitch channels into agents. It's all there on day one.
- OpenClaw if you need very wide channel coverage out of the box (25+ messaging platforms) and a polished mobile/desktop companion experience including voice wake and live canvas.
- Hermes Agent if you want the agent to compound knowledge by writing its own reusable skill docs, and you value flexibility across many deployment backends (local, Docker, SSH, Singularity, Modal, Daytona, Vercel Sandbox).
Sources
OpenClaw
- OpenClaw — openclaw.ai
- OpenClaw documentation
- Sandboxing
- MCP
- Sandboxing & Isolation (DeepWiki)
- Hardening OpenClaw on AKS with Kata microVM Isolation (Microsoft)
Hermes Agent
- Hermes Agent — Nous Research
- Hermes Agent docs
- Configuration
- Docker
- Security
- Tools & Toolsets
- MCP (Model Context Protocol)
- Profiles: Running Multiple Agents
Frona
Other