Wenn KI-Agenten zum Einbruchswerkzeug werden

Wenn KI-Agenten zum Einbruchswerkzeug werden

Der eigentliche Schock an diesem Fall ist nicht, dass irgendwo ein neues Tool namens Hermes auftaucht. Der Schock ist, dass sich eine bekannte Sicherheitsfrage weiter nach vorne schiebt: Aus einem KI-Assistenten wird ein operatives Risiko, sobald er nicht mehr nur antwortet, sondern Befehle ausfuehrt, Dateien durchsucht, Rechte testet oder mit externen Werkzeugen arbeitet.

Genau das beschreibt der aktuelle Bericht von BleepingComputer vom 24. Juli 2026. Demnach soll ein Angreifer den Open-Source-Agenten Hermes in einem unbeaufsichtigten "YOLO"-Modus genutzt haben, um bei einem mutmasslichen Einbruch in das thailaendische Finanzministerium Schritte nach der Erstkompromittierung zu automatisieren. Beschrieben werden dabei nicht nur normale Abfragen, sondern typische Post-Exploitation-Aufgaben: Privilegien pruefen, Services enumerieren, Dateipfade durchsuchen und interne Systeme weiter analysieren.

Fuer deutsche B2B-Teams ist der Name Hermes dabei fast Nebensache. Die wichtigere Lehre lautet: Sobald ein Agent Shell-Zugriff, Dateioperationen, Connectoren oder Admin-nahe Tools erhaelt, verschiebt sich das Risiko von "falsche Antwort" zu "falsche Aktion". Genau an dieser Stelle wird Agentensicherheit zu einer Frage von Rechten, Freigaben, Logging und Governance.

Wer das fuer ein exotisches Einzelfallproblem haelt, sollte den eigenen Stack kurz mit dieser Brille ansehen: Gibt es bereits Agenten, die Tickets schliessen, Skripte starten, Mails versenden, Cloud-Ressourcen aendern oder auf sensible Dateibereiche zugreifen? Dann sind Sie schon nicht mehr im Copilot-, sondern im Aktionsraum. Passend dazu lohnt auch der Blick auf Warum KI-Agenten nicht am Modell scheitern, sondern an ihren Verbindungen.

Wie ein Agent aus Antworten ploetzlich Aktionen macht

Viele Unternehmen behandeln KI noch gedanklich wie ein Chatfenster. Diese Sicht wird gefaehrlich, sobald ein System als Agent arbeitet. Ein Agent ist nicht nur ein Modell mit Textausgabe, sondern ein laufender Prozess mit Ziel, Kontext, Werkzeugen und oft auch Speicher ueber mehrere Arbeitsschritte hinweg.

Laut dem Bericht nutzte der Operator Hermes nicht, damit es kreative Texte schreibt, sondern damit es Arbeit in einer Angriffskette uebernimmt: Hosts untersuchen, moegliche Rechteerweiterung vorbereiten, Dateien katalogisieren und Umgebungen weiter ausleuchten. Das ist der Punkt, an dem KI nicht mehr Assistent, sondern Ausfuehrungsschicht wird.

Die Produkt- und Projektdokumentation solcher Systeme macht diese Logik sogar offen sichtbar. Hermes wird als Agent mit Tool-Nutzung beschrieben; die Dokumentation warnt vor riskanten Sicherheitsentscheidungen und behandelt Modi mit reduzierter menschlicher Bestaetigung als besonders sensibel. Auch andere Anbieter dokumentieren denselben Grundsatz: Bei Agenten entsteht Leistung gerade dadurch, dass sie Tools nutzen und Aufgaben in mehreren Schritten verfolgen. OpenAI beschreibt Agenten als Systeme, die Modelle mit Werkzeugen und Kontrolllogik verbinden. Anthropic dokumentiert Tool Use und Sandbox-Grenzen ebenfalls nicht als Nebenfunktion, sondern als Kern des Agentenbetriebs.

Alltagssprachlich gesagt: Ein Copilot gibt Ihnen eine Empfehlung. Ein Agent kann anfangen, selbst Tueren zu pruefen.

Genau deshalb ist die Frage "Nutzen wir schon KI?" in Unternehmen oft zu oberflaechlich. Die wichtigere Frage lautet: Was darf diese KI tun, ohne dass ein Mensch zwischendrin stoppen muss? Sobald darauf eine lange Liste folgt, steigt das Risiko abrupt.

Die Grenze laeuft also nicht zwischen harmloser und boeser KI, sondern zwischen begrenzter Assistenz und ausgedehnter Handlungsmacht. Wenn ein Agent Dateien lesen, Shell-Befehle starten, Web-Panels aufrufen, Mailflows anstossen oder mit Zugangsdaten an andere Systeme andocken darf, entsteht ein ganz anderer Sicherheitscharakter als bei einem reinen Chat-Assistenten.

Warum zu viele Rechte bei Agenten so gefaehrlich sind

Fuer dieses Muster gibt es inzwischen einen brauchbaren Sicherheitsbegriff: Excessive Agency. OWASP meint damit vereinfacht gesagt Systeme, denen zu viele Aktionen, zu viele Rechte oder zu wenig kontrollierte Entscheidungsfreiheit gegeben werden. Das Problem ist nicht nur, dass ein Modell einen Fehler machen kann. Das Problem ist, dass dieser Fehler direkt in Handlung uebersetzt wird.

