Vollständiger Hermes-Agent-Mac-Sicherheitsleitfaden 2026: Berechtigungen, Schlüssel und Dateigrenzen richtig setzen

2026 scheitern viele Mac-Installationen am ersten Tag: Das Modell verbindet sich, die Gateway startet — und die ganze Maschine wird dem Agent übergeben. Die offizielle Hermes-Dokumentation ist eindeutig: Die einzige harte Grenze gegen bösartiges LLM-Verhalten ist das Betriebssystem. Befehlsfreigaben, Container-Isolation und Gateway-Allowlists sind Verteidigung in der Tiefe über OS-Grenzen hinaus; sie ersetzen nicht die Datei- und Geheimnisbereiche, die Sie selbst definieren.

Fazit vorweg: Hermes Agent sollte standardmäßig weder Ihr gesamtes Home-Verzeichnis noch alle Shell-Befehle erhalten. Starten Sie mit minimalem Arbeitsbereich, minimalen API-Schlüsseln und approvals.mode: manual, beweisen Sie eine echte Aufgabe, dann erweitern Sie Rechte bewusst. Die folgenden Abschnitte entsprechen dem, was Sie innerhalb von etwa 30 Minuten nach der Installation erledigen sollten.

1. Sicherheits-Baseline vor echten Aufgaben

Hermes nutzt standardmäßig terminal.backend: local — Befehle laufen als Ihr aktueller macOS-Benutzer. Fehlt der Gateway eine Allowlist, lehnt der Start alle externen Nutzer ab — ein gesundes Fail-Closed-Verhalten. GATEWAY_ALLOW_ALL_USERS=true nur zum „schnellen Anlaufen“ bedeutet: Jeder, der den Bot erreicht, kann Tool-Aufrufe auslösen.

Realistische Risiken sind keine Science-Fiction-„rebellische KI“, sondern drei vorhersehbare Fehlermodi:

• Versehentliches Löschen oder Überschreiben: rekursives rm, Zerstörung von ~/.ssh oder ~/.hermes/.env;
• Geheimnis-Leck: API-Schlüssel in Logs, MCP-Kindprozessen oder Container-Umgebungsweitergabe;
• Unautorisierte Auslöser: nicht freigegebene Telegram-/Discord-/Slack-Nutzer starten Deploy-, Massen- oder Zahlungsskripte.

Sichere Konfiguration heißt nicht „alles abschalten“. Der Agent soll nur dort handeln, wo die Arbeit stattfindet. Nutzen Sie diese Schichtentabelle als Leitfaden für den Rest des Artikels:

2. Dedizierten Arbeitsbereich nutzen

2.1 Haupt-macOS-Benutzer vs. dediziertes Konto

Vermeiden Sie, eine dauerhaft laufende Gateway unter Ihrem Alltags-macOS-Konto zu betreiben, wenn möglich. Alltagskonten haben oft bereits Fotos, Mail, Browser-Passwörter freigegeben — das Backend local erbt die gesamte TCC-Oberfläche.

Drei praktische Stufen:

• Lokaler Test (geringes Risiko): Hauptkonto behalten, nur CLI, Backend local, cwd auf dedizierten Ordner beschränkt;
• Dedizierter macOS-Benutzer (empfohlen): Systemeinstellungen → Benutzer:innen und Gruppen, Standardbenutzer hermes anlegen, nur Workspace und nötige SSH-Keys mounten;
• Separate Maschine / VM (Produktions-Gateway): terminal.backend: ssh zu Mac mini oder Linux-Worker; Gateway routet nur Nachrichten.

Hermes SECURITY.md betont: Multi-User-Isolation muss auf OS/Host-Ebene passieren. In-App-Session-Keys leiten Traffic; sie sind keine Autorisierungsgrenze.

2.2 Verzeichnisstruktur und MESSAGING_CWD

Auf dem dedizierten Konto einen isolierten Bereich anlegen — Standard-cwd niemals auf ~ setzen:

mkdir -p ~/hermes-workspace/{inbox,outbox,scratch,backups}
chmod 700 ~/hermes-workspace

In ~/.hermes/.env:

MESSAGING_CWD=/Users/hermes/hermes-workspace

Empfohlene Zonen:

• inbox: schreibgeschützte oder halb-schreibgeschützte Eingaben für den Agent;
• scratch: temporäre Skripte und Build-Artefakte mit Schreibrecht;
• outbox: Agent-Ausgaben, die Sie vor externer Weitergabe prüfen;
• backups: kein Agent-Schreibzugriff — nur Time Machine oder rsync.

Muss ein Repo angebunden werden, nur ein einzelnes Projektunterverzeichnis — nicht ganz ~/Projects. Bei Docker-Persistenz mappt Container-/workspace unter ~/.hermes/sandboxes/docker/; alte Sandboxes löschen, damit sensible Dateien nicht liegen bleiben.

3. Geheimnisse und API-Schlüssel

3.1 Wo Anmeldedaten lagern

