Ihr KI-Support-Bot ist jetzt Ihre größte Angriffsfläche – härten Sie ihn ab

Wenn Ihr KI-Support-Bot ein Konto zurücksetzen, eine E-Mail-Adresse ändern oder Rückerstattungen ausstellen kann, ist er de facto Ihr neues Root-Konto. Und ja, Angreifer haben begonnen, LLM-Support-Flows via Social Engineering genau zu diesen Befugnissen zu verleiten. Jüngste Vorfälle, in denen Support-Chatbots zur Gewährung von Zugriff überlistet wurden, sollten die Debatte beenden: Ein Large Language Model vor die Kontowiederherstellung zu setzen – ohne Capability-Gates – ist keine Automatisierung, sondern die Delegation von Autorität an ein probabilistisches, auf Hilfsbereitschaft trainiertes System.

Dieser Beitrag ist ein unverblümter, praxisnaher Blueprint für CTOs: wie Sie KI-gestützten Support ausliefern, der sich nicht einlullen lässt und Ihre Kunden kompromittiert. Wir behandeln das LLM als nicht vertrauenswürdige UI, binden jede sensible Aktion an kryptografische Nachweise und machen Policy zum einzigen Pfad für Seiteneffekte. Die Ziele sind einfach und messbar: null irreversible Account-Takeovers (ATOs) über den Support, unter 30 Sekunden zusätzliche Reibung für Hochrisiko-Flows und prüfbare Evidenz für jede privilegierte Aktion.

Das Angriffsmuster, das Sie treffen wird

Hier ist der häufige Fehlermodus, den wir in Berichten und Red-Team-Übungen immer wieder sehen:

1. Der Angreifer startet den Dialog mit dem KI-Support-Agenten und behauptet dringenden Kontoverlust (Telefon gestohlen, E-Mail kompromittiert, Influencer-Konto unter Angriff usw.).
2. Der Agent ist darauf trainiert, hilfsbereit zu sein, sucht deshalb nach Signalen, die wie Identitätsnachweise aussehen (alte E-Mail, teilweise Kartennummern, öffentliche Daten) und stößt dann per Tool-/Funktionsaufruf einen Recovery-Pfad an.
3. Schwache oder fehlende Capability-Gates erlauben es dem Agenten, E-Mail-Änderungen oder MFA-Resets anhand mehrdeutiger oder fälschbarer Signale (SMS, E-Mail, wissensbasierte Fragen) zu initiieren.
4. Ergebnis: irreversible Übernahme, minimale forensische Evidenz darüber, wer was warum autorisiert hat.

Wenn Ihr Stack dem LLM erlaubt, direkt nach dem Moment, in dem es sich „sicher fühlt“, sensible Endpunkte aufzurufen, sind Sie nur einen Prompt von der nächsten Breach-Schlagzeile entfernt.

Erstes Prinzip: Das LLM ist eine nicht vertrauenswürdige UI, kein Akteur

Das Sprachmodell sollte niemals direkten Zugriff auf privilegierte APIs haben. Denken Sie daran wie an eine sprachgesteuerte Shell, die lediglich beim Policy-Engine um Fähigkeiten bitten kann. Jeder Seiteneffekt muss sein:

• Explizit beschreibbar durch eine typisierte Capability (kein Freitext).
• Gebunden an das verifizierte Subjekt (User, Gerät, Session).
• Zeit- und kontextbegrenzt (Einmalnutzung, TTL in Sekunden, risikobasiert gescoped).
• Auditierbar mit einem fälschungsevidenten Log von Absicht, Evidenz und Freigabe.

Das Design-Framework: fünf Gates, die der Angreifer passieren muss

1) Scoping: Halten Sie den Bot bei PII kurz

Hungern Sie den Agenten standardmäßig nach sensiblen Daten aus. Retrieval-augmented Generation sollte niemals rohe PII in den Kontext des LLM ziehen, es sei denn, eine Policy-Prüfung autorisiert es. Strukturieren Sie Ihre Tools so, dass der Agent Ja/Nein- oder Minimaloffenlegungsfragen an ein „PII-Oracle“ stellen kann, statt vollständige Datensätze zu ingestieren.

