# Is Hermes Agent safe, and what the open-source Kortix platform adds

> Hermes Agent runs on hardware you choose and reaches your files, your messaging accounts and tools on that host, with command approval, a denylist and optional sandboxing as its guardrails. Kortix, the open-source AI Operating System, adds per-resource permissions, server-side secrets and one sandbox per session for a team.

URL: https://hermesalternative.com/hermes-agent-security

## A call an agent may not make on its own

`kortix.yaml`

```yaml
# kortix.yaml
connectors:
  - slug: gmail
    provider: composio
    app: gmail
    policies:
      - match: "get_*"
        action: always_run
      - match: "*"
        action: require_approval
```

Source: https://kortix.com/docs/connect/connectors

A connector runs reads automatically and holds every other call for approval, declared in `kortix.yaml`.

## What a Hermes agent reaches

Hermes Agent installs on a server you control and runs as your user, so its tools reach what that account reaches: files, a terminal, web search, browser control, and the messaging accounts you connect. Its [security guide](https://hermes-agent.nousresearch.com/docs/user-guide/security) lists eight layers, among them dangerous-command approval, file-write denylists, sandboxing on Docker, Singularity or Modal backends with hardened settings, MCP credential filtering, and cross-session isolation. Hermes's own [work-machine guide](https://hermes-agent.nousresearch.com/docs/guides/secure-hermes-on-a-work-machine) states the limit plainly: the deny rules and file-write guards are a guardrail against an agent that is honest and wrong, and containment against an adversarial process needs an isolated backend.

## The four controls a team sets first

Before a team grants an agent real access, it has to answer four questions. Kortix gives an answer to each one.

The first control is which tools an agent may use, and who may run it. Kortix gives per-resource permissions to people and agents, and sets each connector action to Allow, Ask or Block down to the arguments of the call.

The second control is where credentials live. Connector credentials are brokered server-side and never enter the machine. Secrets are encrypted at rest with a key per project, and a session receives one only through the secret's audience and the agent's grant.

The third control is where the work runs. One isolated sandbox per session, each on its own branch, so a bad command touches nothing shared.

The fourth control is what is recorded and reviewed. Approval gates you set, which are off until you set them, an audit trail that records every action, and a merge that is default-deny for agents, so a person approves what lands. [How a team runs Hermes](/hermes-for-teams) walks the same questions for one operator.

## Where the controls live

Kortix keeps all of that as files in a git repo the company owns. Agents, skills, memory, connector config and the permission grants are text you can read, diff and roll back, so a reviewer sees the same config the agents run. [Compare the controls](/kortix-vs-hermes), [self-host the platform](/self-hosting-hermes-alternative), read how it [stands next to OpenClaw](/hermes-vs-openclaw), [move an existing Hermes setup over](/migrate-from-hermes), or check the [FAQ](/faq).

## Where the controls sit

Kortix first, then Hermes Agent, each fact from its own documentation.

| | Kortix (recommended) | Hermes Agent |
| --- | --- | --- |
| Open source | Yes. Read it, fork it, audit it. | Yes; the source is on GitHub. |
| Where tools run | On each session's own cloud computer, not your machine. | On the host by default; Docker, SSH or cloud backend optional. |
| Per-tool permissions | Per-resource permissions for people and agents; Allow, Ask or Block per action. | Toolsets enabled per platform; a glob denylist for commands. |
| Credential handling | Connector credentials brokered server-side; secrets encrypted at rest, key per project. | Keys in a local env file or an external secret manager. |
| Session isolation | One isolated sandbox per session, on its own branch. | Cross-session isolation; profiles keep memory and skills separate. |
| Approval gates | Approval gates you set, off until you set them. | Command approval modes; fail-closed timeout; hardline blocklist. |
| Audit trail | Every action is recorded; reading the log depends on the plan. | Lifecycle hooks log activity and post signed events to webhooks. |
| Multi-user | Roles, groups and per-resource permissions; SAML 2.0 single sign-on and SCIM 2.0. | One gateway with allowlists or DM pairing per person. |

## Hermes Agent security questions

### Does Hermes run tools on my host?

By default yes. Its terminal tool runs on the local machine unless you switch to a Docker, SSH or cloud backend, so its tools reach what your user account reaches.

### Can I limit which tools an agent uses?

Hermes lets you enable toolsets per platform and set a glob denylist for commands. Kortix scopes each connector action to Allow, Ask or Block, per agent and per person.

### What record is kept of what it did?

Hermes logs activity through lifecycle hooks and can post signed events to webhooks. Kortix records every action in an audit trail, and session work lands through a reviewed change request.

### Can several people share one Hermes install?

One gateway can authorize several people through allowlists or DM pairing, each with their own session. It has no org roles or review workflow.

## Give the agent scoped access, not the whole host.

Start free in the cloud, or self-host with your own keys.

[Try Kortix](https://kortix.com) · [See how teams run it](https://hermesalternative.com/hermes-for-teams)

Open source · Any model, your keys · Self-host, VPC, or on-prem