Assistent vs. Agent: Wo sich Ihr KI-Sicherheitsmodell ändert

Anbieter verwenden „Assistent", „Copilot" und „Agent" als marketinggetriebene Abstufungen desselben Begriffs. Für die IT-Sicherheit sind dies jedoch keine Nuancen. Es gibt eine klare Grenze, und deren Überschreitung verändert grundlegend, was schiefgehen kann, wer die Verantwortung trägt und welcher Kriterienkatalog greift.

Diese Grenze markiert die Frage, ob das System eigenständig handeln kann. Das ist eine deutlich präzisere Frage als abstrakte Autonomie.

Das Problem

Ein Support-Werkzeug beginnt oft damit, Entwürfe für Antworten zu verfassen. Ein Mensch liest jeden Entwurf und sendet ihn manuell ab. Nach einigen Monaten wird das Modell treffsicherer, und jemand stellt fest: Dass eine Person bei jedem Entwurf ungelesen auf Senden klickt, ist reine Farce. Also versendet das Werkzeug Antworten für definierte Ticket-Kategorien direkt.

Am zugrundeliegenden Modell hat sich nichts geändert, und auch das Architekturdiagramm sieht praktisch identisch aus. Das Fehlermuster hat sich jedoch radikal gewandelt: Zuvor war der schlimmste anzunehmende Fall ein schlechter Entwurf, der rechtzeitig auffiel. Danach ist es eine fehlerhafte Nachricht, die ungefiltert beim Kunden ankommt.

Später erhält das System Zugriff auf ein Tool zur Abfrage von Kontodetails, damit die Antworten präzise ausfallen. Plötzlich ist der Inhalt eines manipulierten Tickets ein Text, den das Modell liest, während es gleichzeitig über Zugangsdaten verfügt, um Kundendatenbanken abzufragen. Das Werkzeug hat die Grenze gleich zweimal überschritten, und bei keinem Schritt fand ein formales Sicherheits-Review statt, weil jeder Schritt nur eine winzige Erweiterung bestehender Funktionen darstellte.

Warum es bei KI anders ist

Fünf spezifische Eigenschaften trennen einen Agenten von einem einfachen Assistenten. Sie kommen meist schrittweise hinzu, weshalb die Grenze oft unbemerkt überschritten wird.

Erstens besitzt das System eine eigene Identität. Es authentifiziert sich als ein bestimmter Akteur. Sobald dies der Fall ist, greifen alle klassischen Berechtigungsprinzipien, mit dem entscheidenden Unterschied, dass die Instanz, die über den Einsatz dieser Berechtigungen entscheidet, probabilistisch arbeitet.

Zweitens kann das System handeln, und zwar über Schnittstellen, die Daten schreiben, Nachrichten versenden, Software ausrollen oder Zahlungen ausführen. Entscheidend ist hierbei, ob die Auswirkungen eines Tools reversibel sind und ob jemand die Aktion vor ihrer Ausführung prüft, nicht bloß, ob das Tool existiert.

Drittens behält es Zustand, also ein Gedächtnis über mehrere Arbeitsschritte oder Sitzungen hinweg. Dies ist die Eigenschaft, die am häufigsten unterschätzt wird. Zustand bedeutet, dass der Einfluss eines Angreifers über die Konversation hinaus bestehen bleibt, die ihn eingeschleust hat. OWASP führt dies unter ASI06 als Memory and Context Poisoning auf [1].

Viertens arbeitet es ohne Unterbrechung autonom weiter und führt mehrstufige Pläne eigenständig bis zum Ende aus. Der Schadensradius einer einzigen Fehlentscheidung wächst dadurch von einer falschen Antwort auf sämtliche nachfolgenden Handlungsschritte an.

Fünftens koordiniert es sich mit anderen Systemen, sei es im Verbund mehrerer Agenten oder indem ein Agent Werkzeuge aufruft, die ihrerseits als Agenten agieren. Risiken wie Insecure Inter-Agent Communication (ASI07) und Cascading Failures (ASI08) entstehen genau dadurch, dass sich ein Fehler in einer Komponente unkontrolliert fortpflanzt [1].

Die OWASP Top 10 for LLM Applications 2026 behalten für all diese Szenarien ihre Gültigkeit: Prompt Injection fällt unter LLM01, unabhängig davon, ob das System handeln kann, und das Offenlegen sensibler Kontexte bleibt LLM08 [2]. Diese Liste deckt jedoch nicht ab, was geschieht, nachdem das Modell eine Entscheidung getroffen hat, da sie für Anwendungen konzipiert wurde, die ein Modell nutzen, nicht für Systeme, die über ein solches handeln. Die agentenspezifische OWASP-Liste schließt diese Lücke, beginnend mit Agent Goal Hijack bei ASI01 und Tool Misuse bei ASI02 [1].

