MCP-Tool-Definitionen als Angriffsfläche: vergiftete Beschreibungen, Shadowing und stille Änderungen

Ziel

Die von einem MCP-Server zurückgegebene Tool-Liste als nicht vertrauenswürdige Eingabe behandeln und erkennen, wenn sie versucht, den Agenten zu beeinflussen, oder sich nach der Genehmigung ändert.

Voraussetzungen

Ein Client oder Gateway, bei dem Tool-Definitionen protokolliert werden können, bevor sie das Modell erreichen; eine Liste der genehmigten Server.

Schritte

1. Die Position der Spezifikation lesen: Tools tragen einen Namen, eine Beschreibung, ein Eingabeschema, ein optionales Ausgabeschema und optionale Annotationen, und Clients MÜSSEN Tool-Annotationen als nicht vertrauenswürdig betrachten, sofern sie nicht von vertrauenswürdigen Servern stammen. Dieselbe Haltung auf Beschreibungen anwenden, die das Modell als Prosa liest.

2. Bei der Genehmigung für jeden Server einen Hash der vollständigen Definition jedes Tools speichern (Name, Beschreibung, Schemata, Annotationen).

3. Bei jeder Verbindung, und immer wenn der Server eine List-Changed-Benachrichtigung sendet, die Hashes neu berechnen. Hat sich eine Definition geändert, die Tools des Servers aussetzen, bis eine Person den Diff überprüft hat.

4. Beschreibungen auf Anweisungen prüfen, die sich an das Modell statt an die nutzende Person richten: Aufforderungen, Dateien zu lesen, die nichts mit dem Zweck des Tools zu tun haben, zusätzliche Daten in Argumente aufzunehmen, dieses Tool einem anderen Server vorzuziehen oder etwas vor der nutzenden Person geheim zu halten.

5. Shadowing erkennen: zwei Server, die Tools mit gleichen oder leicht verwechselbaren Namen anbieten, oder eine Beschreibung eines Servers, die sich auf die Tools eines anderen Servers bezieht. Toolnamen im Client nach Server mit einem Namespace versehen.

6. Prüfen, dass das tatsächliche Verhalten eines Tools zu seinen Annotationen passt; ein als schreibgeschützt annotiertes Tool mit schreibenden Effekten ist ein Grund, den Server zu entfernen.

7. Der nutzenden Person vor einem Aufruf mit Nebeneffekten den Servernamen und die genauen Argumente zeigen, nicht nur die Selbstbeschreibung des Tools.

Erwartetes Ergebnis

Änderungen an Tool-Definitionen werden zu sichtbaren Ereignissen statt zu stillen Aktualisierungen; eine Beschreibung, die versucht, das Modell zu steuern, wird bei der Überprüfung entdeckt statt bei einem Vorfall.

Grenzen und Prüfbasis

Hashing erkennt Änderung, nicht Absicht; eine von Anfang an bösartige Definition benötigt die Überprüfung aus Schritt 4. Ein Server kann sich beim Aufruf trotzdem anders verhalten, als seine Beschreibung sagt — Definitionen schränken serverseitig nichts ein. Lokale Server laufen mit den Rechten der nutzenden Person; die MCP-Sicherheitsanleitung behandelt die Kompromittierung eines lokalen Servers als eigenes Risiko.