Im Hermes-Fall ist genau diese Verschiebung der springende Punkt. Nach der vorliegenden Berichterstattung gab ein menschlicher Operator Ziele und Werkzeuge vor; der Agent entschied den Angriff also nicht selbststaendig im strategischen Sinn. Aber durch den unbeaufsichtigten Modus konnte er operative Schritte ohne staendige menschliche Freigabe weiter ausfuehren. Fuer Verteidiger ist das hochrelevant, weil dadurch Tempo, Reichweite und Beharrlichkeit einer Angriffskette steigen koennen.

Hinzu kommt ein zweiter Verstaerker: Agenten arbeiten haeufig mit untrusted content. Sie lesen Webseiten, Dateien, Tickets, Mails oder interne Dokumente. Genau dort koennen manipulative Inhalte, irrefuehrende Anweisungen oder indirekte Steuerimpulse landen. Wenn dann noch breite Tool-Rechte dazukommen, wird aus einer fehlerhaften Einordnung schnell ein realer Eingriff. Das ist der praktische Grund, warum Prompt-Injection und Excessive Agency so oft zusammen gedacht werden.

Fuer Unternehmen bedeutet das: Das groesste Risiko sitzt oft nicht im Modell selbst, sondern in der Kombination aus

• zu breiten Rechten,
• zu vielen angeschlossenen Werkzeugen,
• fehlenden Stop-Punkten,
• schwacher Protokollierung,
• und unscharfer Trennung zwischen Lesen, Entscheiden und Handeln.

Genau diese Logik steckt auch hinter der Frage, warum klassisches Monitoring oft nicht mehr reicht, wenn Agenten laenger, zustandsbehaftet und toolfaehig arbeiten. Dazu passt auch Wenn KI aus der Sandbox will, reicht klassisches Monitoring nicht mehr.

Die Management-Lehre ist deshalb unbequem, aber klar: Ein Agent ist aus Sicherheitssicht wie ein neuer digitaler Mitarbeiter mit Sonderrechten. Wer ihn nicht wie eine eigene Identitaet mit Scope, Rollen, Logs und Freigabegrenzen behandelt, baut sich leicht einen internen Beschleuniger fuer Fehlhandlungen oder Missbrauch.

Welche Workflows jetzt anders gebaut werden sollten

Die falsche Reaktion auf solche Faelle waere, Agenten pauschal abzuschalten. Die richtige Reaktion ist, ihre Handlungsmacht sauber zu begrenzen.

Erstens sollten Unternehmen Agenten nach Risikoklassen trennen. Ein lesender Recherche-Agent ist etwas anderes als ein Agent, der Tickets schliesst, Infrastruktur aendert oder auf sensible Dateibereiche zugreift. Diese Klassen duerfen weder dieselben Rechte noch dieselben Freigaberegeln erben.

Zweitens sollten gefaehrliche Aktionen aus dem Standardfluss herausgenommen werden. Alles, was loescht, exportiert, Rechte veraendert, extern uebertraegt oder Systemzustand aendert, braucht eine engere Kontrolle als das blosse Lesen oder Zusammenfassen. Praktisch bedeutet das oft: read-only zuerst, write spaeter, admin nur separat.

Drittens braucht jeder produktive Agent eine eigene Identitaet, klare Tool-Scopes und nachvollziehbare Logs. Wer Agenten ueber geteilte Konten oder weitreichende Service-Tokens laufen laesst, verliert im Ernstfall die wichtigste Sicherheitswaehrung: Zurechenbarkeit.

Viertens muessen Teams untrusted content als Eingriffsvektor behandeln. Wenn ein Agent Inhalte aus Tickets, Mails, Webseiten oder hochgeladenen Dokumenten liest, darf daraus nicht automatisch eine kritische Aktion entstehen. Zwischen Verstehen und Handeln gehoert ein Kontrollpunkt.

Fuenftens lohnt sich eine einfache Architekturregel: Der Agent darf Probleme erklaeren, aber nicht automatisch alles reparieren. Genau hier kippen viele Systeme von produktiv zu riskant.

Wer das auf die eigene Umgebung uebertragen will, sollte nicht nur Agenten inventarisieren, sondern auch deren reale Wirkung in Workflows sichtbar machen: Welche Tools sind angeschlossen? Welche Rechte haengen daran? Wo endet Beobachtung, wo beginnt Aktion? Und welche Aktionen wuerden im schlimmsten Fall denselben Schadenshebel erzeugen wie in einem Angriffsszenario?

Damit wird aus dem Hermes-Fall eine nuetzliche Betriebsfrage statt bloss einer exotischen Sicherheitsmeldung. Nicht der Name des Agenten ist das Problem. Das Problem ist jede Umgebung, in der ein Agent zu viel darf, zu wenig bestaetigen muss und dabei auf Systeme trifft, die ihm blind vertrauen.

Wer dieses Denken vertiefen will, findet die naechste Ebene in Warum Enterprise-GenAI das Ransomware-Risiko vergroessert.