Ihr MCP-Server ist sicher. Das dahinterliegende Hauptbuch ist es nicht.

In einem kürzlich hier bei Unite.AI erschienenen Beitrag stellte Gil Feig sechs bewährte Vorgehensweisen für den Aufbau eines sicheren MCP-Servers vor. Sie sind fundiert, und jeder, der einen MCP-Server bereitstellt, sollte sie befolgen. Sein Rat, jeder Integration „eine eigene, fein abgestufte Rolle mit strikt auf die erforderlichen Berechtigungen beschränktem Umfang“ zuzuweisen, ist genau richtig. Dabei wird jedoch vorausgesetzt, dass das System am anderen Ende über fein abgestufte Rollen verfügt. Dahinter steckt eine weiter gefasste, selten ausgesprochene Annahme: dass sich die Systeme hinter dem Server nach demselben Standard absichern lassen.

Bei Unternehmenssoftware ist das oft nicht möglich. Ich leite das Engineering-Team hinter einer Integrationsschicht, die 32 Buchhaltungs- und ERP-Systeme anbindet und optional um einen MCP-Server ergänzt werden kann. Wir sehen regelmäßig, dass Agenten auf unserer Seite gut authentifiziert, mit klar begrenzten Berechtigungen ausgestattet und sorgfältig protokolliert sind, während sie in Systeme schreiben, die überhaupt nicht erkennen können, dass ein Agent beteiligt war.

In diesem Beitrag geht es um die zweite Hälfte des Problems: darum, was die angebundenen Systeme tatsächlich bieten, was sich über die Integrationsschicht steuern lässt und wo diese Kontrolle endet.

Wo die MCP-Spezifikation die Verantwortung übergibt

Die MCP-Autorisierungsspezifikation steckt ihren eigenen Geltungsbereich klar ab. Der MCP-Server ist für seine Clients ein OAuth-Ressourcenserver. Ruft er eine vorgelagerte API auf, agiert er als separater OAuth-Client mit einem eigenen, vom vorgelagerten System ausgestellten Token. Das Token des Clients durchzureichen, ist ausdrücklich untersagt.

Das ist die richtige Architektur. Zugleich bedeutet es, dass alles am Aufruf des vorgelagerten Systems – einschließlich der Frage, wer was tun darf und wie dies protokolliert wird – vollständig von diesem System abhängt. Die Spezifikation kann nicht beheben, was das vorgelagerte System nicht bietet.

Dasselbe gilt für die OWASP-Leitlinien zu übermäßiger Autonomie. Sie empfehlen, die Berechtigungen, über die die Erweiterungen eines Agenten in anderen Systemen verfügen, auf das notwendige Minimum zu beschränken und Aktionen im Kontext des Nutzers auszuführen, in dessen Auftrag der Agent handelt. Beides ist guter Rat. Beides setzt voraus, dass das andere System eine Möglichkeit bietet, Mindestberechtigungen und den Nutzerkontext abzubilden.

Was die angebundenen Systeme tatsächlich bieten

So sehen die 32 Buchhaltungs- und ERP-Systeme, die wir anbinden, aus Sicht eines Integrators aus.

Ein Drittel kommt ganz ohne OAuth aus

21 der 32 Systeme verwenden OAuth. Die übrigen 11 setzen auf statische Zugangsdaten: API-Schlüssel, Benutzername und Passwort oder ein Tokenpaar. Manche dieser Schlüssel laufen nie ab. Ein weit verbreitetes System gibt in seiner API-Dokumentation an, dass seine API-Token unbegrenzt gültig sind, solange der jeweilige Nutzer existiert.

Lange Laufzeiten, kaum Widerrufsmöglichkeiten

OAuth hilft weniger, als man hoffen würde. Ein Anbieter stellt Refresh-Tokens mit einer Laufzeit von ungefähr 20 Jahren aus. Diese Zugangsdaten sind darauf ausgelegt, länger zu bestehen als der Agent, der sie verwendet, das Framework, auf dem der Agent basiert, und möglicherweise sogar die Person, die auf „Zulassen“ geklickt hat. In einem anderen System laufen sogar die Zugriffstoken nicht ab.

Und sobald Zugangsdaten im Umlauf sind, stellt sich die Frage, wer sie deaktivieren kann. Der dafür maßgebliche Standard, OAuth-Token-Widerruf (RFC 7009), existiert seit 2013. Dennoch bieten ungefähr vier von zehn Systemen Integratoren keine technische Möglichkeit, Zugangsdaten zu widerrufen. Jedes System mit API-Schlüsseln gehört zu dieser Gruppe. Als einzige Möglichkeit bleibt, den Kunden zu bitten, den Zugriff manuell zu löschen.

Grob abgestufte Berechtigungen, keine Agentenidentität

