Einen Always-On-KI-Agenten zu Hause absichern: eine Reise durch Sackgassen

TL;DR

Ich betreibe zu Hause einen always-on KI-Agenten mit Shell-Zugriff auf einem übrig gebliebenen Mini-PC, und der schwierige Teil war nicht, ihn zu bauen, sondern sicherzustellen, dass sich eine Kompromittierung nicht ausbreiten kann. Den Agenten an Ort und Stelle einzumauern scheiterte: Sein ganzer Job besteht darin, ausgehende Verbindungen aufzubauen, also bricht Egress-Filtering ihn entweder kaputt oder verkommt zu einer Allowlist, die du ständig pflegen musst. Was funktioniert hat, war, die Box auf einen eigenen Router zu verlegen, komplett raus aus meinem Heim-LAN, sodass eine vollständige Kompromittierung zwar das Internet erreichen kann, aber nicht meine Laptops oder das NAS. Der Fernzugriff läuft über einen ngrok-Tunnel zu einem SSH nur mit Key-Auth; der Rest ist Defense-in-Depth auf der Box selbst, dazu eine ehrliche Liste dessen, wovor das alles nicht schützt.

Wie ich Hermes Agent abgesichert habe, einen always-on CLI-basierten KI-Assistenten von Nous Research, der auf einem übrig gebliebenen Mini-PC zu Hause läuft. Das hier ist kein „So geht das perfekte Setup"-Post. Es ist der ehrliche Bericht über drei Ansätze, die gescheitert sind, und den einen, der funktioniert hat.

Das Ziel

Ich wollte einen KI-Agenten, der 24/7 bei mir zu Hause läuft und den ich von überall erreichen kann: vom Handy, von einem Laptop in einem fremden Netzwerk, aus einem Hotelzimmer unterwegs. Hermes kann Shell-Befehle ausführen, Dateien lesen und schreiben, im Web browsen und externe APIs aufrufen. Genau das macht ihn nützlich. Und genau das macht ihn gefährlich. Ein always-on Prozess mit Shell-Zugriff, der mitten in deinem Heimnetzwerk sitzt, ist etwas, bei dem man ernsthaft etwas falsch machen kann.

Also wurde daraus das eigentliche Projekt: Wie betreibe ich das Ding so, dass (a) ich es aus der Ferne erreichen kann, (b) es nicht den Rest meines Heimnetzwerks erreichen kann, und (c) falls es selbst oder die Maschine, auf der es läuft, jemals kompromittiert wird, der Schaden so klein wie möglich bleibt?

Der Host ist ein Dell OptiPlex 9020M mit Linux: ein billiger, stromsparender, fast lüfterloser Mini-PC. Die finale Stock-Version von Hermes habe ich Mitte Juni 2026 installiert.

Eine Sache spare ich mir hier: warum Hermes und nicht einer der anderen selbst gehosteten Agenten. Das war eine eigene Entscheidung, vor allem wegen der Sicherheitslage und der Tatsache, dass er von einem unabhängigen Lab kommt und nicht von einem Frontier-Anbieter. Den Vergleich habe ich in einem eigenen Post durchgekaut, Hermes vs. OpenClaw. Dieser Post setzt da an, wo jener aufgehört hat: Der Agent ist ausgewählt und installiert, und jetzt muss ich ihn betreiben, ohne dass er zum schwächsten Punkt in meinem Netzwerk wird.

Versuch 1: An Ort und Stelle härten, im Heim-LAN

Mein erster Instinkt war der aus dem Lehrbuch: die Maschine im Heimnetzwerk lassen und richtig dicht machen. Aggressive Firewall-Regeln, strenges Egress-Filtering, minimale Dienste, das volle Programm. Die Box so lange härten, bis sie sicher genug ist, um neben allem anderen zu existieren.

