MCP-Server und Coding-Agent: Sicherheitsrisiken und Kontrollen vor dem Go-Live

Ein Coding-Agent, der mit MCP-Servern oder externen Tools verbunden ist, ist nicht mehr nur ein Assistent, der Code vorschlägt. Er kann Repositorys lesen, Tickets abfragen, interne Dokumentationen durchsuchen, APIs aufrufen, Befehle ausführen, auf Datenbanken zugreifen, Pull Requests öffnen, Konfigurationen ändern oder mit Cloud-Diensten interagieren. Die Risikooberfläche ändert sich: Es geht nicht mehr nur um die generierte Datei, sondern um die Berechtigungen, Daten und Aktionen, die der Agent während seiner Arbeit nutzen kann.

Das Model Context Protocol (MCP) wurde entwickelt, um die Verbindung zwischen LLM-Anwendungen, Tools und Datenquellen zu standardisieren. Für Softwareentwicklungsteams ist dies nützlich, da es Ad-hoc-Integrationen reduziert und es einfacher macht, Agenten mit operativem Kontext zu versorgen. Dieselbe Fähigkeit verlagert das Problem jedoch auf eine heiklere Frage: Wenn der Agent eine Aufgabe falsch interpretiert, eine Prompt-Injection erleidet oder das falsche Tool wählt, welche Systeme kann er dann tatsächlich beeinflussen?

Bevor MCP in einem Entwicklungsworkflow eingesetzt wird, müssen Security Engineers, CTOs und erfahrene Entwickler Tools, Identitäten, Autorisierungen, Token, Protokolle und zulässige Aktionen abbilden. Ein schreibgeschützter (read-only) MCP-Server für öffentliche Dokumentationen hat ein völlig anderes Risikoprofil als ein Server mit Zugriff auf Repositorys, CI/CD, Cloud-Umgebungen, Tickets, Datenbanken oder Unternehmenssysteme.

Von der Code-Generierung zur Tool-Nutzung

Beim traditionellen “Vibe Coding” besteht das Hauptrisiko darin, nicht verifizierten Code zu akzeptieren. Mit MCP und agentischer Tool-Nutzung erstreckt sich das Risiko auf den gesamten Prozess, der diesen Code hervorbringt: Der Agent kann Daten lesen, Tools auswählen, Parameter zusammenstellen, Ausgaben interpretieren, die nächste Aktion entscheiden und Änderungen vorschlagen oder anwenden. Wenn die Tools über weitreichende Privilegien verfügen, kann ein Kontextfehler zu einer realen Aktion werden.

Ein Agent, der ein Issue liest und dann eine Route ändert, kann eine Sicherheitslücke im Code einführen. Ein Agent, der dasselbe Issue liest, die Datenbank abfragt, eine Cloud-Konfiguration aktualisiert und einen Pull Request öffnet, hat einen weitaus größeren Wirkungsbereich: Er kann Daten offenlegen, Anmeldeinformationen verwenden, Richtlinien ändern, Berechtigungen ausweiten oder ein Diff basierend auf einer nicht vertrauenswürdigen Ausgabe generieren.

MCP-Sicherheit, Schwachstellen in MCP-Servern, die Sicherheit agentischer Tools und der Missbrauch von Agenten-Tools müssen daher gemeinsam betrachtet werden. Das Problem ist nicht nur, ob der MCP-Server “funktioniert”, sondern welche Fähigkeiten er offenlegt, gegenüber welcher Identität, mit welcher Autorisierung, mit welcher Isolierung, mit welcher Protokollierung und mit welchen menschlichen Bestätigungen.

Excessive Agency: Wenn der Agent mehr Macht hat als nötig

OWASP führt “Excessive Agency” (übermäßige Handlungsbefugnis) als eines der Hauptrisiken für LLM-Anwendungen auf: Ein Modell mit übermäßiger Autonomie, Funktionalität oder Berechtigungen kann unbeabsichtigte Aktionen ausführen, insbesondere wenn es durch Prompt-Injection oder nicht vertrauenswürdige Daten manipuliert wird. Mit MCP wird dieses Risiko praktisch, da das Protokoll den Agenten mit realen Werkzeugen verbindet.