Hermes erwartet alle API-Schlüssel und Tokens ausschließlich in ~/.hermes/.env — nicht in config.yaml oder git. Direkt nach der Installation:

chmod 600 ~/.hermes/.env
chmod 700 ~/.hermes

Speicheroptionen und Grenzen:

3.2 Provider-Keys nicht in Container weiterleiten

terminal.docker_forward_env und terminal.env_passthrough injizieren Variablen in Docker oder lokale Kindprozesse. Leiten Sie niemals primäre OpenAI-/Anthropic-Keys per Passthrough — Code im Container kann sie lesen und exfiltrieren. Nur aufgabenbezogene Tokens (z. B. eingeschränktes GITHUB_TOKEN).

MCP-Unterprozesse erhalten sichere Defaults (PATH, HOME usw.), außer Sie listen Variablen explizit im MCP-env:-Block — das ist Absicht.

3.3 Checkliste Schlüssel-Rotation

Bei Verdacht auf Leck oder planierter Wartung in dieser Reihenfolge:

1. Gateway stoppen: launchctl unload oder Gateway-Prozess beenden;
2. In Cloud-Konsolen widerrufen und neu ausstellen jeder möglicherweise exponierter Key (LLM-Provider, Telegram-Bot, GitHub-PAT);
3. ~/.hermes/.env aktualisieren und prüfen, dass alte Werte weg sind;
4. ~/.hermes/logs/ und Shell-Historie auf Klartext-Geheimnisse scannen;
5. Bei geleakten Gateway-Tokens Pairing rotieren: hermes pairing list / revoke;
6. Gateway neu starten; mit Minimalaufgabe validieren, bevor Automatisierung wieder aktiv wird.

4. Befehls- und Dateiberechtigungen

Hermes enthält Erkennung gefährlicher Befehle (tools/approval.py). In ~/.hermes/config.yaml beibehalten:

approvals:
  mode: manual    # manual | smart | off
  timeout: 60     # bei Ablauf: ablehnen (fail-closed)

smart nutzt ein Hilfsmodell zur Risikobewertung — für erfahrene Betreiber. off oder /yolo deaktiviert Freigaben — nur in Wegwerf-Containern oder CI. Harte Blocklist-Einträge (z. B. rm -rf /, Fork-Bomben) werden auch im YOLO-Modus abgelehnt.

4.1 Vorlage Erlauben / Nachfragen / Verbieten

CLI-Freigabeoptionen: once / session / always / deny. In Produktion niemals always für rm oder systemctl — das schreibt dauerhaft in command_allowlist. Regelmäßig mit hermes config edit prüfen.

4.2 In Produktion Docker-Isolation bevorzugen

Mit terminal.backend: docker (oder modal/daytona/vercel_sandbox) entfallen gefährliche Befehlsprüfungen — der Container ist die Grenze. Docker entzieht standardmäßig Capabilities, begrenzt PIDs und isoliert /tmp per tmpfs. Beispiel:

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []          # leer = keine Host-Geheimnisse im Container
  container_cpu: 1
  container_memory: 5120
  container_disk: 51200
  container_persistent: true

Container können standardmäßig noch das öffentliche Internet erreichen. Braucht ein Skill kein Netzwerk, Egress auf Docker-Ebene einschränken oder --network=none wo passend.

5. macOS-Datenschutz-Dialoge

Hermes CLI/Gateway kann TCC-Dialoge für Dateien, Browsersteuerung oder Screenshots auslösen. Menüpfade variieren je macOS-Version; die Regel nicht: Nur das Nötigste gewähren, vorzugsweise auf dem dedizierten Benutzerkonto.

• Dateien und Ordner: nur hermes-workspace hinzufügen, nicht „gesamte Festplatte“ oder Dokumente;
• Automatisierung (Apple Events): verweigern, wenn Sie Mail/Notes nicht über Hermes steuern;
• Bedienungshilfen / Bildschirmaufnahme: nur aktivieren, wenn Browser-Tools es verlangen;
• Vollzugriff auf Festplatte: vermeiden außer bei konkretem Bedarf — umgeht TCC.

Systemeinstellungen → Datenschutz & Sicherheit → jeweilige Kategorie; jederzeit widerrufbar. Nach großem macOS-Update die Liste erneut prüfen.

6. Gateway-Autorisierung und Audit-Logs

6.1 Wer mit dem Bot sprechen darf

Allowlists in ~/.hermes/.env konfigurieren. Nicht GATEWAY_ALLOW_ALL_USERS=true in Produktion:

TELEGRAM_ALLOWED_USERS=your_numeric_id
GATEWAY_ALLOWED_USERS=your_numeric_id
# Oder DM-Pairing: 8-stelliger Code; freigeben via hermes pairing approve

Prüfreihenfolge: Plattform-Allow-All-Flag → freigegebene Pairing-Liste → Plattform-Whitelist → globale Whitelist → Standard-Ablehnung. Pairing-Codes laufen nach einer Stunde ab, Rate-Limit zehn Minuten, Sperre eine Stunde nach fünf Fehlversuchen — flexibler als nur fest codierte IDs.

