Warum herkömmliche AppSec-Tools bei MCP-basierten Architekturen versagen

Kurz nachdem GenAI unsere Vorstellung vom alltäglichen Umgang mit Computern auf den Kopf gestellt hatte, begannen Sicherheitsexperten – wie es ihre Art ist – sich Gedanken darüber zu machen, was dies für die Sicherheit von Unternehmen bedeuten würde. Frühen Versionen von GenAI fehlten angemessene Schutzmechanismen gegen neue Angriffe, und so stellte sich natürlich die Frage: „Bieten aktuelle AppSec-Tools ausreichenden Schutz?“ Mit der Einführung von agentenbasierter KI und dem Model Context Protocol (MCP) ist die Frage, ob bestehende Tools in dieser neuen Weltordnung helfen können, nach wie vor ein Anliegen für alle, die mit Budget- oder Personalengpässen zu kämpfen haben.

Auch wenn Anwendungssicherheit nach wie vor ein wesentlicher Bestandteil der Unternehmenspraxis ist, lautet die kurze Antwort auf die Frage, ob aktuelle AppSec-Tools Schutz bieten, „nicht vollständig“. Herkömmliche AppSec-Tools sind nach wie vor notwendig, reichen aber allein nicht aus.

Herkömmliche AppSec-Tools bieten keinen Schutz für MCP-basierte, agentengesteuerte Architekturen, da sie die vorherrschenden Risikokategorien, die für MCP-basierte Agentenarchitekturen spezifisch sind, nicht berücksichtigen. Sie wurden nicht dafür konzipiert, die Absicht von Modellen, den Konversationskontext oder die autonome Orchestrierung von Tools zu analysieren.

Herkömmliche AppSec-Tools wurden entwickelt, um eine andere Art von Problemen zu lösen. Sie wurden für eine deterministische, von Menschen gesteuerte API-Welt konzipiert, während MCP auf autonomen, KI-gesteuerten und kontextintensiven Arbeitsabläufen basiert.

MCP führt eine neue Kategorie von Angriffsflächen ein, nicht jedoch eine, die eine bestehende ersetzt.

In diesem Blogbeitrag untersuchen wir, warum herkömmliche AppSec-Tools wie WAFs und API-Gateways versagen, da sie weder die semantische Absicht hinter einer Eingabeaufforderung interpretieren noch eine gesamte Konversation im Kontext analysieren noch modellvermittelte Berechtigungsänderungen verwalten können.

Ein weiterer Paradigmenwechsel in der Sicherheit

Die Einführung des Cloud-Computing Anfang der 2000er Jahre zwang die Branche dazu, das Thema Cybersicherheit neu zu überdenken. Mit der Cloud verlagerte sich der Schwerpunkt der Cybersicherheit von einem perimeter- und hardwareorientierten Modell hin zu einem dezentralen, datenzentrierten Ansatz. Die Infrastruktur wurde programmierbar, und die Verantwortung verteilte sich auf Anbieter und Kunden. Um die Cloud zu sichern, mussten wir nicht nur unsere Denkweise in Bezug auf Cybersicherheit ändern, sondern benötigten auch neue Tools zum Schutz des Unternehmens.

GenAI hat einen ähnlichen Paradigmenwechsel erzwungen. Die Anwendung umfasst nun KI-Modelle und -Agenten, die stochastischer Natur sind und nicht deterministisch. Anstelle expliziter Logik müssen wir uns nun mit dem Verhalten der Modelle auseinandersetzen. Der Umgang mit zielorientierten und autonomen Systemen erfordert im Vergleich zu einer herkömmlichen Anwendung zusätzliches Fachwissen.

MCP erhöht die Komplexität dieses Paradigmenwechsels noch weiter. Wenn Ihre Architektur MCP nutzt, um Agenten mit Tools und Daten zu verbinden, benötigen Sie Sicherheitskontrollen, die speziell auf das Verhalten von Agenten, Tool-Ökosysteme und sich schnell verändernde Ausführungsgraphen ausgelegt sind. Leider wurden herkömmliche AppSec-Tools entwickelt, um Code, Builds, Abhängigkeiten und bereitgestellte Dienste zu sichern. Sie sind nicht in der Lage, KI-Agenten zu schützen, die planen, Tools aufrufen und den Zustand im Laufe der Zeit verändern.