Die Frage, die man sich bei jedem Tool stellen muss, ist konkret: Muss der Agent wirklich schreiben können, oder reicht Lesen aus? Muss er auf Produktionsdaten zugreifen können, oder reicht eine Staging-Umgebung? Muss er auf alle Repositorys zugreifen können oder nur auf ein spezifisches Projekt? Muss er beliebige Endpunkte aufrufen können oder nur Operationen mit einem kontrollierten Schema? Muss er Shell-Befehle ausführen können, oder reicht es, bereits vorbereitete Ergebnisse abzurufen?

Ein gesundes Berechtigungsmodell trennt Lesen, Schreiben und destruktive Aktionen. Das Lesen technischer Dokumentationen ist nicht dasselbe wie das Lesen von Protokollen mit personenbezogenen Daten. Ein Ticket zu öffnen ist nicht dasselbe wie es zu schließen. Einen Befehl vorzubereiten ist nicht dasselbe wie ihn auszuführen. Einen Patch zu generieren ist nicht dasselbe wie ihn zu mergen. Je irreversibler, kostspieliger oder mit realen Daten verknüpft eine Aktion ist, desto mehr sind menschliche Genehmigung, Sandbox-Umgebungen und Audit-Trails erforderlich.

Confused Deputy, Token-Passthrough und MCP-Autorisierung

Die MCP-Sicherheitsdokumentation weist auf das Risiko des “Confused Deputy” hin: Eine Komponente mit Privilegien kann dazu verleitet werden, im Namen eines Clients oder einer Ressource zu handeln, die nicht vorgesehen war. In einem agentischen Workflow ist dieses Szenario kritisch, da sich der Agent zwischen Benutzer, Client, MCP-Server, OAuth-Provider, Unternehmens-APIs und den finalen Ressourcen befinden kann.

Die MCP-Spezifikation für HTTP-Transporte definiert Autorisierungsfähigkeiten auf Basis von OAuth 2.1, und neuere Versionen betonen die Verwendung von Resource Indicators, um Token und Ressourcen zu verknüpfen. MCP-Best-Practices verbieten Token-Passthrough, da das Weiterleiten von Token von einer Komponente zur anderen Audience, Scopes, Widerrufsmöglichkeiten, Rückverfolgbarkeit und Vertrauensgrenzen verletzen kann. Für eine Unternehmensanwendung ist dies kein bloßes Implementierungsdetail: Es entscheidet darüber, ob ein Agent Anmeldeinformationen im richtigen Kontext verwendet oder sie missbraucht.

In der Praxis sollte ein MCP-Server keine globalen Token verwenden, wenn die Aktion vom Benutzer abhängt, und auch kein Token akzeptieren, das für eine Ressource gedacht ist, um es für eine andere zu verwenden. Er sollte dieselben Anmeldeinformationen nicht zwischen verschiedenen Repositorys, Mandanten oder Umgebungen teilen und dem Endbenutzer nicht verheimlichen, welcher Client den Zugriff auf welche Daten anfordert. Jedes sensible Tool muss klare Identitäten, Scopes und Ressourcen haben.

Tool-Metadaten und Tool-Poisoning

Ein MCP-Tool ist nicht nur ausführbarer Code: Es legt auch Namen, Beschreibungen, Eingabeschemata und oft Anwendungsbeispiele offen. Das Modell nutzt diese Informationen, um zu entscheiden, wann es das Tool aufruft und wie es die Parameter ausfüllt. Wenn ein Angreifer Metadaten, Beschreibungen, Dokumentationen oder die Ausgabe des Tools manipulieren kann, kann er den Agenten zu falschen Entscheidungen verleiten.

