KI-Agenten gehen zunehmend dazu über, nicht mehr nur Fragen zu beantworten, sondern auch Aktionen in den Systemen auszuführen, auf die Unternehmen täglich angewiesen sind.
Wenn Organisationen ihnen Zugriff auf Anwendungen, Daten, Kommunikation und Finanzabläufe geben, lautet die Sicherheitsfrage nicht mehr nur, ob ein KI-Modell die richtige Antwort liefert. Es geht auch darum, was passiert, wenn ein Agent etwas tut, das seine Betreiber niemals beabsichtigt haben.
Der jüngste Vorfall bei Hugging Facezeigt, wie schnell dieser Unterschied relevant werden kann.
An dem Vorfall waren KI-Agenten beteiligt, die in der Evaluierungsumgebung von OpenAI betrieben wurden. Sie fanden nicht autorisierte Wege, um zu kommunizieren, Entdeckungen zu teilen, Internetzugang zu erlangen und über getrennte Evaluierungsaufgaben hinweg zusammenzuarbeiten, bevor sie Teile der Infrastruktur von Hugging Face kompromittierten.
Das effektiv umzusetzen, ist selbst für Organisationen mit umfassender KI-Expertise eine Herausforderung. Die große Mehrheit der Unternehmen, die Agenten einsetzen, muss Kontrollen entwickeln, die berücksichtigen, wie sich diese Systeme außerhalb ihrer vorgesehenen Grenzen verhalten könnten.
Nehmen wir an, Sie sind ein mittelgroßer Gesundheitsdienstleister, der einen KI-Agenten zur Bearbeitung von Fragen zur Abrechnung einsetzt. Sie wünschen sich schnellere Antworten und weniger Routineaufgaben für die Beschäftigten – da liegt es nahe, den Agenten über ein Administratorkonto mit der Abrechnungsplattform zu verbinden und ihm aufzutragen, die Unternehmensrichtlinien zu befolgen.
Stellen Sie sich nun vor, eine eingehende Rechnung enthält Anweisungen, Kontodaten zur „Verifizierung“ an eine unbekannte externe Adresse zu exportieren – ein Szenario, das dem wachsenden Risiko von indirekten Prompt-Injection-Angriffenentspricht. Der Agent behandelt die in der Rechnung eingebetteten Anweisungen als autorisierte Anfrage, und seine weitreichenden Berechtigungen sowie der uneingeschränkte ausgehende Zugriff ermöglichen es ihm, die Datensätze zu exportieren.
Das Ergebnis könnte die unbefugte Offenlegung geschützter Gesundheitsdaten sein, wodurch Pflichten zur Reaktion auf Datenschutzverletzungen ausgelöst würden und der Organisation möglicherweise aufsichtsrechtliche Strafen drohten.
Der KI-Agent befolgte die erhaltenen Anweisungen, doch sein Governance-Modell verlieh ihm Befugnisse, die er nicht hätte haben dürfen. Eine Handlung muss nicht böswillig sein, um einen kostspieligen Sicherheitsvorfall zu verursachen. Eine Kombination aus vagen Anfragen und Zugangsdaten, die es einem Agenten ermöglichen, Geld zu bewegen, Datensätze offenzulegen oder Produktivsysteme zu verändern, kann dasselbe Ergebnis hervorbringen wie ein Angriff.
Viele Organisationen treiben den Einsatz von Agenten voran, in der Hoffnung auf verlockende Kosteneinsparungen, ohne angemessene Kontrollen einzurichten. Ernst & Young zufolge befassen sich 92 % der Technologie-Führungskräfte mit souveräner KI, aber nur 25 % verfügen über eine unternehmensweite Governance für agentische KI.
Diese Lücke verdeutlicht die größere Herausforderung: Organisationen setzen zunehmend leistungsfähige Systeme schneller ein, als sie klare Regeln dafür schaffen, was diese Systeme tun dürfen, wodurch Sicherheitskontrollen für KI-Agentenvor der Einführung immer wichtiger werden.
Den Schadensradius des Agenten definieren
Bewährte Sicherheitskontrollen bilden die Grundlage für die Eindämmung von Agentenrisiken. Die Herausforderung besteht darin, diese Kontrollen auf jedes System anzuwenden und zu testen, das ein Agent erreichen kann, und auf jede Aktion, die er ausführen kann. Das Prinzip der geringsten Privilegien, bei dem nur die unbedingt erforderlichen Berechtigungen für eine Aufgabe vergeben werden, ist ein sinnvoller Ausgangspunkt: Gewähren Sie nur den für eine klar definierte Aufgabe erforderlichen Zugriff und begrenzen Sie anschließend, wie weit dieser Zugriff einen automatisierten Workflow führen kann.
Damit sind jedoch nicht alle Möglichkeiten abgedeckt, wie Agenten Fehler machen können. Um sie auf Kurs zu halten, sollten Sie zunächst die konkreten Grenzen der Aufgabe schriftlich festhalten. Ein Abrechnungsagent muss beispielsweise möglicherweise ausgewählte Felder zum aktuellen Fall eines Patienten einsehen können, um eine Erläuterung zu formulieren oder eine Anpassung vorzuschlagen. Dafür braucht er keinen Zugriff auf klinische Notizen, nicht zugehörige Konten, Massenexporte oder das Löschen von Datensätzen. Gewähren Sie für diese Vorgänge eng begrenzten Zugriff und führen Sie bei jeder Anfrage Autorisierungsprüfungen durch.
Eine hilfreiche Betrachtungsweise besteht darin, den Schadensradius eines Agenten zu definieren, bevor er überhaupt Zugriff auf ein System erhält. Stellen Sie fünf grundlegende Fragen: Was kann er lesen? Was kann er ändern? Wen oder was kann er beeinflussen? Wie viel kann er ausgeben? Und wie schnell kann er handeln? Die Antworten sollten die Berechtigungen und Kontrollen für den Agenten bestimmen – nicht die Annahme, dass er sich wie vorgesehen verhalten wird.
Zugriff und Befugnisse trennen
Die Unterscheidung zwischen dem Lesen und dem Ausführen von Aktionen ist besonders wichtig. Ein Agent, der einen Kontostand abrufen kann, sollte ihn nicht standardmäßig ändern können. Ein Agent, der eine Nachricht formuliert, sollte nicht das Privileg haben, sie beliebig zu versenden; beschränken Sie daher Empfänger und Netzwerkziele. Selbst die Gewährung von Lesezugriff kann bei uneingeschränkter Kommunikation zu einer unbeabsichtigten Offenlegung führen.
Identitätskontrollen verstärken diese Grenzen. Geben Sie jedem Workflow ein identifizierbares Dienstkonto, einen verantwortlichen Besitzer und Zugangsdaten, die ablaufen oder schnell ausgetauscht werden können. Ein Hilfsagent sollte nicht mehr Befugnisse erhalten, als die Aufgabe erfordert, und Delegation darf niemals als Umgehungsmöglichkeit für die ursprünglichen Einschränkungen zur Verfügung stehen.
Klare Grenzen für Agentenaktionen setzen
Berücksichtigen Sie auch Mengenbegrenzungen. Wenn ein Agent Rückerstattungen bis zu 50 US-Dollar ohne Prüfung ausstellen darf, kann das nach hinten losgehen, wenn er Tausende Rückerstattungen veranlasst oder dieselbe Belastung wiederholt erstattet. Legen Sie kumulative Limits pro Konto und über den gesamten Workflow hinweg fest. Setzen Sie Obergrenzen für Tool-Aufrufe, Ausführungszeit und Modellausgaben.
Setzen Sie diese Grenzen in Systemen durch, die der Agent weder umschreiben noch umgehen kann. Ihn per Prompt auf bestimmte Ausgabenrichtlinien hinzuweisen, ersetzt keine unabhängigen Berechtigungs- und Budgetprüfungen vor der Ausführung. Ziel ist es, sicheres Verhalten durchsetzbar zu machen, statt den Agenten lediglich darum zu bitten, es zu befolgen.
Grenzen von Agenten vor der Einführung testen
Menschliche Aufsicht bleibt wichtig, insbesondere bevor Agenten mit risikoreicheren Aktionen betraut werden.
Vor der Einführung sollten Sicherheitsteams diese Grenzen gezielt testen, indem sie den Abrechnungsagenten irreführende Rechnungen, widersprüchliche Anweisungen, wiederholte Rückerstattungsanfragen, nicht autorisierte Empfänger und Anfragen mit Zugriff auf Kundendaten vorlegen. Vergewissern Sie sich, dass das nachgelagerte System unzulässige Aktionen ablehnt, selbst wenn das Modell versucht, sie auszuführen.
Agenten nach der Inbetriebnahme überwachen
Die fortlaufende Überwachung des Agenten nach seiner Einführung ist unerlässlich. Anders als herkömmliche Software können sich agentische Systeme je nach Kontext, Tools, Anweisungen und zugrunde liegenden Modellen unterschiedlich verhalten.
Laufzeitschutz ergänzt Tests, indem er Kontrollen während des Betriebs des Agenten beobachtet und durchsetzt. Überwachen Sie die Aktionen des Agenten, um sicherzustellen, dass er innerhalb seiner festgelegten Berechtigungen bleibt, und protokollieren Sie sowohl versuchte als auch abgeschlossene Aktionen sowie Richtlinienentscheidungen und Genehmigungen. So können Sicherheitsteams erkennen, wann er sich diesen Grenzen nähert oder sie überschreitet. Legen Sie für diesen Fall Möglichkeiten fest, die Ausführung zu stoppen und den Zugriff zu entziehen. Überprüfen Sie Protokolle und Berechtigungen regelmäßig und passen Sie sie an, wenn sich die Rolle oder das Verhalten des Agenten verändert.
Damit wird die Gestaltung von Berechtigungen zu einer Geschäftsentscheidung. Bevor Sicherheitsverantwortliche Agenten frei agieren lassen, sollten sie den möglichen Schaden bedenken und die entsprechende Gefährdung begrenzen. Berechtigungen sollten sich nach den potenziellen Auswirkungen der Aktionen eines Agenten richten, nicht nach dem Vertrauen in sein Verhalten. Sicherheitsverantwortliche sollten Berechtigungen für das schlimmstmögliche Ergebnis auslegen, nicht für das beabsichtigte Verhalten.
Vertrauen ist kein Ersatz für Kontrolle.
Auch lesenswert: Lesen Sie, wie ein Fehler in Meta Muse es lokaler Malware ermöglichen könnte, einen KI-Agenten zu kapern und bereits vom Nutzer gewährte Berechtigungen zu missbrauchen.