Einem MCP-Server nur die Berechtigungen geben, die seine Tools brauchen

Wie ein Server zu weitreichendem Zugriff kommt

Ein typischer Weg zu einem Server mit zu vielen Rechten sieht so aus: Ein Team kapselt für eine Demo eine interne API, gibt dem Server den vorhandenen Schlüssel, und schon kann der Assistent alles, was dieser Schlüssel erlaubt. Typische Anzeichen im Review:

• Ein Servicekonto oder API-Schlüssel für alle Tools, mitunter mit Schreib- oder Adminrechten
• Ein einziger Sammel-Scope, einmal angefordert und nie eingeschränkt
• Tool-Annotationen wie readOnlyHint, die behandelt werden, als würden sie etwas durchsetzen

Annotationen sind Hinweise. Laut MCP-Spezifikation für Tools müssen Clients sie als nicht vertrauenswürdig behandeln, sofern sie nicht von vertrauenswürdigen Servern stammen. Durchgesetzt wird deshalb im Server und in den Systemen dahinter.

Drei Stellen, an denen über Zugriff entschieden wird

Autorisierung ist in MCP optional. Für einen entfernten Server, den Sie über den HTTP-Autorisierungsablauf schützen, behandelt die aktuelle Spezifikation den Server als OAuth-Resource-Server, der Tokens für andere Empfänger ablehnen muss. Ein lokaler Server, der über stdio startet, liegt außerhalb dieses Ablaufs: Laut Spezifikation bezieht er Zugangsdaten aus seiner Umgebung, und die Frage nach dem Umfang verschiebt sich auf das, was Sie dort hinterlegen.

1. 1

   Token-Scopes am MCP-Server

   Scopes legen fest, welche Tool-Gruppen ein Client versuchen darf. Die aktuelle Spezifikation empfiehlt einen minimalen Startumfang und, wenn ein Tool mehr braucht, eine 403-Antwort mit einer insufficient_scope-Challenge, die die nötigen Scopes nennt. Prüfen Sie, ob die eingesetzten Client- und Server-Revisionen diese Erweiterung unterstützen, denn Clients für ältere Revisionen tun das womöglich nicht.

2. 2

   Eine Prüfung in jedem Tool

   Bevor es handelt, prüft das Tool, ob dieser Nutzer diese Aktion auf diesem Datensatz ausführen darf. Die MCP-Sicherheitshinweise nennen es einen häufigen Fehler, Scopes im Token ohne serverseitige Autorisierungslogik für ausreichend zu halten.

3. 3

   Die Zugangsdaten zum Fachsystem

   Die Spezifikation verbietet, das Token des Clients durchzureichen. Der Server ruft das Fachsystem mit eigenen Zugangsdaten von dessen Autorisierungsserver auf, im Auftrag des Nutzers oder als eng begrenzte Service-Identität.

Diese Ebenen greifen nicht automatisch ineinander. Ein gültiges MCP-Token verschafft dem Server keine Rechte in Ihrem CRM. Um dort für den Nutzer zu handeln, braucht es eine eigene Freigabe durch den Autorisierungsserver des CRM mit eigenen Scopes.

Eine Berechtigungsmatrix für einen hypothetischen Server

Angenommen, ein Supportteam möchte seinen Assistenten mit Helpdesk und Abrechnungssystem arbeiten lassen. Vor dem ersten Code würden wir mit den Verantwortlichen beider Systeme eine Matrix wie diese abstimmen. Tool-Namen und Scopes sind erfunden.

