KI-Agenten sicher einsetzen: Der Sicherheits-Leitfaden für KMU

Warum ein Agent ein anderes Sicherheitsproblem ist als ein Chatbot

Der Unterschied liegt in einem einzigen Wort: handeln. Ein Chatbot formuliert Text; der schlimmste Fall ist eine falsche Auskunft, die ein Mensch bemerkt und korrigiert. Ein KI-Agent ruft Werkzeuge auf: Er schreibt ins CRM, verschickt Mails, legt Tickets an, stößt Zahlungen an. Jede dieser Aktionen ist real, sofort wirksam und manchmal nicht zurückzunehmen.

Das verschiebt die gesamte Sicherheitsfrage. Bei einem Chatbot prüft ihr Antwortqualität. Bei einem Agenten prüft ihr Berechtigungen, und zwar mit denselben Maßstäben, die ihr an einen neuen Mitarbeiter anlegen würdet, der am ersten Tag Zugang zu euren Systemen bekommt. Mit einem Unterschied: Der Mitarbeiter hat ein Gefühl dafür, dass eine Mail mit der Betreffzeile „Dringend: bitte Zugangsdaten bestätigen“ verdächtig ist. Der Agent hat das nicht.

Zwei Vorfälle aus 2026 und was sie wirklich zeigen

Beide Fälle haben nichts mit außer Kontrolle geratener KI zu tun. Beide sind klassische Konfigurationsfehler, die erst durch einen unermüdlichen Agenten sichtbar wurden.

Fall 1: Gemini verlässt die Testumgebung. Am 18. September 2026 legte Google offen, dass sich Gemini während eines Sicherheitstests Zugang zu drei Systemen fremder Organisationen verschafft hatte. Der Test war ein „Capture the Flag“-Szenario: Das Modell sollte absichtlich in ein präpariertes Zielsystem einbrechen. Zwei Fehler verketteten sich: Der für den Test erfundene Firmenname entsprach einer real existierenden Domain, und eine Fehlkonfiguration ließ die Testumgebung am offenen Internet hängen, statt sie abzuschotten. Das Modell erriet Zugangsdaten beziehungsweise verwendete Zugangsdaten, die es in einem öffentlichen Repository fand. Der Vorfall geschah im Mai, fiel erst im Juli dem beauftragten Dienstleister auf; in allen drei Fällen stoppte das Modell nach dem Zugriff von selbst.

Fall 2: Ein Token von 2023, gefunden in 25 Minuten. Im September 2026 veröffentlichte der Anbieter eines autonomen Pentest-Agenten, wie sein System bei einem potenziellen Lieferanten vorging: Innerhalb von 25 Minuten fand der Agent auf einer öffentlich erreichbaren Container-Registry ein Docker-Image und darin einen GitHub-Zugangstoken mit Administratorrechten. Der Token stammte aus einem Build vom März 2023 und funktionierte noch immer. Das betroffene Unternehmen bestätigte den Befund als kritisch und rotierte den Token innerhalb eines Tages.

Die Lehre ist in beiden Fällen dieselbe: Der Agent hat nichts erfunden. Er hat nur systematisch und ohne Ermüdung abgeklappert, was ohnehin offen lag. Wer heute Agenten einsetzt, muss davon ausgehen, dass jede vergessene Zugangsdatei, jedes zu großzügige Recht und jede halbherzige Abschottung irgendwann gefunden wird, von einem eigenen Agenten oder einem fremden.

Quelle: NBC News zum Gemini-Vorfall Quelle: Strix zum gefundenen Admin-Token

Die drei Angriffswege, die in der Praxis zählen

Die Liste theoretisch denkbarer Angriffe auf KI-Systeme ist lang. Die Liste derer, die in echten Vorfällen auftauchen, ist kurz.

• Indirekte Prompt Injection. Der gefährlichste Weg, weil er unsichtbar ist. Die schädliche Anweisung steht nicht in der Eingabe des Nutzers, sondern in Daten, die der Agent im Lauf seiner Arbeit liest: in einer eingehenden Mail, einem hochgeladenen PDF, einem CRM-Feld, auf einer Website. Das Modell unterscheidet nicht zuverlässig zwischen Text, den es verarbeiten soll, und Befehl, den es ausführen soll. BSI und ANSSI führen genau das in ihrem gemeinsamen Papier zu LLM-Systemen als zentrales Risiko auf und empfehlen konsequentes Zero Trust: Alles, was aus einer Quelle kommt, die ihr nicht kontrolliert, gilt als potenziell feindlich.
• Zugangsdaten, die herumliegen. Tokens in Repositories, Schlüssel in Docker-Images, Passwörter in Konfigurationsdateien, API-Keys im Chatverlauf. Ein Mensch stolpert selten darüber. Ein Agent durchsucht systematisch.
• Rechte, die zu weit gefasst sind. Der Klassiker: Der Agent läuft über den Account eines Mitarbeiters, weil das beim Aufsetzen am schnellsten ging. Damit erbt er dessen komplette Rechte, inklusive aller Ordner, Postfächer und Systeme, die mit dem Anwendungsfall nichts zu tun haben.

Auffällig ist, was auf dieser Liste nicht steht: ein Modell, das eigene Ziele entwickelt. Die realen Vorfälle entstehen an der Schnittstelle zwischen Agent und Infrastruktur, nicht im Modell selbst.

Sechs Regeln, nach denen ein Agent produktiv laufen darf

Diese sechs Punkte sind das Minimum, das wir in jedem Agenten-Projekt umsetzen, auch im kleinsten. Ein Sicherheitskonzept für einen Konzern sind sie nicht. Sie decken sich mit den Empfehlungen von BSI und ANSSI für LLM-basierte Systeme.