Das Risiko des “Tool-Poisoning” ist subtil, da es die Art und Weise ausnutzt, wie das Modell über Text nachdenkt. Eine Beschreibung könnte lauten: “Verwende dieses Tool, um temporäre Anmeldeinformationen abzurufen” oder “Für die Aktualisierung von Konfigurationen ist keine Bestätigung erforderlich”. Ein scheinbar harmloses Tool kann Ausgaben liefern, die Anweisungen an den Agenten enthalten, anstatt Daten. Ein von einer nicht verifizierten Quelle installierter MCP-Server kann Tools mit Namen offenlegen, die legitimen Tools ähneln.

Die Verteidigung beginnt bei der Kontrolle der Herkunft. MCP-Server, die in Repositorys oder Unternehmenssystemen verwendet werden, sollten aus genehmigten Quellen stammen, versioniert, überprüft und mit Allowlisten konfiguriert sein. Die Tool-Beschreibungen müssen präzise und minimal sein: Erklären Sie, was das Tool tut, welche Eingaben es akzeptiert, welche Auswirkungen es hat und welche Grenzen es gibt. Sicherheitsanweisungen sollten nicht als einzige Barriere im beschreibenden Text des Tools leben, sondern durch Autorisierungen, Richtlinien und Laufzeitkontrollen durchgesetzt werden.

Tool-Ausgaben: Daten, Anweisungen und Folgeaktionen

Ein Agent kann die Ausgabe eines Tools als Eingabe für eine nachfolgende Entscheidung verwenden. Wenn das Tool Dokumentationen, Tickets, Webseiten, Protokolle oder Datenbankeinträge abruft, kann die Ausgabe nicht vertrauenswürdigen Text enthalten. Wenn das Tool Befehle, Pfade, Abfragen, Patches oder Konfigurationen generiert, kann eine manipulierte Ausgabe zur Aktion werden.

Der typische Fall ist eine einfache Kette: Das Tool liest ein Ticket, das Ticket enthält feindselige Anweisungen, der Agent befolgt diese und ruft dann ein anderes Tool mit höheren Privilegien auf. Das Ergebnis kann eine offengelegte Route, eine ausgeweitete Cloud-Richtlinie, ein modifizierter Test, eine ungefilterte Abfrage oder ein in eine Datei kopiertes Geheimnis sein. Indirekte Prompt-Injection wird weitaus gefährlicher, wenn das Modell nach dem Lesen des Inhalts Werkzeuge verwenden kann.

Tool-Ausgaben müssen wie jede externe Eingabe validiert werden: Ein striktes Schema, explizite Typen, Escaping, Feldgrenzen, Allowlisten für Folgeaktionen sowie die Trennung von Daten und Anweisungen reduzieren das Risiko. Bei sensiblen Aktionen sollte der Agent anzeigen, was er gelesen hat, welches Tool er aufrufen möchte, welche Parameter er verwenden wird und welche Auswirkungen zu erwarten sind, da eine pauschale Bestätigung dem Prüfer nicht genügend Kontext bietet.

Prompt-Injection durch Dokumente, Tickets und Unternehmenssysteme

MCP macht es einfach, einen Agenten mit Systemen zu verbinden, die bereits voller Inhalte sind: Jira, GitHub Issues, Slack, E-Mails, Wikis, CRM, Dokumentationen, Wissensdatenbanken, Protokolle und Ticketsysteme. Diese Inhalte wurden nicht als sichere Anweisungen für ein Modell geschrieben und können bösartigen Text, von Benutzern kopierte Fragmente, veraltete Beispiele, nicht verifizierte Befehle oder manipulierte Daten enthalten.

Ein Support-Ticket könnte einen Satz enthalten, der darauf ausgelegt ist, den Agenten dazu zu bringen, die Projektregeln zu ignorieren. Ein Kommentar in einem Issue könnte dazu auffordern, einen Admin-Endpunkt zu verwenden. Ein internes Dokument könnte ein altes Verfahren mit nicht mehr gültigen Anmeldeinformationen oder Berechtigungen enthalten. Eine vom Tool abgerufene Webseite könnte versteckte Anweisungen enthalten. Wenn der Agent alles als vertrauenswürdigen Kontext behandelt, werden die Tools zu einem Verstärker des Risikos.

