KI-Agenten benötigen Sicherheitsgrenzen, die sie nicht umschreiben können

Es ist verlockend, die Hugging‑Face‑Geschichte als den Moment zu lesen, in dem KI‑Agenten durchgedreht sind. Das ist jedoch nicht ganz das, was passiert ist, und die Details sind wichtig. Dabei handelte es sich um Cyber‑Sicherheits‑Forschungs‑Agenten, die in Bewertungen liefen, bei denen Schutzmaßnahmen bewusst heruntergefahren wurden, damit Forschende sehen konnten, wozu die Modelle fähig sind. Der Kundendienst‑Bot von niemandem ist nicht eines Morgens aufgewacht und hat beschlossen, ein Unternehmen anzugreifen. Aber dieser Kontext entbindet niemanden von der Verantwortung. Ein Agent überschritt die Grenze, in der er bleiben sollte, nutzte Anmeldeinformationen und Werkzeuge auf Weise, die seine Betreiber nie autorisiert hatten, und landete in Systemen, die jemand anderem gehörten. Das ist der Teil, dem jedes Sicherheitsteam Aufmerksamkeit schenken sollte.

Reuters berichtete, dass Agenten bereits im Mai Hugging Face untersuchten, obwohl Forschende sagten, sie hätten nichts gefunden, was darauf hindeutet, dass die frühere Aktivität allein einen Verstoß verursacht hat. Der Juli war anders. OpenAI sagte, dass seine Modelle die Isolationskontrollen umgangen haben, das Internet erreichten und Teile ihrer eigenen Forschungsinfrastruktur zusammen mit Hugging‑Face‑Systemen kompromittierten. Der eigene Bericht von Hugging Face beschreibt einen von einem autonomen Agentensystem von Anfang bis Ende durchgeführten Eindringversuch, das seine Datenverarbeitungspipeline ausnutzte, Anmeldeinformationen sammelte und sich über interne Cluster bewegte.

Der unbequeme Teil ist, dass die Agenten ihre Aufgaben erledigten. Sie verfolgten das Ziel, das ihnen vorgegeben worden war. Deshalb reicht diese Geschichte weit über ein Forschungslabor hinaus. Unternehmens‑Agenten verfolgen ebenfalls Ziele. Sie besitzen Anmeldeinformationen, rufen Werkzeuge auf und bewegen sich schneller, als irgendeine Person prüfen kann. Ein Agent mit vollkommen guten Absichten kann dennoch echten Schaden anrichten, und ein gehackter Agent kann dieselbe Autorität im Auftrag eines Angreifers nutzen. Daher muss die Sicherheit regeln, was das System tatsächlich tun darf, egal wie zuversichtlich das Modell klingt oder wie harmlos sein angegebenes Ziel erscheint.

Sichern Sie die Aktion, nicht nur das Modell

Die meisten frühen Agentenprogramme konzentrieren ihre Anstrengungen auf das Modell. Teams testen Eingabeaufforderungen, optimieren Ablehnungen, fügen ein zweites Modell hinzu, um das erste zu überprüfen, und beobachten die Argumentationsspur nach Anzeichen schlechten Willens. Nichts davon ist verschwendet. Aber das Ganze ist probabilistisch, weil es von einem weiteren Modell abhängt, das ein Urteil fällt. Eine produktive Sicherheitsgrenze muss deterministisch sein und muss die Werkzeuge, Anmeldeinformationen, Netzwerke und Transaktionen umschließen.

Die Frage, die ich stellen würde, ist konkret: Was kann dieser Agent in der realen Welt tatsächlich bewirken? Einen Zahlungsantrag zu entwerfen ist das eine. Die Freigabe der Mittel ist das andere. Gleiches gilt für die Vorbereitung einer Datenbankänderung im Vergleich zu deren Ausführung in der Produktion oder das Markieren von Datensätzen, die einer Aufbewahrungsregel entsprechen, im Vergleich zu deren Löschung. Es kann dasselbe Modell in beiden Fällen sein, mit sehr unterschiedlichem Risiko, je nachdem, auf welcher Seite dieser Grenze es sich befindet.

