Sicherheit von Sprachbots: Wie können Unternehmen ihre Sprachassistenten vor Angriffen schützen?

Voicebots beantworten heute Kundenanfragen, greifen auf Unternehmensdaten zu und führen teilweise sogar eigenständig Prozesse aus. Genau das macht sie zu einem attraktiven Ziel für Angreifer. Wer heute einen Sprachassistenten im Kundenservice einsetzt, sollte deshalb wissen, welche Risiken damit verbunden sind und wie man ihnen begegnen kann.Verschärft wird das Ganze durch ein zweites Phänomen: Viele Mitarbeitende nutzen im Alltag längst eigene KI-Tools, oft ohne Wissen der IT. 

Dafür hat sich der Begriff Schatten KI etabliert. Gleichzeitig vertrauen Kunden und Unternehmen den Antworten von KI-Systemen immer mehr, weil die Ergebnisse einfach besser geworden sind, was Voicebots als Angriffsziel zusätzlich attraktiver macht.

Dafür hat sich der Begriff Schatten KI etabliert. Gleichzeitig vertrauen Kunden und Unternehmen den Antworten von KI-Systemen immer mehr, weil die Ergebnisse einfach besser geworden sind, was Voicebots als Angriffsziel zusätzlich attraktiver macht.

Welche Angriffe auf Sprachbots stellen tatsächlich eine Bedrohung dar?

Sicherheitsrisiken bei KI lassen sich mittlerweile gut einordnen. Eine der bekanntesten Orientierungen dafür liefert OWASP, die Open Worldwide Application Security Project Community OWASP-Community ist eine Non Profit Organisation, die sich seit Jahren für Sicherheit in verschiedenen Bereichen einsetzt, etwa in der Softwareentwicklung, und dafür regelmäßig Top 10 Risiken und passende Leitlinien veröffentlicht. Seit einigen Monaten gibt es dafür auch ein eigenes „GenAI Security Project“ also eine Liste speziell für Risiken bei generativer KI.

Eines der größten Risiken darin ist Prompt Injection. Damit ist gemeint, dass ein Anrufer den Bot mit geschickt formulierten Sätzen dazu bringt, Dinge zu tun, die er eigentlich nicht tun soll, etwa eine Information preiszugeben oder einen Rabatt zuzusagen. Man kann sich das ähnlich vorstellen wie einen Trickbetrüger am Telefon, nur dass hier die passenden Worte gegen ein KI-System statt gegen einen Menschen eingesetzt werden. Solche Angriffe laufen inzwischen häufig sogar automatisiert ab.nicht zugänglich sein sollten.

Daneben gibt es noch weitere Angriffsvektoren. Modelle lassen sich zum Beispiel so mit Anfragen überlasten, dass man von einer Art Überlastungsangriff spricht. Das Modell ist dann so überfordert, dass es aus Selbstschutz Dinge tut, die es eigentlich nicht tun sollte. Sprachmodelle können außerdem Unsicherheiten preisgeben oder Inhalte verarbeiten, die eigentlich nicht verarbeitet werden sollten.

Ein weiteres Risiko betrifft die Anbindung an Knowledge-Management-Systeme und RAG-Verfahren (Retrieval-Augmented Generation). Viele Voicebots greifen im Hintergrund auf umfangreiche Unternehmensdaten zu, damit sie auch spezielle Fragen konkret beantworten können. Ist diese Anbindung n.icht ausreichend abgesichert, lässt sie sich ausnutzen, etwa indem die hinterlegten Daten gezielt verändert werden oder Informationen abgezogen werden, die eigentlich nicht zugänglich sein sollten

Auch CRM und ERP-Systeme, also die üblichen Kunden und Warenwirtschaftssysteme im Hintergrund, können missbraucht werden, ebenso wie Schnittstellen zu anderen Programmen, die schon in der klassischen Softwarewelt eine große Fehlerquelle sind und über die sensible Informationen abfließen können. Auch kleine angebundene Zusatzwerkzeuge, mit denen ein Bot zum Beispiel auf externe Programme zugreift, waren in den vergangenen Monaten wiederholt betroffen. Dabei wurde teils Code ausgeführt, der eigentlich nicht ausgeführt werden sollte, oder es wurden Zugangsdaten ausgelesen.