Sichere Workflows trennen genehmigte Quellen von nicht vertrauenswürdigen Inhalten. Ein Ticket kann einen Fehler beschreiben, sollte aber nicht die Richtlinien des Agenten ändern. Eine externe Seite kann Informationen liefern, sollte aber keine Befehle autorisieren. Ein Protokoll kann bei der Diagnose helfen, sollte aber keine Geheimnisse in den Kontext bringen. Wenn der Agent vom Lesen zum Handeln übergeht, ist eine explizite Kontrolle erforderlich.

Tools, die Repositorys, Dateisysteme und Geheimnisse lesen

Im Kontext der Softwareentwicklung sind viele MCP-Server und Konnektoren gerade deshalb nützlich, weil sie Repositorys, Dateisysteme, Konfigurationen und technische Dokumentationen lesen. Das Risiko besteht darin, dass sie zu viel lesen: Ein Agent, der das Projekt frei erkunden kann, könnte auf .env-Dateien, API-Schlüssel, Deployment-Token, Backup-Dateien, Dumps, Protokolle, Zertifikate, Cloud-Konfigurationen oder in Tests verwendete personenbezogene Daten stoßen.

Das Problem lässt sich nicht allein dadurch lösen, dass man dem Anbieter oder dem Modell vertraut. Wenn ein Geheimnis gelesen, in ein Diff kopiert, in ein Protokoll aufgenommen, an ein Tool gesendet oder in eine Antwort eingefügt wird, ist der Schaden operativ, und die Behebung umfasst die Entfernung aus dem Code, die Rotation der Anmeldeinformationen, die Überprüfung der Umgebungen sowie die Kontrolle von Builds, Protokollen und Artefakten.

Aus diesem Grund sollten Dateisystem- und Repository-Tools standardmäßig auf “Deny by Default” eingestellt sein. Sensible Pfade, .env-Dateien, Dumps, Backups, Secret-Manager-Exporte, private Schlüssel und reale Protokolle müssen ausgeschlossen oder nur mit spezifischer Autorisierung zugänglich sein. Die von MCP-Servern verwendeten Anmeldeinformationen müssen von persönlichen und produktiven Anmeldeinformationen getrennt sein: Wenn ein Tool Code lesen muss, sollte es nicht automatisch auch Geheimnisse und Daten lesen können.

Tools, die schreiben, löschen oder deployen

Die Risikoschwelle verschiebt sich, wenn das Tool nicht nur liest. Das Schreiben in Datenbanken, das Aktualisieren von Tickets, das Senden von E-Mails, das Öffnen von PRs, das Ändern von Dateien, das Löschen von Ressourcen, das Rotieren von Anmeldeinformationen, das Starten von Pipelines oder das Deployment sind Aktionen mit realen Auswirkungen – und selbst eine scheinbar kleine Änderung kann weitreichende Folgen haben, wenn sie im falschen Kontext erfolgt.

Ein Agent könnte beschließen, einen Build-Fehler zu beheben, indem er Berechtigungen öffnet, eine Prüfung deaktiviert, CORS erweitert, Umgebungsvariablen ändert oder CI/CD-Workflows modifiziert. Er könnte ein Ticket schließen, weil er die Ausgabe eines Tools falsch interpretiert, eine Nachricht mit internen Daten senden, eine Migration auf der falschen Datenbank ausführen oder einen Pull Request erstellen, der generierten Code und nicht überprüfte Konfigurationen kombiniert.

Schreibaktionen erfordern ein strengeres Modell: Dry-Runs, Staging, explizite Genehmigung, Protokollierung, Rollbacks und klare Grenzen. Der Benutzer muss Parameter und Konsequenzen sehen können, bevor er bestätigt. Für Cloud, Datenbanken, CI/CD, E-Mail, Ticketing und Kundensysteme ist es ratsam, schreibgeschützte Tools von Schreib-Tools zu trennen und destruktive Aktionen standardmäßig zu deaktivieren.

Isolierung zwischen Benutzern, Mandanten und Umgebungen

