MCP-Schreibzugriff auf Ihr CRM

Gewähren Sie zuerst Lesezugriff und behandeln Sie jeden Schreib-Scope als eigene Entscheidung — mit benannter verantwortlicher Person, begrenztem Wirkungsradius und einem Log, das Sie hinterher tatsächlich lesen können. Für die meisten GTM-Teams ist die vertretbare Reihenfolge: 30 Tage nur Lesezugriff, danach Anlegen und Aktualisieren auf einer benannten Teilmenge von Objekten, und niemals Löschen oder Massenschreiben aus einer Agent-Session heraus, die zugleich Inbound-Inhalte einliest. Das Problem ist nicht, dass Agents unzuverlässig wären. Es ist, dass CRM-Schreib-Scopes gröber gewährt werden als die Entscheidungen, die Sie autorisieren wollen — und dass der Audit-Trail, mit dem Sie einen fehlerhaften Lauf rückgängig machen könnten, auf beiden großen Plattformen ein kostenpflichtiges Add-on ist.

Diese Seite ist das Entscheidungsframework: was Sie tatsächlich gewähren, die vier Fragen, die jede Stufe absichern, die Leiter, die Sie erklimmen, und der Vergabe-Nachweis, den Sie führen. Sie setzt voraus, dass Sie wissen, was ein MCP-Server ist — falls nicht, beginnen Sie mit MCP-Server erklärt.

Was ein Schreib-Scope tatsächlich gewährt

Unter der Revision 2025-11-25 des Model Context Protocol agiert ein MCP-Server als OAuth-2.1-Resource-Server und veröffentlicht seine eigenen Scopes. Der Client entdeckt sie. Das wiegt schwerer, als es klingt: Die Scope-Auswahlstrategie der Spezifikation besagt, dass ein Client alle in scopes_supported gelisteten Scopes anfordert, wenn der 401-Challenge des Servers keinen scope-Parameter enthält. Ein AI-Client für allgemeine Zwecke besitzt kein Domänenwissen für eine Vorauswahl, fordert also das Gesamtpaket an und überlässt die Eingrenzung dem Consent-Screen. Die Tool-Zerlegung des Anbieters ist Ihre Berechtigungsgranularität, und Sie erben sie, ob Sie wollen oder nicht.

Die beiden CRM-Plattformen haben in entgegengesetzte Richtungen zerlegt.

Salesforce hat die Oberfläche nach Verb auf getrennte gehostete Server aufgeteilt, GA am 29. April 2026: platform/sobject-reads (Lesen und Abfragen, keine Mutationen), platform/sobject-mutations (Anlegen und Aktualisieren, kein Löschen), platform/sobject-deletes und platform/sobject-all (volles CRUD). Jeder Server ist inaktiv, bis ein Admin ihn einschaltet, und Salesforce hat einen eigenen OAuth-Scope mcp_api geschaffen, gerade damit das Anbinden eines Agents nicht die Herausgabe des api-Scopes erfordert, der vollen Zugriff auf die Platform-APIs gewährt.

HubSpot ging den umgekehrten Weg. Der Remote-Server unter mcp.hubspot.com erreichte GA am 13. April 2026 mit einem einzigen Schreib-Tool, manage_crm_objects, das Anlegen und Aktualisieren über Kontakte, Unternehmen, Deals, Tickets, Line Items, Produkte und Aktivitäten abdeckt. Es gibt keine Konfiguration, in der ein Agent einen Anruf protokollieren, aber keinen Deal-Betrag ändern kann — es ist dasselbe Tool. Quotes, Rechnungen, Bestellungen, Warenkörbe, Abonnements, Segmente sowie die Marketing- und Content-Objekte bleiben schreibgeschützt.

Der erste Schritt jeder Evaluation ist deshalb, vom Anbieter die Tool-Liste und die Scope-Liste vor der Demo zu verlangen, nicht danach. Wenn die Schreiboberfläche ein einziges Tool über sechs Objekte ist, lautet Ihre Richtlinienfrage nicht mehr „welche Felder” — sondern „gewähren wir das überhaupt”.

Der Vier-Fragen-Filter

Führen Sie jeden vorgeschlagenen Schreib-Scope durch diese Fragen, bevor Sie ihn gewähren. Ein Scope, der an einer einzigen scheitert, bleibt ungewährt.