Beide Kataloge ergänzen einander. Wer bei einem Agenten ausschließlich die LLM-Liste anwendet, lässt die Risiken bezüglich Identität, Speicher und Koordination unberücksichtigt. Wer hingegen die Agenten-Liste auf einen reinen Assistenten anwendet, erzeugt unnötigen bürokratischen Mehraufwand für Fähigkeiten, die das System gar nicht besitzt.

Was tatsächlich funktioniert

Bestimmen Sie für jedes eingesetzte System eindeutig, auf welcher Seite der Grenze es steht, und dokumentieren Sie diesen Status verbindlich. Verlassen Sie sich nicht auf Marketingversprechen der Anbieter, sondern prüfen Sie die fünf oben genannten Kriterien. Sobald eine Frage mit Ja beantwortet wird, handelt es sich um einen Agenten, und ein Agent verlangt ein eigenständiges Sicherheits-Review.

Setzen Sie die Bestätigungsschritte genau dort an, wo die tatsächliche Wirkung entsteht. Ein Mensch, der einen groben Plan freigibt, unterscheidet sich grundlegend von einem Menschen, der jeden einzelnen irreversiblen Schritt quittiert. Die Freigabe muss unmittelbar am Wirkungspunkt ansetzen und auf Aktionen beschränkt bleiben, die dies rechtfertigen. Eine Bestätigungsaufforderung, die permanent aufpoppt, wird in der Praxis nur noch blind durchgewunken.

Behandeln Sie den Speicher als Eingabe und nicht als verlässlichen Speicherort. Alles, was ein Agent während einer durch nicht vertrauenswürdige Inhalte beeinflussten Sitzung in sein Gedächtnis geschrieben hat, gilt beim nächsten Lesevorgang als potenziell kompromittiert. Grenzen Sie den Speicher strikt pro Benutzer sowie pro Aufgabe ein und versehen Sie ihn mit Verfallszeiten. Mandantenübergreifender, langlebiger Speicher ist die riskanteste Architekturvariante.

Geben Sie dem Agenten eine dedizierte eigene Identität, statt ihn über persönliche Mitarbeiter-Accounts oder pauschale Service-Accounts laufen zu lassen. Dies ist die wichtigste Einzelmaßnahme, um Aktionen eines Agenten nachvollziehbar zu protokollieren und seine Berechtigungen sauber einzuschränken. Hierbei handelt es sich um klassische Infrastrukturarbeit, nicht um Modellanpassungen.

Begrenzen Sie Schleifen durch harte Limits für Einzelschritte, Ausführungszeiten und finanzielle Kosten, die extern und außerhalb des Agenten durchgesetzt werden. Ein Agent, der sich fälschlicherweise sicher ist, kurz vor dem Ziel zu stehen, wird unbegrenzt weiterlaufen. Die Begrenzung, die ihn stoppt, darf keine Variable sein, die das Modell selbst beeinflussen oder interpretieren kann.

Überwachen Sie die ausgeführten Aktionen aufmerksamer als die reinen Token-Ströme. Das Protokollieren von Prompts und Antworten zeigt Ihnen lediglich, was das Modell formuliert hat. Erst das Logging von Tool-Aufrufen samt Parametern und Rückgabewerten dokumentiert verlässlich, was tatsächlich ausgeführt wurde. Das ist genau das Protokoll, das Sie bei einem Sicherheitsvorfall benötigen. Der Praxistest lautet: Wenn ein Agent am vergangenen Dienstag eine Änderung vorgenommen hat, können Sie exakt nachweisen, welcher Aufruf dies war, unter welcher Identität und mit welchen Parametern? Wenn Sie dafür Konversationsverläufe analysieren müssen, setzt Ihr Logging auf der falschen Ebene an.

Trennen Sie lesende strikt von schreibenden Agenten. Einen universellen Agenten in einen reinen Recherche-Agenten und einen funktional stark eingeschränkten Ausführungs-Agenten aufzuteilen, kostet etwas architektonische Eleganz, schafft aber eine echte Sicherheitsgrenze: Die Komponente, die ungesicherten Inhalten ausgesetzt ist, besitzt keine Schreibberechtigungen. Zudem lässt sich ein späterer Vorfall schnell aufklären, da die handelnde Komponente nur über ein eng begrenztes, klar definiertes Aktionsset verfügte.

