Viele Diskussionen rund um KI-Sicherheit beginnen weiterhin auf der Modellebene: Wie zuverlässig sind die Antworten? Wie werden Halluzinationen reduziert? Welche Guardrails verhindern toxische oder unerwünschte Ausgaben? Diese Fragen bleiben wichtig. Sie beschreiben aber nur einen Teil des Risikos.
Bei agentischen KI-Systemen verschiebt sich der Schwerpunkt. Ein Agent antwortet nicht nur auf eine Eingabe, sondern kann Tools aufrufen, Informationen aus mehreren Quellen zusammenführen, Aufgaben in Teilschritte zerlegen und Aktionen in angebundenen Systemen auslösen. Damit geht es nicht mehr nur darum, was das Modell sagt. Es geht darum, was das System auf Basis dieser Ausgabe tut.
Vom Chatbot zum Akteur
Ein klassisches LLM, das Fragen beantwortet oder Texte zusammenfasst, bleibt in seiner Reichweite begrenzt. Es verarbeitet Eingaben, erzeugt Ausgaben und bleibt im Kern innerhalb eines Kommunikationskontexts. Risiken entstehen vor allem dort, wo Antworten falsch, manipuliert, vertraulich oder irreführend sind.
Ein agentisches System hat eine andere Reichweite. Es kann mit Anwendungen, APIs, Datenbanken, Dateisystemen, E-Mail-Clients oder internen Workflows verbunden sein. Damit entsteht aus einer Modellantwort schnell eine Systemaktion. Ein Agent kann ein Ticket aktualisieren, Daten abrufen, eine Nachricht vorbereiten, einen Prozess anstoßen oder eine Empfehlung in einen nachgelagerten Workflow übergeben.
Der Unterschied lässt sich knapp zusammenfassen:
| Klassische Anwendungssicherheit | Agentic AI Security | |
|---|---|---|
| Eingaben und Pfade | definiert | kontextabhängige Handlungsketten |
| Rollen und Services | feste | dynamische Tool-Nutzung |
| Requests | einzelne | mehrstufige Aktionen |
| Schwachstellen | Code und API | zusätzlich Prompt Injection, Memory, Delegation und Tool-Missbrauch |
Klassische Application Security bleibt damit weiterhin notwendig. Authentifizierung, Autorisierung, Input-Validierung, Verschlüsselung, Logging und sichere Schnittstellen werden nicht weniger wichtig. Der Punkt ist ein anderer: Agentische Systeme bringen zusätzliche Risikomuster in den Betrieb, weil sie nicht nur feste Pfade ausführen, sondern kontextabhängig handeln.
Die neue Angriffsfläche entsteht an den Übergängen
Die Angriffsfläche agentischer Anwendungen liegt selten nur im Modell selbst. Sie entsteht vor allem dort, wo ein Agent mit anderen Systemen verbunden wird: bei Tool-Zugriffen, Datenquellen, Memory, Delegation, externen Inhalten und automatisierten Folgeaktionen.
Das macht die Absicherung anspruchsvoller. Ein einzelner API-Call kann technisch erlaubt sein. Eine einzelne Datenabfrage kann unkritisch wirken. Eine einzelne Empfehlung kann nachvollziehbar aussehen. Das Risiko entsteht häufig erst in der Kombination:
Ein Agent liest Daten → interpretiert einen manipulierten Inhalt → ruft ein Tool auf → stößt eine Aktion an, die im ursprünglichen Nutzerauftrag nicht vorgesehen war.
Genau deshalb reicht es nicht, Agentic AI Security nur als Erweiterung klassischer Prompt-Filter zu behandeln. Prompt Injection ist ein wichtiger Angriffstyp, aber im agentischen Kontext ist sie vor allem deshalb gefährlich, weil sie Tool-Nutzung, Datenzugriffe oder Folgeaktionen beeinflussen kann.
Tool-Zugriffe müssen einzeln kontrollierbar sein
Sobald ein Agent Tools nutzen kann, wird Least Privilege konkreter. Bei klassischen Anwendungen sind Berechtigungen häufig an Services, Rollen oder Benutzergruppen gebunden. Bei Agenten reicht diese Logik allein nicht aus, weil das Verhalten stärker vom Kontext der Aufgabe abhängt.
Ein Agent kann beispielsweise berechtigt sein, Kundendaten abzurufen, um eine Support-Anfrage zu bearbeiten. Derselbe Zugriff wird problematisch, wenn eine manipulierte Eingabe den Agenten veranlasst, dieselben Daten für einen anderen Zweck zu nutzen oder mit einem weiteren Tool zu kombinieren. Das Problem ist dann nicht der Zugriff selbst, sondern die Verbindung aus Zugriff, Kontext und Folgeaktion.
Für produktive Agenten braucht es deshalb klare Regeln: welche Tools in welchem Kontext erlaubt sind, welche Aktionen eine menschliche Freigabe benötigen und welche Aufrufe blockiert oder gesondert protokolliert werden. Ein Agent muss nicht alles dürfen, nur weil eine Schnittstelle technisch erreichbar ist.
Memory ist hilfreich, aber sicherheitsrelevant
Memory macht Agenten nützlicher, weil frühere Interaktionen, Präferenzen oder Arbeitsstände in spätere Entscheidungen einfließen können. Gleichzeitig wird Memory damit selbst zu einer sicherheitsrelevanten Komponente.
Wenn ein Agent Informationen dauerhaft oder über längere Zeit speichert, muss klar sein:
- Welche Inhalte in diese Erinnerung gelangen dürfen
- Wie sie geprüft werden
- Wann sie wieder entfernt werden
Sonst kann manipulierte oder veraltete Information später in Entscheidungen einfließen, ohne dass der ursprüngliche Kontext noch sichtbar ist.
Oft wird dabei übersehen, dass nicht nur offensichtlich bösartige Eingaben riskant sind. Auch scheinbar harmlose Inhalte aus Dokumenten, Tickets, E-Mails oder Webseiten können Anweisungen enthalten, die ein Agent später als Kontext verarbeitet. In agentischen Workflows ist deshalb nicht nur der aktuelle Prompt relevant, sondern auch die Frage, welche gespeicherten Informationen der Agent zur Laufzeit heranzieht.
Delegation braucht klare Grenzen
In komplexeren Setups arbeiten mehrere Agenten oder spezialisierte Subsysteme zusammen. Ein Agent recherchiert, ein anderer bewertet, ein dritter bereitet eine Aktion vor. Diese Arbeitsteilung kann sinnvoll sein, erzeugt aber neue Vertrauensbeziehungen.
Wenn Agent A eine Aufgabe an Agent B weitergibt, muss klar sein, welche Berechtigungen dabei gelten. Darf Agent B dieselben Tools verwenden? Wird der ursprüngliche Nutzerauftrag mitgegeben? Werden Einschränkungen übernommen? Und was passiert, wenn Agent B wiederum ein anderes System oder einen weiteren Agenten einbindet?
Besonders kritisch: Ein niedriger privilegierter Agent stößt indirekt Aktionen an, die später von einem höher privilegierten System ausgeführt werden. Ohne klare Delegationsregeln entsteht schnell ein Berechtigungsgeflecht, das schwer zu prüfen ist. Für Unternehmen bedeutet das: Delegation braucht technische Grenzen, Protokollierung und im Zweifel menschliche Freigaben.
Folgeaktionen sind nicht immer vorhersehbar
Agenten sollen Aufgaben in Teilschritte zerlegen. Genau darin liegt ein Teil ihres Nutzens. Gleichzeitig entstehen dadurch Handlungsketten, die nicht immer vollständig vorhersehbar sind.
Ein Agent, der eine Support-Anfrage analysiert, kann etwa zusätzliche Kundendaten abrufen, ein Ticket priorisieren, eine interne Notiz erstellen und eine Antwort vorbereiten. Jeder einzelne Schritt kann plausibel sein. Die Kombination kann trotzdem problematisch werden:
- Der Agent nutzt eine falsche Quelle
- Er übernimmt eine vertrauliche Information
- Er löst eine Aktion aus, die eigentlich eine Freigabe benötigt hätte
Klassische Security-Tests prüfen häufig bekannte Pfade und bekannte Fehlkonfigurationen. Bei Agenten muss zusätzlich getestet werden, wie sich das System in unterschiedlichen Kontexten verhält — bei widersprüchlichen Informationen, manipulierten Dokumenten, unklaren Nutzeraufträgen oder Tool-Antworten, die Anweisungen enthalten.
Prompt Injection wird im agentischen Kontext operativer
Prompt Injection ist kein neues Thema. Bei agentischen Systemen verändert sich aber die Wirkung. Ein manipuliertes Dokument, eine präparierte Webseite oder eine gezielte Nutzereingabe führt dann nicht nur zu einer unerwünschten Antwort. Sie kann beeinflussen, welche Tools ein Agent aufruft, welche Daten er verarbeitet oder welche Aktion er als nächsten Schritt ausführt.
Die Angriffsfläche wächst, weil Agenten Inhalte aus mehreren Quellen verarbeiten: Nutzereingaben, API-Antworten, Tickets, E-Mails, Datenbankeinträge, Dokumente oder Webseiten. Jede dieser Quellen kann Anweisungen enthalten, die nicht als vertrauenswürdige Steuerlogik behandelt werden dürfen.
Für die Architektur heißt das: Externe Inhalte müssen von Systemanweisungen, Tool-Regeln und Freigabelogik sauber getrennt werden. Ein Agent darf nicht jede gefundene Information als gleichwertige Handlungsanweisung interpretieren. Genau diese Trennung wird zu einem Kernpunkt agentischer Security.
Warum klassische App-Security allein nicht reicht
Herkömmliche Application Security bleibt die Grundlage. Ohne saubere Authentifizierung, Autorisierung, Netzwerksegmentierung, Secrets Management, Monitoring und sichere APIs wird kein Agent sicher betrieben. Agentic AI Security ersetzt diese Maßnahmen nicht.
Sie ergänzt sie um eine zusätzliche Ebene. Klassische Anwendungen folgen meist definierten Pfaden. Agenten arbeiten stärker über Kontext, Tools und Zwischenschritte. Deshalb muss Security nicht nur prüfen, ob ein einzelner Request erlaubt ist, sondern auch, ob eine Handlungskette als Ganzes sinnvoll und erlaubt bleibt.
Das betrifft vor allem drei Bereiche: Berechtigungen müssen kontextbezogener werden, Logs müssen mehr als technische Requests abbilden, und Tests müssen Laufzeitverhalten statt nur statische Pfade berücksichtigen. Ein einzelner Tool-Aufruf kann legitim sein. Eine Sequenz aus Tool-Aufrufen kann trotzdem riskant sein.
Was Unternehmen jetzt prüfen sollten
Für produktive Agenten braucht es keine komplett neue Security-Disziplin neben allem Bestehenden. Es braucht aber eine Erweiterung der bestehenden Sicherheits- und Architekturarbeit um agentische Risikomuster.
Unternehmen sollten vor allem prüfen:
- Welche Tools, APIs und Datenquellen ein Agent erreichen kann.
- Welche Berechtigungen pro Tool und pro Kontext gelten.
- Welche Aktionen menschliche Freigaben benötigen.
- Welche Daten und Zwischenschritte protokolliert werden.
- Ob Memory-Inhalte geprüft, begrenzt und löschbar sind.
- Wie Delegation zwischen Agenten oder Systemen kontrolliert wird.
- Wie Prompt Injection über Dokumente, Webseiten, E-Mails oder API-Antworten getestet wird.
Diese Punkte gehören nicht erst in den Security-Review kurz vor dem Go-live. Sie beeinflussen Architektur, Integrationsdesign, Rollenmodelle und Betrieb. Wer Agenten produktiv einsetzen will, muss deshalb früh klären, welche Fähigkeiten ein Agent haben soll und welche bewusst ausgeschlossen bleiben.
Red-Teaming und Monitoring müssen näher an den Betrieb
Ein einmaliger Test reicht bei agentischen Systemen selten aus. Agenten verändern ihr Verhalten nicht beliebig, aber sie reagieren auf wechselnde Kontexte, neue Datenquellen, andere Nutzeraufträge und zusätzliche Tools. Dadurch können Risiken entstehen, die in einem klassischen Testfall nicht sichtbar waren.
Red-Teaming sollte deshalb nicht nur Prompts prüfen, sondern ganze Handlungsketten. Was passiert, wenn ein manipuliertes Dokument in einer Wissensdatenbank liegt? Wie reagiert der Agent auf eine API-Antwort, die versteckte Anweisungen enthält? Welche Tools ruft er auf, wenn der Nutzerauftrag unklar ist? Und wo wird eine Aktion gestoppt, bevor sie produktive Auswirkungen hat?
Auch Monitoring muss entsprechend breiter gedacht werden. Audit-Logs sollten nicht nur Ergebnisse speichern, sondern auch Tool-Aufrufe, verwendete Datenquellen, Freigaben, blockierte Aktionen und relevante Zwischenschritte. Nur so lässt sich später nachvollziehen, ob ein Agent innerhalb seiner vorgesehenen Grenzen gearbeitet hat.
Sicherheit entsteht in der Architektur
Die wichtigste Veränderung liegt nicht darin, dass klassische Security plötzlich falsch wäre. Sie reicht nur nicht mehr aus, wenn KI-Systeme selbstständig Tools nutzen und Aktionen anstoßen. Dann entsteht Sicherheit nicht nur durch sichere APIs oder gute Modellantworten, sondern durch kontrollierte Handlungsspielräume.
Für Unternehmen bedeutet das: Agenten brauchen klare Identitäten, begrenzte Berechtigungen, kontrollierte Tool-Zugriffe, nachvollziehbare Logs und definierte Eingriffspunkte. Security muss dort greifen, wo aus einer Modellantwort eine Systemaktion wird.
Agentic AI wird damit zur Architekturfrage. Nicht weil jede agentische Anwendung automatisch hochriskant ist, sondern weil ihre Sicherheit davon abhängt, wie Zugriff, Kontext, Tool-Nutzung und Betrieb zusammenspielen.
Ai11 unterstützt Unternehmen bei der Konzeption und Absicherung agentischer KI-Anwendungen — von der Architektur über Governance bis zum produktiven Betrieb. Kontaktieren Sie uns für ein unverbindliches Gespräch.