• search_tickets: Scope support.read; Helpdesk-Aufruf mit einem vom anfragenden Supportmitarbeiter delegierten Token, die Ergebnisse bleiben also in den Queues, die diese Person ohnehin sieht
• get_invoice_status: Scope billing.read; reine Lese-Service-Identität für die Abrechnungs-API und eine Prüfung, ob die Rechnung zu einem Kunden aus einem Ticket des Aufrufers gehört
• draft_ticket_reply: Scope support.write; veröffentlicht nichts und liefert dem Supportmitarbeiter einen Entwurf zur Bearbeitung
• post_ticket_reply: Scope support.write; delegiertes Helpdesk-Token; der Supportmitarbeiter gibt die genaue Antwort frei, und der Server veröffentlicht sie nur, wenn eine gespeicherte Freigabe genau zu dieser Antwort passt, sodass ein direkter Aufruf oder ein geänderter Text abgewiesen wird
• issue_credit_note: nicht angeboten; bleibt in der Abrechnungsanwendung mit ihrem bestehenden Vier-Augen-Prinzip

Auch die letzte Zeile ist eine Entscheidung. Manche Aktionen lassen sich günstiger außerhalb des Assistenten halten, als sie in ihm abzusichern, und die Matrix zeigt das den Risikoverantwortlichen.

Was jedes Tool prüft, bevor es handelt

Ein breiter Scope wie support.read klärt nicht, ob dieser Aufrufer genau diesen Datensatz öffnen darf. Jedes Tool sollte die Identität des Aufrufers aus dem geprüften Token übernehmen, nie aus einem Argument des Modells, und die Aktion am Datensatz prüfen:

• Prüfungen auf Objektebene für jede ID, auch für IDs aus einem früheren Tool-Ergebnis
• Serverseitige Grenzen für Beträge, Zeiträume und Ergebnisgrößen, unabhängig vom Eingabeschema
• Zustands-Handles, die an den authentifizierten Nutzer gebunden sind, denn der Besitz eines Handles darf nicht als Authentifizierung gelten
• Rate Limits je Nutzer und Tool
• Ein Logeintrag mit Nutzer, Client, Tool, Entscheidung und Zieldatensatz, ohne Tokens oder Secrets

Im Code ist das meist eine Autorisierungsfunktion je Tool, die vor jedem Aufruf des Fachsystems läuft und gegen jede Zeile der Matrix getestet wird.

Was das Fachsystem sehen sollte

Audit-Trails reißen ab, wenn das Fachsystem nicht erkennen kann, wer gehandelt hat. Das ist ein Grund, warum die MCP-Sicherheitshinweise das Weiterreichen von Client-Tokens verbieten. Mit einem delegierten Token sieht der Helpdesk den Supportmitarbeiter und wendet sein eigenes Berechtigungsmodell an. Mit einer Service-Identität sieht er nur den MCP-Server. Dann muss das Log des Servers die Service-Identität und bei interaktiven Aufrufen die Person dahinter festhalten, und die Rechte der Identität dürfen nicht weiter reichen als die Tools, die sie nutzen. Getrennte Identitäten je Server oder Tool-Familie sorgen außerdem dafür, dass der Entzug einer Identität nicht alles andere stilllegt.

Aufwand und Grenzen feiner Berechtigungen

Feinere Scopes bringen mehr Zustimmungsdialoge und Konfiguration im Identity Provider, und manche internen APIs kennen nichts Engeres als einen einzigen Schlüssel. Dann kann ein kleiner Proxy mit eigenen Regeln vor der API stehen, oder das Tool bleibt lesend, bis engere Zugangsdaten verfügbar sind.

Enge Berechtigungen begrenzen den Schaden eines Fehlers oder einer erfolgreichen Prompt Injection, verhindern aber keines von beiden. Freigaben und Prüfungen der Ausgabe verringern das verbleibende Risiko, dass eine erlaubte Aktion schiefgeht, beseitigen es aber nicht.

Sicherheit von Coding-Agenten in Engineering-TeamsMCP-Server-Entwicklung

Ein praktischer erster Schritt: Schreiben Sie die Matrix für die ein oder zwei Tools, die Ihr Team zuerst braucht, und besprechen Sie sie mit den Verantwortlichen jedes betroffenen Systems.