Um KI zu sichern, bedarf es eines neuen Ansatzes für die Cybersicherheit sowie speziell dafür entwickelter Tools.

MCP-Architekturen verändern die Sicherheitslage

Wenn Sie mit Agenten arbeiten, die auf dem Model Context Protocol basieren, haben Sie die Veränderungen wahrscheinlich bereits aus erster Hand miterlebt.

Was früher eine übersichtliche Request-Response-Anwendung war, verhält sich nun eher wie ein schnell agierender Operator. Sie liest, trifft eine Entscheidung, ruft Tools auf, liest erneut, trifft erneut eine Entscheidung und handelt dann. Infolgedessen verändert sich auch die Art des Risikos.

Das Architekturmuster

MCP macht die Nutzung von Tools zu einer formalen Integrationsschicht. Agenten können Tools erkennen, auswählen, aufrufen und deren Ergebnisse in einer Schleife auswerten.

Diese Schleife vergrößert Ihre Angriffsfläche. Es handelt sich nicht mehr nur um Ihren Anwendungscode und Ihre APIs. Die Schleife umfasst:

• Dein Code
• Jedes Werkzeug, das der Mitarbeiter erreichen kann
• Die Broker-Ebene, die diese Tools bereitstellt
• Die von diesen Tools zurückgegebenen Inhalte
• Die Logik, die entscheidet, was als Nächstes zu tun ist

Der Agent ruft nicht nur einen einzigen Endpunkt auf. Er navigiert durch einen Tool-Graph. Er hat es mit weitaus größerer Komplexität und Autonomie zu tun.

Warum es sich hierbei nicht nur um APIs mit einem Chatbot als Frontend handelt

In einer herkömmlichen Anwendung ist der Kontrollfluss fest vorgegeben. Eine Anfrage trifft auf einen Endpunkt, die Geschäftslogik wird ausgeführt, und es wird eine Antwort zurückgegeben.

In einem MCP-gesteuerten Agenten verläuft der Kontrollfluss nun iterativ. Das sieht in etwa so aus:

1. Plan
2. Anruf-Tool
3. Ausgabe beobachten
4. Aktualisierungsplan
5. Wiederholen

Eingaben beschränken sich nicht mehr nur auf Felder in Benutzerformularen. Dazu gehören Eingabeaufforderungen, abgerufene Dokumente, Tool-Ausgaben und Zwischenergebnisse der Schlussfolgerung.

Ausgaben bestehen nicht mehr nur aus Text. Es sind Aktionen:

• Erstellte Tickets
• Konfigurationen wurden geändert
• Versendete E-Mails
• Exportierte Daten
• Code zusammengeführt

Sie sichern nicht mehr nur einen Textgenerator. Sie sichern einen Entscheidungszyklus, der reale Systeme verändern kann.

Warum MCP und Agentic AI unterschiedliche Abwehrmaßnahmen benötigen

KI-Anwendungen unterscheiden sich von herkömmlichen Anwendungen. Zwar gelten herkömmliche AppSec-Ansätze nach wie vor, doch benötigen Sie zusätzlich Schutzmaßnahmen für neue Risiken, die speziell mit KI-Modellen, Agenten und MCP-Servern verbunden sind.

Autonome Agenten bergen neue Risiken

Agenten verhalten sich wie halbautonome Nutzer, die sich durch hohe Geschwindigkeit und große Reichweite auszeichnen.

Sie können Funktionen miteinander verknüpfen. Ein schreibgeschütztes Berichtstool in Kombination mit einem schreibfähigen Messaging-Tool kann unbemerkt zu einer Pipeline für den Datendiebstahl werden. Für sich genommen ist keines der beiden Tools gefährlich. Zusammen können diese Funktionen jedoch verheerende Folgen haben.

Die Auswirkungen auf die Sicherheit liegen auf der Hand. Sie müssen nun ganze Abläufe steuern und nicht mehr nur einzelne Endpunkte.

Fehlendes Kontextbewusstsein und fehlende Zuverlässigkeit des Zustands

Ein KI-Modell verwaltet den Zustand nicht auf dieselbe Weise wie eine Anwendung. Es leitet den Kontext aus den Daten ab, die Sie in sein Fenster eingeben, sowie aus den jüngsten Ausgaben des Tools. Es kann:

• Veraltete Protokolle als aktuelle Fakten behandeln
• Teilweise Daten als vollständig akzeptieren
• Kritische Inhalte als verlässlich interpretieren

