MCP macht KI-Coding-Agenten zu angebundenen Systemen

MCP ist einer der Gründe, warum KI-Coding-Agenten wirklich nützlich werden.

Es ist auch einer der Gründe, warum Teams sie ernster nehmen müssen.

Das Model Context Protocol gibt KI-Assistenten eine standardisierte Möglichkeit, sich mit externen Tools und Kontext zu verbinden. In der Praxis können das Repositories, Dokumentation, Ticketsysteme, Datenbanken, Browser, Cloud-Systeme, interne APIs, lokale Dateien und Kommandozeilen-Workflows sein. Für Entwickler, die mit Tools wie Cursor, Claude Code, VS Code, Codex-ähnlichen Agenten oder internen Assistenten arbeiten, kann MCP aus einem generischen Chatbot ein Werkzeug machen, das eine echte Arbeitsumgebung versteht und darin handeln kann.

Das ist mächtig.

Es verändert aber auch das Sicherheitsmodell.

Ein Coding-Assistent, der nur eine Funktion in einem Textfeld vorschlägt, ist eine Art von Risiko. Ein Coding-Agent, der Tools aufrufen, lokalen Zustand prüfen, Systeme abfragen, Tickets aktualisieren, Befehle ausführen oder interne Daten erreichen kann, ist eine andere Art von Risiko. Dann lautet die Frage nicht mehr nur: “Ist der erzeugte Code gut?”

Die Frage lautet:

Womit ist dieser Agent verbunden, und was darf er tun?

Deshalb ist die aktuelle Diskussion über MCP-Sicherheit für Gründer, CTOs und Produktteams relevant. Die nützliche Version von KI-unterstützter Entwicklung ist kein einsames Prompt-Fenster. Sie ist ein integrierter Workflow. Aber Integration bedeutet Befugnis. Befugnis braucht Grenzen.

MCP ist nicht nur Kontext

Das Wort “Kontext” lässt MCP harmlos klingen.

Kontext klingt nach Dokumentation, Codeausschnitten oder hilfreichem Hintergrundwissen. Das ist ein Teil der Geschichte, aber nicht die ganze Geschichte. MCP-Server können Tools bereitstellen. Tools können Aktionen ausführen. Manche Aktionen sind nur lesend. Andere verändern Zustand.

Dieser Unterschied ist entscheidend.

Ein MCP-verbundener Assistent kann zum Beispiel:

ein Repository durchsuchen;
interne Dokumentation lesen;
ein Datenbankschema inspizieren;
eine Browser-Session öffnen;
ein Jira-Ticket erstellen;
Logs abfragen;
ein lokales Skript ausführen;
eine Migration erzeugen;
eine Cloud-API ansprechen;
kundennahen Datenbestand abrufen;
Tests oder Package-Befehle ausführen.

Jede einzelne Fähigkeit kann sinnvoll sein.

Die kombinierte Fähigkeit kann deutlich größer sein, als das Team denkt.

Genau dieses Muster ist für Produktionsreife relevant. KI-Tools kommen oft über Bequemlichkeit ins Team. Ein Entwickler fügt einen Connector hinzu, weil er Zeit spart. Ein anderer ergänzt einen lokalen MCP-Server für eine Datenbank. Jemand verbindet Browser-Automatisierung. Ein Team testet eine Integration ins Ticketsystem. Keine dieser Entscheidungen wirkt einzeln dramatisch.

Aber nach ein paar Wochen kann der Assistent eine relevante Landkarte des Produkts, des Workflows und der umliegenden Systeme besitzen.

Das ist nicht mehr nur bessere Autovervollständigung.

Das ist ein angebundener Akteur in der Delivery-Umgebung.

Das Sicherheitsproblem ist architektonisch

Es ist verlockend, MCP-Sicherheit als Prompt-Problem zu behandeln.

Bessere Anweisungen schreiben. Dem Assistenten sagen, dass er vorsichtig sein soll. Ihn bitten, keine Secrets preiszugeben. Vor gefährlichen Aktionen eine Warnung anzeigen. All das hilft, reicht aber nicht.

Das tiefere Problem ist architektonisch: Welche Systeme sind erreichbar, welche Tools sind verfügbar, welche Rechte haben diese Tools, welche Daten fließen in Prompts und welche Aktionen brauchen menschliche Freigabe?

