Ein MCP-Werkzeug darf sich seine Schreibrechte nicht selbst geben

Die Startfreigabe gilt auch für Trockenläufe

Das betrifft add, update, fix und compile, ausdrücklich auch deren Trockenläufe. Ein Agent darf also einen Workflow bearbeiten, wenn diese Fähigkeit beim Start eingeschaltet wurde. Dass er eine passende Aufgabe erhalten hat, schaltet sie für sich genommen nicht frei.

Was eine Inspektion tatsächlich ausführt

Die zugehörige Änderung trennt außerdem zwei Vorgänge, die leicht unter demselben Etikett landen. Das MCP-Werkzeug mcp-inspect liest nur noch Konfiguration. Eine Live-Abfrage mit den Filtern server oder tool weist es zurück. Die tatsächliche Erkundung eines Servers bleibt über den ausdrücklich vom Betreiber aufgerufenen CLI-Befehl möglich.

Für die Prüfung eines fremden Workflows ist das relevant. Konfiguration lesen und darin deklarierte Programme oder Endpunkte aufrufen haben unterschiedliche Folgen. Im Prüfbericht sollte stehen, welcher Vorgang tatsächlich stattgefunden hat.

Zwei Stellen für die eigene Abnahme

Die Releasefassung verschärft auch pull_request_target: Im Strict Mode sind die Rollen all und read dabei unzulässig. Außerhalb dieses Modus gibt es eine Warnung. Das ist eine konkrete Compile-Prüfung, keine allgemeine Sicherheitsgarantie für Agentenworkflows.

Vor einer Übernahme würde ich deshalb zwei Fälle getrennt prüfen: einen MCP-Schreibaufruf ohne Startfreigabe und einen Workflow mit einer unzulässigen Trigger-Rollen-Kombination. Hier wurden Quellen gelesen, keine dieser Ausführungen selbst getestet.