Viele Unternehmen starten gerade ihre ersten produktiven KI-Agenten: ein Support-Agent liest Tickets und Kundendaten, ein Entwickler-Agent prüft Pull Requests, ein Operations-Agent fragt Logs ab und stößt Reparaturschritte an. In fast jedem Pilotprojekt taucht dieselbe Beruhigungsformel auf: „Der Agent bekommt im System-Prompt klare Regeln.“ Er soll nur Daten anzeigen, die der Nutzer sehen darf. Er soll keine riskanten Aktionen ausführen. Er soll keine vertraulichen Informationen nach außen geben.
Das klingt vernünftig, ist aber keine Sicherheitsarchitektur. Die aktuelle SANS/AWS-Veröffentlichung „Agentic Security: Detection and Response at Machine Speed“ bringt es nüchtern auf den Punkt: Prompts können „bypassed, ignored, or overridden“ werden. Wenn ein Nutzer einen Datensatz über die normale Anwendung nicht lesen darf, darf der Agent diesen Datensatz auch nicht in sein Kontextfenster bekommen. Die Kontrolle muss vor dem Modell greifen — in Identität, Datenzugriff, Tool-Aufruf, Telemetrie und Response.
Warum Agenten andere Grenzen brauchen
Der Unterschied zu klassischen Chatbots ist nicht nur die bessere Antwortqualität. Ein Agent authentifiziert sich im Namen eines Nutzers oder mit vorab genehmigten Rechten, ruft Werkzeuge auf, kombiniert mehrere Schritte und trifft Teilentscheidungen ohne jedes Mal auf menschliche Freigabe zu warten. Damit wird jeder Tool Call zu einer kleinen Produktionshandlung: Daten lesen, Tickets ändern, Code ausführen, E-Mails schreiben, Infrastruktur abfragen oder Records löschen.
SANS/AWS beschreibt vier Reifestufen: einfache Frage-Antwort-Systeme, Systeme mit Zugriff auf Unternehmensdaten, autonom handelnde Agenten und schließlich Agenten-Ökosysteme, in denen mehrere spezialisierte Agenten Aufgaben delegieren. Jede Stufe übernimmt die Sicherheitsanforderungen der vorherigen und fügt neue hinzu. Bei Retrieval-Augmented Generation reicht es nicht mehr, nur den Prompt abzusichern; jede Abfrage ist implizit eine Zugriffsentscheidung gegen Datenbestände. Bei autonomen Agenten kommt hinzu, dass aus einer falschen Entscheidung eine Aktion wird.
Der Bericht nennt außerdem einen Governance-Abstand, der in der Praxis sichtbar ist: Laut der im Papier zitierten McKinsey-Erhebung haben 80 Prozent der Organisationen KI eingeführt, aber nur 10 Prozent verfügen über Governance dafür. Für Security-Teams heißt das: Agenten entstehen schneller, als Rollenmodelle, Logs, Freigabeprozesse und Incident-Response-Playbooks nachziehen.
Die „High-Risk Trifecta“ als Architekturtest
Besonders riskant wird ein Agent, wenn drei Eigenschaften zusammenfallen: Zugriff auf sensible Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und ein Kommunikationskanal nach außen. Help Net Security fasst diesen Punkt in seiner Berichterstattung zur SANS/AWS-Guidance als zentrale Kontrollfrage zusammen. Ein Agent, der interne Kundendaten lesen kann, gleichzeitig E-Mails oder Webinhalte verarbeitet und anschließend Nachrichten, API-Requests oder Dateien nach außen senden darf, ist ein natürlicher Exfiltrationspfad.
Prompt Injection ist dafür der klassische Auslöser. OWASP führt Prompt Injection auch in der 2026er LLM-Top-10 weiterhin als Top-Risiko; Sensitive Information Disclosure und Excessive Agency gehören ebenfalls zu den dominanten Kategorien. Der wichtige Satz aus OWASP lautet sinngemäß: Man sollte nicht versuchen, ein Modell zu bauen, das nie getäuscht werden kann. Man sollte das System so bauen, dass nichts Wichtiges kaputtgeht, wenn das Modell getäuscht wird.
Genau daraus folgt die Architekturregel: Kein einzelner Agent sollte alle drei Elemente der Trifecta gleichzeitig besitzen. Ein Lesedienst kann sensible Daten sehen, aber nicht extern senden. Ein Kommunikationsdienst kann Nachrichten verschicken, bekommt aber nur bereits geprüfte Inhalte. Ein Agent, der untrusted Content verarbeitet, bekommt nur stark begrenzte Tools und keine breiten Produktionsrechte.
Wo Kontrollen tatsächlich sitzen müssen
Die erste harte Grenze ist Autorisierung zur Abrufzeit. Wenn ein Agent im Namen eines Mitarbeiters sucht, muss die Datenbank-, Such- oder RAG-Schicht die Abfrage auf dessen RBAC- oder ABAC-Rechte begrenzen, bevor Ergebnisse an das Modell gehen. Ein System-Prompt wie „zeige nur erlaubte Daten“ ist höchstens eine Bedienungsanweisung. Die Sicherheitsentscheidung gehört in den Policy- und Datenlayer.
Die zweite Grenze ist der Tool-Aufruf. SANS/AWS nennt Default-Deny am Tool-Invocation-Layer das kritischste Muster. Praktisch bedeutet das: Jeder Tool Call wird gegen eine explizite Policy geprüft. Welche Ressource wird berührt? Ist die Aktion lesend oder verändernd? Welche Identität steht dahinter? Ist der Kontext normal? Frameworks wie Cedar oder Open Policy Agent werden im Bericht als skalierbare Policy-as-Code-Bausteine genannt. Entscheidend ist nicht das konkrete Produkt, sondern das Prinzip: Ohne ausdrückliche Erlaubnis passiert nichts.
Die dritte Grenze ist Identität. Agenten sollten keine dauerhaften, breit berechtigten Sammelcredentials nutzen. Sie brauchen eigene, nachvollziehbare nichtmenschliche Identitäten, kurzlebige und eng gescopte Credentials sowie eine Kette, die zeigt, für welchen Nutzer oder welchen Auftrag eine Aktion ausgeführt wurde. Multitenant-Agenten müssen außerdem pro Nutzer oder Team anders berechtigt sein; sonst wächst aus einem Hilfswerkzeug schnell eine Schatten-Admin-Rolle.
Detection in Minuten, nicht in Quartalen
Ein weiterer hilfreicher Begriff aus der SANS/AWS-Guidance ist „Attack Surface Minutes“: Wie lange bleibt eine Schwachstelle oder Fehlkonfiguration ausnutzbar, bevor Kontrollen sie entdecken und eindämmen? Bei Agenten ist diese Metrik wichtiger als ein jährlicher Review, weil autonome Workloads schnell handeln und API-Aufrufe in hoher Frequenz erzeugen.
Klassische User-Behavior-Analytics lassen sich nicht einfach übertragen. Ein Coding-Agent startet legitimerweise mehrere Prozesse, liest viele Dateien, ruft Tools in schneller Folge auf und erzeugt Muster, die bei Menschen verdächtig wären. SANS/AWS empfiehlt daher, die risikoreichsten Agenten zuerst zu instrumentieren und mindestens 30 Tage Baseline-Daten zu sammeln, bevor Detektionsregeln feinjustiert werden. Das ist kein Argument gegen sofortige Überwachung, sondern gegen naive Schwellenwerte.
Für den Ernstfall reicht Alarmierung nicht. Der Bericht fordert parallele Eindämmung über vier Ebenen: Credentials widerrufen und Sessions sperren, Egress blockieren oder Workload isolieren, Tool-Zugriff deaktivieren und Agentenstatus einfrieren, Datenzugriff einschränken und Logging erhöhen. Bei hoher Auswirkung gehört ein menschlicher Checkpoint vor die Aktion; bei niedriger Auswirkung und hoher Legitimitätswahrscheinlichkeit kann Automatisierung sinnvoll sein.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen eine Agenten-Inventur erstellen: Welche Agenten laufen bereits, auf welche Daten greifen sie zu, welche Tools dürfen sie nutzen, welche externen Kanäle haben sie? Diese Inventur muss auch Low-Code- und Fachbereichsagenten umfassen, nicht nur zentrale Plattformprojekte.
Zweitens sollte jedes Agentenprojekt einen Berechtigungs- und Tool-Review bekommen, bevor Produktivdaten angeschlossen werden. Kritische Fragen: Kann der Agent schreiben oder löschen? Kann er extern senden? Berührt er Kundendaten, Secrets, Code-Repositories, CI/CD oder Cloud-Konten? Gibt es ein Kill-Switch-Verfahren?
Drittens brauchen Logs Integrität. Prompts, Tool Calls, Antworten, Policy-Entscheidungen und Eskalationen müssen rekonstruierbar sein. Nicht, weil jedes Token für immer gespeichert werden sollte, sondern weil ein Unternehmen nach einem Vorfall erklären können muss, welcher Agent mit welcher Identität welche Entscheidung getroffen hat.
Risiken und Grenzen
Die SANS/AWS-Guidance ist kein Beleg für einen einzelnen neuen Massenangriff. Sie ist ein Architekturpapier für eine Klasse von Systemen, die bereits produktiv wird. Auch Default-Deny löst nicht jedes Problem: Eine zu breite Policy bleibt gefährlich, erlaubte Ausgabekanäle können missbraucht werden, und Baselines können am Anfang unvollständig sein. Zudem muss Datenschutz gegen Logging-Tiefe abgewogen werden.
Trotzdem ist die Hauptbotschaft belastbar: Agentensicherheit entsteht nicht im Prompt. Sie entsteht in unabhängigen Kontrollen, die auch dann funktionieren, wenn das Modell falsch liegt, manipuliert wird oder unerwartet handelt.
Fazit
Der System-Prompt ist wichtig für Verhalten, aber ungeeignet als Schutzmauer. Unternehmen sollten KI-Agenten wie privilegierte, nichtmenschliche Workloads behandeln: eigene Identität, kurzlebige Rechte, autorisierte Datenabrufe, Default-Deny für Tools, beobachtbare Aktionen, schnelle Eindämmung und menschliche Freigabe bei hohem Risiko. Wer diese Schichten einzieht, kann Agenten produktiv nutzen, ohne darauf zu wetten, dass natürliche Sprache eine Sicherheitsgrenze ersetzt.
Quellen: SANS/AWS, „Agentic Security: Detection and Response at Machine Speed“, August 2026; Help Net Security, „Your AI agent’s system prompt is not a security control“, 3. September 2026; OWASP GenAI Security Project / Help Net Security, „OWASP 2026 LLM Top 10“, August 2026.