Wenn ein Agent ein sensibles Tool erreichen kann, ist der Prompt nur eine Verteidigungsschicht. Die sicherere Grundannahme lautet: Prompts können verwirrt werden, Kontext kann manipuliert werden, und Tool-Beschreibungen können Teil der Angriffsfläche werden. Aktuelle Sicherheitsforschung rund um MCP schaut genau dort hin: clientseitige Prompt Injection, bösartige oder kompromittierte Tool-Beschreibungen, zu breite Rechte und unklare Vertrauensgrenzen zwischen Servern, Clients und Modellkontext.

Das heißt nicht, dass Teams MCP vermeiden sollten.

Es heißt, dass MCP wie Integrationsarchitektur behandelt werden sollte, nicht wie eine harmlose Editor-Einstellung.

Wenn ein Unternehmen eine Anwendung an Stripe, DATEV, Salesforce, Google Workspace oder ein internes ERP anschließt, denkt es normalerweise über Rechte, Audit-Logs, Credentials, Datenflüsse und operative Verantwortung nach. MCP verdient dieselbe Art von Denken, skaliert auf das tatsächliche Risiko.

Für einen wegwerfbaren Prototyp kann ein großzügiges Setup okay sein.

Für ein Produkt mit Kundendaten, internen Workflows, Abrechnung, Betrieb oder regulierten Informationen ist es das nicht.

Tool-Zugriff schafft eine Lieferkette

MCP schafft auch eine neue Form von Lieferkette.

Klassische Software-Supply-Chain-Risiken betreffen Packages, Dependencies, Build-Systeme, Container, Infrastruktur und Deployment-Pfade. MCP ergänzt eine weitere Schicht: Tool-Server, die ein KI-Assistent während der Entwicklung aufrufen kann.

Diese Schicht kann First-Party-Server, Drittanbieter-Server, Open-Source-Server, lokale Skripte, Cloud-Dienste und Vendor-Connectoren enthalten. Manche sind stabil und gut dokumentiert. Manche sind experimentell. Manche werden schnell von einem Entwickler ergänzt, der lokal ein Problem lösen möchte.

Die Frage ist nicht, ob jeder MCP-Server gefährlich ist.

Die Frage ist, ob das Team weiß, welche Server existieren.

Ein nützliches MCP-Inventar beantwortet einfache Fragen:

Welche MCP-Server sind freigegeben?
Wer pflegt sie?
Welche Tools stellen sie bereit?
Sind diese Tools nur lesend oder verändern sie Zustand?
Welche Credentials nutzen sie?
Welche Repositories, Dateien, APIs oder Datenbanken erreichen sie?
Werden Tool-Aufrufe protokolliert?
Kann Zugriff schnell entzogen werden?
Sind Server gepinnt, geprüft und bewusst aktualisiert?
Welche Server dürfen in produktionsnahen Workflows verwendet werden?

Wenn niemand diese Fragen beantworten kann, hat das Team noch kein Betriebsmodell. Es hat ein Experiment.

Experimente sind in Ordnung. Sie sollten aber als Experimente erkennbar bleiben.

Der Fehler entsteht, wenn Prototypen-Bequemlichkeit stillschweigend Teil des normalen Delivery-Prozesses wird.

Das eigentliche Risiko ist unsichtbare Befugnis

Die meisten Teams kennen sichtbare Befugnis.

Eine Admin-Konsole ist sichtbar. Ein Produktionsdatenbank-Credential ist sichtbar. Ein CI-Deployment-Token ist sichtbar. Eine Cloud-IAM-Policy ist sichtbar, auch wenn sie manchmal mühsam zu verstehen ist.

MCP-Befugnis kann weniger offensichtlich sein, weil sie durch einen Assistenten vermittelt wird. Ein Entwickler bittet um Hilfe. Der Assistent ruft ein Tool auf. Das Tool nutzt Credentials. Das Ergebnis erscheint im Chat oder Editor. Für den Entwickler fühlt sich das wie Bequemlichkeit an, nicht wie eine Zugriffsentscheidung.

Genau dort versteckt sich das Risiko.

Beispiele:

Ein Dokumentationsserver stellt private Architekturnotizen bereit, die das Unternehmen nicht verlassen sollten.
Ein Datenbankserver erlaubt Schema-Inspektion, enthält aber versehentlich Beispieldaten mit Kundenbezug.
Ein Browser-Automatisierungsserver nutzt authentifizierte Sessions.
Ein Repository-Server macht Environment-Dateien oder Deployment-Skripte sichtbar.
Ein Ticketsystem-Connector schreibt interne Kommentare, die später Kundenseite erreichen.
Ein lokaler Command-Server lässt den Agenten Package-Skripte mit Seiteneffekten ausführen.

Dafür braucht es keine Science-Fiction-Szenarien.

Das sind gewöhnliche Integrationsfehler mit einer schnelleren Oberfläche.

Der Agent muss nicht bösartig sein, damit das relevant wird. Er muss nur zu breit angebunden, zu wenig begrenzt oder durch feindlichen Kontext fehlgeleitet sein.

Wie ein vernünftiges MCP-Betriebsmodell aussieht

Teams brauchen keine 60-seitige Policy, bevor sie MCP nutzen.

Sie brauchen aber einige klare Regeln.

1. Mit einem Inventar beginnen

Listen Sie jeden MCP-Server auf, den das Team nutzt.

Dazu gehören lokale Server, Vendor-Connectoren, experimentelle Server und alles, was in Editoren oder Agenten-Tools konfiguriert ist. Wenn die Liste überrascht, ist das eine nützliche Erkenntnis. Der erste Schritt ist Sichtbarkeit.

Für jeden Server sollte festgehalten werden, was er lesen kann, was er ändern kann, welche Credentials er nutzt und wer verantwortlich ist.

2. Lesende Tools von Aktionstools trennen

Dokumentation zu lesen ist nicht dasselbe wie ein Ticket zu ändern, einen Befehl auszuführen oder eine Datenbank zu berühren.

Diese Fähigkeiten sollten unterschiedlich behandelt werden. Lesende Tools können oft breiter erlaubt werden. Zustand verändernde Tools brauchen stärkere Prüfung, klarere Logs und engere Rechte.

Dieser Unterschied sollte in der Konfiguration und in den Arbeitsgewohnheiten sichtbar sein. Wenn sich jedes Tool im Assistenten gleich anfühlt, wird der Unterschied unterschätzt.

3. Least Privilege anwenden

Ein Agent, der bei einer Frontend-Implementierung hilft, braucht keinen Zugriff auf Produktionsinfrastruktur. Ein Agent, der ein Datenbankschema erklärt, braucht keine Schreibrechte. Ein Agent, der eine Migration entwirft, muss sie nicht in Produktion ausführen können.

Least Privilege ist keine Bürokratie. Es ist die Methode, mit der nützliche Automatisierung nicht zur unnötigen Schadensfläche wird.

4. Prompts und Tool-Ausgaben als nicht vertrauenswürdig behandeln

MCP-verbundene Agenten verarbeiten oft externe Inhalte: Ticketbeschreibungen, Webseiten, Dokumente, Logs, Package-Metadaten, READMEs und Tool-Beschreibungen.

Ein Teil dieser Inhalte kann Anweisungen enthalten. Der Assistent kann aufgefordert werden, Regeln zu ignorieren, Daten offenzulegen oder Tools anders zu nutzen, als der Nutzer es beabsichtigt hat. Teams sollten davon ausgehen, dass Prompt Injection Teil der Umgebung ist, und entsprechend designen.

Praktische Kontrollen sind Bestätigungen für sensible Tool-Aufrufe, eingeschränkte Tool-Verfügbarkeit, klare Trennung zwischen Daten und Anweisungen sowie Logs, die zeigen, welche Tool-Aufrufe stattgefunden haben.

5. Riskante Aktionen explizit freigeben

Der Agent kann vorschlagen. Er kann vorbereiten. Er kann erklären. Er kann risikoarme Entwicklungsaufgaben auch ausführen.

Manche Aktionen brauchen aber ein Gate:

produktionsnahe Konfiguration ändern;
destruktive Befehle ausführen;
Authentifizierung, Abrechnung oder Tenant-Isolation verändern;
in kundenseitige Systeme schreiben;
Credentials mit breitem Zugriff nutzen;
Tools aufrufen, die echte Geschäftsdatensätze verändern.