• Do: Tools wie „prüfe, ob die letzten 2 Ziffern der Wiederherstellungsnummer X entsprechen“ bereitstellen, die nur ein Boolean zurückgeben.
• Don’t: Dem LLM zu irgendeinem Zeitpunkt Tools wie „vollständiges Kundenprofil abrufen“ exponieren.

Das reduziert Leaks und senkt die Wahrscheinlichkeit, dass das Modell schwache Signale als Beweis nutzt.

2) Capability-DSL statt roher Endpunkte

Ersetzen Sie freie Funktionsaufrufe durch eine schmale, signierte Capability-DSL. Anstelle von Tool: update_email(new_email) definieren Sie Tool: request_email_change(user_id, reason), das eine anhängige Aktion zurückgibt, die eine kryptografische Bestätigung out-of-band erfordert. Der Agent schlägt vor, Ihre Policy-Engine entscheidet.

Nachzuahmendes Muster: Capability-Tokens mit Caveats (macaroons). Jede sensible Aktion benötigt ein Token, das von einem Policy-Service ausgestellt wird, der Folgendes zusichert:

• Subject: user_id 12345, session_id abc
• Context: ip_hash X, device_binding Y, risk_score ≤ 30
• Action: change_email to candidate Z
• Constraints: single-use, TTL 60s, replay nonce N

Ohne dieses Token kann der Action-Service keinen Zustand mutieren – egal, was der Bot sagt. Nutzen Sie macaroons als Inspiration oder setzen Sie strukturierte Capability-Grants ein, signiert mit Ihrem Policy-Key.

3) Identity Binding und frische Re-Auth

Hochrisiko-Flows erfordern Präsenznachweise, nicht Erinnerungen. Erzwingen Sie:

• WebAuthn/Passkeys als primäre Re-Authentifizierung für gerätepräsente Nutzer. Keine Passkeys, keine Sofortwiederherstellung.
• Step-up-Authentifizierung via On-Device-Push in Ihrer Mobile App mit Transaktionstext (z. B. „E-Mail-Änderung auf alice+new@domain.com genehmigen“).
• Gerätevertrauen: Recovery nach Möglichkeit an ein bestehendes, attestiertes Gerät binden. Wenn alle Geräte verloren sind, Risiko erhöhen und verlangsamen.

SMS- und E-Mail-OTPs sind schwache Signale; behandeln Sie sie als Input in einen Risiko-Score, nicht als Freigabe.

4) Out-of-Band, kryptografisch an die Absicht gebunden

Jede Wiederherstellung, die Identifikatoren ändert (E-Mail, Telefon), MFA deaktiviert oder eine neue Recovery-Methode hinzufügt, muss out-of-band durch eine signierte Challenge bestätigt werden, die die exakten Transaktionsparameter einbettet. So erfordert der nutzerseitig sichtbare Prompt selbst dann die Zustimmung auf dem Gerät des Opfers zur spezifischen Änderung, wenn ein Angreifer den Bot zur Einleitung des Flows gebracht hat.

Daumenregeln:

• Ausgehende Bestätigungen müssen die Transaktionsdetails präzise wiedergeben (neue E-Mail, zuletzt gesehene IP, Geolocation, Zeitstempel).
• Challenges verfallen schnell (≤ 5 Minuten) und sind Nonce-gebunden an das Capability-Token.
• Wenn kein vertrauenswürdiger Kanal existiert, eine Abkühlphase (z. B. 24–72 Stunden) und manuelle Prüfung erzwingen.

5) Human-in-the-Loop dort, wo es zählt

Sie werden 100 % der Kontowiederherstellung nicht sicher automatisieren. Halten Sie für Hochrisiko-Flows eine besetzte Nearshore-Warteschlange vor. Als Regel gilt: Alles, was gleichzeitig einen Identifikator ändert und einen Faktor deaktiviert, erfordert eine Person. Das LLM kann Kontext sammeln und die Antwortentwürfe erstellen, aber ein Mensch muss auf „Genehmigen“ klicken. Mit in Brazil ansässigen Analysten erhalten Sie dennoch 6–8 Stunden Überschneidung mit US-Zeitzonen und 20–30 % niedrigere Kosten gegenüber US-Personal – ohne diese Arbeit in Nachtschichten zu verlagern.