Das Spektrum potenzieller Angriffe ist daher breit gefächert. Der Schutz von KI-Systemen erfordert daher mehrere Verteidigungsebenen und nicht nur eine einzige Sicherheitsmaßnahme.

Ein sinnvoller erster Schritt ist deshalb, dem Agenten von vornherein klar zu strukturieren und Grenzen zu setzen. Er darf bestimmte Inhalte nicht verarbeiten, keine nicht autorisierten Rabatte gewähren und keine rechtsverbindlichen Aussagen treffen. Das entscheidet weiterhin ein Mensch.

Genauso wichtig ist es, Anrufer zuverlässig zu verifizieren, etwa über Kundennummer und IBAN oder besser noch über eine Multi Faktor Authentifizierung (MFA), also ein zweites Merkmal wie einen Code aufs Handy, damit ein automatisierter Angriff nicht einfach durchkommt.

Ein einzelner Schutzmechanismus reicht dabei nicht aus. Wirksamer Schutz entsteht erst im Zusammenspiel mehrerer Ebenen, ein Prinzip, das man auch als Verteidigung in der Tiefe (Defense in Depth) kennt. Im Folgenden zeigen wir die drei zentralen Bausteine dafür.

Drei Wege, Voicebots wirksam zu schützen

Guardrails, die direkt in der Voicebot Plattform integriert sind

• Sicherheitsvorkehrungen, die direkt in die Voicebot-Plattform integriert sind,
• Adaptive Protection Tools, die sich zusätzlich einsetzen lassen
• Pentesting, mit dem sich simulierte Angriffe fahren lassen, um Schwachstellen aufzudecken, bevor es ein echter Angreifer tut.

Integrierte Guaardrails in Voicebot-Plattformen

Diese Guardrails sind deshalb ein guter Startpunkt, weil sie ohne zusätzliche Anschaffung direkt in der ohnehin genutzten Voicebot Plattform stecken. Viele Anbieter bringen bereits eigene Sicherheitsregler mit.

NiCE Cognigy

Bei NiCE Cognigy Bei NiCE Cognigy gibt es innerhalb des AI Agents Safety Settings. Dort lassen sich mehrere Schutzkategorien konfigurieren. Die Dokumentation erklärt diese Kategorien grundsätzlich, geht aber nicht immer sehr tief ins Detail. Deshalb ist es sinnvoll, in konkreten Projekten zusätzlich mit dem Integrator oder Hersteller zu klären, was genau hinter den einzelnen Einstellungen steckt.

Der Vorteil integrierter Guardrails liegt darin, dass sie direkt in der Lösung verankert sind. Dadurch entstehen in der Regel nur geringe Verzögerungen. Gleichzeitig können zusätzliche Prompts oder Systeminstruktionen erforderlich sein. Das kann den Tokenverbrauch erhöhen.

Parloa

Parloa bietet eine granularere Konfiguration. Für einzelne Guardrail-Kategorien lassen sich häufig Abstufungen wie low, medium oder high wählen. Zusätzlich können Custom Filters definiert werden. Damit lassen sich bestimmte Begriffe oder Szenarien festlegen, bei denen der Bot reagieren oder gestoppt werden soll. In naher Zukunft erwarten wir hier weitere Verteidigungsfilter, die sich eher auf das gesamte Gespräch fokussieren und jede Frage-Antwort Konstellation innerhalb des Gesprächs im Rahmen einer Gesamtbewertung beachten.

Auch hier gilt: Die Guardrails bieten einen sinnvollen Grundschutz, können aber zusätzlichen Tokenverbrauch verursachen. Ein Prompt ist dabei die Eingabe eines Menschen, Systems oder Agenten, die eine bestimmte Aktion oder Antwort auslöst.

Adaptive Protection Tools: Cisco AI Defense

Solche Werkzeuge sind vor allem dann relevant, wenn die eingebauten Guardrails allein nicht reichen, etwa weil mehrere Bots und Plattformen gleichzeitig überwacht werden müssen oder weil Sicherheitsteams eine zentrale, herstellerunabhängige Kontrollinstanz brauchen. 

