Wie Änderungen an MCP-Tool-Listen eine laufende Sitzung verändern

Eine laufende MCP-Sitzung sollte kein Vertrauen für Tools erben, die bei ihrer Freigabe noch nicht existierten. Tool-Erkennung wirkt wie harmlose Infrastruktur, bis ein Agent eine neu verfügbare Aktion mit demselben Gesprächsfluss und denselben dahinterliegenden Zugangsdaten aufrufen kann. Ab diesem Punkt hat sich die Aktionsoberfläche verändert, auch wenn niemand den Prompt geändert hat.

Ich habe erlebt, wie Ingenieure einen Programmierlauf für Repository-Arbeit freigaben und ihn dann weiterlaufen ließen, während ein Connector eine Bereitstellungs- oder Ticket-Aktion erhielt. Die übliche Begründung lautet: „Der Agent hatte nur die Tools, die er brauchte.“ In dem Moment, in dem sich die Liste ändert, stimmt dieser Satz nicht mehr. Ein langlebiger Agent verdient weniger beiläufiges Vertrauen als ein kurzer Kommandozeilenprozess, nicht mehr.

Meine Regel ist einfach: Vergleichen Sie die Tool-Übersicht bei jeder Änderung, ordnen Sie die Änderung der Berechtigung ein und starten Sie einen neuen Agentenlauf, wenn eine Änderung eine Aktionsoberfläche hinzufügt oder wesentlich verändert. Machen Sie daraus kein Projekt für Richtlinienformulierung. Es geht darum, eine menschliche Entscheidung zu bewahren, die noch dieselbe Bedeutung hat wie bei ihrer ursprünglichen Freigabe.

Eine Tool-Liste ist eine Übersicht über Berechtigungen

Eine MCP-Tool-Liste ist keine Speisekarte. Sie umfasst die Vorgänge, die ein Agent vorschlagen und je nach Client auch ausführen darf. Jeder Eintrag verbindet einen Namen, eine Beschreibung, ein Eingabeschema und ein Verhalten, das oft einen Dienst erreicht, den das Modell nicht direkt prüfen kann.

Die Spezifikation des Model Context Protocol beschreibt Tools als vom Modell gesteuerte Funktionen, die ein Server bereitstellt. Diese Formulierung ist wichtig. Ein Client kann Beschreibungen für das Modell anzeigen, doch die Beschreibung ist keine Sicherheitsgrenze. Das Schema und das serverseitige Verhalten entscheiden, was der Aufruf bewirken kann.

Bei der Prüfung einer Übersicht stelle ich zu jedem Tool fünf Fragen:

• Welche Daten kann dieser Aufruf lesen?
• Welchen Zustand kann dieser Aufruf verändern?
• Wohin kann seine Ausgabe gelangen?
• Welche Zugangsdaten oder welchen Host nutzt es?
• Können seine Argumente den Umfang über das hinaus erweitern, was der Name vermuten lässt?

Ein Tool namens get_build_status kann schreibgeschützt und eng begrenzt sein. Ein Tool namens request kann dagegen überall dort lesen, schreiben und Daten senden, wo seine Zugangsdaten es erlauben. Der erste Name lässt sich leicht freigeben, der zweite leicht unterschätzen.

In der Praxis wird Tool-Erkennung oft mit Berechtigung vermischt. Die Erkennung teilt dem Agenten mit, was verfügbar ist. Die Berechtigung entscheidet, ob der Agent es nutzen darf. Wenn Sie diese beiden Dinge zusammenlegen, wird eine Aktualisierung mitten in der Sitzung zu einer ungeprüften Berechtigungsänderung.

Neue Tools verdienen die gründlichste Prüfung

Ein hinzugefügtes Tool erfordert einen neuen Lauf, wenn es einen neuen Weg zu Daten, Befehlen oder einer externen Partei schafft. Das gilt auch dann, wenn das neue Tool mit Arbeit zusammenhängt, die der Agent bereits erledigt.

Angenommen, ein Agent startet mit repo_search, read_issue und create_branch. Mitten in der Sitzung fügt der Server post_comment hinzu. Manche nennen das eine kleine Erweiterung, weil der Agent bereits Issues liest. Das ist nicht klein. Ein Issue zu lesen ist ein privater Abruf. Einen Kommentar zu posten, sendet vom Modell erzeugten Text an Menschen, die darauf reagieren könnten, und kann Details aus der Unterhaltung oder dem Arbeitsbereich offenlegen.

Behandeln Sie diese Ergänzungen grundsätzlich als wesentlich:

• Jede Aktion, die schreibt, löscht, bereitstellt, veröffentlicht oder eine Nachricht sendet.
• Jedes allgemeine Request-Tool, dessen Ziel über ein Argument bestimmt wird.
• Jede Shell- oder SSH-Aktion, auch wenn sie als Diagnose beworben wird.
• Jede Aktion, die ein neues Repository, Konto, einen neuen Host oder eine neue Datenkategorie liest.
• Jede Aktion, die Zugangsdaten mit größerem Umfang als die bestehenden Tools nutzt.

Auch eine neue Leseaktion kann einen Neustart erfordern. Ingenieure achten manchmal nur auf Schreibvorgänge und geben dann ein Export-Tool frei, das Kundendaten, Build-Protokolle oder in der Konfiguration gespeicherte Geheimnisse lesen kann. Datenabfluss beginnt mit einem Lesezugriff.

Es gibt enge Ausnahmen. Einen zweiten Namen für einen bereits genehmigten, fest definierten Vorgang hinzuzufügen, kann innerhalb des Laufs bleiben, wenn Sie geprüft haben, dass derselbe Dienst mit denselben Argumenten und Zugangsdaten erreicht wird. Das kommt so selten vor, dass ich die Ausnahme nicht allein aufgrund einer Release-Notiz gewähre.

Entfernte Tools sind ein Signal, kein sauberer Widerruf

Ein entferntes Tool sollte Sie dazu bringen, den Client zu prüfen. Sein Verschwinden aus einer neuen Liste beweist nicht, dass der laufende Agent den Zugriff darauf verloren hat. Der Server kann seine angebotene Liste geändert haben, während der Client weiterhin eine frühere Liste im Speicher hält. Ein anderer Client aktualisiert sich möglicherweise sofort. Aus der Entfernung allein lässt sich das Verhalten nicht sicher ableiten.

Das ist bei der Auswertung von Vorfällen wichtig. Ein Team sieht, dass delete_environment vom Server entfernt wurde, nimmt an, die Gefahr sei vorbei, und lässt eine alte Sitzung weiterlaufen. Wenn dieser Client die Tool-Definition bereits aufgelöst hat, kann er den Aufruf weiterhin versuchen. Der Server sollte ihn ablehnen, wenn die Implementierung den Handler entfernt hat, doch angebotene Erkennung und tatsächliche Ausführung sind getrennte Dinge. Prüfen Sie beides.

Pausieren Sie den Agenten und halten Sie die Übersicht vor und nach der Änderung fest. Testen Sie die entfernte Aktion in einer Nicht-Produktionsumgebung, falls Ihnen der Server gehört, oder beenden Sie die Sitzung, falls nicht. Fragen Sie nicht das Modell, ob es das Tool noch hat. Eine Modellantwort beschreibt ihren Kontext zu ungenau, um jemals eine Berechtigungsfrage entscheiden zu können.

Eine Entfernung hat noch eine alltäglichere Folge: Eine Tool-Umbenennung kann zunächst wie eine Entfernung und eine Ergänzung erscheinen. Deshalb vergleichen Sie Definitionen, statt Namen zu zählen.

Umbenennungen brauchen einen Nachweis der Gleichwertigkeit

Eine Umbenennung kann rein kosmetisch sein, aber auch einen weiter gefassten Vertrag verbergen. Die gefährlichen Fälle entstehen oft bei normaler Wartungsarbeit: search_logs wird zu query_logs, ein Schema erhält ein optionales Feld project, und der Dienst akzeptiert nun Kennungen entfernter Projekte. Der Name hat sich kaum verändert, die Berechtigung schon.

Erstellen Sie einen Vergleichsdatensatz, der schlicht genug ist, um ihn auch unter Druck zu verwenden. Halten Sie für jedes alte und neue Tool Name, Beschreibung, JSON Schema, vorhandene deklarierte Annotationen für schreibgeschützt oder destruktiv, zugrunde liegenden Endpunkt oder Befehl, Identität der Zugangsdaten und bekannte Nebenwirkungen fest. JSON Schema zeigt nicht jedes Serververhalten, behandeln Sie es daher als Hinweis, nicht als vollständige Antwort.

Das ist eine nützliche, minimale Form für eine Übersicht:

{
  "name": "query_logs",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project": {"type": "string"},
      "query": {"type": "string"}
    },
    "required": ["query"]
  },
  "destination": "logs-api",
  "credential": "logs-read",
  "effects": ["read"]
}

Der dadurch verhinderte Fehler ist keine fehlerhaft formatierte Anfrage. Er bewahrt Prüfer davor, eine Umbenennung zu akzeptieren und dabei den neuen Selektor project zu übersehen, der eine lokale Abfrage in einen projektübergreifenden Abruf verwandeln kann.