6.2 Was in Logs aufbewahren

Standard-Logverzeichnis: ~/.hermes/logs/. Aufbewahren und rotieren:

• Gateway-Startwarnungen (z. B. fehlende Allowlist);
• Ergebnisse gefährlicher Befehlsfreigaben (genehmigt / abgelehnt / abgelaufen);
• Unautorisierte Zugriffsversuche;
• Skill-Installation und Lazy-Install-Ereignisse;
• Supply-Chain-Hinweise von hermes doctor.

Logs können Pfade, Befehlsargumente und Prompt-Fragmente enthalten — als sensibel behandeln; nicht in öffentliche Cloud-Ordner synchronisieren. MCP-Fehler maskieren Muster wie ghp_ und sk-, ersetzen aber nicht weniger Logging von Geheimnissen von vornherein.

security.website_blocklist aktivieren, um interne Admin-URLs zu blockieren. SSRF-Schutz blockiert standardmäßig RFC1918 und Metadaten-IPs — allow_private_urls: false beibehalten, außer Sie brauchen wirklich LAN-Ollama usw.

7. Berechtigungen stufenweise erweitern

Nicht mit local + yolo + allow all users starten. Sinnvolle Leiter:

1. Woche 1: CLI + manuelle Freigaben + dediziertes Verzeichnis + ein Provider-Key;
2. Woche 2: Gateway hinzufügen, DM-Pairing, nur Ihre ID;
3. Woche 3: auf Backend docker wechseln, ein Repo binden;
4. Produktion: dedizierter Mac mini/VM + Backend ssh + Ressourcenlimits + Log-Alerts.

Bei jedem Stufenaufstieg 15 Minuten für gezielte Freigabetests: Temp-Datei löschen, curl interne IP, Push versuchen — prüfen, dass Blockaden halten.

8. Incident Response

Versehentliches Löschen: aus backups oder Time Machine im Arbeitsbereich wiederherstellen; bei Versionierung git checkout. Agent pausieren und auslösenden Prompt in Logs nachverfolgen.

Key-Leck: Checkliste Abschnitt 3.3; Bot-Tokens in @BotFather zurücksetzen, falls Telegram exponiert war.

Unautorisierter Aufruf: hermes pairing revoke <platform> <user_id>; prüfen, ob Gateway-Webhook-URLs geleakt sind; Zugriff per Firewall oder Tailscale einschränken.

Ungewöhnliche API-Kosten: zuerst Provider-Ausgabenlimits setzen, dann Logs auf Tool-Schleifen oder unkontrollierte Cron-Jobs prüfen.

Hinweis: Hermes garantiert nicht „Daten verlassen nie die Maschine“ — Modell-APIs, Browser-Tools und Websuche gehen alle nach außen. Für rein lokal: auf On-Device-Modelle routen und betroffene Tools selbst deaktivieren.

9. 30-Minuten-Sicherheits-Checkliste nach der Installation

• ☐ ~/hermes-workspace anlegen und MESSAGING_CWD setzen
• ☐ chmod 600 ~/.hermes/.env; keine Geheimnisse in config.yaml
• ☐ approvals.mode: manual; YOLO deaktiviert
• ☐ command_allowlist prüfen — leer oder minimal
• ☐ Gateway-Allowlist oder DM-Pairing; GATEWAY_ALLOW_ALL_USERS aus
• ☐ Produktions-Gateway auf Backend docker oder ssh, nicht local
• ☐ docker_forward_env: []; Provider-Keys nicht weitergeleitet
• ☐ macOS-Datenschutz nur auf Arbeitsbereich beschränkt
• ☐ hermes doctor ausführen; Supply-Chain-Hinweise bearbeiten
• ☐ ~/.hermes/logs/ beschreibbar und nicht in synchronisiertem Cloud-Ordner

Hermes auf einem Mac mini für klarere Grenzen

Die Hermes-Gateway auf einem dedizierten Mac mini zu betreiben schlägt „volle Rechte auf dem Alltags-MacBook“: Ihre Hauptmaschine bleibt für Code und Nachrichten; der Mini führt Agent, Docker-Sandboxes und Logs aus — physisch getrennt von privaten Fotos und Browser-Cookies. Die vereinheitlichte Speicherarchitektur von Apple Silicon hilft bei lokalen Hilfsmodellen (z. B. Ollama); Gatekeeper, SIP und FileVault erhöhen die Systemintegrität, und TCC lässt sich auf einem dedizierten Konto minimieren.

Der Mac mini M4 verbraucht im Leerlauf etwa 4 W, bleibt lüfterlos und leise für 24/7-Gateway-Betrieb und passt gut zu terminal.backend: ssh, wenn Befehle auf einem Worker laufen und der Gateway-Knoten Nachrichten und Freigaben verwaltet. Wenn Sie einen dauerhaften Agent-Host aufbauen, ist der Mac mini M4 einer der klarsten Einstiegspunkte — jetzt zugreifen und Hermes innerhalb der Grenzen halten, die Sie definieren.