Das ist gescheitert, und zwar auf eine nützliche Art. Die Härtung war so restriktiv, dass der Agent seine Arbeit nicht mehr machen konnte. Die grundlegendste Fähigkeit, das Web zu erreichen, war kaputt. Ausgehender Traffic, den der Agent brauchte (API-Aufrufe an Modell-Anbieter, Websuche, Seiten abrufen), verfing sich im selben Netz, das ich ausgeworfen hatte, um schlechten Traffic drinnen zu halten. Also fing ich an, Löcher reinzuschneiden. Jedes Loch fühlte sich an, als würde es die Sicherheit wieder auflösen, die ich gerade eingebaut hatte. Ich jagte einem beweglichen Ziel hinterher: Jedes neue Tool, das der Agent sich zulegte, wollte ein neues ausgehendes Ziel, und ich pflegte von Hand eine Allowlist, die gleichzeitig zu eng war, um nutzbar zu sein, und zu löchrig, um sich sicher anzufühlen.

Es gab noch ein zweites, unabhängiges Problem. Die Härtung war nicht auf der Betriebssystem-Ebene geblieben. Um sie richtig durchzusetzen, waren umfangreiche Änderungen am Quellcode von Hermes selbst nötig, und das machte Updates fragil. Hermes wird aktiv weiterentwickelt und bekommt häufige Updates, und jedes davon hätte meine Patches überschrieben und mich gezwungen, jede Anpassung von Hand neu anzuwenden. Ich pflegte im Grunde einen privaten Fork des Agenten, nur um meine Sicherheitsregeln aufrechtzuerhalten, und diese Regeln erwiesen sich ohnehin schon als zu brüchig, um ihren Zweck zu erfüllen.

Zwei Lektionen, beide im Nachhinein offensichtlich. Ein Agent, dessen gesamter Wert darin besteht, in der Welt zu handeln, ist im Kern feindselig gegenüber Egress-Filtering. Du kannst einem Prozess, dessen ganzer Job darin besteht, ausgehende Verbindungen aufzubauen, nicht wirklich sagen „blockiere alles Ausgehende"; entweder entmannst du ihn, oder du pflegst eine brüchige Allowlist, die der Realität hinterherhinkt. Und Härtung, die durch Patches am eigenen Quellcode des Agenten durchgesetzt wird, ist eine Falle, weil sie deine Sicherheit direkt gegen den Release-Takt des Projekts antreten lässt.

Statt diesen Kampf weiterzuführen, habe ich die Topologie geändert.

Versuch 2: Die Maschine aus dem Heimnetzwerk rausnehmen

Also hörte ich auf, den Agenten innerhalb meines Netzwerks sicher machen zu wollen, und verlegte ihn stattdessen außerhalb.

Mein Heiminternet kommt über den ISP-Router rein. Der OptiPlex hängt direkt an diesem ISP-Router und hatte noch nie Kontakt zu meinem Heim-LAN. Dahinter habe ich einen zweiten Router gesetzt, der das Heim-LAN verwaltet, und alles, was mir wirklich wichtig ist (Laptops, Handys, NAS), lebt dahinter, abgeschottet vom OptiPlex. Der OptiPlex hängt im Subnetz des ISP-Routers, 192.168.2.x; das Heim-LAN hat sein eigenes Subnetz, 192.168.100.x.

Der Effekt: Die Maschine des Agenten steht auf der Internet-Seite einer Router-Grenze, während mein Heimnetzwerk hinter seinem eigenen Router liegt, davon isoliert. Der OptiPlex hat keine Route ins Heim-LAN. Selbst wenn der Agent oder die Maschine vollständig kompromittiert würden, landet der Angreifer in einem Subnetz, das zwar das weite Internet erreichen kann, aber nicht meine persönlichen Geräte. Der Schaden für „die Agenten-Maschine gehört jemand anderem" schrumpft von „mein gesamtes Heimnetzwerk" auf „eine isolierte Box und ihre API-Keys."

                  ┌──────────────────────────────────────┐
   Internet ───►  │  ISP router                          │
                  └───────────────┬──────────────────────┘
                                  │
                  ┌───────────────┴──────────────────────┐
                  │                                      │
        ┌─────────▼──────────┐              ┌────────────▼──────────────┐
        │  Second router     │              │  OptiPlex (Hermes agent)  │
        │  (home LAN gateway)│              │  192.168.2.66             │
        └─────────┬──────────┘              │  no route to home LAN     │
                  │                         └───────────────────────────┘
        ┌─────────▼───────────┐
        │  Home LAN           │
        │  192.168.100.x      │
        │  (laptops, phones,  │
        │   NAS, etc.)        │
        └─────────────────────┘

