KI-Agenten in MCP absichern: Mandat statt API-Schlüssel

Das Wichtigste in Kürze

MCP regelt, wie ein Agent ein Werkzeug aufruft, nicht ob er es im Einzelfall darf.
OAuth schützt den Zugang, aber nicht die Grenze der einzelnen Handlung.
Ein Gateway mit Entscheid vor der Ausführung prüft jeden Aufruf mit Folgen gegen das Mandat.
Signierte Entscheide und Belege liefern Nachweise, die auch nach einem Vorfall tragen.

Warum MCP eine Sicherheitsfrage ist

Das Model Context Protocol verbindet KI-Anwendungen mit Werkzeugen und Daten: Kalender, Ticketsysteme, Datenbanken, Bestell- und Zahlungsfunktionen. Ein Agent, der über MCP ein Werkzeug wie «Bestellung aufgeben» aufrufen kann, handelt damit im Namen seines Auftraggebers.

Je mehr Werkzeuge ein Agent erreicht, desto grösser wird die Angriffsfläche. Die Frage ist nicht mehr nur, ob ein Agent ein Werkzeug technisch aufrufen kann, sondern ob er es in diesem Moment, für diesen Zweck und in diesem Umfang darf.

Die typischen Risiken

Zu weite Zugänge: Ein Server-Token oder API-Schlüssel erlaubt alles, was das Konto erlaubt, ohne Bezug zur Aufgabe.
Eingeschleuste Anweisungen: Inhalte aus Werkzeugen, Websites oder Dokumenten bringen das Modell zu ungewollten Aufrufen (Prompt Injection).
Manipulierte Werkzeugbeschreibungen: Ein fremder Server beschreibt seine Werkzeuge so, dass das Modell sie falsch einsetzt.
Verwechselte Stellvertretung: Ein Server handelt mit eigenen Rechten für einen Nutzer, der diese Rechte nicht hat.
Fehlende Nachweise: Nach einem Vorfall lässt sich nicht zeigen, welcher Aufruf erlaubt war.

Was die Spezifikation regelt

Die MCP-Spezifikation sieht für den Zugriff auf geschützte Server eine Autorisierung auf Basis von OAuth vor. Damit lässt sich festlegen, welcher Client auf welchen Server zugreifen darf und mit welchen Berechtigungen. Das ist ein wichtiger Baustein.

OAuth beantwortet aber die Frage nach dem Zugang, nicht die nach der einzelnen Handlung. Ein Token mit dem Recht «Bestellungen schreiben» unterscheidet nicht zwischen einer Bestellung über 50 und einer über 50'000 Franken. Diese Unterscheidung muss eine zusätzliche Ebene treffen.

Das Muster: Entscheid vor der Ausführung

Bewährt hat sich ein Gateway zwischen Agent und Werkzeug. Bevor ein Aufruf mit Folgen ausgeführt wird, prüft eine Entscheidstelle ausserhalb des Modells den Aufruf gegen das Mandat: Ist der Handlungstyp erlaubt, liegt der Betrag im Rahmen, ist die Gegenpartei zugelassen, ist das Mandat noch gültig?

Der Agent ruft das Werkzeug über das Gateway auf.
Die Entscheidstelle prüft den Aufruf gegen das Mandat und signiert einen Entscheid: erlaubt, abgelehnt oder Eskalation an einen Menschen.
Nur bei «erlaubt» führt das Gateway den Aufruf aus.
Das Ergebnis wird als Ausführungsbeleg an eine Beleg-Kette angehängt.

Ein solches Gateway bietet zum Beispiel die Referenzimplementierung Mandact (vom Betreiber von KYA).

Minimale Befugnis pro Werkzeug

Der zweite Baustein ist minimale Befugnis. Statt einem Agenten alle Werkzeuge eines Servers freizugeben, erhält er für jede Aufgabe genau die Werkzeuge und Grenzen, die er braucht. Lesende Werkzeuge brauchen andere Regeln als schreibende, Werkzeuge mit Zahlungsfolgen strengere als solche ohne.