1. Umkehrbarkeit. Wenn der Agent den falschen Wert schreibt: Können Sie den vorherigen Wert ohne Backup-Restore wiederherstellen? Feldhistorie und Aktivitätslogs machen ein Überschreiben von Hand umkehrbar. Ein gelöschter Datensatz oder ein zusammengeführtes Duplikat nicht.
2. Wirkungsradius pro Aufruf. Wie viele Datensätze kann ein einzelner Tool-Aufruf berühren? Setzen Sie die Obergrenze auf die Anzahl Datensätze, die Ihr Ops-Analyst in einer Stunde von Hand korrigieren könnte — ein Default von [200] für ein zweiköpfiges RevOps-Team — und lehnen Sie jedes Bulk- oder Query-und-Update-Tool ohne Obergrenzen-Parameter ab.
3. Urheber des Datensatzes. Wenn der Schreibvorgang landet: Wessen Name steht darauf? Lautet die Antwort „die Person, die die Verbindung eingerichtet hat”, schreibt der Audit-Trail Agent-Aktionen einem Menschen zu, der zu dem Zeitpunkt geschlafen hat.
4. Beobachtbarkeit. Gibt es ein Log, das einen Agent-Schreibvorgang von einem menschlichen unterscheidet, wie lange wird es aufbewahrt, und ist es in Ihrer Edition enthalten? Beantworten Sie das vor der Vergabe, nicht nach dem ersten Vorfall.

Die Schreib-Leiter

Steigen Sie eine Stufe nach der anderen, mit fester Verweildauer je Stufe. Die Stufen bilden echte Plattformkonfiguration ab, keine Reifegrad-Metapher.

Stufe 0 — nur lesen. Der Default und der richtige Ruhezustand für jeden Anbieter, den Sie seit weniger als 30 Tagen betreiben. Salesforce: aktivieren Sie ausschließlich platform/sobject-reads. HubSpot: gewähren Sie Lese-Scopes und lehnen Sie manage_crm_objects im Consent-Screen ab. Fast der gesamte Nutzen, den Teams von einem CRM-Agent erwarten — Pipeline-Fragen, Account-Recherche, Meeting-Vorbereitung, Hygiene-Reporting — ist hier bei null Schreibrisiko verfügbar.

Stufe 1 — additive Schreibvorgänge auf agenteneigenen Objekten. Aufgaben, Notizen und protokollierte Aktivitäten. Die definierende Eigenschaft: Der Agent legt neue Zeilen an und überschreibt nie ein Feld, das ein Mensch gesetzt hat. In Salesforce ist das platform/sobject-mutations mit Objektberechtigungen, die auf Task, Event und benutzerdefinierte Aktivitätsobjekte begrenzt sind. In HubSpot existiert diese Stufe nicht als eigene Vergabe: manage_crm_objects enthält Deal- und Kontakt-Schreibvorgänge im selben Tool. Stufe 1 in HubSpot zu erreichen heißt also, Stufe-2-Berechtigungen zu akzeptieren und die Eingrenzung stattdessen über die Objekt- und Property-Berechtigungen des verbindenden Users durchzusetzen.

Stufe 2 — Anlegen und Aktualisieren auf benannten Standardobjekten. Kontakte, Unternehmen und Deals beziehungsweise Opportunities, mit Feldebenen-Sicherheit, die alles ausschließt, was in Vergütung oder den Board-Forecast einfließt — Betrag, Abschlussdatum, Phase und Owner — bis Sie 30 saubere Tage auf Stufe 2 mit den übrigen Feldern gelaufen sind. Salesforce setzt das über die Feldebenen-Sicherheit des Permission Sets des verbundenen Users durch; die MCP-Tools respektieren Objektberechtigungen, Feldebenen-Sicherheit und Sharing-Regeln, das Permission Set ist also die eigentliche Kontrolloberfläche, nicht die Serverwahl.

Stufe 3 — Löschen, Bulk und Metadaten. platform/sobject-deletes, platform/sobject-all und die Server, die bis ins Setup reichen. Gewähren Sie das der interaktiven Session eines menschlichen Admins für eine abgegrenzte Migration und widerrufen Sie es am selben Tag. Es ist keine dauerhafte Vergabe für den Agent eines Anbieters.

Service-Account-Isolierung, und warum Sie sie nicht bekommen

Der Instinkt stimmt — geben Sie dem Agent eine eigene Identität statt der einer Person — aber die Plattformen unterstützen das nur zur Hälfte.

Die gehosteten MCP-Server von Salesforce unterstützen ausschließlich den Authorization-Code-Flow. Es gibt keinen Machine-to-Machine-Flow und keine Service-Account-Verbindung; ein Mensch authentifiziert sich und erteilt den Zugriff. Jeder Agent-Schreibvorgang landet daher unter einem echten Salesforce-User, mit dessen Berechtigungen und dessen Namen in der Datensatzhistorie. Die praktikable Fassung von Isolierung ist ein dedizierter, benannter Integrations-User mit eigenem Permission Set, eigener External Client App, einer auf dieses Permission Set beschränkten App Policy, IP-Beschränkungen unter App Authorization und einer gegenüber dem Ein-Jahres-Default der External Client App verkürzten Token-Lebensdauer. Validieren Sie den resultierenden Zugriff mit Apex runAs, bevor Sie Produktion darauf richten.