Das war der mit Abstand größte Sicherheitsgewinn im ganzen Projekt, und er hat null Software gekostet. Netzwerksegmentierung schlägt jede Firewall-Regel, die ich hätte schreiben können. Sie hat außerdem beide Probleme aus Versuch 1 auf einen Schlag gelöst. Der Agent kann jetzt frei ins Internet, weil das jetzt in Ordnung ist: Das, wovor ich Angst hatte, dass er es erreicht, mein Heimnetzwerk, sitzt auf der anderen Seite eines Routers, den er nicht überqueren kann. Und weil die Isolation vom Netzwerk kommt und nicht von Eingriffen in den Code des Agenten, konnte ich wieder Stock-Hermes fahren. Kein privater Fork mehr, keine Patches, die bei jedem Update neu angewendet werden müssen.

Eine Anmerkung zur Wahl der Topologie. Was für das Sicherheitsmodell zählt, ist die Router-Grenze zwischen der Agenten-Maschine und dem Heim-LAN, und in meinem Setup ist diese Grenze die WAN-Firewall des zweiten Routers. Ich hätte eine ähnliche Grenze auch ohne zweiten Router hinbekommen können, indem ich den OptiPlex auf ein eigenes VLAN oder ein separates Subnetz am ISP-Router gesetzt hätte, mit einer Inter-Zone-Firewall-Regel, die den Traffic zwischen den beiden Segmenten blockiert. Mein ISP-Router ist voll konfigurierbar und unterstützt das; viele Prosumer- und Business-Router können das auch. Die Isolation wäre im wichtigsten Bedrohungsmodell (eine kompromittierte Agenten-Maschine, die versucht, Geräte im Heimnetzwerk zu erreichen) gleichwertig: Beide Ansätze setzen eine Firewall-Grenze, die der Traffic des Agenten nicht überqueren kann.

Ich habe mich aus einem Grund für den Zwei-Router-Ansatz entschieden: Die Isolation ist strukturell statt konfigurationsabhängig. Mit zwei physischen Routern gibt es kein VLAN-Tag, keine Inter-Zone-Firewall-Regel und keine Switch-Port-Zuweisung, die versehentlich falsch konfiguriert oder durch ein Firmware-Update überschrieben werden könnte und dabei still und leise einen Pfad zwischen den Segmenten öffnet. Die Grenze existiert, weil die Kabel dort stecken, wo sie stecken. Das ist ein schwächeres Argument, als es klingt (ein korrekt konfiguriertes VLAN auf einem gut gepflegten Router ist völlig vertrauenswürdig), aber mir gefiel, dass die Isolation Konfigurationsfehler, Firmware-Änderungen und meine eigene Vergesslichkeit übersteht. Hätte ich den zweiten Router nicht schon gehabt, oder würde ich das irgendwo mit nur einem Router und ohne Lust auf zusätzliche Hardware aufsetzen, wäre der Single-Router-VLAN-Ansatz völlig vernünftig, und ich würde nicht zögern, ihn zu nutzen.