Ein Beispiel dafür ist Cisco AI Defense. Cisco ist im Bereich Networking und Defense schon lange etabliert und hat sein Portfolio in den vergangenen Jahren gezielt um KI erweitert. 

Ein zentraler Punkt ist die Semantic Inspection. Dabei sitzt ein Schutzmechanismus zwischen der KI-Plattform, also etwa dem Voicebot, und dem Large Language Model. Das Tool analysiert den Datenfluss und kann auffällige Eingaben oder Ausgaben erkennen.

Dabei muss man Latenzen berücksichtigen. Je nach Architektur können zusätzliche Verzögerungen entstehen. Außerdem ist nicht jede Voicebot- oder Agentic-AI-Plattform offen genug, um ein solches Tool direkt zwischenzuschalten. In manchen Fällen funktioniert die Anbindung nur über APIs. In anderen Fällen ist gar kein Zugriff auf das LLM oder den Textfluss möglich.

Eine weitere Möglichkeit besteht darin, die angebundenen APIs zu überwachen. Das betrifft zum Beispiel Wissensdatenbanken, CRM-Systeme, ERP-Systeme, Kundendatenbanken oder andere Applikationen, aus denen Daten gelesen oder in die Daten geschrieben werden.

Cisco bietet hierfür Runtime Protection. Damit lassen sich Zugriffe analysieren und bei Bedarf blockieren. Ziel ist es, das Risiko und den möglichen Schaden eines kompromittierten Bots so gering wie möglich zu halten.

Zusätzlich können Funktionen wie Secure Access, Workspace-Oberflächen, AI Assistant und Agentic Ops unterstützen. Dabei bleibt der sogenannte Human-in-the-Loop wichtig. Das heißt, ein Mensch – in dem Fall der Administrator – entscheidet am Ende, ob eine empfohlene Maßnahme umgesetzt wird, etwa ob ein Bot vorübergehend vom Netz genommen wird.

Damovo Managed Service: Voicebot Pentesting

Der dritte Ansatz ist ein von Damovo entwickelter Pentest-Service. Für Chatbots gibt es solche Penetrationstests schon länger, für Voicebots war das bislang kaum abgedeckt. 

Der Hintergrund ist einfach: Wer versucht, einen Bot manuell zu überlisten, kann das zwar tun, aber bei geschätzt 500 unterschiedlichen Angriffsvektoren in diesem Bereich dauert das entsprechend lange. Zusätzlich müssen die Prompts zur jeweiligen Branche passen.

Damovo nutzt deshalb ein methodisches Vorgehen. Zunächst werden Test-Prompts erstellt und auf die Branche angepasst, zum Beispiel für Versicherungen oder Banken. Diese werden den relevanten OWASP GenAI-Risikokategorien zugeordnet.

Anschließend startet ein Bot automatisierte Testanrufe gegen den Ziel-Voicebot. Nach der Begrüßung und gegebenenfalls Authentifizierung werden die Testdialoge ausgeführt. Beide Kanäle werden separat aufgezeichnet, damit Prompt und Antwort eindeutig getrennt ausgewertet werden können.

Nach jedem Testdialog folgt eine Transkription, die um die Metadaten ergänzt, sodass eine lückenlos nachvollziehbare Beweiskette entsteht. Eine KI-gestützte Auswertung beurteilt, ob der Angriff erfolgreich war, ob der Zielbot geblockt hat oder ob er Informationen preisgegeben hat, die er nicht preisgeben sollte.

 Der Kunde erhält so einen Report, der die Ergebnisse entlang der OWASP GenAI-Kategorien zeigt und die einzelnen Nachweise dokumentiert.

Was das alles kostet und wie viel Aufwand dahinter steckt

Kosten

Bei den heute schon bestehenden Bots entstehen durch Guardrails meistens keine direkten Zusatzkosten, wohl aber indirekt durch den höheren Tokenverbrauch. Wie hoch dieser Mehrverbrauch am Ende genau ausfällt, lässt sich kaum beziffern, da es dazu bislang keine Auswertungen gibt. Es wird aber nicht lange dauern, dass weiterführende Guardrails mit einer zusätzlichen Lizenz belegt werden, da z.B. ein weiteres LLM im Hintergrund den Kontext der gesamten Konversation überprüft.