Architektur-Blueprint, den Sie dieses Quartal shippen können

Komponenten

• LLM-Orchestrator: Führt die Konversation, plant Aktionen, kann aber keine privilegierten APIs direkt aufrufen.
• Policy-Engine: Kodiert Regeln als Code (z. B. OPA/Rego oder ähnlich). Nur dieser Service stellt Capability-Tokens für sensible Tools aus.
• Risk-Service: Berechnet pro Anfrage einen Risiko-Score (Features unten). Policy konsultiert ihn.
• Action-Services: Führen Mutationen nur aus, wenn sie mit einem gültigen Capability-Token aufgerufen werden.
• Out-of-Band-Confirmator: Mobile Push oder WebAuthn-Zeremonie, die die Absicht signiert.
• Evidence-Ledger: Unveränderliches Log (WORM-Speicher) darüber, wer was angefordert hat, wer genehmigt hat, welches Token, welches Risiko.

Risikofaktoren, die wirklich etwas bewirken

• Sitzungsherkunft: erste vs. wiederkehrende Sitzung, Cookie-Alter, Stabilität des TLS-Fingerprints.
• Gerätereputation: attestierte Gerätebindung, Jailbreak-/Root-Signale, Emulator-Erkennung.
• Geovelocity: Entfernung und Zeit seit letztem bekannten guten Login; plötzliche Länderwechsel.
• Netzwerkqualität: ASN-Qualität, Residential vs. Rechenzentrums-IP, aktuelle Missbrauchsberichte.
• Sprache und Verhalten: Abweichung zwischen historischer Nutzersprache und aktueller Interaktion; Schnellfeuer-, Copy-Paste-Muster.
• Account-Kontext: Alter, Ausgaben, frühere Recovery-Versuche, Admin-Status, Creator-Reichweite.

Erzeugen Sie einen kontinuierlichen Risiko-Score von 0–100. Definieren Sie klare Schwellwerte in der Policy: unter 20 = Self-Serve + Passkey; 20–60 = Step-up + Out-of-Band; über 60 = manueller Review und Abkühlphase. Kalibrieren Sie auf Ihren eigenen Daten, nicht auf generischen Tabellen.

Capability-Tokens: Machen Sie Policy zum einzigen Weg zu Seiteneffekten

Für jedes sensible Tool, das der Agent aufrufen könnte, ist ein signiertes, einmaliges Capability-Token erforderlich. Implementierungsdetails, die Sie aus Schwierigkeiten heraushalten:

• Trennung des Ausstellers: Nur die Policy-Engine besitzt den privaten Schlüssel zum Signieren von Tokens. Action-Services akzeptieren keine Bearer-Credentials vom Agenten oder Web-Client.
• Caveats: user_id, session_id, Risiko-Schwelle, exakte Aktion und Parameter, IP-/Gerätebindung, TTL ≤ 60 Sekunden, Nonce.
• Einmal und erledigt: Tokens werden beim ersten Gebrauch verbraucht – unabhängig vom Erfolg; Wiederholungen erfordern eine neue Policy-Entscheidung.
• Replay-Schutz: Nonces für 10–15 Minuten in einem schnellen KV-Store speichern, um Wiederholungen zu erkennen.

Ob Sie Caveats im macaroons-Stil oder signierte JWTs mit strukturierten Claims verwenden – der Punkt bleibt: Das LLM hält nie allgemeine Macht, sondern nur eng zugeschnittene Capability-Scheine.

Out-of-Band-Bestätigungen, die vor Gericht Bestand haben

Bestätigungen müssen kryptografisch an die exakte Transaktion gebunden sein. Gute Optionen:

• WebAuthn-signierte Challenge in einer eingeloggten Browsersession.
• In-App-Push mit gerätespezifischem Schlüsselmaterial in Secure Enclave/TPM und Remote Attestation.

Speichern Sie die signierte Challenge, den angezeigten Text und einen Hash der Konversation in Ihrem Evidence-Ledger. Wenn Regulierer oder Kläger anklopfen, können Sie eine vollständige, unveränderliche Spur von Absicht und Freigabe vorlegen.

Prompting- und Tool-Hygiene

• System-Prompts dürfen das Modell niemals anweisen, Policy aus Empathie zu umgehen. Entfernen Sie jede Variante von „wenn du dir sicher bist“. Confidence ist eine UI-Eigenschaft, kein Sicherheitsindikator.
• Eingeschränktes Decoding für Tool-Aufrufe: Tool-Calls müssen JSON mit verifiziertem Schema sein; bei jeglicher Abweichung ablehnen.
• Datenminimierung: Kontextfenster schlank halten; IDs statt Blobs übergeben; on demand über policy-genehmigte Tools abrufen.

Trade-offs, die Sie Ihrem CEO offen benennen sollten

• Friction vs. Sicherheit: Rechnen Sie mit 15–30 Sekunden Zusatzaufwand bei Hochrisiko-Flows. Das ist günstiger als eine Schlagzeile und eine Sammelklage.
• Automatisierungs-Decke: Sie werden autonome Recoveries je nach Nutzerbasis und Passkey-Adoption auf 70–90 % begrenzen. Der Rest geht in die Human-Queue.
• Mobile-Investment: Out-of-Band-Bestätigungen erfordern solide Mobile-App-Unterstützung. Wenn Sie nur Web haben, priorisieren Sie Passkeys dieses Quartal.
• Modellwahl ist nahezu irrelevant im Vergleich zu Policy- und Capability-Design. Der Unterschied zwischen Modellen ist UX-Polish; der Unterschied zwischen Designs ist Breach oder kein Breach.

Was zu messen ist: Sicherheit ist eine Produktmetrik

• Irreversible ATO via Support: Ziel 0 pro 100.000 Support-Sessions/Monat.
• False-Negative-Rate bei riskanten Flows, die vom Human Review abgefangen werden: Ziel ≥ 90 % der tatsächlich bösartigen Anfragen umgeleitet.
• Median der zusätzlichen Latenz für riskante Recoveries: Ziel ≤ 30 s.
• Volumen Human Review: als % der Gesamtmenge tracken; nutzen, um Ihr Nearshore-Team zu dimensionieren. Startwert: 1 Analyst pro 10–20k MAU bei Consumer-Apps; B2B ist niedriger, aber folgenreicher.
• Token-Missbrauch: Jedes Capability-Token, das wegen Caveat-Verstößen abgelehnt wird, sollte den On-Call alarmieren. Ist diese Zahl ungleich null, Policy-Lücken untersuchen.

Ihr Bot im Red Team – testen wie ein Angreifer

Warten Sie nicht darauf, dass das Internet Ihre Leitplanken testet. Bauen Sie eine interne „Jailbreak-Gauntlet“ und schicken Sie jede Modell-/Prompt-Revision hindurch. Nutzen Sie kuratierte adversariale Transkripte, die versuchen,

• mit empathischen Narrativen und Dringlichkeit Resets auszulösen,
• nicht-englische Prompts oder Codewörter auszunutzen,
• den Bot zu bitten, Geheimnisse zu zusammenzufassen oder umzuformatieren (um PII in den Kontext zu ziehen),
• den Bot zu zwingen, „Security“ unter einer angreiferkontrollierten Adresse zu kontaktieren.

Veröffentlichen Sie die Pass/Fail-Raten für Ihre Führungsebene und nehmen Sie sie in die Release-Kriterien auf. Ziehen Sie Muster aus akademischen Leitfäden zu Agentensicherheit und Tool-Nutzung heran; die exakten Modellgewichte sind weniger wichtig als Disziplin bei Tests und Policy.

Ein 30-60-90-Tage-Plan, der nicht im Gremium steckenbleibt