HubSpot formuliert dieselbe Vererbung direkt: Alle Aktionen respektieren die bestehenden Berechtigungen des verbindenden Users, und User können nur Datensätze sehen und ändern, die sie ohnehin erreichen. Die Kontrolle ist damit der User, von dem aus Sie verbinden. Eine Verbindung aus einem Super-Admin-Account gibt dem Agent mit einem Klick Super-Admin-Schreibreichweite.

Die Regel, die aus beidem folgt: Verbinden Sie einen CRM-MCP-Server niemals aus der Session eines Administrators. Legen Sie den User zuerst an, grenzen Sie ihn ein, verbinden Sie danach.

Es gibt keinen Dry Run — drei Ersatzverfahren

Weder der gehostete Server von Salesforce noch der von HubSpot liefert einen Dry-Run- oder Vorschaumodus für Schreibvorgänge, und MCP definiert kein Dry-Run-Primitiv. Drei Dinge treten an dessen Stelle:

• Zuerst Sandbox. Salesforce veröffentlicht neben Produktion einen Sandbox-Pfad für seine gehosteten Server (/platform/mcp/v1/sandbox/...). Betreiben Sie den Agent über die volle Verweildauer gegen eine Sandbox mit repräsentativen Daten, bevor Sie ihn auf Produktion richten.
• Vorschlagen, dann anwenden. Belassen Sie den Agent auf platform/sobject-reads und lassen Sie ihn die beabsichtigte Änderung als Datensatz-IDs plus Vorher-/Nachher-Werte auf Feldebene ausgeben. Ein Mensch oder ein separat berechtigter Prozess wendet den Stapel an. Das erhält fast den gesamten Durchsatz und nimmt die Schreibautorität vollständig aus dem Modellkontext heraus.
• Bestätigung auf Client-Seite. Die MCP-Spezifikation sagt, es solle stets ein Mensch im Loop sein, der eine Tool-Invocation ablehnen kann, und Clients sollten dem User die Tool-Inputs zeigen, bevor sie den Server aufrufen. Prüfen Sie, ob Ihr Client beides tatsächlich tut — es ist ein SHOULD, kein MUST, und Clients unterscheiden sich.

Was keine Kontrolle ist: Tool-Annotations. Die Spezifikation ist explizit, dass Clients Annotations als nicht vertrauenswürdig behandeln müssen, sofern sie nicht von einem vertrauenswürdigen Server stammen. Ein readOnlyHint in einer Tool-Definition ist also Dokumentation, kein Enforcement. Nur-Lesen muss auf der Ebene von Scope, Server und Permission Set durchgesetzt werden, sonst ist es nicht durchgesetzt.

Der Audit-Trail, und was er kostet

Die eigene Sicherheitsempfehlung von Salesforce lautet, Agent-Traffic im Event Log File Browser zu identifizieren, indem man API_CLIENT_CATEGORY nach SALESFORCE_HOSTED_MCP filtert, und danach STATUS_CODE auf Fehler sowie USER_NAME und CLIENT_IP auf Anomalien zu prüfen. Das funktioniert, mit zwei Einschränkungen, die vor der Unterschrift bepreist gehören: Event Monitoring erfordert außerhalb der Developer Edition Salesforce Shield oder das Event-Monitoring-Add-on — kostenlos sind nur Login- und Logout-Events — und Event Log Files haben ohne das Add-on für erweiterte Aufbewahrung standardmäßig rund einen Tag Aufbewahrung.

Die Account-Activity- und Audit-Log-API von HubSpot ist Enterprise-exklusiv, die Ansichten im Produkt zeigen 30 Tage, und Leseereignisse werden gar nicht erfasst — ein Agent, der ohne Schreibvorgang exfiltriert, hinterlässt dort keine Spur.

Beide Befunde weisen in dieselbe Richtung: Wenn die Budgetposition für das Auditing das Budgetgespräch nicht überlebt hat, sollte der Schreib-Scope es auch nicht überleben.

Prompt Injection ist der Grund für die Obergrenze beim Wirkungsradius

Der konkrete Fall ist ForcedLeak. Noma Security meldete ihn Salesforce am 28. Juli 2025 und legte ihn am 25. September 2025 mit einem CVSS-Score von 9.4 offen. Angreiferanweisungen steckten in gewöhnlichen Web-to-Lead-Formularübermittlungen, lagen inert im CRM und wurden später ausgeführt, als ein Mitarbeiter Agentforce zu dem Lead befragte — verkettet mit einer Schwäche der Content-Security-Policy-Allowlist, an der eine abgelaufene, käuflich erwerbbare Domain beteiligt war, um CRM-Daten zu exfiltrieren. Salesforce lieferte am 8. September 2025 Trusted URLs Enforcement für Agentforce und Einstein aus.

