· Security

MCP: Was ein Agent dürfen sollte – und was nicht

Wir betreiben mehrere MCP-Server – für Mail, Tickets, Tenants und Hosting. Einer davon ist absichtlich nicht registriert. Warum das die wichtigste Entscheidung war.

Das Model Context Protocol hat ein Problem gelöst, das jeder kennt, der mit KI-Agenten arbeitet: Der Agent kann reden, aber nichts tun. Mit MCP bekommt er Werkzeuge – und damit bekommt man als Betreiber eine neue Verantwortung. Denn ein Werkzeug, das einmal registriert ist, ruft der Agent auf, wenn er es für richtig hält. Nicht aus Bosheit. Aus Hilfsbereitschaft.

Vier Server, vier Vertrauensstufen

In unserem Alltag laufen mehrere MCP-Server nebeneinander. Ein Server für Mail, Kalender und Teams: Er darf lesen, suchen, Termine anlegen – und Mails senden, mit Anhang. Ein Server für das Ticketsystem: Er liest offene Tickets, prüft Kollisionen und bucht Arbeitszeit. Ein Server für das Hosting: Er lädt ein Paket hoch, liest Logs, rollt zurück. Und ein Server für Microsoft-365-Tenants, der unter anderem MFA zurücksetzen, Passwörter setzen und Sitzungen beenden könnte.

Der vierte ist nicht registriert. Bewusst.

Die Regel dahinter

Wir sortieren Werkzeuge nicht nach Nützlichkeit, sondern nach dem Schaden, den ein Fehlaufruf anrichtet:

  1. Lesen. Mails suchen, Termine finden, Tenant-Einstellungen auslesen. Ein falscher Aufruf kostet Tokens, sonst nichts. Frei.
  2. Schreiben mit Wirkung auf mich. Zeit buchen, Notiz anlegen, Entwurf speichern. Ein Fehler ist sichtbar und korrigierbar. Frei, mit Protokoll.
  3. Schreiben mit Wirkung auf andere. Mail senden, Termin einladen, Deployment auslösen. Hier gilt: Der Agent baut den Entwurf, der Mensch gibt frei. Beim Hosting ersetzt der automatische Rollback die Freigabe.
  4. Eingriffe in Identitäten und Rechte. Passwörter, MFA, Gruppen, Policies auf fremden Tenants. Nicht registriert, bis der Kunde es ausdrücklich will – und dann mit Bestätigungsschritt im Werkzeug selbst.

Was das in der Praxis bedeutet

Die Regel steht nicht nur in einem Dokument, sondern in der Regeldatei, die der Agent bei jedem Aufruf liest: „Kundenmails gehen ausnahmslos erst raus, wenn der Text gesehen und freigegeben wurde. Schreibende Aktionen auf Kundentenants werden vorher angekündigt und bestätigt.“ Ein Agent, der das liest, hält sich daran – und wenn er es einmal nicht täte, ist das Werkzeug, das den größten Schaden anrichten könnte, gar nicht erst da.

Das ist der Kern von Governance für Agenten: nicht die Frage, was technisch geht, sondern welche Tür man bewusst geschlossen lässt.