Solange ein Assistent nur Fragen beantwortet, ist er ein besseres Suchfeld. Sobald er Werkzeuge bekommt – ein Ticket eröffnen, einen Status setzen, eine Mail verschicken, eine Abfrage ausführen –, ist er etwas anderes: ein Benutzerkonto, das Anweisungen aus Texten entgegennimmt, die niemand von Ihnen geschrieben hat. Die meisten Sicherheitsprüfungen, die wir sehen, decken genau diesen Unterschied nicht ab.

Im vorigen Beitrag ging es um den internen Assistenten, der Wissen aus Confluence, Jira und den Fachanwendungen zusammenführt. Der nächste Schritt kommt in jedem dieser Projekte, meist innerhalb weniger Wochen: Wenn der Assistent ohnehin weiss, wie der Prozess geht, soll er den Schritt doch gleich ausführen. Die Begeisterung darüber ist berechtigt. Sie überspringt nur eine Frage.

Ein System, das liest, kann im schlimmsten Fall etwas Falsches sagen. Ein System, das handelt, kann im schlimmsten Fall etwas Falsches tun – unter einer Kennung, die Rechte hat, und mit einer Geschwindigkeit, bei der niemand zuschaut. Das ist kein Grund, es zu lassen. Es ist ein Grund, die Sicherheitsfrage vor dem ersten schreibenden Werkzeug zu stellen und nicht nach dem ersten Vorfall.

Der Unterschied: Daten und Anweisungen sind dasselbe Material

Klassische Anwendungen trennen sauber zwischen Programm und Eingabe. Der Code bestimmt, was passiert; die Daten bestimmen nur, womit. Diese Trennung ist die Grundlage fast aller Sicherheitsmechanismen, die wir kennen.

Bei einem Sprachmodell verschwimmt sie. Die Anweisung Ihres Unternehmens, die Frage des Mitarbeiters und der Inhalt eines Dokuments, das der Assistent zur Beantwortung heranzieht, landen am Ende im selben Kontext – als Text. Das Modell wurde darauf trainiert, Text zu befolgen. Es hat keine verlässliche Möglichkeit zu unterscheiden, ob eine Anweisung von Ihnen stammt oder aus einem PDF, das vor zwei Jahren jemand in ein Ticket gehängt hat.

Daraus folgen vier Angriffswege, die in dieser Form neu sind.

Angriffsweg 1: Die Anweisung steckt im Material

Ein Lieferant schickt eine Rechnung als PDF. Im Dokument steht, in weisser Schrift auf weissem Grund, ein zusätzlicher Absatz: der Hinweis, dass bei Rückfragen die hinterlegte Bankverbindung durch eine andere zu ersetzen sei. Ein Mensch sieht ihn nicht. Der Assistent, der das Dokument für die Sachbearbeitung zusammenfasst, liest ihn mit.

Das ist der Kern der indirekten Prompt Injection: Der Angreifer spricht nicht mit dem Assistenten, er legt ihm etwas in den Weg. Die Einfallstore sind unspektakulär und bei Ihnen längst vorhanden – Mailanhänge, Ticketkommentare von externen Partnern, Confluence-Seiten mit offenen Bearbeitungsrechten, Formulare auf der Website, Dateien aus einem Kundenportal.

Entscheidend ist dabei die Wirkungskette, nicht der Trick: Ein manipulierter Text ist harmlos, solange der Assistent nur antwortet. Gefährlich wird er in dem Moment, in dem derselbe Assistent ein Werkzeug auslösen darf.

Angriffsweg 2: Rechte, die weiter reichen als der Mensch

In fast jeder ersten Umsetzung greift der Assistent mit einem technischen Dienstkonto auf die Fachsysteme zu. Das ist bequem und manchmal unvermeidbar – und es bedeutet, dass der Assistent mehr darf als die Person, die ihn gerade benutzt. Ein Praktikant stellt eine Frage, beantwortet wird sie mit den Rechten eines Systemkontos, das auf alles zugreift.

Dieses Muster kennt die Sicherheitsliteratur seit Jahrzehnten unter dem Namen des verwirrten Stellvertreters: Eine Komponente mit hohen Rechten handelt im Auftrag von jemandem mit niedrigen Rechten und prüft nicht, ob der Auftraggeber das selbst gedurft hätte. Neu ist nur, dass der Stellvertreter jetzt Anweisungen in natürlicher Sprache entgegennimmt und erstaunlich hilfsbereit ist.