Ein ehrlicher Vorbehalt zur Behauptung „keine Route ins Heim-LAN": Die Grenze ist selbst ein Gerät, und dieses Gerät steht in Reichweite der Box, die ich als kompromittiert behandle. Der OptiPlex teilt sich das Subnetz des ISP-Routers mit der WAN-Seite des zweiten Routers, also kann ein kompromittierter OptiPlex nicht durch den zweiten Router routen, aber er könnte den Router direkt angreifen, und wenn er reinkäme, stünde er hinter der Grenze. Diesen Pfad habe ich so weit wie möglich geschlossen. Das Admin-Interface des zweiten Routers ist auf seiner WAN-Seite deaktiviert und durch ein starkes Passwort geschützt, sodass es vom Subnetz aus, in dem der Agent lebt, gar keine Management-Oberfläche zu erreichen gibt. Die Route ins Heim-LAN existiert nicht, und das eine Gerät, das eine solche Route erzeugen könnte, ist von dort, wo der Agent sitzt, nicht administrierbar.

Aber das hat ein neues Problem geschaffen. Wenn die Maschine in ihrem eigenen kleinen Subnetz sitzt, wie komme ich dann noch dran?

Versuch 3: Tailscale, getötet von einem VPN-Konflikt

Für den Fernzugriff war meine erste Wahl Tailscale. Es baut ein WireGuard-Mesh-Overlay: Du installierst es auf dem Ziel und auf deinem Client, und die beiden finden sich über Tailscales Koordinationsserver und öffnen einen direkten, verschlüsselten Tunnel. Sauber, Ende-zu-Ende verschlüsselt, mit ACLs und Device-Tags. Ich habe es auf dem OptiPlex mit einem Isolations-Tag (tag:isolated) und Tailscales eingebautem SSH-Server aufgesetzt:

sudo tailscale up --advertise-tags=tag:isolated --ssh

Der Plan war, dass der OptiPlex nur über das Tailnet erreichbar wäre, nur von meinen autorisierten Geräten, wobei Tailscale sowohl die Verschlüsselung als auch die Authentifizierung übernimmt. Keine offenen Ports, kein Port-Forwarding am Router, keine öffentliche IP.

Ich habe eine Weile damit verbracht, es zu debuggen: die Netmap inspiziert, die SSH-Policy geprüft, mit tcpdump auf tailscale0 den Traffic beobachtet. Das Setup selbst war in Ordnung. Was es umgebracht hat, war ein Konflikt mit meinem VPN.

Das ist eine bekannte und nervige Kategorie von Problem. Tailscale ist selbst ein WireGuard-Client, will also Routen und ein virtuelles Interface verwalten. Ein kommerzieller VPN-Client will genau dasselbe, besonders wenn er auch WireGuard-basiert ist oder einen Kill-Switch fährt, der die Default-Route kapert. Auf dem Laptop oder Handy, von dem aus ich mich verbinden wollte, bedeutete mein persönliches VPN gleichzeitig mit Tailscale laufen zu lassen, dass eins von beiden ständig den Kürzeren zog. Verbindungen waren instabil oder kamen gar nicht erst zustande.

Ich hätte das mit Policy-Based Routing, Split Tunneling oder indem ich das VPN jedes Mal ausschalte, wenn ich den Agenten erreichen will, umgehen können. All das hätte den Sinn der Sache untergraben. Ich wollte etwas, das von jedem Gerät aus, in jedem Netzwerkzustand „einfach funktioniert". Tailscale hat das in meinem Setup nicht getan. Also habe ich es rausgeworfen:

sudo apt-get remove --purge -y tailscale
sudo apt-get remove -y tailscale-archive-keyring

Nichts davon ist eine Kritik an Tailscale. Es ist exzellent, und wenn ich auf meinen Client-Geräten kein Consumer-VPN laufen hätte, wäre es die richtige Antwort gewesen. Der Konflikt lag an meinen Gewohnheiten, nicht am Tool.

Versuch 4: Ein TCP-Tunnel über ngrok (was ich jetzt nutze)

Ich brauchte eine Methode für den Fernzugriff, der die Routing-Tabellen oder der VPN-Status auf meinem Client egal sind. Etwas, wo ich mich mit einer festen öffentlichen Adresse verbinde und diese die Verbindung zur Maschine zurück weiterleitet. Ich habe mich für ngrok entschieden.