Tage 0–30: die Blutung stoppen

• Entfernen Sie den direkten Zugriff auf alle Endpunkte, die Identifikatoren ändern oder MFA deaktivieren, aus Ihren LLM-Tools.
• Führen Sie einen Policy-Service ein, der Capability-Tokens für sensible Tools signieren muss; den Rest stubben.
• Shippen Sie eine minimale Out-of-Band-Bestätigung für E-Mail-Änderungen via In-App-Push oder WebAuthn.
• Beginnen Sie, jede versuchte sensible Aktion und den Konversations-Hash in einen WORM-Speicher zu loggen.

Tage 31–60: die Messlatte höher legen

• Rollen Sie einen Risiko-Scoring-Service aus und implementieren Sie Policy-Schwellen für die Tool-Aktivierung.
• Beschränken Sie Tool-Aufrufe auf ein strenges JSON-Schema mit Signaturprüfung; fehlerhafte Aufrufe ablehnen.
• Schalten Sie Abkühlphasen für Hochrisiko-Flows ein, wenn kein vertrauenswürdiges Gerät verfügbar ist.
• Besetzen Sie während der Geschäftszeiten eine Nearshore-Review-Queue; messen Sie Umleitungsquote und Entscheidungs-Latenz.

Tage 61–90: zur Routine machen

• Härten Sie Capability-Tokens mit Geräte-/IP-Bindungen, 60-Sekunden-TTLs und Einmal-Nonces.
• Weiten Sie Out-of-Band auf alle Identifikatoränderungen und MFA-Resets aus; feilen Sie am Transaktionstext.
• Gießen Sie Policy in OPA/Rego (oder Ihre gewählte Engine) und unterziehen Sie sie Code-Review und CI – wie Applikationscode.
• Automatisieren Sie Red-Team-Regressionstests und verlangen Sie Bestehen für jede Prompt-/Modelländerung.

Warum Nearshore nach Brazil hier hilft

Wenn Sie akzeptieren, dass 10–30 % der Flows menschlich geprüft werden sollten, hängen Ihre Stückkosten von Staffing und Überschneidung ab. Brazil bietet 6–8 Stunden Überschneidung mit US-Zeitzonen, Senior-Analysten mit Englisch und Portugiesisch/Spanisch sowie 20–30 % Kostenvorteil gegenüber US-Hires. Wichtiger: Sie halten privilegierte Entscheidungen in Haus-Zeitzonen – keine Eskalationen um 2 Uhr morgens, kein Offshore-„Abnicken“.

Fazit

Sie können sich hier nicht herausprompten. Die richtige Antwort ist architektonisch: von Policy ausgestellte, zeit- und kontextgebundene Capability-Tokens; Out-of-Band-Bestätigungen, die kryptografisch exakt an die Absicht gebunden sind; und eine Risiko-Engine, die verdächtige Flows drosselt oder an Menschen umleitet. Das LLM ist ein brillantes Interface, um Kontext zu sammeln und Entscheidungen zu erklären – aber solange es keine Sicherheitsnachweise halten kann, darf es niemals derjenige sein, der den Hebel zieht.

Kernpunkte

• Behandeln Sie das LLM als nicht vertrauenswürdige UI; es soll vorschlagen, nicht entscheiden.
• Nutzen Sie signierte, einmalige Capability-Tokens mit strikten Caveats für jede sensible Aktion.
• Binden Sie Recovery an Anwesenheitsnachweise (Passkeys, In-App-Push), nicht an Erinnerungen oder nur E-Mail/SMS.
• Bauen Sie eine Risiko-Engine und definieren Sie Policy-Schwellen, die Tool-Aktivierung steuern.
• Rechnen Sie mit 10–30 % Human-in-the-Loop bei Hochrisiko-Flows; Nearshore hält Kosten und Latenz im Zaum.
• Loggen Sie Absichten, Tokens, Freigaben und Konversations-Hashes in ein WORM-basiertes Evidence-Ledger.
• Automatisieren Sie adversariale Tests und machen Sie sie Teil der Release-Kriterien für Prompts/Modelle.