#Hermes Agent Permissions & Security

Hermes can run commands, touch files, browse the web, and connect to chat platforms — the greater the power, the more important security governance becomes. This chapter summarizes its security mechanisms and best practices.

#Threat Model: What Are We Defending Against?

Risk                              Possible outcome
────                              ────────────────
Accidental file delete/edit       Data loss
Dangerous commands (rm, curl|bash)System damage
Leaked secrets                    Account compromise
Strangers commanding via gateway  Abuse, info leakage
Model "hallucinating" bad actions Unexpected side effects

Hermes's security design centers on restrict, isolate, approve, authenticate.

#1) Command Approval & Allowlists

Hermes includes a command-approval system: risky operations require your confirmation, with allowlist patterns to pre-approve trusted commands.

model wants to run a command → matches allowlist?
   ├─ yes → run directly
   └─ no  → pause, wait for your approve/deny

Tip: allowlist frequent, safe read-only commands; keep writes, deletes, and network requests behind approval.

#2) Execution Isolation: Sandbox the Commands

Via execution backends, run tools in an isolated environment instead of bare metal:

Container hardening (read-only root, dropped capabilities) sharply limits the blast radius of mistakes or malicious output.

#3) Gateway Access Control

Once the agent is on public chat platforms, authentication and authorization are essential:

• DM pairing: first DMs must complete pairing to confirm an authorized user
• User allowlist: per-platform list of who may interact
• Per-platform config: set permissions separately for each platform

deny by default → only allowlisted users may chat → add command approval for risky actions

#4) Credentials & Data Security

• Local storage: all data in ~/.hermes/, no telemetry, no cloud upload
• Encrypted credential storage: keys are stored securely
• Isolate secrets in .env: never put keys in shared/committed files
• Directory permissions: ensure ~/.hermes/ is readable/writable only by you

#Security Checklist

[ ] Use hermes tools to disable all non-essential tools (least privilege)
[ ] Run risky tools in Docker / SSH backends
[ ] Enable command approval; only allowlist trusted read-only commands
[ ] Enable DM pairing + user allowlist on the gateway
[ ] Keep API keys in .env, out of Git; tighten ~/.hermes/ permissions
[ ] Run hermes update regularly to pick up security fixes
[ ] Route important actions through the multi-agent "verification" step
[ ] Periodically review MEMORY.md / session history; remove sensitive info

#Defense in Depth

┌─────────────────────────────────────────────┐
│ Gateway layer: DM pairing + user allowlist  │
├─────────────────────────────────────────────┤
│ Decision layer: command approval + patterns │
├─────────────────────────────────────────────┤
│ Execution layer: Docker/SSH sandbox + hardening│
├─────────────────────────────────────────────┤
│ Data layer: local storage + encrypted creds + perms│
└─────────────────────────────────────────────┘

No single layer is a silver bullet; stacking layers is the robust approach.

#Next Steps

• Tool System — choose the right execution backend
• Message Channels — gateway access-control details
• Slash Commands — /status, /stop, and other controls