Wenn sich alte und neue Datensätze bei Ziel, Zugangsdaten, Auswirkungen oder Argumentumfang unterscheiden, behandeln Sie das als neue Fähigkeit und starten Sie neu. Wenn Sie das zugrunde liegende Verhalten nicht identifizieren können, starten Sie ebenfalls neu. „Wahrscheinlich gleich“ ist kein Prüfergebnis.

Schema-Änderungen sind wichtiger als Beschreibungen

Ein Tool kann seinen Namen behalten und trotzdem gefährlicher werden. Eingabeschemata zeigen, wo das häufig geschieht: neue URL-Felder, Pfadfelder, Kontoauswahlen, frei formulierte Befehlszeichenfolgen, Empfängerlisten und optionale Flags, die den Ausführungsmodus ändern.

Stellen Sie sich ein Tool vor, das zunächst diese Eingabe hat:

{
  "type": "object",
  "properties": {"issue_id": {"type": "string"}},
  "required": ["issue_id"]
}

Später akzeptiert es include_private_notes oder destination_url. Das erste Feld verändert, was das Tool liest. Das zweite schafft einen Weg nach außen. Keines braucht einen auffälligen neuen Tool-Namen, um eine weitere Freigabegrenze zu erfordern.

Auch Beschreibungen verändern sich. Ein Server kann „Release-Details abrufen“ in „Release-Details abrufen und aktualisieren“ ändern, ohne das Schema anzupassen. Lesen Sie Beschreibungen, aber bleiben Sie nicht dabei stehen. Fragen Sie die verantwortliche Person, welcher Handler ausgeführt wird, welches Prinzipal er nutzt und ob er ausgehende Anfragen stellt. Eine gute Antwort nennt einen Befehl, Endpunkt oder Dienstaccount. „Das ist nur ein interner Helfer“ sagt nichts Nützliches aus.

Die MCP-Spezifikation erlaubt Tool-Metadaten und Annotationen, doch ihre Unterstützung und Auslegung durch Clients unterscheiden sich. Nutzen Sie sie als hilfreiche Kennzeichnungen. Treffen Sie keine Freigabeentscheidung allein anhand einer Kennzeichnung wie schreibgeschützt, wenn der Aufruf letztlich einen universellen Endpunkt erreicht.

Ein neuer Lauf schafft eine erklärbare Grenze

Ein neuer Lauf ist erforderlich, wenn die Freigabe nach der Änderung der Übersicht etwas anderes bedeuten würde. Diese Grenze hat praktischen Wert: Sie stoppt den aktuellen Prozess, macht die nächste Freigabe einem bekannten ausführbaren Prozess zuordenbar und trennt in Ihren Aufzeichnungen die alte Menge von Aufrufen von der neuen.

Der Ablauf ist kurz:

1. Stoppen Sie weitere Tool-Aufrufe, wenn sich die Übersicht unerwartet ändert.
2. Speichern Sie die alte und neue Übersicht, einschließlich Schemata und, falls verfügbar, Serverversion.
3. Kennzeichnen Sie jede Differenz als entfernt, umbenannt, verändert oder hinzugefügt.
4. Starten Sie neu, wenn eine Differenz Datenzugriff, Auswirkungen, Zielumfang oder Umfang der Zugangsdaten erweitert.
5. Geben Sie den neuen Lauf erst frei, wenn Sie seine erlaubte Aktionsoberfläche in einfacher Sprache beschreiben können.

Starten Sie nicht neu, nur um einem Ritual zu genügen. Starten Sie neu, weil dadurch eine konkrete frühere Freigabe ungültig wird. Dieser Unterschied hält die Regel brauchbar. Ein Team, das bei jeder Rechtschreibkorrektur neu startet, wird die Regel irgendwann ignorieren. Ein Team, das bei neuen Berechtigungen neu startet, lernt sie zu erkennen.

Autorisierung pro Sitzung funktioniert gut, wenn sie eine Freigabe an einen endenden Prozess bindet. Sallyport folgt diesem Modell, indem es die Code-Signatur für einen neuen Agentenprozess anzeigt und diese Freigabe für den Lauf bis zu dessen Ende beibehält. Eine geänderte Übersicht bleibt ein Grund, diesen Prozess zu beenden, wenn sich die anfragbaren Aktionen erweitert haben.

Freigabe pro Aufruf für Aktionen, die bewusst umständlich bleiben sollten

