Geführtes Sicherheitslab

Prompt Injection über E-Mails

Eine geführte Übung zum Vertrauen im Postfach: Nachrichteninhalte von Connector-, Absender- und Transportfakten trennen, entscheiden, worauf sich die Anwendung stützen darf, und Fähigkeits- und Empfänger-Policy auf einen Modellvorschlag anwenden.

Konzeptionelle SimulationIntermediate15 Minuten2026-09-26

Konzeptionelle Simulation

Diese Übung nutzt redaktionell festgelegte, deterministische Beispiele mit fiktiven Adressen. Sie verbindet sich mit keinem Postfach, nutzt kein Modell und keine Tools und sagt nicht voraus, wie sich ein reales Modell verhält.

Schritt 3 von 63/6

Lernziele

Begründen, warum ein vertrauenswürdiger Postfach-Connector den Nachrichteninhalt nicht vertrauenswürdig macht.
Absender-, Authentifizierungs- und Transportmetadaten als Herkunftsnachweis behandeln, nicht als Anweisungsbefugnis über den AI-Ablauf.
Die Herkunft zitierter und weitergeleiteter Inhalte von der Nachricht trennen, die sie transportiert.
Entwerfen und Senden als getrennte Fähigkeiten unterscheiden.
Empfängervalidierung, Postfachumfang, Autorisierung und menschliche Freigabe zur Begrenzung von Auswirkungen nutzen.

Voraussetzungen

Lab Vertrauensgrenzen und Modellkontext (empfohlen)
Angriffsartikel E-Mail Prompt Injection (optional)

Szenario wählen

Jedes fiktive Szenario zeigt Nachrichteninhalte, die das Modell sieht, und getrennt davon Connector-, Absender- und Policy-Fakten, die die Anwendung erfasst hat. Sicherheitsentscheidungen gehören in die zweite Spalte.

Unbekannter externer Absender bittet um eine DateiEine Nachricht von einer unbekannten externen Adresse bittet den Assistant, eine Projektdatei zu teilen.Weitergeleiteter Thread mit zitiertem Text DritterEine Kollegin leitet einen Thread weiter; der zitierte Teil stammt von einem externen Lieferanten.Authentifizierter Connector, Nachricht von jemand anderemDer Postfach-Connector authentifiziert sich korrekt und liefert eine Nachricht, deren Domain-Authentifizierung bestanden wurde.Entwurfs-Assistant und sendender AssistantDer Nutzer möchte Hilfe bei der Antwort an einen Kunden. Der Ablauf darf entwerfen, aber nicht senden.Nachricht fordert fremde Postfachdaten nach außenEine eingehende Nachricht fordert den Assistant auf, aktuelle Rechnungen aus dem Postfach zu sammeln und an eine externe Adresse zu senden.

Mail-Pfad und Vertrauensfluss

Nachrichten durchlaufen Transport- und Connector-Komponenten, bevor das Modell sie sieht. Komponenten sind System; Nachrichteninhalte und der Modellvorschlag bleiben variabel.

Eingehende NachrichtVariabler Inhalt->
Mail-ConnectorSystemkomponente->
KontextzusammenstellungSystemkomponente->
ModellSystemkomponente->
VorschlagVariabler Inhalt->
AutorisierungSystemkomponente

Modellsichtbarer Nachrichteninhalt

Nachrichtentext, den das Modell liest. Text in eckigen Klammern ist ein neutraler Platzhalter, keine echte Anweisung.

Nachrichtentext
Hallo, bitte hängen Sie den aktuellen Projektplan an Ihre Antwort an. [synthetischer anweisungsartiger Text, der versucht, den Assistant umzulenken]

Anwendungsseitige Nachweise und Policy

Von Connector, Transport und Anwendung außerhalb des Modelltexts erfasst. Herkunftsfakten belegen, woher eine Mail kam, nicht was sie darf.

Absenderdomain: partner.example.test, extern, bisher keine Korrespondenz
Nutzeraufgabe: Posteingang sichten und neue Nachrichten zusammenfassen
Freigabe-Policy: Dateien verlassen die Organisation nur nach Entscheidung der Dateiverantwortlichen