Die meisten statischen Schlüssel übernehmen einfach sämtliche Berechtigungen des Nutzers, der sie erstellt hat; nur bei wenigen Systemen lässt sich ein Schlüssel auf einzelne Endpunkte beschränken. Viele OAuth-Systeme bieten Berechtigungsbereiche, doch diese sind meist grob abgestuft und lauten etwa „Buchhaltung: Lesen und Schreiben“. Und in keinem der 32 Systeme konnten wir eine Möglichkeit finden, über die API bei derselben Transaktion sowohl den Agenten als auch die Person zu erfassen, in deren Auftrag er handelt. Externe Agenten erscheinen entweder als der Nutzer, der sie verbunden hat, oder als allgemeiner Systemnutzer. Bezeichnenderweise hat ein Anbieter, der Agenten in sein eigenes Produkt integriert hat, wie Microsoft in Business Central, ihnen eigene Benutzerkonten zugewiesen. Das ist dasselbe Modell, das ich weiter unten empfehle – nur ist es dort den eigenen Agenten des Anbieters vorbehalten.

Was sich über die Integrationsschicht durchsetzen lässt

Das alles bedeutet nicht, dass man aufgeben sollte. Zwischen dem Agenten und dem Buchhaltungssystem lässt sich fast alles kontrollieren:

• eigene Zugangsdaten für jeden Agenten gegenüber der eigenen Integrationsschicht
• eigene Berechtigungsbereiche, zum Beispiel schreibgeschützter Zugriff auf Rechnungen
• ein Prüfprotokoll für jeden Aufruf durch einen Agenten, einschließlich der Person, in deren Auftrag er gehandelt hat
• Idempotenzschlüssel, damit ein Agent bei einem erneuten Versuch dieselbe Rechnung nicht zweimal bucht
• Ratenbegrenzungen für jeden Agenten
• Genehmigungsschritte vor jedem Schreibvorgang

Nichts davon hängt davon ab, was das Zielsystem unterstützt. Eine leistungsfähige Zugriffsschicht auf der Integrationsebene lässt sich schon heute einrichten. Wenn Agenten auch nur in die Nähe von Finanzdaten kommen, sollte man eine solche Schicht aufbauen.

Wo die Möglichkeiten enden

Was Sie nicht tun können, ist, diese Ebene über die Systemgrenze hinaus zu erweitern. Dort versagen drei Dinge.

Zurechenbarkeit

Im Buchhaltungssystem erscheint die Buchung des Agenten unter dem Namen der Person, die die Verbindung autorisiert hat, oder unter dem eines technischen Benutzers. Wer dieses System prüft, sieht eine Buchung dieses Benutzers. Ob sie von einer Person oder einem Agenten stammt, lässt sich nicht erkennen. Im Hauptbuch sieht ein Agent, der um 3 Uhr morgens 400 Rechnungen verbucht, genauso aus wie ein besonders gewissenhafter Finanzmanager. Um den Vorgang zu rekonstruieren, braucht man die Protokolle des Integrators – das ist eine andere Vertrauenskette als die des führenden Systems. Für forensische Untersuchungen oder eine Prüfung ist das eine ungünstige Ausgangslage.

Auch die meisten Unternehmen sind hier nicht weiter. In einer Umfrage der Cloud Security Alliance gaben nur 28 % der Befragten an, die Aktionen von Agenten in allen Umgebungen zuverlässig einer Person oder einem System zuordnen zu können. 44 % verwenden statische API-Schlüssel für ihre Agenten oder planen, dies zu tun.

Minimalprinzip

Sie können festlegen, dass ein Agent Rechnungen nur lesen darf. Hat das Zielsystem jedoch keine Berechtigungsbereiche, verfügen die Zugangsdaten hinter Ihrer Ebene weiterhin über uneingeschränkten Zugriff. Wer sie in die Hände bekommt, umgeht Ihre Ebene vollständig – und damit auch jede Regel, die Sie dort eingerichtet haben.

Widerruf

Sie können Ihren eigenen Agenten sofort sperren. Das hilft jedoch nicht, wenn die Zugangsdaten zum Zielsystem selbst kompromittiert wurden. Und bei vier von zehn Systemen, die keine Widerrufsschnittstelle bieten, besteht der Notausschalter darin, dem Kunden eine E-Mail zu schicken.

Die pragmatische Lösung: ein dedizierter Benutzer für den Agenten

Das Nützlichste, was Sie heute tun können, ist wenig spektakulär: Richten Sie im Zielsystem einen eigenen Benutzer für den Agenten ein und verbinden Sie den Agenten ausschließlich über diesen Benutzer.

Das funktioniert in jedem System, in dem sich Benutzer anlegen lassen, und bietet drei Vorteile, die die Integrationsebene nicht leisten kann:

• Zurechenbarkeit im führenden System. Buchungen erscheinen als „Kreditoren-Agent“ und nicht unter dem Namen des Finanzmanagers, der vor sechs Monaten auf „Verbinden“ geklickt hat.
• Eine Möglichkeit zum Widerruf – auch ohne API dafür. Der Kunde kann den Benutzer in der Oberfläche deaktivieren. Das funktioniert auch bei Systemen ohne Widerrufsschnittstelle.
• Eine teilweise Umsetzung des Minimalprinzips. Verfügt das System überhaupt über ein Rollenmodell, lässt sich der Agentenbenutzer oft auf die tatsächlich benötigten Module beschränken.

Die Kosten sind real. Jemand muss den Benutzer während der Einrichtung manuell anlegen – das verursacht ausgerechnet im ungünstigsten Moment zusätzlichen Aufwand. Etwa die Hälfte der Systeme berechnet Gebühren für jeden weiteren Benutzer: von wenigen Euro im Monat bei Werkzeugen für kleine Unternehmen bis zu mehr als hundert Euro im Monat bei einem umfassenden ERP-System. Bei mehreren anderen ist die Zahl der Benutzer je nach Tarif begrenzt, sodass ein zusätzlicher Benutzer für das ganze Unternehmen einen teureren Tarif bedeuten kann. Und ein Dienstbenutzer, für den niemand verantwortlich ist, wird selbst zum Risiko und trägt zum Wildwuchs nichtmenschlicher Identitäten bei, über den Unite.AI bereits berichtet hat. Wie jedes andere Konto braucht auch dieser Benutzer eine verantwortliche Person und einen Prüftermin.

Auch dadurch erhalten Systeme, die keine Berechtigungsbereiche kennen, keine solchen. Aber Zurechenbarkeit und Widerruf liegen damit wieder in dem System, in das Prüfer tatsächlich Einblick nehmen.

Die strukturelle Lösung: delegierte Identität

Die richtige Lösung gibt es auf dem Papier bereits: den OAuth-2.0-Tokenaustausch (RFC 8693). Er unterscheidet zwischen Identitätsübernahme und Delegation. Bei einer Delegation behält der Agent seine eigene Identität, und das Token hält über den „act“-Claim fest, dass er im Auftrag einer Person handelt.

Auf die Buchhaltung übertragen würde das Folgendes bedeuten:

• Das Hauptbuch hält fest, dass dieser Agent im Auftrag dieser Person gebucht hat.
• Berechtigungsbereiche werden für jede Delegation einzeln vergeben, nicht für jeden Benutzer.
• Eine einzelne Delegation lässt sich widerrufen, ohne das Konto der betreffenden Person anzutasten.

Soweit ich herausfinden konnte, unterstützt keines der 32 Systeme etwas Vergleichbares. Vorerst bleibt es also ein Ziel, keine verfügbare Option. Damit richtet sich die Forderung an die Anbieter von Buchhaltungs- und ERP-Software und nicht an Integratoren: Agenten schreiben bereits in Ihre Hauptbücher, und Ihre APIs sollten das kenntlich machen können.

Was zu tun ist, bevor ein Agent auf ein Hauptbuch zugreift

Wenn Sie Agenten mit Buchhaltungs- oder ERP-Systemen verbinden, sollten Sie diese kurze Checkliste durchgehen:

1. Erfassen Sie das Zugangsdatenmodell jedes Zielsystems. Verwendet es OAuth oder einen statischen Schlüssel? Wie lange sind die Zugangsdaten gültig? Gibt es Berechtigungsbereiche, und lassen sie sich widerrufen?
2. Richten Sie trotzdem Ihre eigene Zugriffsebene ein. Identität pro Agent, Berechtigungsbereiche, Idempotenz und Freigaben gehören auf Ihre Seite – unabhängig davon, was das Zielsystem bietet.
3. Verwenden Sie, wo immer das System es zulässt, einen eigenen Benutzer für den Agenten. Nehmen Sie den Aufwand bei der Einrichtung und die Lizenzkosten als Preis für die Zurechenbarkeit in Kauf.
4. Gestalten Sie Ihr eigenes Prüfprotokoll manipulationssicher. Bei vielen Systemen wird es der einzige Nachweis dafür sein, dass ein Agent beteiligt war.
5. Dokumentieren Sie das Restrisiko. Wenn ein System keine Scopes und keine Möglichkeit zum Widerruf bietet, sagen Sie das Ihrem Kunden und halten Sie es in Ihrem eigenen Risikoregister fest.

Auf die Grenze kommt es an

Die Absicherung Ihres MCP-Servers ist notwendig. Sie reicht jedoch nicht aus. Die Sicherheit eines Agenten, der in ein Hauptbuch schreibt, entscheidet sich an der Grenze zwischen Ihrer Ebene und dem maßgeblichen Datensystem. Heute wird diese Grenze von den Systemen festgelegt, nicht von Ihnen.

Die gute Nachricht: Die Lücke ist klar umrissen. Die Standards existieren. Was fehlt, ist ihre Unterstützung in den Systemen, in denen die Bücher geführt werden.