Die sicherheitstechnische Konsequenz daraus ist, dass Zustandsverwaltung, Herkunftsnachweis und Sicherheitsvorkehrungen explizit zu den Aufgaben des Systems gehören müssen. Das Modell allein gewährleistet diese Aspekte nicht zuverlässig.

Agentenspezifische Angriffe, die in der herkömmlichen AppSec nicht vorkommen

Es überrascht nicht, dass MCP-Ökosysteme neue Angriffsarten mit sich bringen, die sich nicht mit herkömmlichen Bedrohungen vergleichen lassen. Prompt-Injection, Tool-Poisoning, Rug Pulls und vieles mehr sind Beispiele für solche neuen Angriffsarten.

• Prompt-Injektion und Jailbreaks: Ein LLM wird manipuliert, um einen böswilligen MCP-Tool-Aufruf zu erzeugen.
• Unberechtigte MCP-Server: Agenten könnten versuchen, eine Verbindung zu nicht vertrauenswürdigen, nicht genehmigten oder unzulässigen MCP-Servern herzustellen, was Risiken für nachgelagerte Systeme mit sich bringt.
• Tool-Poisoning: Ein Angreifer bettet Tools mit schädlichen Inhalten oder Payloads ein und ermöglicht es so indirekt dem Agenten oder LLM, unsichere Aktionen auszuführen.
• „Rug Pulls“: Ein Tool wirkt während der Einführungsphase oder beim Testen zunächst harmlos. Später ändern sich jedoch sein Verhalten, die Zuständigkeiten, die Berechtigungen oder die Ergebnisse.
• Datenexfiltration: Es können Tools eingesetzt werden, um sensible Daten, personenbezogene Daten (PII) und geistiges Eigentum (IP), die über MCP-Tools fließen, zu exfiltrieren.
• Tool-Aktualisierungen und Abweichungen: MCP-Server können ihre Ressourcen hinzufügen, entfernen oder ändern, wodurch blinde Flecken entstehen.

Für die Sicherheit bedeutet dies, dass Tools und deren Ergebnisse als nicht vertrauenswürdige Eingaben behandelt werden müssen, die mit eigenen Risiken in Bezug auf die Lieferkette und die Laufzeit verbunden sind.

Lücken bei der Identitätsprüfung und Autorisierung

Viele Agenten laufen unter groben Dienstidentitäten, gemeinsam genutzten Tokens oder Entwicklerschlüsseln, wodurch die Zuordnung unklar wird. Wenn ein Agent im Namen mehrerer Nutzer handelt, ist nicht mehr ersichtlich, „wer dies getan hat“.

Erschwerend kommt hinzu, dass Teams oft weitreichende Zugriffsrechte gewähren, für den Fall, dass ein Mitarbeiter diese benötigt, und damit das Prinzip der geringsten Berechtigungen über Bord werfen. Aus Sicherheitssicht entsteht dadurch ein dringender Bedarf an einer Identitätslösung, die die Delegation von Berechtigungen, bereichsbezogenen Zugriff, schrittweise Autorisierung und eine zuverlässige Zuordnung unterstützt.

Wo herkömmliche AppSec-Tools an ihre Grenzen stoßen

Traditionelle AppSec-Verfahren sind für die Sicherheit des Unternehmens unverzichtbar. Es wäre unklug, eines dieser Verfahren einzustellen, nur weil es die neuen Risiken im Zusammenhang mit agentenbasierter KI und MCP nicht abdeckt. Allerdings sind sie bei der Absicherung von MCP-Workflows nur begrenzt wirksam. Der folgende Abschnitt bietet einen Überblick über traditionelle AppSec-Tools, ihren Nutzen und ihre Grenzen bei der Absicherung von MCP.

SAST und Code-Scanning

Statische Anwendungssicherheitstests (SAST) analysieren Code vor der Produktionsfreigabe, um Fehler in Ihrem Quellcode, Bytecode und Ihren Binärdateien aufzudecken. Dabei werden keine unsicheren Abläufe berücksichtigt, die zur Laufzeit entstehen.

SAST bietet keine Laufzeitabdeckung und kann keine Rückschlüsse ziehen auf:

• Dynamische Werkzeugauswahl
• Schnelle Eingabe mithilfe von abgerufenen Inhalten
• Mehrstufige Aktionsketten

