Was ein KI-Agent im System wirklich darf — belegt an der laufenden Hermes-Konfiguration, nicht an erdachten Schemas.
Live-Status wird vom Backend geladen.
KI-Agenten haben Zugriff auf Systeme, Daten und externe Dienste. Ein falsch konfigurierter Agent kann unbeabsichtigt sensible Informationen preisgeben, unerwünschte Aktionen ausführen oder zur Angriffsfläche für Dritte werden. HYPDB.ONE bietet dir die Werkzeuge, um Agenten sicher zu betreiben – dieser Guide zeigt dir, wie, mit den Einstellungen, die im System wirklich existieren.
Jeder Agent bekommt nur die Rechte, die er für seine Aufgabe wirklich braucht. Ein Recherche-Agent benötigt keinen Schreibzugriff auf deine Datenbank. Ein E-Mail-Agent braucht keinen Zugriff auf dein Dateisystem.
agent.permissions-Feld
Diese Anleitung beschrieb zuvor einen YAML-Block agent: { name, permissions: [web_search, …] }. Ein solches Schema gibt es in Hermes nicht. Die Datei config.yaml kennt unter agent: ausschließlich max_turns, personalities, reasoning_effort und verbose. Rechte werden nicht pro Agent deklariert, sondern über Werkzeugauswahl und Freigaben gesteuert — siehe Schritt 2 und 3.
Auch die Rollen reader, editor, admin und custom gibt es als Konfigurationswerte nicht. Die Zugriffsbreite entsteht über die verfügbaren Werkzeuge: known_builtin_toolsets und platform_toolsets in config.yaml legen fest, welche Werkzeuggruppen ein Kontext überhaupt bekommt. Wer ein Werkzeug nicht freigibt, kann es auch nicht missbrauchen.
Hermes fragt bei riskanten Terminal-Befehlen nach. Die Liste command_allowlist hebt diese Rückfrage für bestimmte Befehle dauerhaft auf. Sie ist das sicherheitskritischste Feld der Konfiguration — jeder Eintrag ist eine bewusste Ausnahme.
# ~/.hermes/config.yaml — belegter Stand
command_allowlist:
- cua:key:background
- cua:key:foreground
- execute_code
- recursive delete
- script execution via -e/-c flag
- sudo with privilege flag (stdin/askpass/shell/list)Belegt aus tools/approval.py und tools/approval_floors.py: Die Freigaben werden profilweise aus config.yaml gelesen; Muster dürfen Shell-Glob (podman *) enthalten, aber keine Shell-Operatoren.
recursive delete und sudo with privilege flag … stehen in dieser Liste. Das ist eine bewusste Betriebsentscheidung dieses Systems, keine Empfehlung für Neuaufbauten. Für eine frische Installation gehören solche Einträge nicht in die Freigabeliste.
Die Isolation hängt am Terminal-Backend. Im Backend container läuft jeder Terminal-Auftrag in einem eigenen Container mit festen Ressourcengrenzen:
# ~/.hermes/config.yaml — belegter Stand
terminal:
backend: local # local | container
container_cpu: 1
container_memory: 5120 # MB
container_disk: 51200 # MB
container_persistent: true
lifetime_seconds: 300
timeout: 180Auf diesem System steht terminal.backend: local. Die Isolation ist damit nicht aktiv — Befehle laufen direkt auf dem Host. Wer echte Container-Isolation will, stellt auf container um und startet den Dienst neu. Das ist die einzige Stelle, an der die Isolation ein- und ausgeschaltet wird.
Diese Anleitung empfahl zuvor docker run … hypdb-agent:latest. Ein solches Image existiert auf diesem System nicht, und ein hypdb-agent-Container ist nicht Teil von HYPDB.ONE. Netzwerksegmentierung ist ebenfalls nicht vorkonfiguriert: Wenn du Agenten voneinander trennen musst, ist das eine eigene Docker-/Netzwerk-Aufgabe, keine HYPDB.ONE-Einstellung.
| Mechanismus | Beleg im Code | Status |
|---|---|---|
| Befehlsfreigabe / Rückfrage | tools/approval.py | aktiv |
| Freigabe-Muster | tools/approval_floors.py | aktiv |
| Terminal-Container | tools/terminal_tool_backends.py | inaktiv (backend: local) |
| Loop-Wächter | tool_loop_guardrails | aktiv (Warnung ab 2 Fehlern) |
| LLM-/API-Schlüssel | auth.json, .env | Datei, nie im Code |
| Passwort-Vault (Browser) | tools/browser_vault_tool.py | aktiv |
| Zugangsschutz API | /api/agents ohne Sitzung | 401 verweigert |
| Key-Ablauf-Dashboard | — | existiert nicht |
| Automatisches Wochen-Audit | — | existiert nicht |
Ein Agent, der denselben Fehlschlag wiederholt, ist das häufigste Betriebsproblem. Hermes bricht dazu ab, sobald ein Grenzwert erreicht ist:
# ~/.hermes/config.yaml — belegter Stand
tool_loop_guardrails:
hard_stop_enabled: false
warnings_enabled: true
warn_after:
exact_failure: 2
idempotent_no_progress: 2
same_tool_failure: 3
hard_stop_after:
exact_failure: 5
idempotent_no_progress: 5
same_tool_failure: 8Der zuvor hier gezeigte Block agent.rate_limit mit requests_per_minute, daily_budget und cost_limit existiert nicht — im Code kommt rate_limit nicht als Agent-Konfiguration vor. Kostenbegrenzung musst du derzeit über das Modell und das eigene Budget beim Anbieter regeln. Sobald eine echte Konfiguration existiert, wird sie hier ergänzt.
Für Prompt-Injection gilt: Systemanweisungen und Nutzereingaben gehören getrennt, und Werkzeuge, die gefährlich sind (Shell, Dateischreiben, Netzwerk), sollten nur nach Rückfrage laufen. Einen eingebauten Filter für „verdächtige Eingabemuster" gibt es nicht — die Absicherung liegt in der Freigabeliste aus Schritt 2.
Jeder Auftrag erzeugt einen Lauf mit Protokoll und eigenem Sitzungszustand. Das Betriebsprotokoll des Systems liegt im Obsidian-Vault unter 03_System/hermes_state/; die Statusleiste oben auf dieser Seite liest live /health, /api/stats und /api/status.
Die Statusanzeige misst den laufenden Dienst. Steht dort BACKEND OFFLINE, ist das eine Messung — nicht eine Vermutung und nicht eine Dekoration.
Aktuelle Werte auf diesem System: telemetry.shared_metrics.enabled: true und send: true. Für Warnungen per Telegram ist der Gateway zuständig; ein separates Benachrichtigungs-Dashboard mit Schwellwerten je Agent gibt es nicht.
HYPDB.ONE führt hier kein wöchentliches automatisiertes Audit durch — dieser Abschnitt behauptete zuvor einen solchen Dienst. Die genannten Prüfpunkte (Key-Ablauf, Rollenabweichungen, Aktivitätsmuster, Container-Images) laufen nicht als Dienst. Diese Punkte prüfst du selbst:
command_allowlist — passt jeder Eintrag noch zur aktuellen Betriebsweise?local oder container — ist die gewünschte Isolation aktiv?false..env/auth.json und in keiner HTML- oder JS-Datei?/api/agents ohne Sitzung muss 401 liefern.known_builtin_toolsets).env/auth.json, in .gitignore, nie im Codelocal oder container)command_allowlist) geprüft und auf das Nötige begrenztDie technische Umsetzung dieser Punkte liegt in den JARVIS-OS-Konstruktseiten.