Der Schaden entsteht dabei nicht erst durch böse Absicht. Es genügt, dass jemand nach einer Information fragt, die er nicht sehen dürfte, und der Assistent sie bereitwillig zusammenfasst.

Angriffsweg 3: Der Abfluss passiert über die Antwort

Berechtigungen werden fast immer auf dem Hinweg geprüft: Darf dieser Nutzer dieses Dokument sehen? Auf dem Rückweg prüft selten jemand. Dabei ist die Antwort selbst ein Kanal.

Drei Varianten begegnen uns regelmässig. Die Zusammenfassung, die Inhalte aus einem Dokument enthält, das der Empfänger zwar auslösen, aber nicht lesen durfte. Die Antwort, die der Assistent auf Anweisung aus dem Material an eine externe Adresse weiterleitet, weil er ein Mailwerkzeug hat. Und die unscheinbarste: ein Bild oder ein Link in der Antwort, dessen Adresse die gerade gelesenen Daten als Parameter enthält – abgeflossen ist es in dem Moment, in dem die Oberfläche die Adresse aufruft.

Keine dieser Varianten taucht in einem Berechtigungskonzept auf, das nur den Zugriff regelt.

Angriffsweg 4: Das Gedächtnis bleibt

Sobald ein Assistent sich Dinge merkt – Präferenzen, frühere Gespräche, Notizen zu einem Vorgang –, wird aus einem einmaligen Vorfall ein dauerhafter Zustand. Eine Anweisung, die einmal in den gespeicherten Kontext gelangt ist, wirkt bei jeder weiteren Sitzung mit. Der Angriff muss nur ein einziges Mal gelingen.

Was wirklich trägt

Die gute Nachricht: Keine der folgenden Massnahmen erfordert Forschung. Sie erfordern Entscheidungen, und zwar bevor das erste schreibende Werkzeug freigeschaltet wird.

Material ist niemals Auftrag. Alles, was der Assistent zur Beantwortung heranzieht, wird als Zitat behandelt und nicht als Instruktion – technisch getrennt übergeben, als Daten markiert, mit der ausdrücklichen Regel, dass Anweisungen aus diesem Bereich nicht befolgt werden. Das ist keine Garantie; Sprachmodelle lassen sich überreden. Es ist die erste von mehreren Schichten, und sie kostet fast nichts.

Der Assistent handelt mit den Rechten des Menschen. Nicht mit denen eines Dienstkontos. Die Identität des Nutzers wird bis zum Fachsystem durchgereicht, die Prüfung passiert dort, wo sie immer passiert ist. Das ist der aufwendigste Punkt auf dieser Liste und der einzige, bei dem sich Sparen später rächt. Wenn ein Altsystem das nicht hergibt, bleibt als Zwischenlösung ein Dienstkonto mit minimalem Umfang plus eine eigene Prüfschicht – aber mit dem Wissen, dass Sie damit eine Schuld aufgenommen haben.

Werkzeuge werden eng geschnitten. Nicht «Datenbankabfrage ausführen», sondern «Vertragsstatus zu dieser Vertragsnummer lesen». Nicht «Mail versenden», sondern «Antwort an den Absender des Vorgangs senden». Ein eng geschnittenes Werkzeug kann missbraucht werden, aber der Schaden ist begrenzt und beschreibbar. Ein allgemeines Werkzeug ist ein offenes Tor mit einer höflichen Bitte davor.

Schreibende Schritte brauchen eine menschliche Bestätigung – oder eine Schwelle. Welche Schritte das sind, entscheidet sich nicht nach technischem Aufwand, sondern nach den Kosten eines Fehlers. Wir haben die Logik dahinter im Beitrag zu Konfidenzschwellen und Human-in-the-Loop ausgeführt; für Sicherheit gilt dieselbe Rechnung mit einem Zusatz: Bei allem, was Geld bewegt, Berechtigungen ändert oder das Haus verlässt, ist die Antwort immer eine Bestätigung.

Ausgehende Wege werden begrenzt. Empfänger aus einer festen Liste statt aus dem Text. Keine frei zusammengesetzten Adressen in Antworten. Externe Inhalte in der Oberfläche nicht automatisch nachladen. Das sind drei kleine Entscheidungen, die den dritten Angriffsweg weitgehend schliessen.