Die Fehlerursache in einem MCP-System ist selten eine fehlerhafte Codezeile. Es handelt sich vielmehr um eine gültige Abfolge von Aufrufen, die niemals miteinander verkettet hätten werden dürfen.

DAST und API-Tests

Beim dynamischen Testen der Anwendungssicherheit (DAST) werden Schwachstellen und Sicherheitslücken aufgespürt, indem externe Angriffe auf eine Anwendung simuliert werden, während diese ausgeführt wird. Beim dynamischen Testen wird von vorhersehbaren Endpunkten und festen Eingaben ausgegangen.

Bei der API-Sicherheit liegt der Schwerpunkt auf dem Schutz von Anwendungsprogrammierschnittstellen vor Missbrauch, unbefugtem Zugriff und Datenoffenlegung. Dabei werden Authentifizierung, Autorisierung, Eingabevalidierung sowie häufige Risiken wie mangelhafte Autorisierung auf Objektebene und übermäßige Datenoffenlegung über definierte Endpunkte hinweg bewertet.

Sowohl bei DAST als auch bei der API-Sicherheit wird von einem relativ deterministischen Verhalten ausgegangen. Die Endpunkte sind bekannt. Die Anfragen folgen erwarteten Mustern. Ein- und Ausgabedaten können isoliert ausgewertet werden.

Das Verhalten des Agenten ist probabilistisch und pfadabhängig. Zwei identische Eingabeaufforderungen können zu unterschiedlichen Werkzeugketten führen.

DAST und herkömmliche API-Tests prüfen von Natur aus keine Sequenzrisiken, wie zum Beispiel:

• Ein vertrauliches Dokument lesen
• Fassen Sie das Dokument zusammen
• Veröffentliche die Zusammenfassung in einem öffentlichen Kanal

Jeder Schritt erscheint korrekt. Die Authentifizierung ist erfolgreich. Die Autorisierungsprüfungen werden bestanden. Die API-Antworten sind korrekt. DAST- und API-Scanner haben keine Möglichkeit festzustellen, dass die Kette selbst ein inakzeptables Risiko für das Unternehmen darstellt.

Bei MCP- und agentenbasierten KI-Systemen ist das Risiko nicht immer auf eine einzelne Anfrage beschränkt. Es ergibt sich aus der Kombination mehrerer zulässiger Aktionen über verschiedene Tools und Datenquellen hinweg. Genau an dieser Stelle verlieren herkömmliche dynamische Tests und API-Sicherheitskontrollen an Aussagekraft.

SCA und Abhängigkeitsprüfung

Bei der Software-Kompositionsanalyse (SCA) wird der Code einer Anwendung auf Open-Source-Abhängigkeiten überprüft, um alle Open-Source-Pakete, deren Lizenzkonformitätsdaten sowie alle bekannten Sicherheitslücken zu identifizieren.

SCA berücksichtigt MCP-Risiken nicht in nennenswertem Umfang, da MCP-Tools häufig außerhalb Ihres Repositorys liegen. Sie werden zur Laufzeit über Registries oder Remote-Kataloge erkannt und aufgerufen, nicht jedoch in einer Anforderungsdatei deklariert oder in die Quellcodeverwaltung übernommen. Das bedeutet, dass MCP-Tools möglicherweise nie in dem von SCA analysierten Abhängigkeitsgraphen erscheinen.

Ein bösartiges oder kompromittiertes Tool ähnelt eher einem dynamisch geladenen Plugin als einem herkömmlichen Paket. Risiken können durch manipulierte Metadaten, ausgetauschte Endpunkte, widerrufene Herausgebervertrauenswürdigkeit oder eine Tool-Version entstehen, die das Verhalten ohne Code-Commit ändert. Herkömmliche SCA-Verfahren verfolgen keine externen Tool-Kataloge, validieren keine Herausgeberidentität und überwachen keine Vertrauens- und Integritätssignale in dieser Ausführungsebene.

Geheimnisse scannen

Secret-Scanner sind automatisierte Sicherheitstools, die offengelegte sensible Informationen wie API-Schlüssel, Tokens, Passwörter und Verschlüsselungsschlüssel aufspüren, die im Quellcode, in Konfigurationsdateien und in der Dokumentation versteckt sind. Während Secret-Scanner bei der Erkennung von Schlüsseln im Quellcode sehr effektiv sind, haben sie Schwierigkeiten dabei, zu erkennen, wenn ein Mitarbeiter Geheimnisse durch Zusammenfassungen, Kopier- und Einfügevorgänge oder durch den Export mithilfe von Tools preisgibt.