Ein MCP-Server kann von mehreren Personen, Teams, Repositorys oder Umgebungen genutzt werden. Wenn die Identität nicht korrekt weitergegeben wird, riskiert der Server, mit einem zu weitreichenden technischen Konto zu agieren, was zu klassischen Autorisierungsproblemen führt: Ein Benutzer kann Daten eines anderen Teams lesen, ein Agent kann Repositorys außerhalb seines Bereichs ändern, eine Testumgebung kann die Produktion berühren, ein Mandant kann einen anderen beeinflussen.

Sicherheit muss pro Benutzer und Ressource konzipiert werden. Tool-Aufrufe müssen einer Person oder einem autorisierten Dienst zuordenbar sein, Token müssen Scopes haben, die mit Repository, Projekt, Mandant und Umgebung übereinstimmen, und Autorisierungen auf Objektebene können nicht durch eine generische Regel wie “der Agent ist autorisiert” ersetzt werden. Wenn ein Tool auf mandantenfähige Daten zugreift, muss jede Anfrage den korrekten Mandanten bis zur finalen Ressource beibehalten.

In Pre-Production-Tests müssen verschiedene Benutzer simuliert werden: Ein Entwickler mit Admin-Rechten reicht nicht aus, um den Ablauf zu validieren. Es muss überprüft werden, was mit einem Standardbenutzer, einer schreibgeschützten Rolle, einem Mitglied eines anderen Mandanten, einem abgelaufenen Konto, einem Token mit reduziertem Scope und einer von der Produktion getrennten Staging-Umgebung passiert.

Supply Chain der MCP-Server

Die Installation eines MCP-Servers bedeutet, eine Komponente einzuführen, die oft Zugriff auf Daten und Aktionen hat. Es kann sich um ein npm-Paket, einen Container, eine Binärdatei, ein lokales Skript, einen Remote-Dienst oder einen SaaS-Konnektor handeln. Wenn der Server kompromittiert, schlecht gewartet, aus einer nicht verifizierten Quelle heruntergeladen oder falsch konfiguriert ist, beschränkt sich das Risiko nicht auf seinen Code: Es betrifft alles, was er erreichen kann.

Die Supply Chain von MCP-Servern muss mit denselben Kriterien verwaltet werden, die für kritische Anwendungskomponenten gelten. Herkunft, Betreuer, Version, Changelog, Abhängigkeiten, Lizenz, bekannte Schwachstellen, Installationsskripte, Container-Images und Laufzeitkonfigurationen müssen überprüft werden. Ein Server, der zum Lesen öffentlicher Dokumentationen verwendet wird, hat andere Anforderungen als ein Server mit Zugriff auf GitHub, Datenbanken, Cloud-Systeme oder interne Tickets.

Für Unternehmensumgebungen reduziert eine Allowliste oder eine private Registry das Risiko zufälliger Installationen. Sensible MCP-Server sollten in Sandboxes oder Containern mit eingeschränktem Netzwerk, Dateisystem und Geheimnissen laufen. Updates müssen überprüft werden, da eine neue Version die offengelegten Tools, angeforderten Scopes, Ausgaben oder das Verhalten ändern kann.

Protokollierung, Audit-Trail und Incident Response

Ohne Protokolle ist MCP schwer zu steuern. Wenn der Agent eine Datei ändert, ein Ticket öffnet, Daten liest oder eine API aufruft, muss das Team rekonstruieren können, wer die Sitzung gestartet hat, welches Tool aufgerufen wurde, mit welchen Parametern, welche Ausgabe zurückgegeben wurde, welche Aktion folgte und welche Ressource berührt wurde.

Die Protokollierung muss reichhaltig genug sein, um Überprüfungen und Incident Response zu unterstützen, darf aber nicht zu einem neuen Expositionsrisiko werden: Tool-Eingaben und -Ausgaben können sensible Daten, Token oder Kundeninformationen enthalten, daher sind Schwärzung, Aufbewahrungsrichtlinien, Zugriffskontrollen und Warnmeldungen für die heikelsten Tools erforderlich.