Freigabe sollte nicht vage sein. Der Nutzer sollte wissen, welches Tool gegen welches Ziel mit welcher erwarteten Wirkung ausgeführt wird.

6. Genug loggen, um den Ablauf zu rekonstruieren

Wenn ein MCP-verbundener Workflow etwas Wichtiges ändert, sollte das Team die Abfolge rekonstruieren können.

Welcher Assistent wurde genutzt? Welcher Server stellte das Tool bereit? Welche Tool-Aufrufe liefen? Welche Credentials waren beteiligt? Welche Dateien oder Systeme wurden geändert? Welcher Mensch hat die Aktion freigegeben?

Das ist keine Überwachung um der Überwachung willen. Es geht darum, debuggen, auditieren und wiederherstellen zu können.

Wenn ein Vorfall passiert, ist “die KI hat etwas gemacht” keine ausreichende Root Cause.

Was das für Produktteams bedeutet

Die Geschäftsentscheidung lautet nicht, ob MCP gut oder schlecht ist.

Die Geschäftsentscheidung lautet, wo MCP in das Software-Delivery-Modell gehört.

Für viele Teams eignet sich MCP gut für risikoarme Beschleunigung:

Repository-Suche;
interne Dokumentationssuche;
lokale Entwicklungsskripte;
Testläufe;
Codebase-Erklärung;
Ticket-Zusammenfassungen;
Dependency-Recherche;
Abruf von Architekturnotizen.

Solche Workflows können echte Zeit sparen, ohne dem Agenten breite Befugnis zu geben.

Risikoreichere Workflows brauchen mehr Design:

Datenbankzugriff;
Tools mit Kundendaten;
Cloud-Infrastruktur;
Deployment-Systeme;
Abrechnungs- und Rechnungssysteme;
Support-Inboxen;
Browser-Sessions mit authentifiziertem Zugriff;
interne Admin-Panels.

Der Unterschied ist nicht, ob KI beteiligt ist. Der Unterschied ist, ob echte Systeme, echte Daten oder echte geschäftliche Verpflichtungen betroffen sind.

Dort beginnt Produktionsreife.

MCP ist ein Reifetest

MCP ist nützlich, weil es KI-Assistenten weniger isoliert macht.

Genau deshalb testet es die Reife eines Teams.

Ein unreifer Einführungsweg lautet: alles verbinden, schnell vorangehen, darauf vertrauen, dass der Assistent vorsichtig ist.

Ein reifer Einführungsweg lautet: die richtigen Dinge verbinden, erlaubte Aktionen definieren, riskante Operationen explizit machen, Logs halten, Server prüfen, Umgebungen trennen und Wiederherstellung einplanen.

Der zweite Weg ist geschäftlich nicht langsamer. Er verhindert die teure Version von Geschwindigkeit: schnell liefern und danach Wochen damit verbringen, Zugriffe, Datenabflüsse, gebrochene Workflows oder unklare Verantwortung zu entwirren.

Für Mittelstandsteams, SaaS-Gründer und Produktverantwortliche ist das die praktische Perspektive. MCP ist nicht nur ein Entwickler-Spielzeug. Es ist Teil der Architektur von KI-unterstützter Arbeit. Gut designt kann es Teams schneller und konsistenter machen. Nebenbei eingeführt kann es aus einem nützlichen Assistenten eine ungeprüfte Integrationsschicht machen.

Die Sicht von McDougall Digital ist einfach: KI-Coding-Agenten sollten gute Engineering-Praktiken leichter machen, nicht umgehen.

Deshalb gehört MCP in dieselbe Diskussion wie Rechte, Umgebungen, Review-Pfade, Logs, Datenschutz und operative Verantwortung. Nicht, weil das Protokoll schlecht ist, sondern weil der angebundene Workflow mächtig ist.

Die Teams, die mit KI-Coding gewinnen, sind nicht die Teams, die die meisten Tools verbinden. Es sind die Teams, die genau wissen, welche Tools sie verbunden haben, warum sie sie verbunden haben und was passiert, wenn ein Agent versucht, sie zu benutzen.