Auditlog und Incident Response für MCP-gesteuerte SEO-Arbeit

Ein Auditlog ist kein Debug-Log. Es beantwortet nach einer fraglichen Agentenaktion, wer gehandelt hat, welches Ziel betroffen war, welche Grenze galt und was tatsächlich passiert ist.

Für SEO ist das wichtig, weil viele Fehler erst später sichtbar werden: ein zu großer Datenabruf, ein Export aus dem falschen Workspace, eine ungewollte Sitemap-Einreichung oder ein Crawl, der fremde Hosts erreicht.

Was pro Aufruf nachvollziehbar sein muss

Ein sinnvoller Datensatz enthält mindestens:

• Zeit und eindeutige Request-ID,
• Nutzer- oder Dienstidentität und Client,
• Workspace, Projekt und Property,
• Toolname und wirksame Version,
• normalisierte Eingaben ohne Secrets,
• Autorisierungsentscheidung und Scope,
• Budget, Limit und Freigabereferenz,
• Ergebnisstatus, Menge, Kosten und Dauer,
• Task- oder Folge-IDs.

Tokens, Zugangsdaten und vollständige sensible Inhalte gehören nicht in das Log. Für Nachweise reichen häufig Hashes, IDs und bewusst ausgewählte Metadaten.

Ablehnungen gehören ebenfalls in die Spur

Ein Auditlog, das nur erfolgreiche Aufrufe enthält, verpasst wichtige Warnzeichen. Wiederholte Cross-Tenant-Anfragen, ungültige Scopes, fehlende Header oder ständig überschrittene Budgets können auf eine Fehlkonfiguration oder einen Angriff hindeuten.

Die Ablehnung sollte den Grund intern präzise festhalten. Die Antwort an den Client darf trotzdem so knapp bleiben, dass sie keine vertraulichen Strukturen offenlegt.

Der erste Reaktionsplan

Bei einem Vorfall braucht das Team vorbereitete Schalter:

1. betroffenen Token, Client oder Nutzer sperren,
2. einzelne Tools oder Wirkungsklassen deaktivieren,
3. laufende Tasks stoppen und neue Starts blockieren,
4. Exporte und externe Schreibvorgänge identifizieren,
5. betroffene Mandanten und Zeitfenster eingrenzen,
6. Korrektur, Rückrollweg und Kommunikation festlegen.

Ein globaler Shutdown kann notwendig sein, ist aber kein Ersatz für feingranulare Kontrollen. Wenn nur eine neue Schreib-Capability problematisch ist, sollte der lesende Teil nicht zwangsläufig ausfallen.

Aufbewahrung und Zugriff

Auditdaten sind selbst sensibel. Sie können Kundennamen, Properties und Nutzungsmuster verraten. Aufbewahrungsdauer, Zugriff und Export müssen deshalb Teil des Sicherheitsmodells sein.

Definiere vorab, wer Logs lesen darf, wie lange sie benötigt werden und wie ein Kunde seine eigene Aktivität nachvollziehen kann, ohne andere Mandanten zu sehen.

Aus dem Vorfall wird eine Korrektur

Nach der unmittelbaren Reaktion folgt die technische und redaktionelle Korrektur: Toolvertrag anpassen, betroffene Kompatibilitätsaussagen veralten lassen, Fixture ergänzen und den Prüfstand erneut ausführen.

So bleibt ein Incident nicht nur eine interne Notiz, sondern verbessert die überprüfbare Grenze des Systems.