Zu überwachende Ereignisse umfassen Aufrufe von Schreib-Tools, Zugriff auf Geheimnisse, Lesen personenbezogener Daten, Verwendung privilegierter Token, Cross-Mandanten-Aufrufe, Deployments, Löschungen, Änderungen an Cloud-Richtlinien, Updates von MCP-Servern und Autorisierungsfehler. Wenn etwas schiefgeht, muss das Team in der Lage sein, einen Server schnell zu deaktivieren, Token zu widerrufen, Anmeldeinformationen zu rotieren und die erzeugten Änderungen zu identifizieren.

Human-in-the-Loop, der wirklich funktioniert

Eine menschliche Bestätigung einzufügen reicht nicht aus, wenn die Bestätigung keine nützlichen Informationen enthält. Eine generische Nachricht wie “Der Agent möchte ein Tool verwenden, bestätigen Sie?” erlaubt keine Bewertung von Risiko, Daten und Auswirkungen. Für sensible Aktionen ist eine lesbare Bestätigung erforderlich: Tool, Identität, Ressource, Parameter, Umgebung, Art der Aktion, als Eingabe verwendete Ausgabe und erwartete Konsequenz.

Das Niveau der Bestätigung muss der Auswirkung entsprechen. Eine schreibgeschützte Abfrage in einer öffentlichen Dokumentation erfordert möglicherweise wenig Aufwand, während ein Aufruf, der Kundendaten liest, Rollen ändert, Deployments startet, IAM aktualisiert oder in die Datenbank schreibt, eine explizite Überprüfung erfordert. Für repetitive Vorgänge können vordefinierte Richtlinien und Genehmigungen verwendet werden, aber erst, nachdem Scopes und Umgebung eingeschränkt wurden.

Ein guter Human-in-the-Loop dient nicht dazu, die Verantwortung auf den Entwickler abzuwälzen: Er dient dazu, eine implizite Entscheidung des Agenten in eine überprüfbare Entscheidung des Teams zu verwandeln. Wenn die Aktion die Produktion, reale Daten oder Unternehmenssysteme berührt, muss die Überprüfung proportional zum Risiko sein.

Was vor dem Go-Live zu prüfen ist

Bevor eine Anwendung oder ein Workflow, der MCP verwendet, in Produktion geht, ist es ratsam, eine Karte der Tools zu erstellen: Welche MCP-Server sind installiert, sind sie lokal oder remote, wer wartet sie, welche Tools legen sie offen, welche Daten lesen sie, können sie schreiben, verwenden sie OAuth, statische Token oder Dienst-Anmeldeinformationen, sind sie nach Benutzer, Repository, Mandant und Umgebung getrennt und welche Protokolle erzeugen sie?

Die zweite Karte betrifft die Aktionen: Welche Tools können Code, Tickets, Datenbanken, Cloud-Systeme, CI/CD, E-Mails oder Kundensysteme ändern, welche erfordern eine Genehmigung, welche haben einen Dry-Run, welche können im Notfall deaktiviert werden und welche sind auch dann verfügbar, wenn der Agent nicht vertrauenswürdige Inhalte gelesen hat?

Die dritte Karte betrifft die Vertrauensgrenzen. Wo verläuft die Vertrauensgrenze zwischen Benutzer, Client, MCP-Server, OAuth-Provider, Unternehmens-API und finaler Ressource? Welche Identität wird bei jedem Schritt verwendet? Ist ein Token mit der richtigen Ressource verknüpft? Ist eine Aktion dem korrekten Benutzer zuordenbar? Kann ein Mandant einen anderen beeinflussen? Kann eine Staging-Umgebung die Produktion berühren?

MCP-Sicherheitscheckliste für Coding-Agenten