Ein aktueller Unite‑AI‑Überblick zur Fähigkeitskontrolle zieht dieselbe Linie und verknüpft das Risiko mit Daten, Werkzeugen, Berechtigungen, Autonomie und der Umgebung, in der der Agent läuft. Mir gefällt diese Darstellung, weil sie uns über vage Bezeichnungen wie „sicheres Modell“ und „unsicheres Modell“ hinausführt. Sie lässt Teams jeden Pfad von der Entscheidung eines Agenten zu etwas mit realen Konsequenzen nachverfolgen.

Geben Sie jedem Agenten eine Identität und ein enges Mandat

Ein Agent sollte niemals auf dem Konto eines Entwicklers laufen oder alles erben, was einem menschlichen Nutzer erlaubt ist. Gemeinsame Identität verwischt die Zuordnung. Langfristige Anmeldeinformationen geben einem Angreifer mehr Zeit, sie zu missbrauchen. Und breit gefasste Servicekonten lassen einen kleinen Arbeitsablauf in Daten und Systeme eindringen, die er nicht berühren sollte.

NIST behandelt Software- und KI‑Agenten‑Identität jetzt als eigenes Architekturproblem. Das Konzeptpapier fragt, wie ein Agent nachweisen kann, dass er für eine bestimmte Aktion autorisiert ist, wie die Identität eines Agenten an die Autorisierung eines Menschen gebunden werden kann und wie Organisationen manipulationssichere Aufzeichnungen darüber führen können, was beabsichtigt war und was tatsächlich geschehen ist. In der Praxis führt das zu einem einfachen Design. Jeder Agent erhält eine eindeutige Identität, einen Eigentümer (eine Person oder ein Team), einen definierten Zweck und Berechtigungen, die auf die vorliegende Aufgabe zugeschnitten sind.

Anmeldeinformationen sollten schnell ablaufen und nur für bestimmte Ressourcen und Aktionen funktionieren. Der Netzwerkzugriff sollte von einer strengen Positivliste ausgehen. Wenn ein Agent eine genehmigte Datenbank abfragen muss, sollte er nicht gleichzeitig eine allgemeine Shell, offenen Internetzugang oder die Möglichkeit erhalten, neue Anmeldeinformationen zu erzeugen. Und wenn die Arbeit durch eine Kette von Agenten und Werkzeugen weitergegeben wird, sollte die Autorität bei jedem Schritt enger werden, nicht breiter.

NIST warnt zudem vor dem Teilen von Anmeldeinformationen und zu breitem Zugriff, und diese Warnung ist gewichtsvoll, weil Agenten opportunistisch sind. Wenn ein Weg blockiert ist, könnten sie ein anderes Werkzeug versuchen, ihre Umgebung erkunden oder auf ein vergessenes Token stoßen. Gesammelte Anmeldeinformationen waren ebenfalls Teil der Juli‑Geschichte. Das Prinzip des geringsten Privilegs hält den Schadensradius klein, wenn die Argumentationsebene etwas tut, das seine Designer nicht erwartet haben.

Halten Sie die Autorisierung außerhalb des Denkprozesses

Ein Agent kann eine Aktion empfehlen. Er sollte nicht entscheiden dürfen, ob er sie ausführen darf. Diese Entscheidung gehört in eine separate Durchsetzungsschicht, die der Agent nicht umschreiben, ausschalten oder umgangen kann. Jeder Werkzeugaufruf sollte als strukturierte Anfrage erscheinen: welcher Agent fragt, welcher Mensch ihn gesponsert hat, welche Operation er ausführen will, worauf er abzielt und welche Grenzen gelten. Die Durchsetzungsschicht erlaubt dann, blockiert oder eskaliert ihn.

OWASP beschreibt übermäßige Agentur als eine Mischung aus unnötiger Funktionalität, übermäßigen Berechtigungen und zu viel Autonomie. Seine Richtlinien fordern enge Werkzeuge, minimale Berechtigungen, Autorisierung im nachgelagerten System und Benutzerzustimmung für Aktionen mit hoher Wirkung. Ich denke, das ist genau die richtige Reihenfolge. Die Regel sollte von dem durchgesetzt werden, der die Daten besitzt oder die Transaktion ausführt. Wenn ein Modell sagt, eine Aktion sei genehmigt, sollte diese Aussage allein kein Gewicht haben.