WAFs, RASP und Perimeter-Kontrollen

Webanwendungs-Firewalls (WAFs) filtern, überwachen und blockieren den HTTP-Datenverkehr zu und von Webanwendungen und schützen so vor einer Reihe von Angriffen auf Anwendungsebene. Der Laufzeitschutz für Anwendungen (RASP) wird innerhalb einer Anwendung ausgeführt, um Angriffe in Echtzeit zu erkennen und automatisch zu blockieren, indem er die Ausführung überwacht und steuert. Perimeterkontrollen überprüfen den Webdatenverkehr am Netzwerkrand.

Auch hier gilt: Diese Tools haben ihren Platz bei der Absicherung traditioneller Anwendungen. Bei MCP hingegen können Tool-Aufrufe diesen Randbereich über interne Netzwerke oder direkte SaaS-APIs vollständig umgehen.

WAFs, RASP und Perimeter-Kontrollen überprüfen Anfragen, nicht die Absicht. Sie können nicht erkennen, ob eine Toolkette im jeweiligen Kontext sinnvoll ist.

SIEM und Protokollierung als Sicherheitsnetz

Sie können Tool-Aufrufe protokollieren. Doch wie können Sie ohne agentenbezogenen Kontext feststellen, ob eine Abfolge erwartet wurde oder eine Anomalie darstellt?

SIEM-Systeme erfassen, analysieren und korrelieren Daten aus der gesamten IT-Infrastruktur in Echtzeit und sind für Sicherheitszentralen (SOCs) unverzichtbar, um Bedrohungen zu erkennen, zu untersuchen und darauf zu reagieren.

Bei MCP kommen Untersuchungen ins Stocken, wenn keine Rückverfolgbarkeit der Eingabeaufforderungen, der Dokumentherkunft, der Tool-Ergebnisse oder der Entscheidungsgraphen gegeben ist. Ohne Herkunftsangaben lässt sich nicht feststellen, welche Eingabeaufforderung, welches abgerufene Dokument oder welche Tool-Ausgabe die Entscheidung beeinflusst hat. Protokolle ohne agentenbezogenen semantischen Kontext reichen für eine zuverlässige Erkennung und Untersuchung in MCP-Umgebungen nicht aus.

Es geht auch hier nicht darum, dass Protokolle nutzlos sind. Tatsächlich sind sie für viele Aspekte des Geschäftsbetriebs unverzichtbar. Es ist nur so, dass sie für agentenbasierte Systeme eine unvollständige Telemetrie darstellen.

Die Herausforderungen von MCP-basierten Architekturen

Wenn Sie MCP-basierte Architekturen unter dem Gesichtspunkt der Anwendungssicherheit betrachten, müssen Sie bedenken, dass MCP nicht einfach nur eine weitere Integration ist. Agentic AI und MCP verwandeln Ihre Anwendung in einen schnell denkenden, autonomen Operator, der auf eine Vielzahl von Systemen zugreifen kann.

Traditionelle AppSec spielt nach wie vor eine wichtige Rolle. Ohne eine Steuerung des Agent-Kreislaufs selbst haben Sie jedoch keinen Einblick darin, wo die tatsächlichen Entscheidungen – und Risiken – stattfinden.

TrojAI von A10 Networks

Die „TrojAI“- Lösungen von A10 Networks bieten eine umfassende Sicherheitsplattform für KI. Diese branchenführende Plattform ermöglicht es Unternehmen, KI-Modelle, -Anwendungen und -Agenten sowohl bei der Erstellung als auch während der Ausführung zu schützen.

Zu den Lösungen gehören:

• TrojAI Detect – führt automatische Red-Team-Tests an KI-Modellen durch, sichert das Modellverhalten ab und liefert bereits während der Erstellungsphase Anleitungen zur Behebung von Problemen.
• TrojAI Defend – Diese KI-Anwendung und Agent-Firewall schützt Unternehmen in Echtzeit vor Bedrohungen während der Laufzeit.
• TrojAI Defend für MCP – Überwachung und Schutz von agentenbasierter KI und MCP-Workflows.