Sichere Tools sind eine Entwurfsfrage, keine Konfigurationsfrage.
Welche Ihrer Funktionen ein Agent ohne Rückfrage auslösen darf und welche nicht: Diese Liste entsteht vor der ersten Zeile Code. Genau das machen wir im Seminar.
Sicherheit · für Entwicklung
WebMCP-Sicherheit: Tools bauen, die man Agenten geben darf
Die Hauptbedrohung für WebMCP-Tools sind indirekte Prompt Injections: Ein Sprachmodell
verarbeitet alle Eingaben als Token-Folge und kann versteckte Anweisungen in Fremdinhalten
für echte Instruktionen halten; dokumentierte, reproduzierbare Angriffe auf agentische
Systeme existieren. WebMCP begegnet dem mit den vorhandenen Sicherheitsbausteinen des Webs
(Origin-Isolation, Permissions Policy) plus tool-spezifischen Mitteln: Annotations-Hints,
selektiver Exposition über exposedTo und Nutzerbestätigung für sensible
Aktionen. Wer die Regeln auf dieser Seite einhält, baut Tools, die ein Agent nutzen kann,
ohne dass Fremdinhalte das Ruder übernehmen.
Das Bedrohungsmodell in drei Sätzen
Erstens: Alles, was ein Tool an den Agenten zurückgibt, landet im Kontext des Modells; enthält die Ausgabe Fremdinhalte (Reviews, Kommentare, gescrapte Seiten), können darin Anweisungen stecken. Zweitens: Tools mit Schreibwirkung handeln im Namen des Nutzers, in dessen Session; ein fehlgeleiteter Agent kann damit echten Schaden anrichten. Drittens: In eingebetteten Kontexten (iframes) stellt sich zusätzlich die Frage, wer wem Tools anbieten darf.
Die Einzelheiten stehen in der Chrome-Dokumentation zu sicheren WebMCP-Tools und im Explainer.
Die Plattform-Ebene: wer überhaupt Tools anbieten darf
- Origin-Isolation ist Voraussetzung. Dokumente, die
document.domainsetzen, sind ausgeschlossen. - Permissions Policy: Standardmäßig dürfen nur Top-Level-Dokumente und
Same-Origin-iframes Tools registrieren; Cross-Origin-iframes brauchen die ausdrückliche
Freigabe der einbettenden Seite (
allow="tools"). - Selektive Exposition mit
exposedTo: Ein Tool kann auf bestimmte Origins beschränkt werden.
await document.modelContext.registerTool({
name: "get-favorite-products",
// ...
}, {
exposedTo: ["https://trusted-partner.example"],
});Die Faustregel dazu aus der Chrome-Doku: Lese-Tools nur für Origins freigeben, mit denen Sie Nutzerdaten teilen würden; Schreib-Tools nur für Origins, die im Namen des Nutzers handeln dürfen.
Die Tool-Ebene: Annotations ehrlich setzen
-
untrustedContentHint: trueist Pflicht, sobald die Tool-Ausgabe Daten aus externen oder unverifizierten Quellen enthält, aus Sicht des Registrierenden. Der Hint markiert die Payload als nicht vertrauenswürdig, damit der Agent sie als Daten behandelt, nicht als Anweisung. -
readOnlyHint: truean jedes Tool, das nichts verändert. Der Agent (und der Browser) können damit entscheiden, wofür eine Nutzerbestätigung nötig ist und wofür nicht. - Falsch gesetzte Hints sind gefährlicher als fehlende: Ein Schreib-Tool mit readOnlyHint umgeht Schutzmechanismen. Im Zweifel konservativ annotieren.
Die Inhalts-Ebene: Character Budgets
Die Chrome-Doku empfiehlt harte Längen-Budgets, damit Tool-Texte nicht selbst zum Einfallstor oder zur Verwirrungsquelle werden:
| Feld | Budget |
|---|---|
| Tool-Name und Parameter-Namen | maximal 30 Zeichen |
| Tool-Beschreibung | maximal 500 Zeichen |
| Parameter-Beschreibung | maximal 150 Zeichen |
| Tool-Ausgabe | maximal 1.500 Zeichen |
Kurz, präzise, ohne Anweisungen an den Agenten in der Ausgabe. Was nicht in 1.500 Zeichen passt, gehört auf die Seite, nicht in den Tool-Output.
Die Nutzer-Ebene: Bestätigung für sensible Aktionen
Der Entwurf sieht vor, dass sensible Operationen (Käufe, Löschungen, Versand) eine explizite Nutzerbestätigung durchlaufen; die genaue Mechanik ist Teil der laufenden Spezifikationsarbeit. Bis dahin gilt für Betreiber: solche Aktionen serverseitig absichern wie bisher auch. Ein Agent ist ein weiterer Client, kein vertrauenswürdiger.
Checkliste für jedes Tool vor dem Livegang
- Verändert das Tool etwas?
Wenn nein:
readOnlyHint: true. - Enthält die Ausgabe Fremdinhalte?
Wenn ja:
untrustedContentHint: true. - Braucht ein fremder Origin Zugriff?
Wenn nein: kein
exposedTo, Standard behalten; wenn ja: exakte Origin-Liste, keine Wildcards. - Budgets eingehalten (30/500/150/1.500)?
Die Grenzen aus dem Abschnitt darüber.
- Serverseitige Validierung unverändert scharf
Das Schema ist Dokumentation, keine Sicherheitsgrenze.
- Ausgabe ohne Anweisungen
Keine Formulierungen, die wie Anweisungen an einen Agenten lesbar sind.
Quellen
Alle Belege sind öffentlich zugänglich und am auf Erreichbarkeit geprüft.
- Chrome-Doku: Secure WebMCP tools Bedrohungsmodell, Hints, Budgets
- webmachinelearning/webmcp Spezifikation und Diskussion
- Chrome-Dokumentation API-Referenz und Anleitungen