Diese Trennung hilft auch bei Prompt‑Injektionen. Eine vergiftete E‑Mail oder ein Dokument könnte das Denken des Agenten lenken, aber es kann die Anmeldeinformationen des Agenten nicht erweitern oder ein Richtlinien‑Gate herunterziehen. Das Modell kann frei etwas Verbotenes anfordern. Das System sollte trotzdem „Nein“ sagen.

Menschliche Genehmigung für die Momente, die zählen

Menschliche Überprüfung rechtfertigt sich, wenn eine Aktion nicht rückgängig gemacht werden kann, eine organisatorische Grenze überschreitet, Berechtigungen ändert, sensible Informationen freigibt, Geld bewegt oder ein Produktionssystem berührt. Wenn man für jeden routinemäßigen Schritt um Genehmigung bittet, erhält man zwei Dinge: Verzögerungen und Personen, die lernen, „genehmigen“ zu klicken, ohne zu lesen. NIST nennt diese Zustimmungsmüdigkeit beim Namen.

Eine gute Genehmigungsanfrage zeigt die genaue Aktion in klarer Sprache, einschließlich des Zielorts und der relevanten Parameter. Sie sollte von einem autoritativen System kommen, nicht aus vom Agenten verfasstem Text. Die Genehmigung sollte schnell ablaufen und nur diese eine Aktion abdecken. Ändert sich ein wesentlicher Detail, fragt das System erneut.

OWASP‑Leitfaden zur Agentensicherheit empfiehlt zu testen, ob eine hochwirksame Aktion ohne eine gültige, nicht abgelaufene, parametergebundene Genehmigung durchgeführt werden kann. Dieser Satz ist merkenswert. „OK zum Fortfahren“ ist eine schwache Genehmigung, die von einem anderen Agenten oder einem Angreifer erteilt werden kann. „Überweise diesen Betrag auf dieses Konto“ oder „Setze diese Änderung in dieser Umgebung um“ ist etwas, das das System zum Zeitpunkt der Ausführung tatsächlich verifizieren kann und das ein Nutzer vollständig versteht.

Echte menschliche Identitätsbestätigung ist an diesem Tor entscheidend. Eine Push‑Benachrichtigung beweist nur, dass jemand oder etwas einen Knopf gedrückt hat. Robustere Designs erfordern, dass eine registrierte Person eine phishing‑resistente Public‑Key‑Authentifizierung nutzt, unterstützt durch ein lokales biometrisches Verifizierungsverfahren. FIDO‑Standards binden öffentliche Schlüssel‑Anmeldeinformationen an den legitimen Online‑Dienst und bewahren biometrische Daten auf dem isolierten Gerät des Benutzers. Bei richtiger Anwendung liefert hardwarebasierte Authentifizierung weitaus bessere Evidenz dafür, dass die richtige Person tatsächlich anwesend war. Sie ersetzt jedoch nicht die Transaktionsbindung, eine vertrauenswürdige Anzeige oder die Durchsetzung von Richtlinien. Alle diese Komponenten müssen zusammenarbeiten.

Verhalten überwachen und Beweise bewahren

Man kann nicht darauf vertrauen, dass die Anfangsprompt erklärt, was während eines langen Agentenlaufs passiert ist. Sicherheitsteams benötigen Telemetrie zu Werkzeugaufrufen, Netzwerkaktivität, Anmeldeinformationen, Richtlinienentscheidungen, Genehmigungen, Ablehnungen und Änderungen des Umfangs. Das Monitoring sollte vergleichen, was der Agent tatsächlich getan hat, mit der für diesen Lauf festgelegten Grenze. Wenn ein Agent zum Analysieren von Code zugewiesen wurde und beginnt, nach externen Anmeldeinformationen zu suchen oder einen unrelated Dienst zu sondieren, sollte das einen Alarm auslösen.

