Frona, OpenClaw, and Hermes Agent are capable open-source personal-agent platforms. All three can run on your own infrastructure, use tools and MCP servers, connect to messaging platforms, and retain information between conversations.
The meaningful difference is no longer whether a product has “memory” or “sandboxing.” They all do. The difference is what each product treats as a security boundary and what it is willing to accept as durable knowledge.
Frona is built around two choices:
- Every actor has an identity and every privileged action is authorized. Users, agents, MCP servers, apps, and channels are separate principals governed by one policy engine.
- Model output is a memory proposal, not automatically a fact. Frona's PKM backend grounds claims in evidence, resolves identities, reconciles changes, and validates the resulting knowledge graph before committing it.
This comparison was reviewed against the projects' public documentation on August 28, 2026. Features change quickly; the linked primary sources are the final authority.
At a glance
| Frona | OpenClaw | Hermes Agent | |
|---|---|---|---|
| Product shape | Self-hosted, multi-user web platform with a Rust engine | Local-first personal-agent Gateway with web, desktop, and mobile surfaces | Single-tenant Python agent centered on CLI, profiles, bots, and messaging |
| Deployment model | Docker Compose or Kubernetes; one engine can serve multiple users | One trusted operator boundary per Gateway; experimental Fleet runs a complete isolated cell per tenant | Local install, Docker/Compose, remote terminal backends, or whole-process OpenShell isolation |
| Long-term memory | Basic summaries or integrated PKM: grounded atomic claims, typed entities, relationships, playbooks, and Markdown pages | Markdown user model, durable notes, daily memory, hybrid search, dreaming, and optional memory engines/wiki | Bounded MEMORY.md + USER.md, full-text session search, learned skills, and eight optional external memory providers |
| Default memory scope | Per user and available across that user's agents; space context adds project-level continuity | Primarily per agent workspace; optional wiki vault can be global or per agent | Per profile; an external provider is needed for shared cross-agent memory |
| Execution isolation | Sandboxed child processes for CLI calls, MCP servers, and apps; enabled and verified by default, but explicitly disableable | Tool sandbox is configurable and off by default; Gateway and native plugins remain outside it | Default terminal backend runs on the host; production with untrusted input requires whole-process Docker or OpenShell |
| Authorization | One Cedar policy model for tools, delegation, messages, files, network destinations, and port binds | Gateway auth, sender policies, tool policy, approvals, sandbox configuration, and operator roles | Gateway allowlists/pairing, tool controls, approvals, and isolation-backend configuration |
| Multiple users | Accounts, ownership boundaries, groups, local auth, PATs, and OIDC SSO in one platform | Multiple people can collaborate, but one Gateway is not an adversarial tenant boundary; isolate tenants into separate cells | Authorized callers inside one adapter share the same capability level; use separate instances for capability separation |
| Credentials | Encrypted local store plus 1Password, Bitwarden, HashiCorp Vault, and KeePass; time-bound grants and access logs | SecretRefs, protected store, 1Password and Vault integrations, auditing, and an optional secret-egress proxy | .env/config credentials with environment filtering and redaction; Docker egress proxy or OpenShell Provider store for stronger isolation |
| MCP | Registry installation, per-server policies and sandbox, credential bindings, and token-saving bridge mode | Native MCP support with policy-controlled exposure; MCP execution remains in the Gateway trust boundary | Stdio and HTTP MCP, OAuth, curated catalog, per-server filtering, and credential filtering |
| Best fit | Governed, inspectable assistants for people or teams that prioritize security and reliable long-term knowledge | Broad device/channel ecosystem and a highly configurable local-first personal assistant | Flexible CLI/research agent with many tools, deployment backends, and pluggable memory services |
What this table does not imply
“Supported” does not mean “identical.” A container, a tool allowlist, and a principal-aware authorization engine solve different problems. Likewise, Markdown notes, vector recall, and an evidence-backed knowledge graph are different kinds of memory.
Security: where the trust boundaries are
Security comparisons become misleading when they count checkboxes. The useful questions are:
- Who is allowed to act?
- What is the smallest unit that can be isolated?
- Does the control cover every execution path or only selected tools?
- What happens when untrusted content reaches the model?
- Where do credentials live, and can access be limited and audited?
Security model comparison
| Security question | Frona | OpenClaw | Hermes Agent |
|---|---|---|---|
| Primary trust model | Multiple authenticated users and typed service principals inside one application | One trusted operator boundary per Gateway | One trusted operator/tenant per agent instance |
| Workload boundary | Each CLI invocation, MCP server, and deployed app runs as a separately identified sandboxed child process | When enabled, tool execution runs in a Docker, Podman, SSH, or OpenShell environment; scope can be shared, per agent, per session, or required per creator role | A terminal backend isolates shell/file operations; only whole-process Docker or OpenShell covers the Python agent, code execution, MCP, plugins, hooks, and skills together |
| Default posture | Sandbox enabled; startup verifies the selected driver. Network access is configurable and currently defaults to full access | Agent-wide sandbox mode defaults to off; Docker sandbox networking defaults to none once sandboxing is enabled | Local terminal backend runs directly on the host; approvals and scanners are guardrails, not containment |
| Fine-grained authorization | Cedar policies evaluate principal, action, resource, and context across tools, delegation, messages, filesystem, and network | Strong tool/sender/sandbox controls, expressed across several configuration surfaces | Allowlists, pairing, tool settings, command approval, website blocking, and backend policy |
| MCP and extension isolation | Each MCP server has its own principal, ephemeral token, process sandbox, filesystem rules, network rules, and credential bindings | Native plugins execute in-process with Gateway privileges; MCP and plugin tools are Gateway-side even when a session uses a tool sandbox | MCP subprocesses and plugins remain in the agent process trust envelope unless the whole Hermes process is wrapped |
| Untrusted inbound content | receive_message and receive_signal policy decisions can discard input or route it into a tag-only task with a restricted registry and no reply capability | Wraps and sanitizes external content; recommends a dedicated restricted reader agent for hostile content | Scans context and memory for injection patterns; the security policy treats scanners as heuristics and requires OS isolation for untrusted surfaces |
| Credential lifecycle | The user approves a credential binding once, for hours, days, or permanently; grants are revocable and each access is logged | SecretRefs keep supported values out of config, with audit/apply workflows and optional egress-time injection; local protected-store values are not encrypted at rest | Filters subprocess environments and redacts common secret formats; Docker egress proxy/OpenShell can keep real keys out of the workload |
| Identity and login | Local accounts, Argon2 passwords, JWT rotation, PATs, groups, and OIDC SSO | Gateway token/password, device pairing, trusted-proxy auth, profiles, and operator roles; authenticated operators remain within one Gateway trust domain | Per-platform allowlists and DM pairing; callers inside the authorized set have equal capability |
Why Frona's policy engine matters
A sandbox answers “what can this process reach?” It does not by itself answer “which agent may invoke this tool?”, “may this MCP server act for this user?”, or “should a message from this sender be allowed to trigger a privileged run?”
Frona sends those decisions through the same Cedar policy engine. A rule can target a typed principal, action, resource, and request context. The model covers:
- tool invocation, agent delegation, and agent-to-agent messaging;
- filesystem reads and writes;
- outbound connections and listening ports;
- inbound message and signal sources;
- users, agents, MCP servers, deployed apps, channels, and contacts.
This gives Frona one authorization vocabulary from the chat surface down to the sandbox. A narrowly scoped MCP server, for example, can be permitted to connect only to api.github.com:443, read no user files, and receive only its own process-scoped token.
OpenClaw and Hermes both offer meaningful hardening. OpenClaw now has detailed security auditing, role-required sandboxes, hardened container defaults, external-content sanitization, SecretRefs, and an experimental isolated Fleet model. Hermes has fail-closed gateway allowlists, dangerous-command approval, credential filtering, hardened Docker settings, and a clearly documented whole-process OpenShell posture. Frona's advantage is not that these projects lack security features; it is that identity, authorization, sandbox rules, and credential grants are designed as one application-level system.
Sandboxing without one container per principal
Frona's engine spawns work as child processes and applies the selected operating-system sandbox driver. A CLI call is created and reaped on demand; an MCP server or app is supervised as a long-running child. Each receives rules generated from its own principal and a short-lived token that expires with the process.
This differs from the container-centric isolation paths in OpenClaw and Hermes:
- OpenClaw's default sandbox backend creates container environments at shared, agent, session, or creator-principal scope. Its Gateway and native plugins stay on the host side of that boundary.
- Hermes can isolate terminal operations in a backend container, but its own security policy says that code execution, MCP, plugins, hooks, and skills require whole-process wrapping when input is untrusted.
Containers and OpenShell can provide stronger infrastructure boundaries for hostile workloads. Frona's design optimizes for always-on, per-principal enforcement inside a multi-user assistant platform without requiring a separate full application instance or long-lived container for every user, agent, or MCP server.
Credentials are grants, not environment setup
All three projects have improved secret handling. The distinction to emphasize is the access workflow.
In Frona, an agent that needs a credential pauses and asks the user to bind a vault item. The user chooses the item and the lifetime: once, hours, days, or permanent. Values are injected into the sandbox environment, not printed in chat. Grants can be revoked immediately, and access records identify the agent, conversation, reason, and time. Local values are encrypted with AES-256-GCM; external values can come from 1Password, Bitwarden, HashiCorp Vault, or KeePass.
OpenClaw's SecretRefs and egress proxy are strong options for operator-configured secrets, and its 1Password/Vault integrations invalidate the old claim that it only uses plaintext environment variables. Hermes likewise filters credentials and offers an egress proxy or OpenShell Provider store. Frona's differentiator is the productized, user-facing approval, expiry, revocation, and audit lifecycle for each agent or MCP principal.
Inbound messages can lose privilege
Frona evaluates both receive_message and receive_signal for every inbound source:
| Message decision | Signal decision | Outcome |
|---|---|---|
| Allow | Allow | Normal agent run: may reply and use its authorized tools |
| Deny | Allow | Tag-only quarantined run: restricted tools, cannot reply |
| Deny | Deny | Discarded without inference |
This lets an operator accept a verification code or classify an alert without granting that sender the ability to steer a tool-enabled conversation. It is a policy boundary, not a prompt asking the model to be careful. See channel authorization and signals.
Memory: recall is not the same as knowledge
OpenClaw and Hermes have both added substantial memory functionality. It would be inaccurate to describe either one as having only a simple transcript summary.
- OpenClaw has one of the broadest recall stacks:
USER.md,MEMORY.md, daily notes, hybrid vector and keyword search, importance/recency ranking, automatic pre-compaction flush, provenance-aware dreaming, optional session indexing, alternate memory engines, and a bundled memory-wiki plugin. - Hermes Agent keeps a small curated profile in every prompt, searches the complete session history with SQLite FTS5, turns solved work into skills, and can add one of eight external memory providers for semantic retrieval, user modeling, or managed knowledge.
- Frona includes a lightweight Basic backend and an integrated PKM backend. PKM is less about maximizing recall sources and more about deciding which claims are safe and coherent enough to become durable shared knowledge.
Memory model comparison
| Memory question | Frona PKM | OpenClaw | Hermes Agent |
|---|---|---|---|
| Unit of durable knowledge | Atomic claim attached to a typed entity, with evidence and lifecycle state | Core: curated Markdown directives/notes and daily files. Optional wiki: structured claims and pages | Core: delimited entries in bounded MEMORY.md and USER.md. Providers add their own units |
| Who shares it | A user's agents share one personal knowledge graph; spaces separately carry project context | Core memory lives in each agent workspace; wiki vault can be global or per agent | Memory is profile-scoped; use an external provider for cross-agent sharing |
| How it is created | Immediate short memory plus scheduled extraction from conversations, task events, and qualified tool evidence | Agent writes files; memory flush and dreaming promote selected material; plugins can compile other sources | Agent adds/replaces/removes entries; provider plugins sync turns and extract according to provider behavior |
| Grounding | Each accepted claim retains admissible source evidence. Agent prose needs user, task, or successful tool support; recalled memory cannot prove itself | Automatic ingestion tracks source-session lineage; dreaming taint-gates promotion; optional wiki claims can carry evidence and provenance | Built-in entries are model-curated and injection-scanned but do not carry per-claim source evidence; session search returns original messages. Provider behavior varies |
| Identity resolution | Matches aliases, types, attributes, relationships, and context against the effective ontology before merging or creating an entity | Core uses files; optional wiki supports canonical IDs, aliases, entity metadata, and relationships | Built-in memory is flat text; provider behavior varies |
| Corrections and conflicts | Reconciles new and existing atomic claims, preserves history, and projects the current state; inconsistent facts can remain quarantined | User-model directives can be superseded; dreaming consolidates; wiki claims can be contested and resolved | The model replaces or removes built-in entries; external-provider behavior varies |
| Schema validation | Proposed types, relations, properties, and graph changes are validated against a bundled plus user-extended ontology before atomic commit | Optional wiki provides a structured belief layer, but core memory and wiki remain separate plugin layers | No common schema across the built-in store and external providers |
| Procedural memory | Successful workflows and tool evidence can become linked, reusable playbooks | Skills and standing intents complement memory; optional wiki can store maintained knowledge | Agent-created skills capture solved procedures; Learning Journey shows accumulated skills and memories |
| Retrieval | Small profile, recent memory, and playbook index are pushed; pages are searched/read on demand and usage is recorded | Hybrid vector + BM25 search with recency, importance, and diversity ranking; optional transcript and multimodal indexing | Core profile is injected at session start; SQLite FTS5 searches all sessions; provider retrieval is prefetched and exposed through tools |
| Human inspection | UI graph, entity pages, ontology browser, citations, consolidation state/history, and Markdown vault | Editable Markdown, CLI diagnostics, Control UI, Dream Diary, and optional wiki dashboards/pages | Editable Markdown, session browser/search, and Learning Journey; provider tools vary |
Frona treats model output as a proposal
The central PKM problem is not storage capacity. It is preventing four common model failures from becoming self-reinforcing memory:
| Failure | Example | Frona's check |
|---|---|---|
| Invention | The agent states a plausible detail that no source supports | Grounding retains only claims backed by an admissible source span, confirmed task event, or successful evidence-bearing tool result |
| Misclassification | The same kind of project or person is given several improvised types | Classification works against the effective ontology and proposes new vocabulary explicitly |
| Identity collapse | Two people with the same name are merged, or one service is duplicated under aliases | Resolution compares types, aliases, attributes, relations, and identity evidence |
| Contradiction | An old endpoint remains current after a migration | Reconciliation preserves the prior claim, records the change, and projects only the accepted current state |
The full proposed schema and instance graph are validated together before commit. Facts that cannot be reconciled can remain suspect rather than silently entering the pages agents retrieve. See Personal Knowledge Management for the pipeline and data model.
Shared by the user, not trapped in one agent
Frona's PKM graph belongs to the user. If the Researcher learns a grounded fact about a project, the Developer can retrieve it later without copying Markdown between agent profiles or configuring a third-party memory service. Spaces add a separate, narrower layer: summarized context shared only by the conversations and agents working inside that project space.
This is intentionally different from OpenClaw's agent-workspace default and Hermes's profile-scoped core memory. Both competitors can create broader sharing—OpenClaw with a global wiki vault and Hermes through external providers—but Frona makes the user the native ownership boundary for long-term personal knowledge.
Inspectable evidence, not just a confident answer
Frona projects its graph into readable Markdown and exposes the underlying entities, relationships, memory history, ontology, citations, and consolidation runs in the UI. When a page is useful, the agent cites it; that use becomes a retrieval signal. When a claim looks wrong, the user can trace it back to the conversation, note, task event, or tool result that supported it.
OpenClaw deserves credit here: its newer provenance-aware memory and optional memory-wiki plugin also expose lineage, structured evidence, and review surfaces. Frona's distinction is that grounding, ontology reasoning, identity resolution, reconciliation, and page generation are one integrated commit pipeline rather than a core memory engine plus an optional adjacent wiki layer.
Capabilities beyond security and memory
The two priority areas should not hide the wider product tradeoffs.
| Capability | Frona | OpenClaw | Hermes Agent |
|---|---|---|---|
| Channels | Slack, Discord, Telegram, Signal, SMS, WhatsApp Cloud, and WhatsApp Personal | The widest catalog of the three, plus mature desktop/mobile node integration | Telegram, Discord, Slack, WhatsApp, Signal, email, Home Assistant, Teams, and other gateway plugins |
| Voice | Outbound telephone calls through Twilio | Voice wake, talk mode, voice notes, TTS, and mobile/desktop audio features | CLI and messaging voice, transcription, TTS providers, and Discord voice |
| Agent delegation | Policy-controlled delegation with typed task results and parallel workers | Multi-agent routing, session spawning, delegates, and specialist lanes | Isolated subagents, Mixture of Agents, bots, and parallel tool pipelines |
| Apps and visual output | Agents build and publish sandboxed web apps through an approval flow | Canvas/A2UI, widgets, dashboards, and native companion apps | Dashboard and plugins; application building is generally tool/workflow driven |
| Skills | Built-in, shared, personal, and per-agent skills with policy-aware access | Large AgentSkills/ClawHub ecosystem with managed and workspace skills | Bundled and community skills, agent-created skills, and security scanning |
| Automation | Schedules, heartbeats, inbound signals, and pause/resume workflows | Cron, hooks, webhooks, heartbeats, standing intents, and session orchestration | Cron, routines, gateway automations, and bot workflows |
| Operational model | Integrated administration UI, users/groups, SSO, model groups, usage, policy, vault, and backup flows | Rich local CLI/Control UI with extensive diagnostics and a highly configurable Gateway | CLI-first setup and profiles with gateway/dashboard options and broad backend flexibility |
When to choose each product
Choose Frona when:
- several users need one self-hosted platform with application-level ownership and OIDC login;
- agents, MCP servers, apps, and channels should have distinct identities and least-privilege policies;
- credential access needs an approval, expiration, revocation, and audit trail;
- long-term memory must be shared across a user's agents and remain grounded, structured, inspectable, and correctable;
- you want a finished web product with deployment, administration, policies, vaults, apps, and memory in one system.
Choose OpenClaw when:
- you want the broadest local-first ecosystem across channels, mobile/desktop nodes, voice, canvas, and plugins;
- you prefer transparent Markdown memory with excellent hybrid retrieval and many optional memory layers;
- a one-operator-per-Gateway trust model fits, or you are comfortable operating isolated Fleet cells per tenant;
- you value deep configuration, diagnostics, and a fast-moving community ecosystem.
Choose Hermes Agent when:
- you want a CLI- and research-oriented agent with many tools and execution backends;
- profile-scoped curated memory plus searchable sessions is sufficient, or you want to choose an external memory provider;
- auto-created skills and repeatable learned procedures matter more than a single governed knowledge graph;
- you are comfortable selecting a whole-process Docker/OpenShell posture for production or untrusted input.
Sources
OpenClaw
- Security model
- Sandboxing
- Multi-tenant hosting
- Secrets management
- 1Password integration
- Memory overview
- Memory search
- Memory provenance and deletion
- Memory wiki
- OpenClaw security policy
Hermes Agent
- Hermes Agent security policy
- Security guide
- Persistent memory
- Memory providers
- MCP
- Skills
- Quickstart and supported surfaces