Was nicht funktioniert

Entscheidungen anhand von Produktkategorien scheitern regelmäßig, da Bezeichnungen wie „Copilot" bloßes Marketing darstellen und nichts über die technischen Fähigkeiten aussagen. Manche Copilots machen lediglich Textvorschläge, andere committen Code und triggern CI/CD-Pipelines. Der Name verrät Ihnen darüber rein gar nichts.

Den Menschen im Prozess als Sicherheitsmaßnahme anzusehen, ohne dessen reale Wirksamkeit zu verifizieren, funktioniert ebenfalls nicht. Wenn eine Person vierzig Aktionen pro Tag bestätigen muss, verkommt sie zum reinen Stempelautomaten, und die Schutzwirkung ist rein dekorativ. Wenige, dafür gezielte Genehmigungsschritte bieten deutlich mehr Sicherheit als eine Flut an Bestätigungen.

Die Annahme, dass reine Lese-Werkzeuge einen Agenten automatisch harmlos machen, ist ein weiterer Trugschluss. Ein Agent, der ausschließlich lesen kann, dabei aber Zugriff auf Kundendatensätze hat und Netzwerkverbindungen aufbauen darf, stellt einen idealen Pfad für Datenabflüsse dar. Das Prinzip der geringsten Rechte gilt für Leseoperationen gleichermaßen.

Sich ausschließlich auf die Absicherung des Sprachmodells zu konzentrieren, lässt den Großteil der tatsächlichen Risiken unberührt. Schutzgeländer für Ein- und Ausgaben wirken nur auf einer Ebene. Sie nützen wenig, wenn Zugangsdaten zu weitreichend vergeben sind oder der Speicher manipulierte Anweisungen bis zum nächsten Tag persistiert.

Die schrittweise Grenzüberschreitung ist der häufigste Fehler in Projekten. Kaum jemand winkt die Entwicklung eines vollautonomen Agenten auf einen Schlag durch. Stattdessen wird zunächst ein Werkzeug ergänzt, später eine manuelle Freigabe entfernt und schließlich ein Speicher aktiviert. Jeder Schritt für sich wirkt unbedenklich; das Endergebnis ist jedoch ein grundlegend anderes System unter unverändertem Namen, das im Ticket-System oft noch unter der ursprünglichen Bezeichnung für reine Entwurfswerkzeuge geführt wird.

Zu vertrauen, dass Framework-Voreinstellungen restriktiv gewählt sind, ist die letzte typische Falle. Agenten-Frameworks sind darauf optimiert, dass Entwickler möglichst schnell lauffähige Ergebnisse erzielen. Das bedeutet in der Regel: standardmäßig breiter Tool-Zugriff, aktivierter Speicher und keinerlei Schrittbegrenzungen. Für einen Prototyp mag das genügen, für den Produktivbetrieb ist es fahrlässig. Da bei fehlerhafter Konfiguration zunächst nichts offensichtlich abstürzt, werden diese Einstellungen später selten hinterfragt.

Wo Sie anfangen sollten

• Erfassen Sie Ihre KI-Systeme und prüfen Sie jedes anhand der fünf Kriterien: Identität, Handlung, Zustand, Fortsetzung und Koordination. Jedes System, das drei oder mehr Kriterien erfüllt, ist als Agent einzustufen, unabhängig von der internen Bezeichnung.
• Weisen Sie für jeden Agenten die Identität aus, unter der er sich authentifiziert. Handelt es sich um geteilte Konten oder Benutzer-Accounts, ist dies die erste Baustelle.
• Identifizieren Sie alle irreversiblen Aktionen und überprüfen Sie, ob ein Mensch diese vorab einsieht und ob dieser auch die zeitliche Möglichkeit hat, sie fundiert zu bewerten.
• Prüfen Sie, welche Daten im Speicher persistiert werden, über welchen Zeitraum und ob diese strikt pro Benutzer isoliert sind.
• Verankern Sie die Definition dieser Grenze verbindlich in Ihrem Change-Management. Das Hinzufügen eines Werkzeugs, das Entfernen einer manuellen Freigabe oder das Aktivieren von Speicher muss zwingend ein erneutes Sicherheits-Review auslösen.

Die entscheidende Fragestellung lautet daher stets: Führt eine Fehlentscheidung zu einer falschen Antwort oder zu einer falschen Aktion? Davon leitet sich jede weitere Sicherheitsmaßnahme ab.

Quellen

1. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, veröffentlicht am 9. Dezember 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
2. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, veröffentlicht am 3. August 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/