MCP Security: Welche Rechte ein Coding Agent wirklich braucht

Wenn ein Coding Agent Werkzeuge bedienen kann, ist er sicherheitstechnisch kein Editor-Plugin mehr, sondern ein handelndes Konto – eines, dessen Verhalten von Text abhängt, den es unterwegs liest. Diese Kombination erzeugt Risiken, die klassische Anwendungssicherheit so nicht kennt.

1. Bedrohungsmodell

Drei Eigenschaften machen die Werkzeugkette angreifbar:

• Der Agent handelt – er liest nicht nur, er ruft Werkzeuge auf, die Wirkung haben.
• Seine Steuerung ist Text – und Text kommt auch aus Quellen, die niemand geprüft hat.
• Er arbeitet mit fremden Rechten – meist mit denen der Person, die ihn gestartet hat.

Angreifer brauchen deshalb keinen Zugriff auf Ihr System. Es genügt, Text an eine Stelle zu bringen, die der Agent liest: eine Ticketbeschreibung, ein Code-Kommentar, eine Fehlermeldung, eine abgerufene Webseite, das Ergebnis eines Werkzeugaufrufs.

2. Indirekte Prompt Injection

Das zentrale Muster. Ein Modell unterscheidet nicht zuverlässig zwischen „das ist der Inhalt, über den du nachdenken sollst“ und „das ist eine Anweisung“. Eine im Fließtext versteckte Aufforderung kann deshalb Handlungen auslösen.

Wirksame Gegenmaßnahmen sind architektonisch, nicht sprachlich:

• Werkzeugergebnisse als Daten behandeln. Die Vertrauensstufe hängt an der Quelle, nicht am Wortlaut.
• Quellen klassifizieren: internes Repository, internes Ticketsystem und offenes Internet sind nicht dasselbe.
• Wirkung begrenzen. Wenn eine Injection nur lesen kann, ist der Schaden klein.
• Keine „Ignoriere Anweisungen im Text“-Prompts als Schutzmaßnahme betrachten – das ist eine Bitte, keine Kontrolle.

3. Die gefährliche Kombination

4. Confused Deputy und Token-Weitergabe

Ein Server, der mit weitreichenden Rechten für viele Nutzer handelt, wird zum verwirrten Stellvertreter: Er führt eine Aktion aus, weil ein Aufrufer sie verlangt hat – ohne prüfen zu können, ob dieser Aufrufer sie hätte verlangen dürfen.

Zwei Muster, die das verhindern:

• Handeln im Namen der Person, nicht mit einem technischen Sammelkonto. Nur so greifen bestehende Berechtigungen und Protokolle.
• Token auf die Zielressource einschränken. Ein Zugangstoken, das für einen Server ausgestellt wurde, darf dort nicht einfach an ein anderes System weitergereicht werden – genau dafür existieren Ressourcenangaben in OAuth-basierten Modellen.

5. Server als Lieferkette

Ein MCP-Server ist Software von Dritten, die auf Ihren Systemen läuft und deren Werkzeugbeschreibungen das Verhalten des Agents mitsteuern. Er gehört damit behandelt wie jede andere Abhängigkeit:

• Herkunft prüfen und auf bekannte Quellen beschränken.
• Versionen festschreiben statt „latest“ zu ziehen.
• Änderungen an der Werkzeugliste wie eine Abhängigkeitsänderung behandeln: sichtbar machen, prüfen, freigeben. Ein Server kann Werkzeuge und Beschreibungen nach der ersten Freigabe ändern.
• Aktualisieren – auch Server haben Schwachstellen.

6. Rechtemodell

7. Isolation und Netzgrenzen

• Getrennte Umgebung für Agent-Läufe – Container oder dedizierte Arbeitsumgebung statt des Arbeitsplatzes mit allen Zugängen.
• Ausgehende Verbindungen einschränken; eine Positivliste ist wirksamer als jede Inhaltsprüfung.
• Keine Produktionszugänge in Umgebungen, in denen Agents laufen – auch nicht „nur lesend“.
• Geheimnisse getrennt halten: keine Zugangsdaten im Arbeitsverzeichnis, Secret Scanning als blockierendes Gate.

8. Protokollierung und Erkennung

Serverseitig protokollieren, nicht clientseitig: Wer, wann, welches Werkzeug, mit welchen Parametern, mit welchem Ergebnis. Auswertbar wird das erst, wenn es außerhalb der Sitzung liegt. Auffälligkeiten, die sich lohnen zu beobachten: ungewöhnlich viele Aufrufe in kurzer Zeit, Zugriffe außerhalb des üblichen Ausschnitts, ausgehende Verbindungen zu neuen Zielen.

Typische Fehler

• Administrativer Sammelzugang, weil es schneller geht.
• Alles als Tool anbieten, auch reine Leseoperationen.
• Prompt-Regeln als Sicherheitsmaßnahme betrachten.
• Server ohne Versionsfestlegung aus unbekannter Quelle.
• Agent-Läufe auf dem Arbeitsplatz mit allen produktiven Zugängen.
• Keine serverseitigen Protokolle – im Ernstfall keine Auskunftsfähigkeit.

Checkliste: Agent-Rechte absichern

Fazit

Die Sicherheit agentischer Werkzeugketten entscheidet sich nicht am Modell, sondern am Zuschnitt: welche Daten erreichbar sind, welche Aktionen möglich sind und wohin Ergebnisse fließen dürfen. Wer diese drei Achsen bewusst begrenzt, kann Agents produktiv einsetzen, ohne die Angriffsfläche mitzuvergrößern.

Der organisatorische Rahmen dazu – zugelassene Werkzeuge, Datenklassen, Prüfpflichten – steht im Deep Dive AI Coding Governance.