Zugriffsregeln für KI-Agenten im Telekom-Back-Office festlegen

Ein Agent bereitet Gutschriften für Kundinnen und Kunden vor, die von einem Ausfall in einem Tal betroffen sind. In seinem Prompt steht: nie mehr als eine Monatsgebühr gutschreiben, und nur für Kunden am betroffenen Zugangsknoten. An den meisten Tagen funktioniert das. Dann leitet ein Kunde einen langen E-Mail-Verlauf an den Support weiter, und irgendwo darin steht ein Satz, den das Modell als Anweisung behandelt. Oder die Liste der betroffenen Kunden stammt aus einem Ticket, das jemand von Hand bearbeitet hat. In beiden Fällen war der Prompt die einzige Grenze für das, was der Agent an die Abrechnung geschickt hat.

Zugriffsregeln für Agenten müssen von den Systemen durchgesetzt werden, die die Daten halten und die Aktionen ausführen. Dieser Artikel stellt sechs Regeln vor, mit denen das im Telekom-Back-Office gelingt, jeweils mit einem Beispiel aus dem Betriebsalltag, und erklärt, wo die MCP-Autorisierungsspezifikation hilft.

Warum eine Anweisung an das Modell keine Kontrolle ist

Ein Sprachmodell befolgt Anweisungen mit hoher Wahrscheinlichkeit, und der Text, den es während der Arbeit liest, ist Teil seiner Eingabe. Eine Kunden-E-Mail, ein Ticketkommentar oder eine Notiz in einem CRM-Datensatz können verändern, was es als Nächstes tut. Damit ist ein Prompt ein guter Ort, um eine Aufgabe zu beschreiben, und ein schwacher Ort, um eine Grenze durchzusetzen.

Eine Kontrolle ist etwas, das auch dann noch greift, wenn das Modell sich irrt. Das Abrechnungssystem lehnt eine Gutschrift über dem Limit ab. Das Auftragssystem weist eine Kündigung von einer Identität zurück, die kein Recht zum Kündigen hat. Das Log hält den Versuch in jedem Fall fest.

Die MCP-Spezifikation legt diese Pflicht auf die Serverseite: Server, die Tools bereitstellen, müssen Eingaben validieren, Zugriffskontrollen umsetzen und Aufrufe begrenzen (MCP-Spezifikation, Tools). Der Work Trend Index 2026 von Microsoft macht einen ähnlichen Punkt für Organisationen als Ganzes und fordert die IT auf, Agenten mit „identities, permissions, policy enforcement, and lifecycle management“ zu verwalten (Microsoft, 2026).

Identität, Rolle und Berechtigung bei jedem Zugriff prüfen

Jede Anfrage eines Agenten trägt eine eigene Identität, getrennt von der Person, die ihn gestartet hat, und das System prüft Rolle und Berechtigung bei jeder Anfrage. Die Prüfung läuft bei jeder Anfrage, weil ein Agent stundenlang laufen kann und sich seine Rechte in dieser Zeit ändern können.

Jeder Agent hat ausserdem eine namentlich benannte Person, die für ihn verantwortlich ist, seine Ergebnisse prüft und seine Fehler korrigiert.

Beispiel: eine Wegportierung. Eine Anfrage trifft ein, die Nummer eines Kunden zu einem anderen Anbieter zu portieren. Ein Agent darf den Kunden, die aktiven Dienste und die offenen Rechnungen lesen, um zu prüfen, ob die Anfrage zum Vertrag passt. Wenn er verlangt, dass die Schlussrechnung erstellt wird, prüft das Abrechnungssystem die Identität und die Rolle des Agenten für genau diese Aktion erneut und lehnt ab, wenn die Rolle nur das Lesen abdeckt.

Kundendaten trennen

Agenten sehen die Kunden, für die sie arbeiten, und sonst nichts. Für einen Anbieter, der über Reseller verkauft oder mehrere Marken betreibt, muss diese Trennung im Datenmodell und in jeder Abfrage bestehen, damit ein Filter in den Anweisungen des Agenten nie die einzige Schranke ist.

Beispiel: der Agent eines Resellers. Ein Reseller verkauft Ihre Glasfaser unter seiner eigenen Marke und möchte mit einem eigenen Agenten den Status der Aufträge seiner Kunden prüfen. Die Identität des Agenten gehört zu diesem Reseller, und jede Abfrage liefert nur die Kunden dieses Resellers. Fragt der Agent nach einer Auftragsnummer, die zu einem anderen Reseller gehört, ist die Antwort dieselbe wie für eine Nummer, die nicht existiert.

Jedem Agenten nur die Rechte geben, die er braucht

Die Rechte folgen der Aufgabe. Ein Agent, der eine Umzugsliste vorbereitet, liest Aufträge und technische Rückmeldungen. Ein Agent, der Mahnschreiben entwirft, liest Rechnungen und Zahlungen. Keiner von beiden kann einen Tarif ändern.

Die MCP-Autorisierungsspezifikation verlangt von Clients, nur die Scopes anzufordern, die sie brauchen, und erlaubt dem Server, eine Anfrage mit zu wenigen Rechten mit 403 Forbidden und einem Fehler insufficient_scope zu beantworten, der die erforderlichen Scopes nennt (MCP-Spezifikation, Autorisierung). Die MCP-Sicherheitshinweise zählen Wildcard-Scopes sowie das blosse Vertrauen auf die Scopes in einem Token ohne Autorisierungslogik auf dem Server zu den häufigen Fehlern (MCP Security Best Practices).

Beispiel: eine Tarifmigration in grosser Zahl. Sie stellen einen alten DSL-Tarif ein und überführen seine Kundinnen und Kunden in einen Glasfaser- oder Nachfolgetarif. Der Migrationsagent darf die Verträge in diesem Tarif lesen und Änderungsaufträge für genau dieses Segment anlegen. Er kann keine Verträge kündigen, keine Gutschriften erteilen und keine Kunden in anderen Tarifen anrühren, selbst wenn der Fall eines Kunden so aussieht, als bräuchte er eines davon.

Kündigungen und Gutschriften ausdrücklich freigeben

Manche Aktionen beenden einen Dienst oder bewegen Geld. Bei diesen bereitet der Agent den Fall vor, und das System hält ihn zurück, bis eine namentlich benannte Person ihn freigibt. Die Freigabe ist ein eigener Schritt mit einer eigenen Berechtigung und wird mit dem Namen der Person festgehalten, die sie erteilt hat.

Beispiel: eine Gutschrift. Nach dem Ausfall entwirft der Agent Gutschriften für die betroffenen Kunden und hängt die Belege an: Zugangsknoten, Ausfallzeitraum, Monatsgebühr. Die Gutschriften liegen in der Abrechnung mit dem Status „wartet auf Freigabe“. Jemand in der Abrechnung prüft den Stapel, gibt ihn frei oder schickt einzelne Gutschriften zurück. Die Rolle des Agenten hat keine Berechtigung zur Freigabe, also kann ihn keine Formulierung in einem Prompt dazu bringen.

Dasselbe gilt für Kündigungen und Wegportierungen. Der Agent kann die Daten prüfen, die Schlussrechnung vorbereiten und auflisten, was unklar ist. Den Schritt, der den Dienst beendet, macht ein Mensch.

Ein Audit-Log führen, welcher Agent wann was getan hat

Das Log beantwortet die Fragen, die Ihnen Monate später gestellt werden. Für jede Aktion hält es fest: den Agenten, die für ihn verantwortliche Person, in wessen Auftrag er gehandelt hat, die Operation, die berührten Datensätze, die Werte vorher und nachher, den Zeitpunkt und, falls eine Freigabe nötig war, wer sie erteilt hat. Abgelehnte Anfragen gehören ebenfalls ins Log, weil sie Ihnen zeigen, wo ein Agent immer wieder etwas versucht, das er nicht tun sollte.

Beispiel: ein bestrittener Tarifwechsel. Drei Monate nach der Migration sagt ein Kunde, er habe dem neuen Tarif nie zugestimmt. Das Log zeigt das Datum, an dem der Migrationsagent den Änderungsauftrag angelegt hat, den Stapel, zu dem er gehörte, die Person im Produktmanagement, die diesen Stapel freigegeben hat, und die Benachrichtigung, die an den Kunden ging. Ohne das rekonstruieren Sie es aus E-Mails.

Den Entzug und das Stoppen laufender Aufträge testen

Der Entzug der Rechte eines Agenten zählt nur, wenn die nächste Anfrage scheitert. Testen Sie das, bevor Sie sich darauf verlassen, und testen Sie es, während ein Auftrag läuft.

Beispiel: eine Migration auf halbem Weg stoppen. Die Tarifmigration läuft über einige tausend Verträge, als jemand bemerkt, dass der neue Preis falsch ist. Drei Dinge müssen gleichzeitig geschehen: Die Rechte des Agenten werden entzogen, seine anstehenden Änderungsaufträge stoppen, und Sie wissen genau, welche Verträge bereits geändert wurden. Üben Sie das in einer Testumgebung: Starten Sie einen Stapel, entziehen Sie dem Agenten mittendrin die Rechte und prüfen Sie, ob der nächste Aufruf abgelehnt wird, ob nichts weiter verarbeitet wird und ob das Log Ihnen sagt, wo er angehalten hat.

Kurzlebige Tokens helfen dabei. Die MCP-Hinweise zur Autorisierung empfehlen sie, weil ein gestohlenes langlebiges Token länger funktioniert (Understanding Authorization in MCP).

Wo die MCP-Autorisierung hilft und wo sie endet

Erreichen Ihre Agenten Geschäftssysteme über einen entfernten MCP-Server, deckt die Autorisierungsspezifikation die Verbindung ab. Sie folgt OAuth 2.1. Der MCP-Server agiert als Resource Server, muss prüfen, dass ein Zugriffstoken für ihn ausgestellt wurde, und darf Tokens, die für andere Dienste bestimmt sind, weder annehmen noch weitergeben. Im Protokoll ist die Autorisierung optional, und Implementierungen über HTTP sollten der Spezifikation folgen (MCP-Spezifikation, Autorisierung).

Damit weiss der Server, welcher Client für welche nutzende Person mit welchen Scopes aufruft. Die Entscheidung, ob dieser Agent für diesen Kunden eine Gutschrift vorbereiten darf und ob eine Person sie freigegeben hat, gehört weiterhin dem Geschäftssystem hinter dem Server. Wenn Sie einen Hersteller bewerten, lassen Sie sich beide Ebenen zeigen und den Log-Eintrag, den jede davon schreibt.

Wie METAVSHN den Zugriff für Menschen und Agenten regelt

METAVSHN hat eine einzige Zugriffsschicht für Menschen und Agenten: Identität, Rollen, Rechte, Freigaben und das Audit-Log. Sie liegt vor Abrechnung, CRM, Aufträgen, Produktkatalog und Lager, sodass dieselbe Regel gilt, ob eine Mitarbeiterin einen Kundendatensatz öffnet oder ein Agent ihn über die METAVSHN CLI oder den MCP-Server anfordert. Kundendaten sind pro Mandant getrennt, Kündigungen und Gutschriften laufen über Freigaben, und die Berechtigungshinweise in der CLI gewähren für sich allein nichts. Die Plattform wird in unseren eigenen Rechenzentren in Zürich gehostet.

Wir betreiben selbst einen ISP (Ticinocom läuft auf METAVSHN), deshalb stammen diese Regeln aus den Fällen, die wir jede Woche bearbeiten: Wegportierungen, Gutschriften nach Ausfällen und Tarifmigrationen.

Wenn Sie sehen möchten, wie eine Freigabe und ihr Audit-Eintrag bei einer von einem Agenten vorbereiteten Gutschrift aussehen, buchen Sie mit uns eine 30-minütige Sicherheitsvorführung: METAVSHN kontaktieren.

Quellen

Alle Quellen abgerufen am 31. Oktober 2026.

1. Model Context Protocol, „Tools“, Spezifikationsversion 2026-07-28, Juli 2026. modelcontextprotocol.io
2. Model Context Protocol, „Authorization“, Spezifikationsversion 2026-07-28, Juli 2026. modelcontextprotocol.io
3. Model Context Protocol, „Understanding Authorization in MCP“, Juli 2026. modelcontextprotocol.io
4. Model Context Protocol, „Security Best Practices“, Protokollversion 2026-07-28, Juli 2026. modelcontextprotocol.io
5. Microsoft WorkLab, „2026 Work Trend Index Annual Report: Agents, human agency, and the opportunity for every organization“, 5. Mai 2026. microsoft.com