MCP · 8 Min.
MCP Security 2026: Tool-Zugriffe fuer KI-Agenten sicher gestalten
MCP macht Agenten nützlicher, aber auch mächtiger. Sicherheit entscheidet sich an Tool-Scopes, Identitäten und klaren Freigaben.
SYSTEMS Grafik zu MCP Security: Context -> Tools -> Control. Fokus: Wie verhindert man, dass MCP-Tools zu breiten Zugriff auf Unternehmenssysteme bekommen?
Kurzfassung
MCP verbindet Agenten mit Tools, Datenquellen und Workflows. Sicherheit hängt an Identität, Tool-Scopes, Auth, Consent und Audit. Jeder MCP-Server sollte nur einen klar begrenzten Verantwortungsbereich haben.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Update Mai 2026: Die MCP-Risiken sind konkreter geworden Die aktuellen MCP -Sicherheitsdokumente nennen konkrete Angriffspfade: Confused-Deputy-Probleme in Proxy-Setups, Token-Passthrough als Anti-Pattern, SSRF-Risiken bei serverseitigen Clients, Session-Hijacking, kompromittierte lokale MCP-Server und zu breite Scopes. Das ist kein abstraktes "KI ist riskant". Es sind klassische Security-Probleme, die durch Agenten-Tooling schneller eskalieren.
Die wichtigste Konsequenz fuer Unternehmen: MCP darf nicht als "ein Connector fuer alles" gebaut werden. Jeder Server braucht Scope-Minimierung, exakte Redirect-URI-Pruefung, sichere Consent-Flows, Audit-Logs und eine klare Trennung zwischen Kontext lesen und Aktionen ausfuehren.
Warum MCP mehr ist als Integration Das Model Context Protocol standardisiert, wie AI-Anwendungen Kontext und Werkzeuge nutzen. Für Unternehmen ist das attraktiv: Ein Agent kann CRM, Kalender, Dokumente, Datenbanken oder interne APIs über definierte Schnittstellen erreichen.
Genau darin liegt das Risiko. Sobald ein Agent Tools aufrufen darf, wird MCP zur Berechtigungsschicht. Ein schlecht geschnittener MCP-Server kann mehr Zugriff öffnen, als der Agent für seine Aufgabe braucht.
Tools, Resources und Prompts trennen MCP kennt unterschiedliche Bausteine. Tools führen Aktionen aus. Resources liefern Kontext. Prompts stellen Vorlagen bereit. Diese Trennung ist sicherheitsrelevant.
Ein Agent, der nur Preise nachschlagen soll, braucht vielleicht eine Resource. Er braucht nicht automatisch ein Tool, um Kundendaten zu verändern. Ein Agent, der Termine vorbereitet, braucht vielleicht Kalender-Lesezugriff, aber nicht direkt die Berechtigung, Einladungen an alle Kontakte zu senden.
Das Least-Privilege-Modell für MCP Ein gutes MCP-Setup folgt dem Prinzip minimaler Rechte.
Das Ziel ist nicht, MCP kompliziert zu machen. Das Ziel ist, dass jeder Zugriff erklärbar bleibt.
Pro Server ein klarer Fachbereich. Pro Tool eine konkrete Aktion mit schema-validierten Inputs. Keine geteilten Admin-Zugänge. OAuth oder vergleichbare Authentifizierung für sensible Ressourcen. Tool-Allowlist pro Agent. Freigabe vor Aktionen mit Außenwirkung. Die gefährlichen Tool-Kombinationen Ein einzelnes Tool wirkt oft harmlos. Gefährlich wird die Kombination. Lesen aus einem CRM, Schreiben in E-Mail und Zugriff auf externe Websites können zusammen eine Datenabflusskette bilden.
Deshalb muss Security nicht nur jedes Tool einzeln prüfen, sondern auch Tool-Kombinationen. Welche Pfade entstehen, wenn ein Agent mehrere Werkzeuge nacheinander nutzen darf?
Was fast alle falsch machen Der häufigste Fehler ist ein Universal-MCP-Server mit zu vielen Fähigkeiten. Das ist bequem für Demos, aber schlecht für Produktion. Wenn ein Server Files, CRM, E-Mail und Datenbankzugriff bündelt, wird jeder Agent, der ihn nutzt, schwer kontrollierbar.
Der zweite Fehler ist fehlendes Consent-Design. Nutzer sollten bei riskanten Aktionen verstehen, was der Agent tun will, mit welchen Daten und welchem Ergebnis.
Der SYSTEMS-Blick MCP ist ein starker Standard, aber Standards ersetzen keine Architekturentscheidung. Unternehmen brauchen eine MCP-Landkarte: Welche Server existieren, welche Tools bieten sie an, welche Daten berühren sie und welche Agenten dürfen sie nutzen?
Erst dann wird MCP von einer Demo-Verbindung zu einer belastbaren Tool-Schicht für autonome Arbeit.