ngrok läuft als dauerhafter Dienst auf dem OptiPlex. Es wählt sich nach draußen zur Relay-Infrastruktur von ngrok ein und hält einen Tunnel offen. ngrok weist einen öffentlichen TCP-Endpunkt zu, der an einen lokalen Port weiterleitet. Ich habe ihn auf den lokalen SSH-Port gerichtet:

ngrok tunnel:  tcp://<region>.ngrok.io:<port>  ──►  localhost:22

Jetzt kann ich von überall aus per SSH zu <region>.ngrok.io auf Port <port> verbinden, und ngrok leitet die Verbindung durch zum SSH-Daemon des OptiPlex. Die Maschine hat keinen offenen eingehenden Port an meinem Heimrouter. Kein Port-Forwarding, keine offengelegte öffentliche IP bei meiner Verbindung, kein Dynamic DNS. Der OptiPlex hat sich nach draußen eingewählt; der Tunnel wird von innen offen gehalten.

(Eine Anmerkung zur Terminologie: Leute nennen das oft einen „Reverse-SSH-Tunnel", in Analogie zu ssh -R, bei dem du einen Port auf einem entfernten Server öffnest, der zurück zu deiner lokalen Maschine weiterleitet. ngrok erzeugt denselben Von-außen-reinkommen-Effekt, aber das Relay ist ngroks eigene Infrastruktur, nicht das Reverse-Port-Forwarding eines SSH-Servers. Gleiches Konzept, „eine öffentliche Adresse, die zu einem internen Dienst tunnelt"; anderer Mechanismus.)

Um es zuverlässig zu halten, läuft ngrok als systemweiter systemd-Dienst, der bei einem Fehler neu startet, sodass der Tunnel nach einem Reboot oder einer Netzwerk-Störung von selbst wiederkommt. Der SSH-Daemon dahinter ist auf reine Key-Authentifizierung festgelegt: keine Passwörter, kein Keyboard-Interactive. Den Agenten zu erreichen bedeutet also, den richtigen privaten Key zu haben, die ngrok-TCP-Adresse und den Port zu kennen, und sich mit einem Dienst zu verbinden, der nur die zwei von mir autorisierten Keys akzeptiert.

Das ist der aktuelle Zugriffsweg, und er war stabil.

Was ich beibehalten habe: Defense in Depth auf der Box selbst

Die Maschine aus dem Heimnetzwerk zu nehmen und erreichbar zu machen hat die Probleme auf Netzwerkebene gelöst. Aber ich wollte die Box selbst trotzdem gehärtet haben, damit selbst der Worst Case „isoliertes Subnetz" so eingedämmt wie möglich bleibt. Das ist die Härtung, die überlebt hat. Anders als bei Versuch 1 bricht nichts davon die Funktionsfähigkeit des Agenten, weil es eingehenden Traffic und das Verhalten des Agenten selbst adressiert, nicht die ausgehende Konnektivität. Und nichts davon rührt den Quellcode des Agenten an: Es ist alles Konfiguration auf Systemebene, Dateisystem-Layout und eingebaute Features, die per Konfiguration eingeschaltet werden.

Host-Firewall (nftables, default-deny inbound). Die Maschine läuft mit nftables und einer default-DROP-Policy für eingehenden Traffic. Nichts erreicht die Box, außer es handelt sich um eine bestehende Verbindung, Loopback, DHCP oder ICMP. Das liegt oben auf dem NAT und der Netzwerksegmentierung, sodass der eingehende Schutz dreifach geschichtet ist: der ISP-Router, die Grenze des zweiten Routers und die Host-Firewall.

SSH, nur mit Key. Passwort- und Keyboard-Interactive-Authentifizierung sind deaktiviert. Zwei autorisierte Keys, beide von mir. SSH ist der einzige Dienst, den der ngrok-Tunnel offenlegt, also ist das die Credential-Schranke am einzigen realistischen Einstiegspunkt.

