MCP nannte seine Sicherheitslabels Hints und wundert sich, warum niemand ihnen vertraut

Du hast deinen Agenten an ein Dutzend MCP-Tools angeschlossen und ihn auf deinen Montags-Backlog losgelassen. Slack, GitHub, eine Payment-API — der komplette domestizierte Zoo. Das Leben fühlt sich automatisiert an. Dann wiederholt der Agent einen fehlgeschlagenen Payment-Call, und dein Kunde kassiert eine doppelte Abbuchung.

Nichts in MCP hat dem Agenten gesagt, dass dieser Endpoint nicht sicher für Retries ist. Kein Label, kein Flag. Nur eine nackte Funktion und ein Modell, das tut, was Modelle eben tun — "hilfreich" sein.

Und hier wird's interessant. Die MCP-Spec hat genau die Sicherheitsfelder eingebaut, die du bräuchtest. Vier Annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Vier Booleans, die das Doppelabbuchungs-Szenario komplett verhindern könnten. Das MCP-Team hat sie am 16. März 2026 veröffentlicht. Und die Spec nennt jede einzelne davon einen "Hint".

Keinen Vertrag. Keine Einschränkung. Einen Hint. Wie ein Post-it auf einer geladenen Waffe: "Vielleicht nicht auf Menschen richten."

Sechs Wochen später hat die Industrie ihr Urteil gesprochen. Microsoft lieferte sein Agent Governance Toolkit am 2. April — YAML-basierte Policy-Durchsetzung, komplett von Grund auf gebaut, null Referenzen auf MCP-Annotations. Anthropic launchte Managed Agents Permission Policies am 21. April — Custom Allowlists und Scoping, die Annotation-Felder komplett ignoriert. Google folgte einen Tag später mit Agent Gateway am 22. April — gleiches Muster, gleiche From-Scratch Policy Engine. Drei große Plattformen in zwanzig Tagen. Keine davon nutzte die Sicherheits-Metadaten, die bereits im Protokoll existieren, von dem sie alle abhängen.

Das ist nicht dasselbe Problem wie die theatralischen Permission-Dialoge auf Plattform-Ebene — darüber haben wir schon geschrieben. Und es geht auch nicht um unvalidierte Tool-Outputs — das ist ein anderes Loch. Hier geht es um die Protokoll-Ebene — den einen Ort, an dem Sicherheits-Metadaten kanonisch sein sollten — die aktiv ihre eigene Glaubwürdigkeit untergräbt. Mit einer Wortwahl.

Justin Spahr-Summers, MCP-Mitschöpfer, hat das Offensichtliche beim Spec-Review im März 2026 auf GitHub laut ausgesprochen: "The information itself, if it could be trusted, would be very useful, but I wonder how a client makes use of this flag knowing that it's not trustable." Der Designer der Sicherheits-Metadaten hat öffentlich infrage gestellt, ob irgendjemand ihnen vertrauen kann. Das ist keine rote Flagge. Das ist die Fabrik, die rote Flaggen herstellt.

Selbst-attestierte Sicherheits-Metadaten ohne Verifikation sind kein Sicherheitsfeature. Sie sind ein Kummerkasten. destructiveHint: false von einem nicht vertrauenswürdigen MCP-Server ist genauso zuverlässig wie das Tool zu fragen "Hey, bist du gefährlich?" und die Antwort zu glauben. Über 17.000 MCP-Server sitzen mittlerweile in öffentlichen Registries. Die Anzahl, die eine unabhängige Verifizierung ihrer deklarierten Annotations hat: null.

Jedes ernsthafte System hat das vor Jahrzehnten begriffen. Unix hintet nicht auf Dateiberechtigungen — der Kernel erzwingt sie. OAuth hintet nicht auf Scopes — der Authorization Server validiert sie. Docker hintet nicht auf Container-Privilegien — die Runtime wendet sie an. In jedem funktionierenden Sicherheitsmodell ist die Entität, die die Sicherheitsaussage macht, nicht dieselbe Entität, die eingeschränkt wird. Das ist keine Paranoia. Das ist das Erste, was man lernt, bevor man an Production rangelassen wird.

MCP-Annotations verletzen dieses Prinzip by Design. Der Tool-Server deklariert seine eigenen Sicherheitseigenschaften, der Client liest sie, und nichts dazwischen verifiziert die Aussage. Der MCP-Blog hat das direkt eingeräumt: "A server can claim readOnlyHint: true and delete files anyway." Die Dokumentation der Spec gibt zu, dass die Sicherheitslabels lügen können und es keinen Mechanismus gibt, das aufzudecken.

Das Wort "Hint" hat den Rest des Schadens angerichtet. Wenn du Sicherheits-Metadaten als Hint bezeichnest, sagst du jedem Integrator: Das ist optional, unzuverlässig und nicht dein Problem. Sie haben zugehört. Drei Plattformen, drei komplett selbstgebaute Governance-Systeme, null Adoption der bestehenden Annotations auf Protokoll-Ebene — alles im April 2026. Nicht weil die Metadaten nutzlos sind, sondern weil die Spec sie im Voraus als Dekoration gekennzeichnet hat.

Und jetzt kommt der Teil, der schlimmer ist als gar nichts zu haben. Keine Annotations bedeutet: Du weißt, dass du im Blindflug unterwegs bist. "Hint"-Annotations bedeuten: Du hast vielleicht Sicherheitsdaten — vielleicht korrekt, vielleicht frei erfunden — und du musst entscheiden, ob du ihnen vertraust, mit null Verifikations-Tools. Falsches Vertrauen ist gefährlicher als ehrliche Unwissenheit. Unwissenheit macht dich wenigstens vorsichtig.

Also schreibst du YAML-Policies von Hand. Konfigurierst Tool-Allowlists manuell. Baust dieselben Leitplanken, die Annotations eigentlich liefern sollten, nur eben komplett von null, weil die Sicherheitsschicht des Protokolls dir präventiv gesagt hat, dich nicht auf sie zu verlassen. Das arbeitsintensivste Sicherheitsmodell, das möglich ist — nicht weil bessere Metadaten nicht existieren, sondern weil jemand entschieden hat, sie "Hint" zu nennen.

Der Fix ist nicht mal technisch. Die vier Felder sind korrekt designed. Das Datenmodell funktioniert. Was kaputt ist, ist ein Wort und die Philosophie dahinter. Ändere "Hint" zu "Declaration". Füge einen Verifikations-Endpoint hinzu — lass Clients deklarierte Eigenschaften gegen beobachtetes Verhalten testen. Mach Lügen erkennbar. Das günstigste Sicherheits-Upgrade im gesamten Agent-Stack liegt fertig strukturiert in der Spec und ist komplett kastriert durch eine Benennungsentscheidung, die 17.000 Servern und drei Governance-Plattformen gesagt hat, es nicht ernst zu nehmen.

Jemand hat einen Feuerlöscher gebaut, "enthält vielleicht Wasser, vielleicht auch nicht" draufgeschrieben und fragt sich jetzt, warum das Gebäude brennt.