MCP bringt tatsächlich neue Risiken mit sich. Sind Sie bereit?

Bei MCP ist Kontext keine statische Datenmenge, sondern lebendige Erinnerung. Agenten greifen auf diesen gemeinsamen Zustand zurück, um Entscheidungen zu treffen, Schritte zu eskalieren oder sich zurückzuziehen. Verlieren, verzögern oder beschädigen sich Kontextaktualisierungen, führt das zu „Kontextdrift“. Stellen Sie sich einen Staffellauf vor, bei dem jeder Läufer eine andere Karte hat – und niemand merkt es, bis er längst halb von der Strecke abgekommen ist. Bei MCP bedeutet Kontextdrift, dass Agenten mit widersprüchlichen Informationen arbeiten. Das sorgt nicht nur für Verwirrung, sondern für echtes Chaos, weil kritische Entscheidungen auf fehlerhaften Daten basieren und niemand es bemerkt, bevor etwas schiefgeht. Zwei Agenten sind sich uneinig, was eben passiert ist? Das ist kein Streit, sondern ein potenzieller Vorfall.

Traditionelle Systeme haben bei großem Umfang keine solchen Probleme, weil der Kontext meist zentral oder statisch ist, gespeichert entweder als Cookies oder in Sitzungstabellen. MCP macht Abweichungen nicht nur möglich, sondern wahrscheinlich, wenn Sie keine strikte Synchronisation, Integritätsprüfungen und automatisierte Konfliktlösung einbauen. Viel Erfolg bei der Fehlersuche, wenn Ihr Incident-Response-Team gefragt ist.

Schatten-IT kennt jeder – lernen Sie jetzt Schatten-Agenten kennen! MCP lässt Sie Agenten dynamisch teilnehmen, verlassen und gemeinsam genutzte Kontexte aktualisieren. Das bietet Ihnen Leistung und Flexibilität, aber auch eine Chance für böswillige oder falsch konfigurierte Agenten, sich unbemerkt einzuschleichen.

Wenn Sie nicht nachvollziehen, wer teilnimmt, welche Rechte er hat und wann er da war, übergeben Sie Ihre Schlüssel gleich selbst. Schattenakteure können Daten abziehen, schädliche Befehle einspeisen oder unbemerkt Abläufe sabotieren. Ihre Übersicht ist stets veraltet – und Sie bemerken es erst, wenn etwas ausfällt.

Vergiss den Denial-of-Service. Im MCP-Bereich müssen Sie Server nicht lahmlegen, sondern einfach nur die Kontextkanäle überfluten oder stören. Wenn Agenten keinen verlässlichen Kontext austauschen oder abrufen können, blockieren sie, scheitern oder reagieren unvorhersehbar. Ihre Automatisierung im Workflow stoppt, und Geschäftsprozesse bleiben stehen. Das ist keine theoretische Annahme, sondern der nächste logische Schritt für Angreifer, die wissen, wie Ihre Agenten echte Arbeit leisten.

Früher hast du Nutzer, Dienstkonten und vielleicht ein paar Geräte verwaltet. Mit MCP und autonomen Agenten behältst du jetzt einen Haufen (manchmal wilder) digitaler Katzen im Blick, jede mit eigener Authentifizierung, eigenem Lebenszyklus und eigenen Berechtigungen. Onboarding, Rotation und Außerdienststellung der Agenten müssen genauso sorgfältig erfolgen wie bei jedem Benutzer- oder Dienstkonto. Wenn du das ignorierst, öffnest du Tür und Tor für Identitätsdiebstahl, schleichend steigende Rechte und Zombie-Agenten, die lange nach Ablauf ihrer Nutzungszeit aktiv bleiben. Ich weiß, klingt heftig. Viele Organisationen haben weiterhin verwaiste Konten, die seit 1998 nicht gelöscht wurden. Aber zumindest können diese nicht aktiv werden. Zombie-Agenten hingegen schon.

Geht doch mal etwas schief (und das wird passieren), wird es sehr schwer, den Ablauf zu rekonstruieren. Der MCP-Kontext ist flüchtig und verschwindet, sobald er nicht mehr relevant ist. Das macht den Betrieb effizient, erschwert aber die Analyse nach einem Vorfall erheblich. Wenn Sie nicht jede Aktualisierung, jeden Beteiligten und jede Interaktion protokollieren, können Sie nie herausfinden, welcher Agent den vergifteten Apfel übergeben oder welche Kontextänderung die Kette in Gang gesetzt hat.

Ein Grund dafür, dass semantisches Logging und umfassendere Telemetrie zunehmend in Observability-Stacks Einzug halten. Dabei erfassen wir nicht nur zeitgestempelte Verbindungen, sondern benötigen vollständige Kontextinformationen, um Fehler genau zu verstehen.