Die tödliche Trifekta durchbrechen: Wie Asana über die Sicherheit von agentischer KI denkt
Agentic AI führt eine Klasse von Sicherheitsrisiken ein, die die Branche noch nicht gelöst hat. So definieren wir es bei Asana, und das sind die Sicherheitsinvarianten, die wir für alle unsere KI-Funktionen beibehalten.
Das Problem
Agentische KI-Systeme beantworten nicht nur Fragen. Sie lesen Dokumente, führen Aktionen aus und koordinieren über Tools hinweg. Je mehr sie tun können, desto größer ist ihre Angriffsfläche.
Im Gegensatz zu herkömmlichem Code haben LLMs eine Eigenschaft, die dies grundsätzlich erschwert: Sie können Anweisungen nicht zuverlässig von Daten unterscheiden. Alles, was in ein LLM eingespeist wird, landet im selben Stream, sodass ein sorgfältig erstelltes Datenelement das Modell auf dieselbe Weise manipulieren kann wie eine legitime Anweisung. Dies ist die Ursache für die Prompt-Injection, die Simon Willison als „die Erbsünde“ von LLM-basierten Anwendungen bezeichnet.
Das ist nicht nur theoretisch. Forscher haben diese Angriffsart gegen Microsoft 365 Copilot, den MCP-Server von GitHub, Slack AI und viele andere demonstriert. Bruce Schneier formulierte es unverblümt: Die Branche verfügt noch nicht über robuste Abwehrmechanismen gegen diese Angriffsart.
Wie baut man also agentische KI verantwortungsvoll auf, wenn die Branche die Grundlagen noch nicht verstanden hat?
Die tödliche Trifekt
Willison fasst das Kernrisiko in drei Fähigkeiten zusammen, die in Kombination die Voraussetzungen für Schaden schaffen:
Zugang zu sensiblen Daten. Der KI-Assistent kann vertrauliche oder private Informationen lesen.
Exposition gegenüber nicht vertrauenswürdigen Inhalten. Der KI-Assistent verarbeitet Eingaben, die versteckte Anweisungen von böswilligen Akteuren enthalten können.
Die Möglichkeit, extern zu kommunizieren. Der Assistent kann Informationen außerhalb des Systems senden.
Eine nützliche Präzisierung zum dritten Punkt: Es geht wirklich um die Fähigkeit, Nebenwirkungen zu erzeugen, nicht nur um ausgehende Kommunikation. Die Exfiltration von Daten auf den Server eines Angreifers ist das klassische Beispiel, aber eine bösartige Anweisung, die still und leise jedes Projekt in einem Arbeitsbereich umbenennt oder sensible Inhalte an den falschen internen Kanal sendet, stellt die gleiche Art von Problem dar. Wir verwenden „externe Kommunikation“ als Abkürzung, aber die umfassendere Version ist das, wogegen wir uns tatsächlich schützen.
Jeder einzelne Teil der Trifecta ist beherrschbar. Selbst zwei zusammen sind es in der Regel. Aber wenn alle drei zusammenkommen, haben Sie einen tragfähigen Angriffspfad.
Die wichtige Analytik: Wenn man einen der drei Bereiche durchbricht, verringert sich das Gesamtrisiko erheblich. Wir müssen das Problem der Prompt-Injection nicht perfekt lösen. Das hat noch niemand geschafft. Wir müssen sicherstellen, dass alle drei Bedingungen nicht einfach gleichzeitig erfüllt werden können.
Korny Sietsma baut darauf auf und ordnet dem Dreiklang Risikominderungsmaßnahmen wie Sandboxing, Aufgabenzersetzung, Zugriffsrechte mit geringsten Privilegien und Human-in-the-Loop zu. Dies sind die Bausteine. Die Frage ist, wie man sie umsetzt.
Kontext, Kontrollpunkte und Kontrollen
Wir strukturieren unser Denken um drei Säulen, die direkt mit der tödlichen Trifecta verknüpft sind. Jede Säule schränkt eine Lage ein.
Asana hat mehrere KI-Oberflächen. AI Teammates sind eigenständige Teilnehmer mit eigener Mitgliedschaft und eigenen Berechtigungen im Arbeitsbereich. Andere KI-Funktionen agieren als Nutzer, wobei die Grenze darin besteht, worauf dieser Nutzer bereits Zugriff hat. Die folgenden Invarianten konzentrieren sich auf den agentischen Fall, bei dem die Oberfläche am größten ist, und wir werden darauf hinweisen, wo sich die Implementierung je nach Oberfläche unterscheidet.
Kontext: Verwalten, was die KI sehen kann
Trifecta-Bein: Zugriff auf sensible Daten
Damit agentische KI nützlich sein kann, braucht sie Kontext. Die Herausforderung besteht darin, ihr genug Informationen zu geben, damit sie hilfreich sein kann, ohne ihr einen Generalschlüssel zu geben.
Unsere grundlegende Invariante ist das Prinzip des geringsten Privilegs, wobei die genaue Ausprägung von der Oberfläche abhängt. Für AI Teammates, die eine eigene Mitgliedschaft haben, die von der eines einzelnen Nutzers getrennt ist, ist die Grenze die Schnittmenge der Berechtigungen des Teamkollegen und der des Nutzers. Für KI-Funktionen, die als Nutzer agieren, ist die Grenze einfach der eigene Zugriff dieses Nutzers. In jedem Fall regelt dieselbe serverseitige Autorisierungsebene, die jede andere Interaktion in Asana regelt, auch den Zugriff der KI. KI-Funktionen erhalten keine erweiterten Berechtigungen. Sie arbeiten innerhalb des Zugriffskontrollsystems von Asana, nicht außerhalb davon.
Die Definition des Kontextes umfasst mehr als die Regulierung des internen Datenzugriffs innerhalb von Asana; sie umfasst gleichermaßen die externen Integrationen, mit denen ein Agent interagieren kann. Während Integrationen derzeit eine explizite Nutzerautorisierung erfordern, entwickeln wir detaillierte, Agent-spezifische Kontrollpfade. Dies ermöglicht es Unternehmen, Integrationsberechtigungen für AI Teammates einzuschränken, die mit risikoreichen Eingaben umgehen. Unsere zentrale architektonische Konstante ist klar: Die Grenze dessen, was eine KI sehen kann, muss dynamisch sein und von den Dateneigentümern bestimmt werden, anstatt ein fest codierter Produktstandard zu sein.
Selbst wenn ein Angreifer bösartige Anweisungen in den Kontext der KI einschleust, ist das, was die KI tatsächlich sehen kann, durch das gleiche Berechtigungsmodell wie alles andere begrenzt.
Kontrollpunkte: Filtern, was die KI hört
Trifecta-Etappe: Gefährdung durch nicht vertrauenswürdige Inhalte
Dies ist die schwierigste Etappe. In einer Work-Management-Plattform liest KI hauptsächlich nutzergenerierte Inhalte: Aufgaben, Kommentare, angehängte Dokumente. Ein Teil davon stammt von außerhalb des Unternehmens. Sie können sich nicht weigern, diese Inhalte zu lesen.
Stattdessen richten wir Kontrollpunkte ein: Stellen, an denen wir vertrauenswürdige Absichten von willkürlichem Inhalt unterscheiden und an denen Menschen eingreifen können, wenn etwas nicht in Ordnung zu sein scheint.
Quellenbewusste Bearbeitung von Anweisungen. KI-Funktionen kennzeichnen Inhalte nach Autor-Vertrauenswürdigkeit und nach Quelle, sodass das Modell Anweisungen von autorisierten Benutzern höher gewichten kann als Anweisungen, die in willkürlichen Inhalten auftauchen. Dies verringert die Angriffsfläche für die Prompt-Injection, schließt sie aber nicht aus; das Modell liest immer noch alles in seinem Kontext, und die Sicherheitsgarantie ist eher partiell als absolut. Im Folgenden erörtern wir die Grenzen dieses Ansatzes.
Protokollierung und forensische Untersuchung. Jeder Modellaufruf wird mit seinen Inputs, Outputs, dem Akteur, dem Feature-Kontext und den nachgelagerten Ereignissen protokolliert, einschließlich der Work-Graph-Objekte, die eine Automatisierung berührt hat, und der URLs, die im Output aufgetreten sind. Wir warnen automatisch vor betrieblichen Signalen wie Fehlerraten und Kostenspitzen. Bei sicherheitsrelevanten Unregelmäßigkeiten unterstützen dieselben Protokolle die nachträgliche Untersuchung durch Menschen. Wie Willison feststellt, würde sogar eine musterbasierte Erkennung, die die meisten Angriffe abfängt, für sich genommen eine schlechte Note erhalten. Transparenz und die Möglichkeit, Untersuchungen durchzuführen, sind das dauerhafte Fundament, auf dem wir aufbauen, nicht die Mauer.
Human-in-the-Loop-Design. KI-Funktionen stellen ihre Arbeit zur Überprüfung durch Menschen bereit, anstatt stillschweigend irreversible Aktionen durchzuführen.
Aufgabenzerlegung und bereichsbezogene Aktionen. Komplexe Workflows werden in kleinere Phasen unterteilt, und die Aktionen, die KI-Funktionen zur Verfügung stehen, sind absichtlich eingeschränkt und nicht offen.
Keine dieser Maßnahmen ist für sich genommen absolut sicher. Gemeinsam bilden sie eine tiefgreifende Verteidigung.
Kontrollmechanismen: Schränken Sie ein, worauf die KI reagieren kann
Dritte Säule: Die Fähigkeit, Nebenwirkungen zu erzeugen
Das dritte Bein ist der Bereich, in dem die meisten Angriffe in der realen Welt stattfinden. Wenn ein Angreifer eine KI davon überzeugt, sensible Daten in eine URL einzubetten, sie über eine Integration zu senden oder einen Datensatz zu ändern, auf den sich andere Personen verlassen, ist der Angriff erfolgreich.
Wir investieren hier in mehrere Kontrollkategorien:
Behandeln Sie LLM-Ergebnisse als nicht vertrauenswürdig. Generierter Inhalt erhält keinen Vertrauensbonus, nur weil er von einer Asana AI stammt. Er durchläuft die gleichen Validierungs- und Rendering-Pfade wie jeder andere nutzergenerierte Inhalt.
Obligatorische menschliche Genehmigung für Aktionen mit großen Auswirkungen. Bestimmte Aktionskategorien erfordern immer eine explizite menschliche Genehmigung, unabhängig davon, wie sicher die KI ist oder wie routinemäßig die Anfrage aussieht. Bei AI Teammates umfasst dies Aktionen, die den Zugriff erweitern (Ändern von Berechtigungen, Hinzufügen von Mitgliedern), und Aktionen, die Daten zerstören (Löschungen). Die KI kann diese vorschlagen, aber sie kann sie nicht selbst ausführen.
Sicherheitsvorkehrungen für die Linkverarbeitung. Externe URLs in KI-generiertem Inhalt werden verarbeitet, bevor sie einen Nutzer erreichen. Neue URLs, die nicht in der Eingabe enthalten waren, werden besonders genau geprüft und in ihrer vollständigen, unverdeckten Form angezeigt, anstatt als umbenannter Ankertext. So kann die KI nicht dazu missbraucht werden, einen Exfiltrations-Endpunkt als freundlichen „Klicken Sie hier für die Zusammenfassung“-Link zu tarnen.
Kein universelles ausgehendes HTTP. KI-Funktionen verfügen nicht über eine offene Primitiven-Anweisung wie „Sende eine Anfrage an eine beliebige URL“. Externe Integrationen laufen über eingeschränkte Kanäle mit eigener Autorisierung.
Audit Trail für Aktionen. Jede Schreib-, Mutations- und ausgehende Aktion, die eine KI-Funktion vornimmt, wird zusammen mit dem Modellaufruf, der sie ausgelöst hat, protokolliert, sodass ein Ermittler rekonstruieren kann, was eine KI getan hat, und nicht nur, was von ihr verlangt wurde.
Das Ziel ist nicht, externe Kommunikation unmöglich zu machen. KI-Funktionen müssen auf Links verweisen, Aufgaben aktualisieren und nützliche Ergebnisse liefern. Das Ziel ist es, sicherzustellen, dass sie dies nicht verdeckt auf eine Weise tun können, die der Nutzer nicht beabsichtigt hat.
Ein Muster für von KI ausgegebene Werte
Innerhalb dieses Rahmens taucht immer wieder dasselbe konkrete Teilproblem auf: Eine KI-Funktion erzeugt etwas (eine Objekt-ID, einen Empfänger, eine URL) und der nachgelagerte Code reagiert darauf, oft mit umfassenderen Berechtigungen als die KI selbst. Halluzinationen und Prompt-Injections führen zum selben Ergebnis: Einem vom Modell ausgegebenen Wert wird vertraut.
Wir verwenden ein vierteiliges Muster als Checkliste für die Designüberprüfung dieser Werte:
Beschränken Sie, was die KI überhaupt erst erzeugen darf, bevor die Validierung ausgeführt werden muss.
Validieren Sie jeden von der KI erzeugten Wert serverseitig anhand derselben Autorisierungsebene wie alles andere. Das Modell wird als nicht vertrauenswürdiger Client behandelt.
Begründen Sie die Auswahl, indem Sie genügend strukturierten Kontext beibehalten, um zu erklären, warum die KI diese Auswahl getroffen hat. Das macht später Nachforschungen, Auswertungen und Incident-Response möglich.
Eskalieren Sie mit Reibung, Fallback oder menschlicher Überprüfung, wenn ein Wert ein hohes Risiko birgt oder außerhalb des erwarteten Bereichs liegt.
Der rote Faden: Das Modellverhalten sollte nicht die primäre Sicherheitskontrolle sein. Bessere Prompts und „Wir haben dem Modell gesagt, dass es das nicht tun soll“ sind nützliche Abwehrmaßnahmen, aber die dauerhaften Kontrollen befinden sich im System rund um das Modell.
Grundsätze als Basis
Diese Entscheidungen sind nicht ad hoc. Sie ergeben sich aus den veröffentlichten KI-Prinzipien von Asana.
Menschen sind für ihre Entscheidungen verantwortlich – das ist die Grundlage für das Checkpoint-orientierte Design. Die KI unterstützt, aber der Mensch bleibt auf dem Laufenden und ist verantwortlich.
Wir setzen uns für Sicherheit ein, was die Investition in mehrstufige Kontrollen rechtfertigt, selbst wenn sie Reibung verursachen. Die Alternative erhöht das Risiko, da KI-Funktionen komplexere Aufgaben übernehmen.
Wir setzen uns für Transparenz ein, weshalb wir diesen Beitrag schreiben. Wir haben die Sicherheit von AI Agents noch nicht gelöst. Aber offen darüber zu sein, wie wir über diese Risiken denken und welche Maßnahmen wir ergreifen, um sie zu minimieren, hilft der gesamten Community, Fortschritte bei einer gemeinsamen Herausforderung zu erzielen, und lädt zu einer kritischen Auseinandersetzung ein, die uns besser macht.
Die ehrlichen Grenzen
Die Prompt-Injection ist immer noch grundsätzlich ungelöst, und die indirekte Prompt-Injection (die gegnerischen Anweisungen kommen eingebettet in Inhalte, die die KI während ihrer Arbeit abruft, und nicht in Inhalte, die ein Benutzer ihr direkt übergibt) ist die Variante, von der die Branche im Jahr 2026 am stärksten betroffen war. Quellbewusstes Tagging hilft, schließt diese Lücke aber nicht vollständig, da das Modell immer noch entscheiden muss, die Tags zu berücksichtigen. Unsere Kontrollpunkte verringern das Risiko erheblich, aber sie beseitigen es nicht. Solange Anweisungen und Daten ein Kontextfenster teilen, werden bösartige Eingaben, die über die Suche, öffentliche Formulare oder Integrationen abgerufen werden, manchmal durchschlüpfen. Wir behandeln dies als einen aktiven, fortlaufenden Investitionsbereich, wobei wir jeden Pfad, der es extern erstellten Inhalten ermöglicht, eine agentische Funktion zu erreichen, genauer prüfen. Die Arbeit an Designmustern zur Sicherung von LLM-Agents weist in vielversprechende Richtungen, aber ein Branchenkonsens ist noch im Entstehen begriffen.
Die Bedrohungslandschaft verändert sich schnell. Es tauchen immer wieder neue Vektoren auf, von der unsichtbaren bildbasierten Prompt-Injektion bis hin zu mehrstufigen Exfiltrationsketten. Wir gestalten Kontrollen so, dass sie mehrschichtig und kombinierbar sind, damit neue Abwehrmaßnahmen hinzugefügt werden können, wenn neue Bedrohungen auftauchen. Es ist ein Wettrüsten, kein Problem, das man einmal löst. Die OWASP Top 10 für LLM-Anwendungen ist eine nützliche, fortlaufende Referenz.
Wir sehen diese Mängel nicht als Gründe, um langsamer zu werden. Wir sehen sie als Gründe, um bewusst zu handeln. Die tödliche Trifecta zeigt uns, was auf dem Spiel steht. Kontext, Kontrollpunkte und Kontrollen geben uns ein Framework für unser Handeln. Und da kein Team dies alleine lösen kann, investieren wir aktiv zusammen mit unseren Forschungs- und Kundenpartnern, um diese Oberflächen zu härten, während sich die Bedrohungslandschaft weiterentwickelt.
Referenzmaterialien
Simon Willison, „The lethal trifecta for AI agents“, Juni 2025
Korny Sietsma, „Agentic AI and Security“, Martin Fowler, Oktober 2025
Bruce Schneier, „We Are Still Unable to Secure LLMs from Malicious Inputs“, August 2025
OWASP, „Top 10 für LLM-Anwendungen“