Jede Werkzeugnutzung ist nachvollziehbar. Wer hat gefragt, welches Werkzeug wurde mit welchen Parametern ausgelöst, welches Material lag im Kontext, was kam zurück. Ohne dieses Protokoll können Sie nach einem Vorfall nicht sagen, was passiert ist – und in regulierten Branchen ist genau das die Frage, die zuerst gestellt wird. Wie sich solche Nachweise in bestehende Freigabeprozesse einfügen, haben wir im Beitrag zur KI-Governance als Deployment-Gate beschrieben.

Angriffe gehören in die Freigabe, nicht in den Betrieb

Der Fehler, den wir am häufigsten sehen, ist nicht eine fehlende Massnahme. Es ist die Annahme, dass man Sicherheit einmal herstellt. Bei einem System, dessen Verhalten vom Modell, vom Prompt und vom gerade geladenen Material abhängt, ändert sich die Lage bei jedem Update.

Die praktikable Antwort ist dieselbe wie bei der Qualität: eine feste Sammlung von Fällen, die bei jeder Änderung durchläuft. Nur bestehen diese Fälle nicht aus Fragen mit erwarteten Antworten, sondern aus Dokumenten mit versteckten Anweisungen, aus Anfragen nach Daten jenseits der eigenen Berechtigung, aus Versuchen, den Assistenten zu einem Werkzeugaufruf zu bewegen, den der Nutzer nicht auslösen dürfte. Bestanden heisst: Das Werkzeug wurde nicht ausgelöst, die Daten blieben drin. Wie man eine solche Sammlung aufbaut und im Betrieb hält, steht im Beitrag zum Evaluation Harness.

Diese Fälle sind schnell geschrieben. Zwanzig gute Angriffsfälle sind ein Nachmittag Arbeit und der Unterschied zwischen «wir glauben, es ist sicher» und «wir prüfen es bei jedem Release».

Die Reihenfolge, wenn die Zeit knapp ist

Kein Unternehmen setzt sechs Massnahmen gleichzeitig um. Wenn Sie nächste Woche anfangen, dann in dieser Reihenfolge:

Erstens: Inventar der Werkzeuge. Welche Aktionen kann der Assistent heute auslösen, mit welchen Rechten, mit welcher Reichweite? Diese Liste ist in einer Stunde erstellt und überrascht fast immer – meist, weil ein Werkzeug deutlich allgemeiner geschnitten ist, als irgendjemand erinnert.

Zweitens: Die schreibenden Werkzeuge trennen. Alles, was nur liest, kann bleiben. Alles, was schreibt, verschickt oder bezahlt, bekommt eine Bestätigung vorgeschaltet – vorläufig, bis die Rechtefrage sauber gelöst ist. Das ist an einem Tag gemacht und nimmt den grössten Teil des Risikos heraus.

Drittens: Das Protokoll. Danach erst die aufwendigeren Themen, allen voran die durchgereichte Identität.

Diese Reihenfolge ist bewusst nicht die saubere. Sie ist die, die am ersten Tag die meiste Wirkung hat.

Fazit

Ein Assistent, der handeln darf, ist kein Suchfeld mehr, sondern ein Teilnehmer in Ihren Systemen. Behandeln Sie ihn so: mit einer Identität, mit eng geschnittenen Rechten, mit einem Protokoll und mit der Annahme, dass alles, was er liest, von jemandem stammen könnte, der etwas anderes will als Sie.

Das ist weniger Aufwand, als es klingt – und ungleich weniger als die Aufarbeitung des ersten Vorfalls in einem Haus, das Aufsicht kennt. Wann Agenten sich überhaupt lohnen, haben wir separat beschrieben; die Antwort ändert sich durch diesen Beitrag nicht. Sie bekommt nur eine Bedingung.

Wenn Sie einen Assistenten betreiben oder gerade einen bauen und nicht sicher sind, welche Werkzeuge er heute wirklich auslösen kann: Wir schauen uns das an. Das ist eine Frage von Tagen, nicht von Monaten – sprechen Sie uns an, oder sehen Sie sich an, wie wir Sicherheit und Automatisierung und KI zusammenbringen.