KI-Agenten und Sicherheit: Warum Authentifizierung allein nicht reicht
Im Juni 2025 entdeckten Sicherheitsforscher eine Schwachstelle in Microsoft 365 Copilot, die mit einem CVSS-Score von 9.3 als kritisch eingestuft wurde. Der Name: EchoLeak (CVE-2025-32711). Das Besondere daran war nicht die Komplexität, sondern die Einfachheit.
Ein Angreifer schickte eine harmlos aussehende E-Mail mit versteckten Anweisungen. Für das menschliche Auge unsichtbar, für das KI-Modell eine Befehlsfolge. Die E-Mail wartete geduldig, bis Copilot sie in einen Kontext zog. In dem Moment griff der Agent mit den Rechten des Opfers auf sensible Daten zu und gab sie weiter. Kein Klick nötig. Keine Interaktion. Der Nutzer hat nichts falsch gemacht.
1Password hat diesen Fall in einer umfassenden Analyse aufgegriffen und daraus eine grundsätzliche Frage abgeleitet: Wo genau bricht das bisherige Sicherheitsmodell, wenn ein KI-Agent nicht nur antwortet, sondern handelt?
Das Access-Trust-Gap
Traditionelle IT-Sicherheit beantwortet zwei Fragen: Wer ist das? Und was darf diese Person? Authentifizierung klärt die erste, Autorisierung die zweite. Das Modell funktioniert, solange ein Mensch die Aktion ausführt, seine Absicht klar ist und alles innerhalb einer definierten Session passiert.
KI-Agenten passen nicht in dieses Modell. Ein Agent bewegt sich durch mehrere Systeme, nutzt verschiedene Berechtigungen und verknüpft Aktionen auf eine Weise, die für den Nutzer nicht sichtbar ist. Seine Absicht ist nicht fix. Sie kann sich während der Ausführung ändern, abhängig davon, was der Agent findet, was er interpretiert und welche externen Inhalte in seinen Kontext gelangen.
Identity und Authorization beantworten Fragen, die gestellt wurden, bevor etwas passiert ist. Sie sagen nicht, ob das, was gerade passiert, noch sinnvoll ist.
1Password hat das in einem eigenen Benchmark dokumentiert. In ihrem AI Agent Security Benchmark zeigten die Autoren: Selbst wenn ein Agent gültige Anmeldedaten hat, handelt er regelmäßig außerhalb seines vorgesehenen Bereichs. In einem Fall erkannte das Modell eine Phishing-Seite korrekt, öffnete sie trotzdem, holte sich die Anmeldedaten und gab sie ein. Das Problem war nicht, ob der Zugriff erlaubt war, sondern wie er genutzt wurde.
Die Zahl, die wehtut
Die Hilfszahlen für IT-Verantwortliche sind alarmierend. Laut einer EY-Umfrage haben 64 Prozent der Unternehmen mit mehr als einer Milliarde Dollar Umsatz mehr als eine Million Dollar durch KI-Ausfälle verloren. Fünfundzwanzig Prozent der Unternehmen berichteten von einem Sicherheitsvorfall, der mit unautorisiertem KI-Gebrauch zusammenhing.
Internes sogenanntes Shadow AI ist dabei das größere Problem. Laut einer Help Net Security-Analyse haben 63 Prozent der Mitarbeiter, die 2025 KI-Tools nutzten, sensible Unternehmensdaten einschließlich Quellcode und Kundendaten in persönliche Chatbot-Konten kopiert. Durchschnittlich laufen in größeren Unternehmen rund 1.200 inoffizielle KI-Anwendungen. 86 Prozent der Organisationen haben keinerlei Sicht auf ihre KI-Datenströme.
Prompt Injection: der Angriff, der nicht aufhört
Prompt Injection ist nicht neu, aber die Art, wie er eingesetzt wird, hat sich 2025 grundlegend verändert. Der OWASP Top 10 für LLM-Anwendungen führt ihn als primären Angriffsvektor. Multi-Turn-Attacken, die sich über mehrere Konversationen erstrecken, erreichten in Tests eine Erfolgsrate von 92 Prozent bei acht Open-Weight-Modellen.
Das Grundproblem ist technisch ungelöst: Sprachmodelle können nicht zuverlässig zwischen legitimen Anweisungen und schadhaften Inhalten unterscheiden, die in externen Daten versteckt sind. Solange das so ist, nützt die beste Authentifizierung nichts, wenn der Agent mit diesen Rechten dann das Falsche tut.
Stanfords Trustworthy AI Research Lab hat gezeigt, dass Fein-Tuning-Angriffe die Modell-Sicherung bei Claude Haiku in 72 Prozent und bei GPT-4o in 57 Prozent der Fälle umgehen. Modellinterne Guardrails allein reichen nicht aus.
Was 1Password vorschlägt: dynamische Autorität
Der Kernvorschlag aus der 1Password-Analyse ist simpel: Statt eine einmalige Zugriffsentscheidung zu treffen und anzunehmen, dass sie gilt, müssen Systeme den Zugriff während der Ausführung kontinuierlich bewerten.
Das bedeutet konkret:
Kurzlebige Berechtigungen. Statt Standing Permissions werden Credentials nur für eine spezifische Aktion ausgestellt. AWS STS, OAuth 2.0 Token Exchange oder SPIFFE/SPIRE setzen genau dieses Prinzip um. Der Agent hat nur Zugriff, solange und nur auf das, was er gerade braucht.
Kontextbezogene Durchsetzung. Jede Agentenaktion wird gegen eine Policy geprüft: Passt diese Aktion zum Auftrag? Ist sie zum richtigen Zeitpunkt erlaubt? Wurde sie durch externe Inhalte beeinflusst? Die Antwort muss deterministisch erfolgen, nicht vom Modell selbst.
Audit und Rekonstruktion. Jede Aktion muss dokumentiert werden, damit im Nachhinein rekonstruierbar ist, was passiert ist und warum.
1Passwords Nancy Wang fasst es zusammen: Sandboxed Tool Execution, kurzlebige Credentials, Runtime-Policy-Enforcement und umfassende Audit-Logs sollten Standard in der Plattform sein, nicht individuelle Engineering-Leistung.
Was das für deutsche Unternehmen bedeutet
Die Diskussion um KI-Sicherheit wird in Deutschland oft auf Datenschutz reduziert. Das ist wichtig, aber es greift zu kurz. EchoLeak hat gezeigt, dass ein KI-Agent mit gültigen Berechtigungen sensible Daten abfließen lassen kann, ohne dass jemand eine Datenschutzerklärung verletzt hat. Der Agent war authentifiziert. Er war autorisiert. Er hat trotzdem das Falsche getan.
Für IT-Verantwortliche in Deutschland bedeutet das im Alltag:
KI-Agenten abschotten. Kein Agent sollte mehr Berechtigungen haben als nötig. Wer Copilot oder andere KI-Assistenten in seiner Organisation einsetzt, sollte ihre Zugriffsrechte genauso restriktiv konfigurieren wie bei einem Dienstleister, dem man nicht vertraut.
Shadow AI sichtbar machen. Wenn 63 Prozent der Mitarbeiter sensible Daten in persönliche KI-Tools kopieren, ist das kein Mitarbeiterproblem, sondern ein Kontrollproblem. DLP-Systeme und Netzwerk-Monitoring für KI-Dienste sind kein Nice-to-have mehr.
Runtime-Controls evaluieren. Produkte wie 1Password Unified Access, aber auch open-source Ansätze wie SPIFFE für Workload-Identity, bieten erste Lösungen. Wer KI-Agenten in Produktion betreibt, muss sich jetzt damit beschäftigen, nicht nach dem ersten Vorfall.
Red Teaming integrieren. Nancy Wang von 1Password empfiehlt, kontinuierliches Adversarial Testing in den Entwicklungszyklus zu integrieren. Modellupdates, Prompt-Änderungen oder Agenten-Rekonfigurationen sollten automatisch Test-Suites auslösen.
Die Community wehrt sich
Nicht nur Sicherheitsexperten stellen die Frage nach Vertrauen. Eine aktuelle Petition auf GitHub fordert, KI-generierten Code aus dem Kern von Node.js zu verbannen. Die Unterschreiber argumentieren, „dass eine Verwässerung des Kerns, der über die Jahre hinweg mit Sorgfalt und Gewissenhaftigkeit von Hand verfasst wurde, im Widerspruch zu den Werten des Projekts steht."
Das ist kein Anti-KI-Reflex. Das ist die Frage, ob man Code, der kritische Infrastruktur betreibt, von einer Maschine schreiben lassen sollte, deren Entscheidungen nicht nachvollziehbar sind. In der Open-Source-Welt, wo Transparenz und Peer-Review das Fundament sind, ist KI-generierter Code ein grundsätzliches Problem: Wer reviewt den Code? Wer versteht, warum er so geschrieben ist, wie er ist?
Meine Einschätzung
Der 1Password-Artikel trifft einen Punkt, der in der Branche noch nicht genug Beachtung findet: Die Frage ist nicht mehr, ob ein KI-Agent zugreifen darf. Die Frage ist, ob er es gerade tun sollte.
In der Praxis sehe ich das bei den eigenen Projekten. Ein SIP-Voice-Agent, den ich im Einsatz habe, hat Zugriff auf interne Systeme. Die Authentifizierung stimmt, die Autorisierung stimmt, aber sobald er auf externe Inhalte trifft, kann sein Verhalten unvorhersehbar werden. Die Lösung ist nicht, dem Agenten die Berechtigungen zu entziehen. Die Lösung ist, seine Aktionen im Moment der Ausführung zu prüfen und zu begrenzen.
Der nächste Sicherheitslayer sitzt nicht an der Tür. Er sitzt im Flur.
Quellen: