MCP und Rechte: Was darf Ihr Marketing-Agent wirklich – und wer hat die Haken gesetzt?

Ein Marketing-Agent, der Berichte aus Ihrem Werbekonto zieht, ist ein Gewinn. Ein Marketing-Agent, der in demselben Werbekonto Kampagnen ändern, Budgets verschieben und Zielgruppen löschen darf, ist ein Risiko, das Sie vielleicht gar nicht eingeplant haben. Der Unterschied zwischen beiden steht nicht im Namen des Agenten und auch nicht in seinem Funktionsumfang auf der Produktseite. Er steht in einer Liste, die bei der Anbindung abgehakt wird: den Zugriffsrechten.

Technisch heißen diese Rechte „Scopes“. Wenn ein KI-Agent über das Model Context Protocol (MCP) an Werkzeuge und Daten angeschlossen wird, bekommt er mit seinem Zugangsschlüssel eine Liste erlaubter Aktionen mit. Diese Liste kann klein und passgenau sein, zum Beispiel „nur Berichte lesen“. Sie kann aber auch groß und pauschal sein, zum Beispiel „alles“. Welche der beiden Varianten bei Ihnen gilt, entscheidet darüber, wie groß der Schaden im schlimmsten Fall ist, wie leicht Sie Fehler nachvollziehen können und wie schnell Sie im Notfall reagieren können.

Dieser Beitrag ist ein Grundlagenartikel, keine Nachricht des Tages. Er stützt sich auf einen einzigen, klar benennbaren Abschnitt der offiziellen MCP-Dokumentation: „Scope Minimization“ in den „Security Best Practices“ auf modelcontextprotocol.io, Dokumentversion 2026-07-28, von uns am 26. Oktober 2026 abgerufen und gelesen. Wir erklären, was dort steht, in einer Sprache, die auch ohne Entwicklerhintergrund verständlich ist, und wir übersetzen es in eine Prüfliste für Unternehmen im DACH-Raum, die Agenten an ihr Werbekonto, ihr CRM oder ihre Content-Werkzeuge anschließen wollen oder bereits angeschlossen haben.

Was MCP ist, was gesichert ist und was wir nicht wissen

Das Model Context Protocol ist ein offener Standard, mit dem KI-Anwendungen strukturiert auf Werkzeuge, Dienste und Datenquellen zugreifen können. Statt für jede Plattform eine eigene Schnittstelle zu bauen, sprechen Agent und Werkzeug eine gemeinsame Sprache. Für Sie als Unternehmen ist das vor allem aus einem Grund relevant: Je einfacher sich ein Agent anschließen lässt, desto häufiger wird es passieren, und desto wichtiger wird die Frage, was er nach dem Anschließen darf.

Bevor wir in die Details gehen, sauber getrennt, was belegt ist und was nicht:

• Belegt: Die MCP-Dokumentation enthält in der Version 2026-07-28 einen eigenen Abschnitt „Scope Minimization“. Er beschreibt einen Angriff, benennt Risiken, empfiehlt ein abgestuftes Rechtemodell und listet häufige Fehler. Wir haben den Abschnitt am 26. Oktober 2026 selbst gelesen.
• Belegt: Das Dokument richtet sich laut seiner eigenen Einleitung an Entwickler, die Autorisierung umsetzen, an Betreiber von MCP-Servern und an Sicherheitsfachleute, die MCP-basierte Systeme bewerten. Es ist also kein Leitfaden für Marketingabteilungen. Wir übersetzen es hier und geben dabei nichts als Aussage der Dokumentation aus, was dort nicht steht.
• Nicht belegt: Ob der Anschluss Ihres konkreten Werbekontos, Ihres CRM oder Ihres Content-Werkzeugs die abgestufte Rechtevergabe überhaupt anbietet, steht nicht in der Dokumentation. Das müssen Sie beim jeweiligen Anbieter prüfen. Ebenso wenig sagt die Dokumentation etwas darüber, welche Plattformen MCP einsetzen. Wir nennen deshalb in diesem Beitrag bewusst keine Plattformnamen als Beispiele für MCP-Anschlüsse.
• Verfügbarkeit: MCP selbst ist ein offener Standard und nicht an eine Region gebunden. Wie weit einzelne Anbieter den Standard in ihren Produkten unterstützen, ist von Anbieter zu Anbieter verschieden und hier nicht belegt. Für DACH gilt deshalb: Der Grundsatz der Rechte-Minimierung ist unabhängig vom Anbieter anwendbar, ob Ihr Anschluss ihn unterstützt, müssen Sie klären.

Das ist ein Evergreen-Thema. Es wird nicht durch ein Datum fällig, sondern durch den Moment, in dem Sie das erste Mal einem Agenten einen Zugang geben. Falls das schon passiert ist, ist die beste Zeit für die Prüfung jetzt.

Was die Leitlinie zu „Scope Minimization“ beschreibt

Der Abschnitt beginnt mit einem Satz, der das ganze Thema zusammenfasst: Schlechtes Scope-Design erhöht die Auswirkungen einer Kompromittierung des Zugangsschlüssels, erhöht die Reibung für Nutzer und verschleiert die Audit-Spur. Drei Probleme in einem Satz, und alle drei betreffen den Alltag eines Unternehmens, nicht nur Sicherheitsabteilungen.

Die Dokumentation beschreibt dann einen Angriff in nüchternen Worten. Ein Angreifer erlangt einen Zugriffsschlüssel, ein sogenanntes Access-Token. Das kann durch ein Leck in Protokolldateien geschehen, durch das Auslesen des Arbeitsspeichers oder durch lokales Abfangen. Dieses Token trägt breite Rechte, in der Dokumentation als Beispiele files:*, db:* und admin:* genannt. Diese breiten Rechte waren von Anfang an vergeben worden, und zwar aus einem technischen Grund: Der MCP-Server hatte alle Rechte, die er überhaupt kennt, in seiner Liste scopes_supported veröffentlicht, und der Client hatte sie alle angefordert. Mit dem gestohlenen Token kann der Angreifer dann, so die Dokumentation, auf andere Daten ausweichen (laterale Datenzugriffe), eine Kette von Rechten aneinanderreihen (Privilege Chaining) und ist nur schwer wieder auszusperren, ohne die gesamte Oberfläche neu bestätigen zu müssen.

Übersetzt in die Welt eines Marketing-Teams: Stellen Sie sich einen Agenten vor, der Berichte aus Ihrem Werbekonto ziehen soll. Bei der Anbindung wurde der Einfachheit halber „Vollzugriff“ vergeben, damit später niemand mehr nachfragen muss. Wird der Schlüssel dieses Agenten abgegriffen, hat der Angreifer nicht nur Zugriff auf Berichte, sondern auf alles, was dieser Zugang erlaubt. Dass das Beispiel konstruiert ist, ist gewollt. Die Dokumentation beschreibt genau diese Struktur, nur in technischen Begriffen.

Die Risiken, die der Abschnitt aufzählt, lesen sich wie eine Checkliste für Geschäftsführer:

• Größerer Schadensradius: Ein gestohlener Schlüssel mit breiten Rechten öffnet auch Werkzeuge und Daten, die mit der eigentlichen Aufgabe nichts zu tun haben.
• Schwieriger Widerruf: Wer einen Schlüssel mit Maximalrechten widerruft, legt damit alle Abläufe lahm, die an diesem Schlüssel hängen. Gerade deshalb zögert man im Ernstfall.
• Rauschen in der Audit-Spur: Ein einziges Gesamtrecht verdeckt, was der Agent bei jeder einzelnen Aktion eigentlich vorhatte. Im Protokoll steht dann „hatte Zugriff“ statt „wollte lesen“ oder „wollte ändern“.
• Privilege Chaining: Mit breiten Rechten kann ein Angreifer sofort heikle Funktionen aufrufen, ohne dass eine weitere Rückfrage oder Rechteerhöhung nötig wäre.
• Abbruch bei der Zustimmung: Wenn Nutzer bei der Anbindung eine lange Liste von Rechten sehen, lehnen sie ab oder klicken ohne Lesen auf „Zulassen“. Beides ist schlecht.
• Unbemerkte Rechte-Inflation: Ohne Kennzahlen wird eine zu weit gefasste Anforderung irgendwann zur Normalität.

Schlechtes Scope-Design erhöht die Auswirkungen einer Kompromittierung, erhöht die Reibung für Nutzer und verschleiert die Audit-Spur. (sinngemäße Wiedergabe, modelcontextprotocol.io, „Security Best Practices“, Abschnitt „Scope Minimization“, Version 2026-07-28, abgerufen am 26. Oktober 2026)

Für ein mittelständisches Unternehmen ist vor allem der zweite Punkt unterschätzt. Sie merken erst im Ernstfall, dass ein Widerruf nicht „nur“ einen Agenten stoppt, sondern gleich mehrere Abläufe, weil alles über einen gemeinsamen, breit berechtigten Zugang lief. Zu diesem Zeitpunkt ist die Entscheidung zwischen „Schaden begrenzen“ und „Betrieb aufrechterhalten“ unangenehm. Mit getrennten, schmalen Zugängen entsteht dieses Dilemma gar nicht erst.

Die häufigen Fehler und warum sie so naheliegend sind

Der Abschnitt nennt sechs „Common Mistakes“. Wir geben sie wieder und ordnen sie ein, denn jeder dieser Fehler hat einen nachvollziehbaren Grund, warum er passiert.

Erstens: Alle möglichen Rechte werden veröffentlicht. Der MCP-Server listet in scopes_supported sein gesamtes Rechte-Angebot. Das ist bequem, weil sich dann nichts nachpflegen lässt. Es hat aber eine Nebenwirkung, die die Dokumentation an anderer Stelle im selben Abschnitt festhält: Wenn die erste Anfrage des Servers keine konkrete Angabe zu den Rechten macht, sehen die Vorgaben vor, dass Clients ersatzweise alle in scopes_supported aufgeführten Rechte anfordern. Die Begründung der Spezifikation ist, dass allgemeine MCP-Clients kein Fachwissen zu einzelnen Rechten haben und die Entscheidung dem Autorisierungsserver und dem Nutzer bei der Zustimmung überlassen werden soll. Für die Praxis heißt das: Wenn niemand aktiv schmal einstellt, kann der bequeme Weg der breite sein. Das ist kein Vorwurf an irgendjemanden, sondern der Grund, warum jemand aktiv hinschauen muss.

Zweitens: Pauschalrechte wie *, all oder full-access. Sie sind kurz und lösen jedes Berechtigungsproblem, bevor es entsteht. Genau deshalb tauchen sie so oft auf, und genau deshalb nennt die Dokumentation sie als Fehler.

Drittens: Unzusammenhängende Rechte werden gebündelt, um spätere Rückfragen zu vermeiden. Aus Sicht eines Teams ist das nachvollziehbar: Niemand will drei Wochen später erneut einen Antrag stellen. Aus Sicht der Sicherheit ist es das Gegenteil von Rechte-Minimierung.

Viertens: Der gesamte Rechte-Katalog steht in jeder Rückfrage. Statt nur das zu verlangen, was für die aktuelle Aktion gebraucht wird, wird bei jeder Gelegenheit alles abgefragt.

Fünftens: Stille Änderungen der Bedeutung eines Rechts, ohne Versionierung. Was gestern „lesen“ hieß, erlaubt morgen mehr, und niemand hat es bemerkt. Für Sie als Anwender ist das der Grund, warum eine einmalige Prüfung nicht reicht, sondern in Abständen wiederholt werden sollte.

Sechstens: Rechte im Token gelten als ausreichend, ohne dass der Server selbst prüft. Ein Token sagt, was angefordert wurde. Es ersetzt nicht die Prüfung auf der Serverseite, ob die konkrete Aktion erlaubt ist. Diesen Punkt können Sie als Anwender nicht selbst lösen, aber Sie können Anbieter danach fragen.

Das Gegenmodell: Rechte in Stufen statt alles auf einmal

Die Dokumentation empfiehlt ein „progressives Least-Privilege-Modell“. Das klingt technisch, die Idee ist aber einfach und aus dem Alltag bekannt: Ein neuer Mitarbeiter bekommt am ersten Tag nicht den Schlüssel zum Tresor, sondern Zugang zu dem, was er für seine ersten Aufgaben braucht. Weitere Rechte folgen, wenn sie gebraucht werden und jemand sie bewusst vergibt.

Konkret nennt der Abschnitt diese Bausteine:

• Minimaler Start: Zu Beginn gibt es nur einen kleinen Satz niedrigriskanter Rechte für Entdecken und Lesen. Die Dokumentation nennt als Beispiel einen Scope mit dem Namen mcp:tools-basic.
• Schrittweise Erhöhung: Wenn der Agent zum ersten Mal eine Aktion mit höherem Risiko versucht, fordert der Server gezielt das dafür nötige Recht an, und zwar über eine Rückfrage im Header WWW-Authenticate mit der Angabe scope. Erst dann wird das Recht vergeben.
• Toleranz für weniger Rechte: Ein Server soll Schlüssel mit eingeschränkten Rechten akzeptieren, und der Autorisierungsserver darf auch nur einen Teil der angeforderten Rechte ausstellen.

Für Server-Betreiber ergänzt die Dokumentation: genaue Rechte-Rückfragen statt des gesamten Katalogs, und Protokollierung der Erhöhungen, also welches Recht angefordert und welcher Teil gewährt wurde, mit Korrelations-Kennungen, damit sich ein Vorgang später nachvollziehen lässt. Für Clients, also die Seite des Agenten, gilt: mit den Basisrechten beginnen. Bei der Menge der Rechte, die in einer Rückfrage mitgeliefert werden, lässt die Dokumentation dem Server Spielraum von „nur das Nötige“ über „das Nötige plus üblicherweise zusammengehörige Rechte“ bis zu „auch absehbar bald Nötiges“. Die Wahl hängt von der Abwägung zwischen Nutzerkomfort und Reibung ab.

Beachten Sie die Ehrlichkeit dieser Abwägung: Abgestufte Rechte machen etwas mehr Arbeit. Es gibt gelegentlich eine Rückfrage mehr, und jemand muss sie beantworten. Die Dokumentation behauptet nicht, dass Rechte-Minimierung kostenlos sei. Sie sagt, dass sie die Auswirkung einer Kompromittierung begrenzt, die Audit-Spur klarer macht und die Zustimmungsabbrüche verringert. Ob dieser Tausch für Ihr Unternehmen sinnvoll ist, ist eine Abwägung. Bei Zugängen zu Werbebudgets oder Kundendaten fällt sie in der Regel zugunsten der schmalen Rechte aus.

Daniel und Kai: Wo die Rechtefrage im Marketing konkret wird

Auf amazing-agents.com beschreiben wir zwei Rollen, bei denen die Frage nach dem Zugriff besonders greifbar ist. Wir erklären hier nur, wie die Webseite die Rollen beschreibt, und ordnen die Rechtefrage ein. Welche Anbindungen im Einzelfall technisch zum Einsatz kommen, ist Teil eines Setups und hier nicht Thema.

Daniel ist der Analytics-Spezialist im Research-Team unter Nadja. Laut Webseite sammelt er Performance-Daten über alle Social-Media-Kanäle, liefert wöchentlich einen Performance-Report und meldet Anomalien, bevor sie zum Problem werden. Seine Aufgabe ist im Kern lesend: Zahlen holen, vergleichen, einordnen. Aus Sicht der Rechte-Minimierung ist das ein Paradebeispiel für eine Rolle, die mit einem schmalen Lesezugang auskommen sollte. Ein Analytics-Agent, der zusätzlich Kampagnen ändern darf, hat mehr Rechte, als seine Aufgabe verlangt.

Kai ist der Outreach-Lead und Department-Head für den Sales-Outreach. Laut Webseite definiert er Strategie und Sequenzen, die Pipeline läuft von Sourcing über Personalisierung bis Versand und Follow-up, sie ist „jederzeit pausierbar“, und Kai „pausiert, wenn Sie das sagen“. Außerdem respektiert er Opt-outs sofort und dauerhaft. Hier ist die Rechtefrage anders gelagert, denn Outreach schreibt: Er erzeugt Nachrichten, die Menschen außerhalb Ihres Unternehmens erreichen. Je weiter die Rechte reichen, die ein solcher Agent in Ihrem CRM oder Postfach hat, desto wichtiger ist, dass sie bewusst und eng vergeben sind und dass die Möglichkeit zum Pausieren nicht an einem einzigen, schwer widerrufbaren Zugang hängt.

Der Gedanke dahinter ist übertragbar auf jede Rolle: Lesen und Schreiben sind zwei verschiedene Rechte, und sie sollten nicht im selben Schlüssel stecken, nur weil es bequemer ist. Daniel braucht in der Regel keine Schreibrechte für Kampagnen. Kai braucht Schreibrechte für Entwürfe und Versand, aber keinen Zugriff auf Buchhaltungsdaten. Ob Ihr Anschluss diese Trennung hergibt, ist die Frage an den Anbieter, die wir oben als offen markiert haben.

Die Prüfliste für Ihr Unternehmen und so gehen wir im Audit vor

Aus der Leitlinie lässt sich eine Liste ableiten, die jedes Unternehmen ohne Entwicklerteam abarbeiten kann. Wir haben sie so formuliert, dass sie sich in einer Stunde pro angebundenem Agenten prüfen lässt. Es ist unser Vorgehen im Audit, keine Aussage der MCP-Dokumentation. Die Dokumentation liefert die Begründung, die Umsetzung für Marketing-Teams ist unsere Übersetzung.

1. Bestandsaufnahme: Welche Agenten sind angebunden, an welche Werkzeuge und mit welchem Zugang? Wer hat die Anbindung eingerichtet? Ohne diese Liste kann nichts geprüft werden.
2. Haken ansehen: Welche Rechte sind bei jedem Zugang tatsächlich gesetzt? Nicht nur, ob der Agent funktioniert, sondern welche Häkchen beim Zugriff aktiv sind. Achten Sie auf Begriffe wie „Admin“, „Vollzugriff“, „alle“ und auf Sternchen-Rechte.
3. Lesen und Ändern trennen: Für jede Aufgabe festlegen, ob nur gelesen oder auch verändert werden muss. Berichte lesen ist etwas anderes als Budgets ändern. Wo nur gelesen werden muss, kommt ein reiner Lesezugang.
4. Ein Zugang pro Aufgabe: Statt eines gemeinsamen Schlüssels für alles bekommt jede Aufgabe einen eigenen. Dann lässt sich ein Zugang widerrufen, ohne die übrigen Abläufe zu stoppen.
5. Beim Anbieter nachfragen: Bietet der Anschluss abgestufte Rechte? Können Rechte später einzeln hinzugefügt werden? Gibt es ein Protokoll, aus dem hervorgeht, wer wann welches Recht erhalten hat? Die Antworten halten Sie schriftlich fest.
6. Protokoll prüfen: Lässt sich im Nachhinein erkennen, welche Aktion der Agent ausgeführt hat und mit welchem Recht? Wenn nicht, ist die Audit-Spur das erste Problem.
7. Widerruf üben: Einmal durchspielen, wie ein Zugang gesperrt wird, wer das entscheiden darf und was dabei stillsteht. Wenn der Widerruf eines Zugangs den halben Betrieb lahmlegt, sind die Rechte zu breit gebündelt.
8. Termin zur Wiederholung: Rechte ändern sich, Anbieter ändern Bedeutungen. Legen Sie einen festen Rhythmus für die erneute Prüfung fest, zum Beispiel quartalsweise.

So gehen wir im Audit vor: Wir starten mit der Bestandsaufnahme, lassen uns die vergebenen Rechte zeigen und ordnen jede Anbindung einer von drei Gruppen zu: nur lesen, Entwürfe erzeugen, Veränderungen mit Wirkung nach außen. Für die dritte Gruppe legen wir fest, an welcher Stelle ein Mensch freigibt. Aus dem Ergebnis entsteht eine kurze Liste mit Änderungen in der Reihenfolge ihres Risikos. Wir behaupten dabei nichts über Fälle, die wir nicht kennen: Wo ein Anbieter keine abgestufte Vergabe unterstützt, halten wir das als offenen Punkt fest, statt es schönzureden.

Agent mit Grenzen und Freigabe-Schritt: zwei verschiedene Sicherungen

Die Rechte-Minimierung und der Freigabe-Schritt werden oft verwechselt. Beide gehören zusammen, aber sie sichern Verschiedenes.

Die Grenze legt fest, was ein Agent überhaupt tun kann. Sie wirkt, bevor etwas passiert, und sie wirkt auch dann, wenn niemand hinsieht, etwa weil ein Zugangsschlüssel in falsche Hände gerät. Ein Agent mit einem reinen Lesezugang kann keine Kampagne ändern, egal was schiefgeht. Das ist die Aussage der Dokumentation zur Rechte-Minimierung, übertragen auf Ihr Marketing: Der Schaden im Fehlerfall bleibt begrenzt.

Der Freigabe-Schritt legt fest, wer entscheidet, bevor etwas Wirkung nach außen bekommt. Auch ein Agent mit korrekt vergebenen Schreibrechten sollte Veränderungen mit Wirkung auf Kunden, Budgets oder Daten nicht ohne Zustimmung eines Menschen ausführen. Auf amazing-agents.com gilt dieser Rahmen für alle Agenten: Freigabe-Schritte bei kritischen Aktionen, und E-Mails werden als Entwurf erstellt, nicht direkt versendet.

Ohne Grenze und ohne Freigabe-Schritt: Der Agent hat Vollzugriff und handelt allein. Ein Fehler, ein falsch verstandener Auftrag oder ein abgegriffener Schlüssel wirkt sofort und in voller Breite. Im Protokoll steht, dass der Zugang erlaubt war, aber nicht, was beabsichtigt war. Ein Widerruf legt alles lahm.

Mit Grenze und Freigabe-Schritt: Der Agent arbeitet mit einem Zugang, der nur das Nötige erlaubt. Alles, was nach außen wirkt, ist ein Entwurf, bis ein Mensch es freigibt. Die Entscheidung hat einen Namen, die Audit-Spur ist lesbar, und ein Widerruf trifft nur den betroffenen Ablauf.

Wenn Sie nur eine Sache aus diesem Beitrag mitnehmen: Schauen Sie bei jedem angebundenen Agenten einmal nach, welche Haken gesetzt sind. Nicht ob er funktioniert, sondern was er darf. Die Antwort auf diese Frage entscheidet darüber, ob aus einem Fehler eine Randnotiz wird oder ein Vorfall.

Quelle und Stand: modelcontextprotocol.io, „Security Best Practices“, Abschnitt „Scope Minimization“, Dokumentversion 2026-07-28, abgerufen am 26. Oktober 2026. Dieser Beitrag ist keine Rechts- oder Sicherheitsberatung im Einzelfall.