Inventarisieren Sie MCP-Server, Tools, Clients, Umgebungen und Eigentümer.
Klassifizieren Sie Tools in read-only, write, destruktiv, privilegiert und sensibel.
Überprüfen Sie OAuth, Resource Indicators, Audience, Scopes und das Fehlen von Token-Passthrough.
Wenden Sie das Prinzip der geringsten Privilegien (Least Privilege) für Benutzer, Projekt, Repository, Mandant und Umgebung an.
Trennen Sie persönliche, technische, Staging- und Produktions-Anmeldeinformationen.
Beschränken Sie den Zugriff auf Dateisysteme, Repositorys, Secret-Manager, Protokolle und personenbezogene Daten.
Validieren Sie Tool-Eingaben und -Ausgaben mit strikten Schemata und Allowlisten.
Testen Sie indirekte Prompt-Injection auf Tickets, Dokumenten, Issues, E-Mails, Wikis und Webseiten.
Fordern Sie eine explizite Bestätigung für Schreib-, Lösch-, Deployment-, Cloud-, Datenbank-, Ticket- und E-Mail-Aktionen an.
Verwenden Sie Sandboxes oder Container für Tools, die Code ausführen, Befehle absetzen oder auf das Dateisystem zugreifen.
Protokollieren Sie Tool-Aufrufe, Parameter, Ausgaben, Benutzer, Sitzungen, Ressourcen, Umgebungen und Ergebnisse.
Bereiten Sie Rollbacks, Token-Widerruf, Rotation von Anmeldeinformationen und die schnelle Deaktivierung von Servern vor.

Wann Sie ISGroup hinzuziehen sollten

Eine interne Überprüfung kann für lokale Experimente, schreibgeschützte Tools für nicht sensible Dokumentationen oder Prototypen ohne reale Daten ausreichen. Das Risiko ändert sich, wenn MCP in einen produktionsnahen Workflow eintritt: Unternehmens-Repositorys, geteilte Branches, Datenbanken, Cloud-Systeme, Tickets, CI/CD, Kundensysteme, reale Benutzer oder exponierte Umgebungen.

Wenn MCP oder externe Tools zugreifen auf…	Hauptrisiko	Empfohlene Kontrolle
Repositorys, Code, Middleware, Richtlinien, Skripte	Fehlerhafte Anwendungsänderungen oder logische Bypässe	Code Review
Laufzeit-Tools, Prompts, Dokumente, Agenten-Aktionen	Prompt-Injection, Tool-Missbrauch, nicht validierte Ausgaben	Software Assurance Lifecycle
Agenten-Architektur, Vertrauensgrenzen, Identitäten, Token	Schwache Autorisierungsgrenzen	Secure Architecture Review
Web-Apps, APIs oder exponierte Dashboards	Missbrauch von außen nach dem Go-Live	Web Application Penetration Testing
Cloud, IAM, Secret-Manager, Pipelines, Datenbanken	Übermäßige Privilegien oder Fehlkonfigurationen	Cloud Security Assessment

Wenn Tools Code und Middleware beeinflussen, muss das Diff betrachtet werden. Wenn die Anwendung exponiert ist, muss das reale Verhalten mittels Web Application Penetration Testing überprüft werden. Wenn das Hauptrisiko die Agenten-Architektur ist, liegt die Priorität auf der Überprüfung von Identitäten, Autorisierung, Vertrauensgrenzen, Token und Protokollierung. Wenn die Nutzung von Agenten und MCP im Entwicklungszyklus stabil wird, sind im Zeitverlauf wiederholbare Kontrollen erforderlich.

Für eine Überprüfung vorzubereitende Nachweise

Für eine effektive Überprüfung werden die Liste der MCP-Server, Konfigurationen, offengelegten Tools, Scopes, verwendeten Anmeldeinformationen, Umgebungen, das Flussdiagramm und die verbundenen Systeme benötigt. Es müssen schreibgeschützte und Schreib-Tools, genehmigungspflichtige Aktionen, verfügbare Protokolle, Widerrufsmechanismen, Sandbox-Richtlinien und etwaige Allowlisten angegeben werden.