Adaptive Tools sind Enterprise-Grade-Lösungen. Hier entstehen Implementierungs-, Pflege- und Lizenzkosten. Je nach Hersteller und Umfang können diese Kosten deutlich höher ausfallen.

Der Managed Service ist auf einzelne Einsätze ausgelegt und ist in der Regel deutlich günstiger als eine dauerhaft laufende Enterprise-Software. Die Prompts müssen jedoch generell branchenspezifisch und auf die Use Cases angepasst werden, was den Einmalaufwand nach oben treibt.

 Ob der Test einmalig, nach einem neuen Skill / Task oder regelmäßig durchgeführt wird, hängt vom konkreten Use Case ab.

Pflegeaufwand

Auch beim Pflegeaufwand unterscheiden sich die drei Ansätze. Integrierte Guardrails sind sehr pflegeleicht, weil sie eben schon Teil der Lösung sind. Adaptive Tools bedeuten vor allem am Anfang einen mittleren bis hohen Aufwand. Beim Pentest hält sich der Aufwand aufgrund der branchenspezifischen Ausrichtung in einem mittleren Rahmen. 

Latenz

Auch bei der Latenz gibt es Unterschiede. Integrierte Guardrails sind meist sehr nah an der eigentlichen Plattform und verursachen nur geringe Verzögerungen. Adaptive Tools können je nach Architektur zusätzliche Latenzen erzeugen. Pentests sollten außerhalb der Geschäftszeiten stattfinden, damit der Betrieb für reguläre Nutzer nicht beeinträchtigt wird.

Warum das Thema gerade jetzt an Bedeutung gewinnt

Ein wichtiger Treiber ist der wachsende Bedarf an Audits. Themen wie NIS2 und DORA sind längst bekannt, hinzu kommt inzwischen auch die Prüfung von KI-Managementsystemen nach der Norm ISO 42001. Immer mehr Unternehmen müssen also nachweisen können, dass auch ihre Chat- und Voicebots regelmäßig geprüft werden.

Genau hier zeigt sich der Unterschied zwischen den drei Ansätzen. Integrierte Guardrails gelten dafür als eher eingeschränkt, weil es kaum Dokumentation gibt und sich vieles nur schwer nachvollziehen lässt. Adaptive Tools bieten schon deutlich mehr Reporting und Einblicke, sind dabei aber durch die funktionalen Grenzen des jeweiligen Tools limitiert. Der Pentesting Service lässt sich dagegen sehr flexibel anpassen, je nachdem ob ein Kunde 10, 100 oder 500 Angriffsvektoren testen möchte, und liefert dementsprechend die nachvollziehbarste Dokumentation.

Auch beim verbleibenden Restrisiko unterscheiden sich die Ansätze. Integrierte Guardrails allein werden je nach Konfiguration meist als mittleres bis hohes Risiko eingeschätzt. Adaptive Tools senken das Risiko spürbar, weil hier ausgereifte Enterprise Lösungen im Hintergrund arbeiten. Beim Managed Pentesting wird tatsächlich im laufenden Betrieb getestet, mit möglichst vielen realistischen Gesprächen, wodurch das Restrisiko am geringsten ausfällt.

Fazit: Verteidigung in der Tiefe statt einer einzelnen Lösung

Am Ende lässt sich festhalten, dass es hier keine Entweder-oder-Entscheidung gibt. Der Voicebot wird durch Guardrails geschützt, zusätzlich durch adaptive Tools abgesichert, und Pentesting prüft live, wie belastbar die Schutzmechanismen tatsächlich sind.

Sodass selbst wenn eine Ebene einmal versagt, entweder gar nichts passiert oder der Schaden zumindest in einem eng begrenzten Rahmen bleibt.

Wer das Restrisiko möglichst vollständig ausschließen möchte, sollte deshalb alle drei Ebenen gemeinsam betrachten und nicht nur einzelne Maßnahmen umsetzen. Wer wissen möchte, wie es um die Sicherheit des eigenen Voicebots tatsächlich bestellt ist, kann das im Rahmen eines Managed Pentests von Damovo prüfen lassen.