Die eigenen In-Process-Verteidigungen des Agenten. Hermes bringt mehrere Schichten mit, die ich aktiviert gelassen habe:

Ein Pre-Execution-Command-Scanner (Tirith), der jeden Shell-Befehl, den der Agent ausführen will, vorab auf URL-basierte Bedrohungen, Homograph-Angriffe, Pipe-to-Interpreter-Muster und Terminal-Injection prüft, bevor er läuft.
Secret-Redaction auf allen Tool-Outputs, sodass ein API-Key, der jemals in einer Datei oder im stdout eines Befehls auftaucht, maskiert wird, bevor er in den Kontext des Agenten gelangt (und nicht über das Modell exfiltriert werden kann). Das wird beim Start als Snapshot festgelegt und kann mitten in der Session nicht abgeschaltet werden. Das ist Absicht: Der Agent kann seine eigene Redaction nicht deaktivieren.
Manuelles Approval-Gating bei destruktiven Befehlen (rm -rf, Force-Pushes usw.). Der Agent muss nachfragen, bevor er sie ausführt. (Cron-geplante Jobs nutzen einen noch strikteren Modus, bei dem destruktive Befehle automatisch abgelehnt werden.)
Ein Threat-Scanner für Projekt-Kontextdateien (die .hermes.md- / AGENTS.md-Dateien, die in den System-Prompt injiziert werden), der Prompt-Injection-Muster neutralisiert.
Eine Caller-Allowlist am Telegram-Gateway, dem einen Kanal, auf dem der Agent lauscht.

Datentrennung. Die Massendaten des Agenten (Sessions, Logs, Caches) liegen auf einer dedizierten externen SSD, während die sicherheitskritischen Dateien (die .env mit den API-Keys, die Config, die Session-Datenbank) auf der Systemplatte bleiben, mit 600-Rechten.

Ein abgeriegeltes Zweitprofil. Ich halte ein zweites Hermes-Profil vor, bei dem die meisten gefährlichen Toolsets deaktiviert sind (Coding, Computer Use usw.), für Recherche-Aufgaben, bei denen ich nicht die volle Fähigkeit brauche.

Wo das landet: eine ehrliche Bilanz

Hier ist, wovor die finale Aufstellung tatsächlich schützt, und wovor nicht.

Geschützt gegen:

Dass die Agenten-Maschine kompromittiert und benutzt wird, um mein Heimnetzwerk anzugreifen (sie kann dorthin nicht routen).
Unerwünschte eingehende Verbindungen aus dem Internet (keine offenen Ports an meinem Router; Host-Firewall default-deny).
Unautorisierte Personen, die den Agenten über Telegram erreichen (Allowlist).
Dass der Agent meine API-Keys in seinen eigenen Kontext oder einen Chat leaked (Secret Redaction).
Dass der Agent versehentlich oder über eine naive Prompt-Injection einen destruktiven Befehl ausführt (Approval-Gate + Command-Scanner).
SSH-Passwort-Brute-Force (reine Key-Auth).

Nicht geschützt (und das weiß ich):