Auf Anwendungsebene werden Repositorys, Branches, von Agenten generierte oder modifizierte PRs, exponierte APIs, Rollen, Mandanten, verarbeitete Daten, Pipelines, Cloud-Systeme, Datenbanken und Integrationen benötigt. Wenn der Agent Tickets, Dokumente, Wikis, E-Mails oder CRM liest, muss geklärt werden, welche Quellen als vertrauenswürdig gelten und welche nicht. Wenn MCP Zugriff auf die Produktion hat, ist es wichtig zu unterscheiden, was in Staging und was auf realen Systemen getan werden kann.

Diese Nachweise ermöglichen es, generische Kontrollen zu vermeiden. Eine Überprüfung von MCP muss der vollständigen Kette folgen: Benutzer, Prompt, Client, MCP-Server, Autorisierung, Tool, Ausgabe, Aktion, Protokoll und finale Ressource. Nur so lässt sich verstehen, ob ein Agent eine manipulierte Eingabe oder eine falsche Entscheidung in eine operative Auswirkung umwandeln kann.

Häufig gestellte Fragen (FAQ)

Ist MCP sicher in der Softwareentwicklung zu verwenden?
MCP kann sicher verwendet werden, wenn Server, Tools, Autorisierungen, Token, Sandboxes und Protokollierung korrekt konzipiert sind. Das Risiko hängt davon ab, was der Agent tun kann: Das Lesen öffentlicher Dokumentationen, das Ändern von Repositorys, das Abfragen von Datenbanken und das Handeln in der Cloud sind sehr unterschiedliche Szenarien.
Was ist der Unterschied zwischen MCP und einer normalen API-Integration?
Bei einer traditionellen Integration entscheidet der Anwendungscode, wann eine API aufgerufen wird und mit welchen Parametern. In einem agentischen Workflow kann das Modell Tools und Parameter basierend auf dem Kontext auswählen, was spezifische Risiken hinsichtlich Prompt-Injection, Tool-Metadaten, nicht validierter Ausgaben, Autonomie und Audit-Trail einführt.
Eliminiert die menschliche Zustimmung das Risiko des Missbrauchs von Agenten-Tools?
Es reduziert das Risiko nur, wenn die Bestätigung nützliche Informationen anzeigt: aufgerufenes Tool, Identität, Ressource, Umgebung, Parameter und erwartete Auswirkung. Eine generische Bestätigung reicht für Operationen auf Daten, Repositorys, Cloud, Tickets oder Datenbanken nicht aus.
Welche MCP-Tools sind am heikelsten?
Solche, die sensible Daten lesen, auf Geheimnisse zugreifen, Befehle ausführen, Dateien ändern, in Datenbanken schreiben, mit Cloud oder IAM interagieren, Tickets öffnen oder schließen, E-Mails senden, Pipelines starten oder Deployments durchführen.
Wie testet man Prompt-Injection in einem MCP-Workflow?
Man bereitet nicht vertrauenswürdige Inhalte in Tickets, Dokumenten, Issues, E-Mails oder vom Tool abgerufenen Seiten vor und prüft, ob der Agent sie als Daten oder als Anweisungen behandelt. Der Test muss auch die nachfolgenden Tool-Aufrufe beobachten, nicht nur die Textantwort.
Wann ist eine Secure Architecture Review erforderlich?
Wenn MCP Agenten mit Unternehmenssystemen, Cloud, Repositorys, realen Daten, CI/CD oder mehreren Mandanten verbindet. Die Überprüfung muss Identitäten, Autorisierungen, Scopes, Vertrauensgrenzen, Protokollierung, Isolierung und die Verwaltung von Aktionen mit hoher Auswirkung prüfen.
Wann ist eine Code Review erforderlich?
Wenn externe Tools Code, Middleware, Richtlinien, APIs, Validierung, Geheimnisverwaltung, Skripte oder Konfigurationen beeinflussen. Die Code Review hilft zu verstehen, ob der Agent ausgehend von Ausgaben, Prompts oder nicht vertrauenswürdigen Tools anfällige Änderungen vorgenommen hat.

[Callforaction-CR-Footer]

ISGroup Cybersicherheitsberatung