OAuth, Scopes und Mandantentrennung für SEO-MCP-Server

Ein gültiges Access Token ist noch keine ausreichende Freigabe für einen SEO-Workflow. Der Server muss zusätzlich wissen, wer handelt, für welchen Mandanten, in welcher Rolle und mit welchem konkreten Scope.

Gerade Agenturen haben selten nur eine Property. Ein breites Token ohne serverseitige Workspace-Grenze kann dazu führen, dass eine plausible Nutzerfrage Daten aus dem falschen Kundenkonto abruft.

Vier Bindungen für jeden Aufruf

Ein produktiver Server sollte den Request an vier Dinge binden:

Diese Informationen dürfen nicht ausschließlich aus frei formuliertem Prompttext stammen. Workspace- und Projekt-IDs werden als strukturierte Argumente übergeben und gegen die autorisierte Mitgliedschaft geprüft.

Scopes müssen fachlich lesbar sein

Ein Scope wie seo:all ist bequem, aber für Betrieb und Zustimmung kaum hilfreich. Besser sind getrennte Rechte für Inventar lesen, Live-Daten anfordern, Exporte erzeugen und Zustände verändern.

Die genaue Granularität hängt vom Produkt ab. Zu viele Mikroscopes machen die Zustimmung unverständlich; ein einziger globaler Scope macht Least Privilege unmöglich. Eine gute Grenze folgt einer erkennbaren Wirkung:

• gespeicherte Daten lesen,
• kostenpflichtige Daten abrufen,
• Audit oder Analyse starten,
• Workspace-Daten verändern,
• externe Systeme verändern.

Protokollauth und Produktrollen sind nicht dasselbe

MCP definiert einen Autorisierungsweg für HTTP-basierte Transporte. Die Produktrolle – etwa Owner, Editor oder Viewer – bleibt Teil des angebundenen Systems. Der Server muss beide Ebenen zusammenführen.

Ein Token mit einem passenden technischen Scope darf nicht die Produktrolle überstimmen. Umgekehrt sollte ein Workspace-Owner nicht automatisch jede neue MCP-Capability erhalten, wenn die Zustimmung diese Wirkung nicht abdeckt.

Multi-Tenancy wird bei jedem Tool geprüft

Mandantentrennung gehört in die Datenabfrage, nicht nur in den Login. Jeder Toolhandler muss die Workspace-Zugehörigkeit vor dem Zugriff auf Daten oder Jobs bestätigen.

Für Hintergrundaufgaben gilt dieselbe Regel. Ein Task-Handle darf nicht global lesbar sein; Status und Ergebnis müssen an denselben Mandanten und Initiator oder eine ausdrücklich berechtigte Rolle gebunden bleiben.

Testfälle vor dem ersten Live-Zugang

1. Ein Nutzer aus Workspace A fordert eine Projekt-ID aus Workspace B an.
2. Ein Viewer versucht einen kostenpflichtigen Refresh.
3. Ein abgelaufenes oder für einen anderen Issuer ausgestelltes Token wird verwendet.
4. Ein Task-Handle wird von einem anderen Mandanten abgefragt.
5. Ein erlaubter Lese-Scope wird gegen ein Schreibtool eingesetzt.

Ein Server ist erst dann belastbar, wenn diese negativen Pfade kontrolliert scheitern und im Auditlog nachvollziehbar bleiben.