Eine einfache Einteilung hilft: Werkzeuge ohne Folgen laufen frei, Werkzeuge mit begrenzten Folgen laufen mit Entscheid, Werkzeuge mit grossen Folgen verlangen zusätzlich die Freigabe eines Menschen. So bleibt der Agent nützlich, ohne dass jede Anweisung im Kontext unmittelbar Wirkung entfaltet.

Nachweise, die auch später tragen

Nach einem Vorfall zählt, was belegt ist. Ein Gateway, das Entscheide und Belege signiert, liefert genau die Nachweise, die Revision, Kunden oder Gerichte verlangen: Welches Mandat galt, wie wurde entschieden, was wurde ausgeführt, und wann.

KYA prüft diese Nachweise unabhängig, lokal im Browser oder als Paket in der eigenen Pipeline. Der Prüfschein zeigt Schritt für Schritt, was belegt ist und was nicht. Zum Entwicklerbereich.

Ein Beispiel aus dem Einkauf

Ein Assistent im Einkauf darf über einen MCP-Server Bestellungen bei drei Lieferanten aufgeben, je bis 2'000 Franken. Eine Lieferanten-Website enthält die versteckte Anweisung, zusätzlich bei einem unbekannten Anbieter zu bestellen. Das Modell schlägt den Aufruf vor; das Gateway prüft ihn gegen das Mandat, stellt fest, dass der Anbieter nicht zugelassen ist, und lehnt ab. Der abgelehnte Entscheid wird festgehalten und fällt in der Überwachung auf.

Häufige Fragen

Reicht OAuth für die Sicherheit von MCP?

OAuth regelt den Zugang eines Clients zu einem Server. Ob ein einzelner Aufruf im konkreten Umfang erlaubt ist, braucht eine zusätzliche Prüfung, etwa gegen ein Mandat mit Grenzen.

Wo sollte die Entscheidstelle laufen?

Ausserhalb des Modells und unabhängig vom Agenten, zum Beispiel in einem Gateway vor den Werkzeugen. Ein Agent, der selbst über seine Befugnis entscheidet, bietet keinen Schutz gegen Irrtum oder Manipulation.

Muss jeder Werkzeugaufruf geprüft werden?

Nicht jeder. Lesende Aufrufe ohne Folgen können frei laufen. Aufrufe mit Folgen, etwa Bestellungen, Zahlungen oder Änderungen an Daten, sollten vor der Ausführung entschieden werden.

Wie prüfe ich die Nachweise eines MCP-Gateways?

Mit KYA, im Browser oder über den Prüfkern in der eigenen Pipeline. Er prüft Mandat, Entscheid und Beleg nach denselben zehn Schritten.

Was ist das Confused-Deputy-Problem bei MCP?

Ein Server handelt mit seinen eigenen, weiten Rechten für einen Nutzer, der diese Rechte nicht hat. Ein Mandat pro Nutzer und Aufgabe verhindert, dass der Server mehr tut, als der Nutzer darf.

Brauche ich für jedes Werkzeug ein eigenes Mandat?

Nicht zwingend. Ein Mandat kann mehrere Werkzeuge abdecken, sollte aber auf eine Aufgabe zugeschnitten sein und Grenzen für Werkzeuge mit Folgen enthalten.

Gibt es fertige Gateways für MCP?

Es gibt verschiedene Angebote, darunter die Referenzimplementierung des Betreibers von KYA. Entscheidend ist, dass Entscheide signiert und Belege prüfbar sind.

Quellen

Model Context Protocol: Spezifikation: https://modelcontextprotocol.io/specification
OWASP Top 10 für LLM-Anwendungen: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
NIST: Least Privilege: https://csrc.nist.gov/glossary/term/least_privilege