Ein KI-Agent mit gültigem Zugang ist aus Sicht vieler Unternehmenssysteme zunächst unauffällig. Er hat sich authentifiziert, seine Aktionen lassen sich einer Identität zuordnen, ein Gateway sitzt davor. Für klassische Software wäre das ein brauchbarer Anfang. Für autonome Agenten ist es nur die Eingangstür.
Die Sicherheitsfrage verschiebt sich. Nicht mehr nur: Darf dieses System zugreifen? Sondern: Versteht das Unternehmen noch, warum der Agent eine bestimmte Handlung ausführt, welche Informationen er dafür heranzieht und ob sein Kontext bereits manipuliert wurde?
Genau dort setzt die Analyse von VentureBeat an. In vielen Agentenprojekten greifen Teams zuerst zum Gateway. Es ist sichtbar, technisch vertraut und lässt sich in bestehende Identitäts- und Zugriffssysteme einhängen. Das Problem: Die riskanten Vorgänge passieren oft danach.
Der Agent ist kein normaler Nutzer
Ein menschlicher Nutzer kann sich irren, Regeln brechen oder Daten falsch verschicken. Aber er handelt nicht mit derselben Geschwindigkeit, Persistenz und Systemnähe wie ein automatisierter Agent. KI-Agenten kombinieren Modellantworten, gespeicherten Kontext, Tool-Zugriffe und oft mehrere Arbeitsschritte. Sie lesen Dokumente, rufen APIs auf, schreiben Tickets, aktualisieren Datensätze oder bereiten Entscheidungen vor.
Damit verändert sich die Rolle der Authentifizierung. Sie bestätigt, wer oder was handelt. Sie sagt aber nicht, ob die Handlung auf einer sauberen Grundlage beruht. Ein Agent kann korrekt angemeldet sein und trotzdem auf vergiftete Erinnerung zugreifen. Er kann berechtigte Daten abrufen und sie in einen falschen Kontext tragen. Er kann über Zeit sein Verhalten verschieben, ohne dass ein einzelner Vorgang wie ein klassischer Angriff aussieht.
Das ist der unangenehme Teil: Viele Kontrollen erkennen Ereignisse. Agentenrisiken entstehen aber häufig als Verlauf. Ein falscher Speicherbaustein hier, eine manipulierte Anweisung in einem Dokument dort, ein zu breites Recht auf ein internes Tool. Nichts davon muss sofort wie ein Einbruch wirken.
Memory Poisoning ist kein Passwortproblem
Memory Poisoning trifft eine Schwachstelle, die bei Agenten besonders heikel ist: ihr Gedächtnis. Gemeint ist nicht nur ein einzelner Chatverlauf. Es kann um langfristige Memory-Funktionen gehen, um RAG-Speicher, zwischengespeicherten Kontext, Notizen, Zusammenfassungen oder interne Wissensbestände, aus denen ein Agent spätere Entscheidungen ableitet.
Wird dort manipulierte Information abgelegt, entsteht kein lauter Alarm. Der Agent arbeitet weiter. Er wirkt sogar konsistent, weil er aus seiner Sicht auf bekanntes Wissen zurückgreift. Genau das macht diese Klasse von Angriffen so schwer zu behandeln. Sie zielt nicht zwingend darauf, ein System sofort zu übernehmen. Sie kann das Entscheidungsfundament verschieben.
Bei klassischen Anwendungen lassen sich Berechtigungen relativ klar modellieren: Nutzer, Rolle, Ressource, Aktion. Bei Agenten kommt eine zusätzliche Ebene hinzu: die Herkunft und Verlässlichkeit des Kontexts. Ein Dokument kann zugleich Datenquelle und versteckte Handlungsanweisung sein. Eine Tool-Antwort kann Information liefern und Verhalten beeinflussen. Ein Speicher kann helfen, Wiederholungen zu vermeiden, und zugleich zum dauerhaften Träger einer Manipulation werden.
Drift ist der operative Blindfleck
Der Begriff Drift klingt harmlos. In der Praxis beschreibt er ein Kontrollproblem. Ein Agent entfernt sich schrittweise von dem Verhalten, das beim Test, beim Rollout oder bei der Freigabe erwartet wurde. Das kann durch veränderte Datenquellen passieren, durch neue Tools, durch Prompt-Änderungen, durch Speicherinhalte oder durch Kombinationen aus allem.
Für Sicherheitsabteilungen ist das unbequem, weil Drift nicht immer als klarer Verstoß erscheint. Ein Agent kann formal innerhalb seiner Rechte handeln und dennoch unpassende Daten zusammenführen. Er kann eine interne Information in eine Ausgabe einbauen, die für diesen Empfänger nicht gedacht war. Er kann aus einem manipulierten Kontext eine plausible, aber falsche Aktion ableiten.
Das macht Authentifizierung nicht wertlos. Ohne Identität, Attribution und Zugriffskontrolle lässt sich Agentenbetrieb kaum verantworten. Aber diese Schicht beantwortet nur die erste Frage. Danach braucht es Kontrollen, die Verhalten, Datenflüsse und Kontextintegrität betrachten. Wer nur prüft, ob der Agent durch die Tür durfte, übersieht, was er im Gebäude tut.
Gateways sind ein Anfang, keine Sicherheitsarchitektur
Gateways werden in vielen Unternehmen zum natürlichen Sammelpunkt für Agentensicherheit. Sie können Zugriffe bündeln, Richtlinien durchsetzen, Anfragen protokollieren und Modelle oder Tools voneinander trennen. Das ist nützlich. Es löst aber nicht automatisch das Problem der vertrauenswürdigen Ausführung.
Ein Gateway sieht nicht zwangsläufig, ob eine Erinnerung vergiftet wurde. Es erkennt nicht immer, ob eine scheinbar normale Tool-Nutzung aus einer manipulierten Anweisung stammt. Es kann auch nicht allein entscheiden, ob eine Ausgabe sensible Informationen enthält, die aus mehreren erlaubten Quellen zusammengesetzt wurden.
Für Unternehmen entsteht daraus eine nüchterne To-do-Liste. Agenten brauchen minimale Rechte, nicht bequeme Sammelberechtigungen. Schreibzugriffe in Memory-Systeme müssen begrenzt, versioniert und prüfbar sein. Kontextquellen sollten klassifiziert werden: interne Dokumente, externe Inhalte, Tool-Antworten und Nutzereingaben verdienen nicht denselben Vertrauensrang. Kritische Aktionen brauchen Freigaben oder zumindest harte Schwellenwerte. Und Protokolle müssen so gestaltet sein, dass später nicht nur ein API-Aufruf sichtbar ist, sondern auch der Kontext, der zu ihm geführt hat.
Regulierung macht die Lücke sichtbarer
Der EU AI Act ändert nicht die technische Natur dieser Risiken. Er erhöht aber den Druck, sie beschreibbar zu machen. Für Hochrisiko-Systeme stehen Anforderungen wie Dokumentation, Nachvollziehbarkeit, Protokollierung und menschliche Aufsicht im Raum. Gerade bei Agenten sind das keine Formalien. Ohne belastbare Logs und klare Verantwortlichkeiten lässt sich kaum erklären, warum ein autonomer Prozess eine bestimmte Entscheidung vorbereitet oder eine bestimmte Aktion ausgelöst hat.
Auch unabhängig von der Regulierung wird diese Nachvollziehbarkeit zur betrieblichen Mindestanforderung. Wenn ein Agent Zugriff auf Kundendaten, interne Wissensbestände oder operative Systeme erhält, reicht ein erfolgreicher Login als Sicherheitsnachweis nicht aus. Entscheidend wird, ob das Unternehmen den Agenten begrenzen, beobachten und im Zweifel stoppen kann.
Die schlichte Lehre aus der aktuellen Debatte lautet daher: KI-Agenten sollten nicht wie besonders komfortable Chatbots behandelt werden. Sie sind ausführende Software mit Modellanteil, Speicher, Werkzeugen und eigenem Handlungsspielraum. Wer sie absichert, muss nicht nur Identitäten verwalten, sondern Verhalten kontrollieren. Der gefährliche Agent ist nicht unbedingt der, der heimlich einbricht. Es kann auch der sein, der mit gültigem Ausweis hereinkommt und langsam lernt, das Falsche zu tun.