Eine ausreichend entschlossene Prompt-Injection, die sich bis zur Shell durchkettet. Das Terminal-Backend des Agenten läuft lokal, als mein User, mit sudo. Wenn ein Angreifer Input basteln könnte, der den Agenten dazu bringt, beliebige Shell-Befehle auszuführen, gibt es keine Sandbox auf OS-Ebene zwischen dem Agenten und dem Host. Die In-Process-Scanner und das Approval-Gate legen die Latte höher, aber es sind Heuristiken, keine Containment-Grenze.
Physischer Diebstahl der Box. Die Platten sind nicht verschlüsselt. Wer die Maschine hat, hat die API-Keys und die Session-Historie.
Ein bösartiges Skill oder Plugin, das mit vollen Rechten im Prozess des Agenten läuft. Ich mildere das, indem ich keine Third-Party-Plugins lade, aber das ist eine Vertrauensgrenze, keine technische.
Der ngrok-Endpunkt selbst. Wenn ngrok kompromittiert würde, oder wenn meine ngrok-Zugangsdaten leaken würden, wäre der SSH-Port über deren Relay exponiert. Ich vertraue ngrok als Teil meiner Vertrauenskette, ein bewusster Kompromiss für die Bequemlichkeit, kein eigenes Relay zu betreiben.
Datenexfiltration von der Box selbst. Freier ausgehender Zugriff ist das Design; genau das macht den Agenten nützlich und hat mich davon befreit, weiter gegen Egress-Filtering zu kämpfen. Die Kehrseite ist, dass ein kompromittierter Host seine eigene Platte lesen kann (die .env, die Session-Datenbank) und den Inhalt per POST überallhin schicken kann, wohin er will, und nichts auf der Box wird ihn aufhalten. Secret Redaction schützt davor, dass ein Key in den Kontext des Modells leakt; sie tut nichts gegen einen kompromittierten Host, der die Datei direkt liest. Das nehme ich bewusst in Kauf: Jeder API-Key, den der Agent hält, ist auf einen Dienst mit einem harten Ausgabenlimit begrenzt, sodass der Worst Case für einen geleakten Key eine gedeckelte Rechnung ist, kein unbegrenzter Missbrauch.

Die ehrliche Zusammenfassung: Ich habe OS-Level-Isolation des Agenten gegen die Bequemlichkeit eines lokalen Backends eingetauscht, und das kompensiert, indem ich die Maschine im Netzwerk isoliere, sodass der Schaden des Agenten von einem Router begrenzt wird statt von einem Container. Das ist ein vernünftiger Tausch für einen persönlichen Single-User-, Single-Tenant-Agenten. Es wäre nicht der richtige Tausch, wenn der Agent nicht vertrauenswürdige Nutzer bedienen, nicht vertrauenswürdige Inhalte einlesen würde (etwa beliebige E-Mails parsen), oder in einer geteilten Umgebung liefe.

Die Erkenntnis

Wenn es eine Sache gibt, die ich jemandem sagen würde, der zum ersten Mal einen always-on Agenten aufsetzt, dann diese: versuch nicht, den Agenten allein mit Firewall-Regeln sicher zu machen. Der ganze Job eines Agenten besteht darin, in die Welt hinauszugreifen, und Egress-Filtering kämpft dagegen bei jedem Schritt. Setz den Agenten stattdessen auf ein Netzwerksegment, in dem die Dinge, denen er schaden könnte, nicht erreichbar sind, und lass ihn frei mit dem Internet reden. Netzwerksegmentierung ist ein einmaliger physischer/konfiguratorischer Akt, der nicht verfällt, während sich das Verhalten des Agenten weiterentwickelt; eine Egress-Allowlist ist eine Wartungslast, die verrottet, sobald du nicht hinschaust.

Ein zweites Prinzip, auf die harte Tour gelernt: Wenn du den Agenten selbst härtest, bevorzuge Konfiguration und eingebaute Features gegenüber Patches am Quellcode. Eine Anpassung, die im Quellcode des Agenten lebt, stirbt beim nächsten Update; eine, die in der Config oder im Netzwerk lebt, überlebt jedes Upgrade.

Der Rest ist Defense-in-Depth für die Dinge, die die Segmentierung nicht abfängt: reine Key-SSH, eine default-deny Host-Firewall, das eigene Command-Scanning und die Secret Redaction des Agenten. Aber die Segmentierung hat für dieses Setup mehr gebracht als alle anderen Maßnahmen zusammen, und das ist der Teil, den ich zuerst hätte machen sollen.

Host: Dell OptiPlex 9020M, Linux. Agent: Hermes (Nous Research). Fernzugriff: ngrok-TCP-Tunnel zu SSH nur mit Key. Geschrieben im Juli 2026.