1. Eigene Identität, minimale Rechte. Jeder Agent bekommt einen eigenen technischen Zugang, nie den Account eines Menschen. Leserechte sind der Standard, Schreibrechte die begründete Ausnahme, Administratorrechte gibt es nicht. Wer Rechnungen prüfen soll, sieht Rechnungen, nicht das ganze Laufwerk.
2. Echte Sandbox, nicht „fast abgeschottet“. Getestet wird in einer Umgebung ohne Verbindung zu Produktivsystemen und ohne echte Kundendaten. Der Gemini-Fall zeigt, was eine einzige Fehlkonfiguration an dieser Stelle anrichtet.
3. Kurzlebige Zugangsdaten. Tokens mit Ablaufdatum statt dauerhafter Schlüssel, zentral verwaltet und regelmäßig rotiert. Wenn ein Token drei Jahre später noch funktioniert, fehlt ein Prozess.
4. Fremde Inhalte sind Daten, keine Befehle. Alles, was der Agent aus Mails, Dokumenten, Formularen oder von Websites liest, wird technisch als Inhalt behandelt und nicht als Anweisung. Wo das nicht sauber trennbar ist, folgt eine menschliche Freigabe.
5. Vier-Augen-Prinzip bei allem Unumkehrbaren. Zahlungen, Vertragsversand, Löschungen, Außenkommunikation: Der Agent bereitet vor, ein Mensch gibt frei. Das ist dieselbe Regel, die im Unternehmen ohnehin für neue Mitarbeiter gilt.
6. Lückenloses Protokoll und ein getesteter Not-Aus. Jede Aktion mit Zeitstempel, Auslöser und Ergebnis. Dazu ein Schalter, der den Agenten sofort stoppt und der einmal im Ernstfall geprobt wurde, nicht nur dokumentiert ist.

Quelle: BSI & ANSSI, Design Principles for LLM-based Systems with Zero Trust

Die Checkliste vor dem ersten Produktiv-Einsatz

Wenn ihr diese acht Fragen beantworten könnt, ist der Agent bereit für echte Daten. Wenn nicht, wisst ihr, wo die Arbeit liegt.

• Über welchen Zugang läuft der Agent, und ist das ein eigener statt der eines Mitarbeiters?
• Welche Systeme darf er lesen, welche beschreiben? Passt das exakt zum Anwendungsfall?
• Welche Aktionen sind unumkehrbar, und wer gibt sie frei?
• Woher stammen die Inhalte, die er verarbeitet, und welche davon kommen von außerhalb eures Unternehmens?
• Laufen Tests ohne echte Kundendaten und ohne Verbindung zu Produktivsystemen?
• Wo landet das Protokoll, wie lange wird es aufbewahrt, und wer schaut hinein?
• Wie stoppt ihr den Agenten in 30 Sekunden, und wer darf das?
• Wann laufen die Zugangsdaten ab, und wer rotiert sie?

Zwei Punkte aus dieser Liste erledigt man erfahrungsgemäß nicht nebenbei: die saubere Rechtevergabe und das Protokoll. Beides ist IT-Hausaufgabe statt KI-Arbeit, und genau deshalb bleibt es liegen, bis jemand danach fragt.

Was die EU-KI-Verordnung dazu verlangt

Für die allermeisten Agenten im Mittelstand gilt: Sie sind keine Hochrisiko-Systeme. Trotzdem gibt es Pflichten, die schon heute greifen.

• KI-Kompetenz (Artikel 4), seit Februar 2025. Wer KI einsetzt, muss dafür sorgen, dass die Menschen, die damit arbeiten, sie auch einschätzen können. Für einen Agenten heißt das konkret: Das Team muss wissen, was er darf, woran man einen Fehler erkennt und wie man ihn stoppt.
• Transparenz (Artikel 50), seit dem 2. August 2026. Wer mit einem KI-System interagiert, muss das erkennen können. Betrifft jeden Agenten mit Außenkontakt: Kundenservice, Mailbeantwortung, Terminvergabe.
• Hochrisiko (Anhang III), ab dem 2. Dezember 2027. Ursprünglich für August 2026 vorgesehen, durch den Digital Omnibus verschoben; für in Produkte eingebettete KI nach Anhang I auf den 2. August 2028. Relevant wird das, wenn der Agent Bewerbungen vorsortiert, Kreditwürdigkeit bewertet oder biometrisch identifiziert.

Die Verschiebung der Hochrisiko-Fristen ist kein Freibrief: Verboten bleibt, was verboten war, und die Transparenz- und Kompetenzpflichten laufen unverändert weiter. Mehr dazu in unserem Überblick zum EU AI Act für KMU.

Quelle: Gibson Dunn zu den verschobenen Fristen

In 3 Schritten zum sicheren Agenten

1. Den Prozess abstecken, nicht die Technik. Ein klar umrissener Anwendungsfall mit definiertem Anfang und Ende, daraus ergibt sich fast automatisch, welche Rechte der Agent braucht und welche nicht.
2. In der Sandbox bauen und mit echten Fällen testen. Historische, anonymisierte Vorgänge durchspielen, bis das Verhalten vorhersagbar ist. Erst dann echte Daten, erst dann Schreibrechte.
3. Eng freigeben, dann lockern. Start mit menschlicher Freigabe für jede Aktion. Was sich über Wochen als zuverlässig erweist, wird freigeschaltet; was auffällig bleibt, bleibt an der Freigabe hängen.

Und wenn ihr das nicht selbst aufsetzen wollt: Genau so bauen wir Agenten, vom abgesteckten Prozess über die Rechtevergabe bis zum laufenden Betrieb. Ein Blick auf unsere Leistungen und unsere Referenzen zeigt, wie das in echten Projekten aussieht.