ForcedLeak war keine MCP-Schwachstelle, und es als solche zu zitieren wäre falsch. Es ist dieselbe Fehlerklasse, und genau das ist der Punkt: Jeder Agent, der Felder liest, die ein Außenstehender beschreiben kann, führt nicht vertrauenswürdige Eingaben aus, und ein Schreib-Scope macht daraus statt eines Offenlegungsproblems ein Datenintegritätsproblem. Die operative Regel lautet: Ein Agent, dessen Kontext angreiferkontrollierbare Felder enthält — Web-to-Lead-Payloads, Inbound-E-Mail-Bodys, Formularausfüllungen, Chat-Transkripte, hochgeladene Lebensläufe — hält in derselben Session keinen Schreib-Scope. Trennen Sie die Aufgabe „nicht vertrauenswürdige Inhalte lesen” und die Aufgabe „ins CRM schreiben” in zwei Verbindungen mit zwei Identitäten.

Der Vergabe-Nachweis

Führen Sie einen davon je gewährtem Scope, am selben Ort wie Ihr Anbieterregister. Er kostet fünf Minuten und ist das Artefakt, das die jährliche Überprüfung überhaupt möglich macht.

Vendor / server:      [vendor] — [server id, e.g. platform/sobject-mutations]
Level granted:        [0-3]
Objects + fields:     [explicit list; note excluded fields]
Connecting identity:  [named integration user, not an admin]
Blast radius cap:     [max records per call]
Token lifetime:       [duration; ECA default is 1 year]
Audit source:         [ELF filter / Account Activity API] — retention [N days]
Untrusted-input rule: [does this session read outsider-writable fields? Y/N]
Granted by / date:    [name] / [date]
Review date:          [date + 90 days]
Revocation steps:     [deactivate server / uninstall app / disable user]

Fallstricke

• Ein erneuter Consent-Prompt ist eine Scope-Änderung. HubSpot lässt Sie Scopes nicht von Hand auswählen; sie ergeben sich aus den zum Installationszeitpunkt im Server vorhandenen Tools plus dem, was der User gewährt. Fügt HubSpot Tools hinzu, zeigen bestehende Installationen REQUIRES_REAUTHORIZATION, und die Behebung besteht darin, zu trennen und neu zu verbinden — womit gegen das neue, größere Tool-Set neu gewährt wird. Absicherung: Behandeln Sie jeden Reauthorisierungs-Prompt als Change-Control-Ticket und lesen Sie den Consent-Screen erneut, statt ihn durchzuklicken.
• Server, die Sie für ein Pilotprojekt aktiviert haben, bleiben aktiviert. Salesforce-Server sind standardmäßig inaktiv, was Sie an Tag eins schützt und an Tag neunzig nicht. Absicherung: Nehmen Sie den Deaktivierungsschritt in die Exit-Kriterien des Pilotprojekts auf und auditieren Sie die aktiven Server am 90-Tage-Überprüfungsdatum aus dem Vergabe-Nachweis.
• Einstellungen für sensible Daten verändern die Oberfläche stillschweigend. Ist in HubSpot Sensitive Data aktiviert, sind Aktivitätsobjekte und Konversationsdaten über den MCP-Server blockiert. Absicherung: Bestätigen Sie im eigenen Portal statt aus der Dokumentation, welche Objekte der Agent tatsächlich erreicht — die effektive Oberfläche unterscheidet sich je nach Account-Konfiguration.
• Der verbindende User driftet. Permission Sets werden aus einem unabhängigen Grund erweitert, und die Reichweite des Agents wächst mit. Absicherung: Der Integrations-User hat genau ein Permission Set, und dieses Permission Set ist genau einem User zugewiesen, damit eine Erweiterung nicht als Nebeneffekt eintreffen kann.

Verwandt

• MCP-Server erklärt — die Einführung, die dieses Framework voraussetzt; lesen Sie sie zuerst, falls „MCP-Support” auf einer Anbieterseite noch eine unvertraute Behauptung ist
• AI-Nutzungsrichtlinie für RevOps-Teams — die einseitige Richtlinie, die dies umschließt; dieses Framework ist der Abschnitt, auf den sie für CRM-Schreib-Scopes verweist
• Agentic CRM — die Kategorie, die diese Entscheidung unausweichlich macht, da die Prämisse eines Agentic CRM lautet, dass Software der primäre Urheber des Datensatzes ist
• Vendor-Due-Diligence-Workflow — die Sicherheits- und Datenschutzprüfung, die vor dieser Vergabeentscheidung läuft
• Salesforce und HubSpot — die beiden Plattformen, deren Tool-Zerlegung Ihre Berechtigungsgranularität festlegt