Freigabe pro Aufruf ist für Aktionen gedacht, deren Folgen zu groß sind, um sie in einer breiten Sitzungsfreigabe zu verstecken. Nutzen Sie sie für Änderungen in der Produktion, destruktive Vorgänge, öffentliche Nachrichten, Finanzaktionen und Anfragen, die sensible Daten an ein zur Laufzeit gewähltes Ziel senden können.

Einige Teams wollen das mit einer langen Allowlist aus Bedingungen in natürlicher Sprache lösen. Dieser Ansatz bleibt beliebt, weil er weniger Unterbrechungen verspricht. Gleichzeitig erhalten Prüfer damit eine fragilere Regel-Engine, die sie verstehen müssen, während ein Agent läuft. Das sicherere Design setzt auf wenige sichtbare Optionen: verweigern, solange der Vault gesperrt ist, einen bekannten Prozess für einen begrenzten Lauf freigeben oder für eine bestimmte Nutzung von Zugangsdaten einen Klick verlangen.

Die Einstellung für Schlüssel pro Aufruf von Sallyport passt in die letzte Kategorie. Der Agent kann darum bitten, die Aktion auszuführen, erhält aber nie den API-Schlüssel oder SSH-Schlüssel im Klartext. Das verringert das Risiko, dass Zugangsdaten durchsickern, während die Person weiterhin entscheidet, ob diese konkrete Anfrage das Gerät verlassen soll.

Markieren Sie nicht jede Aktion als Einzelaufruf. Wenn ein harmloser Lesezugriff ständig Rückfragen auslöst, bestätigen Menschen, ohne zu lesen. Setzen Sie Reibung dort ein, wo sie Urteilsvermögen bewahrt.

Der Audit-Datensatz muss eine strittige Änderung überstehen

Ein Audit-Protokoll sollte beantworten, welcher Agentenprozess lief, was er aufgerufen hat und ob jemand die verfügbare Oberfläche vor dem Aufruf verändert hat. Nur die endgültige Anfrage zu protokollieren, reicht nicht aus, wenn es im Streit darum geht: „War dieses Tool verfügbar, als wir die Sitzung freigegeben haben?“

Bewahren Sie neben den Sitzungsdaten einen Schnappschuss der Übersicht mit stabilem Digest auf. Halten Sie Tool-Name, kanonisches Schema, Serveridentität und den Zeitpunkt fest, zu dem Ihr Client es gesehen hat. Wenn sich etwas ändert, bewahren Sie beide Schnappschüsse und die Einordnungsentscheidung auf. Sie brauchen keine aufwendige Datenbank, um anzufangen. Ein signierter oder manipulationssicherer Datensatz mit der unveränderten Erkennungsantwort ist weit besser als eine mündliche Rekonstruktion am nächsten Morgen.

Sallyport zeichnet Agentenläufe in seinem Sitzungsjournal und einzelne Aufrufe in seinem Aktivitätsjournal auf. Beide werden aus einem verschlüsselten, hash-verketteten Audit-Protokoll abgeleitet. Der Befehl sp audit verify prüft diese Kette offline über Chiffretext, ohne einen Vault-Schlüssel zu benötigen. Das sind nach einer Änderung nützliche Belege, aber nur, wenn das Team auch festhält, welche Übersicht der Lauf gesehen hat.

Eine Hash-Kette erkennt Veränderungen an aufbewahrten Einträgen. Sie beweist nicht, dass Sie jedes Ereignis in jeder Komponente protokolliert haben, und sie sagt nicht, ob eine Freigabe sinnvoll war. Halten Sie diese Aussagen getrennt. Sicherheitsprüfungen werden schwächer, wenn Menschen von einem Mechanismus Antworten auf Fragen erwarten, die er nicht beantworten kann.

Dynamische Erkennung als Bereitstellungsereignis behandeln

Wenn Ihr MCP-Server Tools ändern kann, ohne den Client neu zu starten, hat das Team faktisch eine neue Aktionsoberfläche in einen laufenden Steuerkanal ausgerollt. Behandeln Sie dieses Ereignis mit der Disziplin eines Releases: Benennen Sie die verantwortliche Person, prüfen Sie den Unterschied, beschreiben Sie die erwartete Berechtigung und halten Sie etwas fest, das eine spätere Untersuchung lesen kann.

Der erste praktische Schritt besteht darin, zu Beginn jedes Agentenlaufs einen Schnappschuss der Übersicht anzulegen und ihn zu vergleichen, bevor eine Aktualisierung wirksam wird. Warten Sie nicht auf einen dramatischen Vorfall. Die unauffällige Umbenennung, die ein optionales Zielfeld hinzufügt, ist genau die Art von Änderung, die vielbeschäftigte und ansonsten sorgfältige Menschen übersehen.