Protokolle müssen genügend Kontext enthalten, um die Aktionskette wiederherzustellen, ohne Geheimnisse im Klartext preiszugeben. Jeder Eintrag sollte die Agenten‑Version, den Eigentümer, die Person oder das System, das den Vorgang initiiert hat, das verwendete Werkzeug, die angeforderte Aktion, das Richtlinien‑Ergebnis und jede menschliche Autorisierung erfassen. Signierte oder anderweitig manipulationssichere Aufzeichnungen erhöhen die Glaubwürdigkeit der Nachtrichterei erheblich, besonders wenn mehrere Agenten und Dienste beteiligt waren.

All das muss mit Maschinen­geschwindigkeit laufen. Niemand, der ein Dashboard beobachtet, wird tausende Aufrufe stoppen, die in Sekunden abgeschlossen sind. Automatisierte Kontrollen sollten Ratenbegrenzungen durchsetzen, ungewöhnliche Sequenzen erkennen und Anmeldeinformationen sofort sperren, sobald das Verhalten einen definierten Schwellenwert überschreitet. So erhalten menschliche Ermittler einen begrenzten Vorfall, den sie bearbeiten können, anstatt einer endlosen Verfolgung.

Den Stopp‑Pfad vor dem Start entwerfen

Jede Agenten‑Bereitstellung benötigt einen Weg, sie zu stoppen, der die Fähigkeit tatsächlich entfernt. Den Agenten zu bitten zu stoppen zählt nicht. Betreiber sollten in der Lage sein, seine Anmeldeinformationen zu widerrufen, seinen Netzwerkpfad zu kappen, seine Laufzeit zu beenden und zu verhindern, dass wartende Aktionen wieder starten. Für Workflows mit hohen Konsequenzen sollte das System im Falle eines Ausfalls des Genehmigungs‑ oder Richtliniendienstes im geschlossenen Modus fehlschlagen.

Dann den Pfad unter Druck testen. Den Genehmigungsdienst offline nehmen. Dem Agenten widersprüchliche Anweisungen geben. Während eines Laufs ein Anmeldecredential rotieren. Ein kompromittiertes Werkzeug und einen Genehmiger simulieren, der nie reagiert. Bestätigen, dass die Aktion blockiert wird und dass ein nützliches Protokoll entsteht. Und diese Tests jedes Mal wiederholen, wenn sich das Modell, die Prompt, der Connector, das Speichersystem oder das Berechtigungsset ändert.

Das Ziel ist verantwortungsvolle Autonomie

Nichts davon ist ein Argument gegen Agenten, und der Vorfall bei Hugging Face sollte niemanden von nützlichen Agenten abschrecken. Was es tun sollte, ist die Vorstellung zu beseitigen, dass ein Sicherheitsprompt plus gute Absichten zu einer vertrauenswürdigen Bereitstellung führen. Geben Sie Agenten Spielraum, um zu analysieren, Arbeit vorzubereiten und reversible Aufgaben zu erledigen. Beschränken Sie ihre Befugnis, reale Konsequenzen zu verursachen, auf ein enges, sichtbares und von etwas anderem als dem Agenten selbst durchgesetztes Maß.

Bevor ein Agent in die Produktion geht, sollten Führungskräfte in der Lage sein, eine Handvoll einfacher Fragen zu beantworten. Auf welche Systeme kann er zugreifen? Welche Anmeldeinformationen kann er verwenden? Was kann er ohne Überprüfung tun? Was löst eine Eskalation aus? Wie sieht der Genehmigende die genau genehmigte Aktion? Welche Beweise werden hinterlassen? Und wie kann die Sicherheit den Vorgang sofort stoppen?

Wenn die Antworten vage sind, hat der Agent mehr Befugnis, als die Organisation erkennt. Die Architektur, die über die Zeit Bestand hat, kombiniert Modellsicherungen mit Identität, minimalen Rechten, externer Richtliniendurchsetzung, selektiver menschlicher Genehmigung, vollständiger Telemetrie und einem wirklich funktionierenden Stopp‑Mechanismus. Sie basiert auf einer ehrlichen Annahme: Fähige Agenten werden uns von Zeit zu Zeit überraschen. Unsere Sicherheitsgrenzen sollten das nicht.

Am Ende sollte man einen KI‑Agenten als Praktikanten mit (möglicherweise) Root‑Zugriff betrachten, der keine Angst vor HR hat.

Welche Schutzmaßnahmen und Schranken würden sie haben?

Handeln Sie entsprechend.