MCP und OAuth2: Wer hat die Aktion des Agents auf Ihrem MCP-Server autorisiert?

Warum der Zugriff auf Tools die Identifizierung erschwert

Das Model Context Protocol (MCP) ist mittlerweile ein Standardelement für agierende KI-Systeme. Es bietet Modellen eine Möglichkeit, externe Tools, Ressourcen und Dienste zu entdecken und aufzurufen. Es ist nicht notwendig, eine individuelle Integration zwischen einem LLM und jeder API, mit der es in Kontakt kommt, zu erstellen; die Anwendung verbindet sich stattdessen mit einem MCP-Server und erfährt, was dieser Server anbietet. Das Durchsuchen einer Datenbank, das Erstellen eines GitHub-Issues, das Abfragen von Salesforce, das Versenden einer E-Mail oder das Abrufen von Datensätzen aus einem Unternehmenssystem – all das fällt unter dieselbe Operation, nämlich einen Tool-Aufruf.

Sobald eine KI handeln kann und nicht nur antworten, werden Identität und Autorisierung schnell kompliziert. Wer ist die KI und wer ist der Mensch dahinter? Wer hat die Aktion autorisiert und was genau darf die KI tun? Für welche Ressource galt die Autorisierung? Kann die KI diese Befugnis an einen anderen Dienst weitergeben? Und die wichtigste Frage: Kann OAuth2, ein Protokoll, das hauptsächlich darauf ausgerichtet ist, Software den Zugriff auf geschützte Ressourcen zu ermöglichen, angemessen einen autonomen Agenten darstellen, der im Auftrag einer Person handelt?

Die Antwort ist kompliziert. Der Ausdruck „im Auftrag von“ weist auf das OAuth2 Token Exchange-Protokoll hin. Die aktuelle MCP-Spezifikation erwähnt es nicht, obwohl klar ist, wo es Platz finden könnte – doch das würde die anderen unten genannten Mängel nicht beseitigen.

Wie MCP in der Praxis funktioniert

MCP definiert ein Standardprotokoll zwischen einem KI-Klienten und einem MCP-Server. Ein vereinfachtes Bild sieht so aus.

Die KI-Anwendung ist der MCP-Client, und der MCP-Server stellt ihm Funktionen zur Verfügung. Das Modell kann diese Funktionen entdecken und entscheiden, wann es sie aufrufen soll. Der bemerkenswerte Wandel besteht darin, dass das LLM nicht mehr nur Text erzeugt – es nimmt an einem Protokoll teil.

Stellen Sie sich einen Assistenten vor, der an einen MCP-Server für einen Unternehmens-Problemverfolgungs-Tool angebunden ist. Zuerst fragt der Client den Server nach den verfügbaren Tools.

{
  "method": "tools/list",
  "params": {}
}

Der Server antwortet mit seiner Liste der Tools.

{
  "tools": [
    {
      "name": "search_issues",
      "description": "Search project issues",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    },
    {
      "name": "create_issue",
      "description": "Create a new project issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  ]
}

Nun weiß das Modell, dass zwei Funktionen zur Verfügung stehen. Angenommen, der Benutzer bittet es, offene Authentifizierungsfehler zu finden und ein Problem zu erstellen, das den wichtigsten davon zusammenfasst. Der Agent könnte mit einem Suchaufruf beginnen.

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "query": "authentication bugs status:open"
    }
  }
}

Der Server gibt Probleme bei der Übereinstimmung an.

{
  "content": [
    {
      "type": "text",
      "text": "Found 17 open authentication issues."
    }
  ]
}

Das Modell liest die Ergebnisse, wählt das wichtigste aus und stellt eine zweite Anfrage.

{
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Critical authentication issue",
      "description": "Summary of the highest-priority authentication defect..."
    }
  }
}

Der Server bestätigt die Erstellung.

{
  "content": [
    {
      "type": "text",
      "text": "Issue AUTH-4821 created successfully."
    }
  ]
}

Hier wird das Sicherheitsproblem deutlich. Der Agent wechselt von der Lesung von Informationen zur Ausführung einer Aktion, die außerhalb des Systems sichtbar ist.

MCP löst das Identitätsproblem nicht

Eine häufige Fehlvorstellung ist, dass MCP das Identitätsproblem löst. Das tut es nicht. MCP definiert lediglich, wie Clients und Server miteinander interagieren, während Authentifizierung und Autorisierung eigenständige Themen sind.

Bei transportbasierten Protokollen auf HTTP basiert der Abschnitt zur Autorisierung in der aktuellen Spezifikation (die Überarbeitung vom 2026-07-28) auf OAuth 2.1. Der Abschnitt trägt den Titel „Authorization“, vermutlich weil dies der zentrale Schwerpunkt von OAuth2 ist, obwohl er auch Authentifizierungsmechanismen umfasst. MCP-Server fungieren als von OAuth2 geschützte Ressourcen und MCP-Clients als OAuth2-Clients. Die Spezifikation beinhaltet außerdem Informationen zu Metadaten geschützter Ressourcen, Metadaten von Autorisierungsservern, Ressourcenindikatoren sowie Verfahren zur Registrierung und Entdeckung von Clients. Dabei werden folgende Spezifikationen zusammengeführt:

• Der OAuth 2.1 IETF-Entwurf (draft-ietf-oauth-v2-1-13)
• Nutzung von Bearer Tokens in OAuth 2.0 (RFC 6750)
• Metadaten des Autorisierungs Servers in OAuth 2.0 (RFC 8414)
• Dynamische Registrierung von Clients in OAuth 2.0 (RFC 7591)
• Ressourcenindikatoren für OAuth 2.0 (RFC 8707)
• Metadaten geschützter Ressourcen in OAuth 2.0 (RFC 9728)
• Identifizierung des Ausstellers durch den Autorisierungs Server (RFC 9207)
• Metadokumente zur Client-ID in OAuth (ein IETF-Entwurf)
• OpenID Connect Discovery 1.0 und OpenID Connect Dynamic Client Registration 1.0

Das Protokoll wird stetig strenger. In der Überarbeitung von Juli 2026 müssen Clients den iss-Parameter überprüfen, um Angriffe durch Verwechslung von Autorisierungsservern zu verhindern; die Anmeldeinformationen der Clients sind mit dem Aussteller verknüpft, der sie erstellt hat, und die dynamische Clientregistrierung wird durch Client-ID-Metadokumente ersetzt. Ob OAuth2 für Agenten ausreicht, bleibt weiterhin ungeklärt.

OAuth existiert bereits vor Agenten

OAuth 2.0 wurde 2012 standardisiert, um eine recht einfache Frage zu beantworten: Wie kann ein Client eingeschränkten Zugriff auf eine geschützte Ressource erhalten, ohne das Passwort des Ressourcenbesitzers kennen zu müssen?

Das Modell funktionierte sehr gut und wurde zur Grundlage für delegierten API-Zugriff im Internet. Autonome KI bringt jedoch eine andere Art von Client mit sich. Ein OAuth2-Client bedeutete früher eine Anwendung. Ein Agent kann autonom sein, langlaufend und mehrschrittig arbeiten, dynamisch Werkzeuge auswählen, mehrere APIs aufrufen, Aufgaben delegieren, im Namen eines Menschen handeln und Entscheidungen treffen, die der Mensch nie ausdrücklich festgelegt hat. Das ist ein völlig anderes Autorisierungsproblem.

OAuth ist nicht ungesichert

Niemand sollte die Kritik übertrieben darstellen. RFC 6749 enthielt tatsächlich Sicherheitsaspekte, und seitdem hat OAuth2 eine umfangreiche Sicherheitsarchitektur entwickelt. Der Punkt ist, dass OAuth2 absichtlich als Framework konzipiert wurde und kein vollständiges, vorgeschriebenes Protokoll für jede moderne Implementierung ist. Die Implementierer konnten zahlreiche Sicherheitsentscheidungen treffen, und im Laufe der Zeit erkannte die Branche, dass bestimmte Kombinationen dieser Entscheidungen gefährlich sein konnten. Deshalb wurden weitere Ergänzungen vorgenommen: Client-Authentifizierung und -Entdeckung, geschützte Ressourcenmetadaten sowie Ressourcenindikatoren, gegenseitiger TLS-Verkehr, DPoP sowie andere sendereingeschränkte Token, Token-Bindung, PKCE sowie Leitlinien zur Erneuerung von Token. Die Anzahl dieser Ergänzungen war so groß, dass das IETF RFC 9700 veröffentlichte – ein Dokument mit den besten aktuellen Praktiken für die Sicherheit von OAuth 2.0, das auf RFCs 6749, 6750 und 6819 aufbaut und schwächere Betriebsmodi abschafft.

OAuth2 ist also nicht gescheitert – es hat sich weiterentwickelt. Doch diese Weiterentwicklung ist selbst ein Zeichen des zugrundeliegenden Problems: Die ursprüngliche Abstraktion benötigte immer wieder zusätzliche Mechanismen, da die Sicherheitsumgebungen immer komplizierter wurden.

Was repräsentiert das Token?

Kehren wir zum früheren Beispiel zurück. Der Benutzer bittet darum, ein Dokument zu erstellen, die KI entscheidet sich, ein MCP-Tool aufzurufen, und der Server erhält ein OAuth2-Zugriffstoken. Was steht für dieses Token? Es könnte der menschliche Benutzer, die KI-Anwendung, der MCP-Client, der MCP-Server, der im Auftrag des Menschen handelt, oder eine Kombination aus Anwendung und Benutzer sein. Diese sind nicht gleichwertig, und bei leicht unterschiedlichen, aber dennoch völlig legitimen OAuth2-Flüssen kann jede dieser Varianten auftreten.

Es ist umso wichtiger, wenn der MCP-Server eine andere API aufruft.

Mehrere Autorisierungsdomänen überschneiden sich nun. Bevor eine Aktion ausgeführt wird, muss der Server möglicherweise die Identität des Benutzers, den Agenten, der die Aufgabe ausführt, den MCP-Client, der die Anfrage gestartet hat, das, was der Benutzer genehmigt hat, die Tools, die der Agent verwenden darf, die verfügbaren downstream-APIs sowie prüfen, ob diese Aktion im Rahmen der ursprünglichen Genehmigung liegt. Das ist weitaus mehr als die einfache Darstellung unten.

Der verwirrte Stellvertreter

Eines der ernsthaftesten Sicherheitsrisiken bei MCP ist der verwirrte Stellvertreter. Angenommen, der MCP-Server erhält ein Token, das für ihn bestimmt ist, und ruft anschließend eine nachgelagerte API auf. Eine nachlässige Implementierung könnte dieses Token einfach weiterleiten – genau dieses Verhalten soll durch die aktuellen Sicherheitshinweise für MCP verhindert werden. Laut der Spezifikation muss ein Server überprüfen, ob ihm tatsächlich ein Token ausgestellt wurde, und darf das Token des Clients auf keinen Fall an einen anderen Dienst weitergeben. Wenn er eine vorangestellte API benötigt, sollte er ein anderes Token erhalten, das für diese nachgelagerte Ressource ausgestellt wurde. Das Prinzip lautet daher:

und nicht so:

Das erste Modell schafft getrennte Vertrauensgrenzen. Das Hinzufügen eines MCP-Gateways verschärft die Situation weiter, doch die Regel bleibt dieselbe: Niemals Token nachgelagert weitergeben.

Welche Rolle spielt OAuth2 bei MCP?

Auf vereinfachter Ebene sieht der Ablauf so aus.

Der MCP-Server ist die geschützte Ressource. Der Client erhält ein Zugriffstoken, übermittelt es bei jeder MCP-Operation und der Server validiert es. Das ist herkömmliches OAuth2. Die Spezifikation stärkt dies durch Ressourcenindikatoren (den resource-Parameter), sodass die Autorisierungsanfrage den spezifischen MCP-Server angibt, für den das Token bestimmt ist. Das ist gut, löst aber nicht wie durch Zauber alle Probleme bei der agierenden Autorisierung.

Was OIDC hinzufügt

OAuth2 beantwortet, auf was ein Client Zugriff hat. OIDC fügt eine Identitätsschicht hinzu, die angibt, wer der authentifizierte Benutzer ist – was für Agenten nützlich ist. Ein Identitätsanbieter kann einen Benutzer beispielsweise wie folgt authentifizieren:

Alice

OIDC kann Identitätsangaben über den Benutzer liefern, OAuth2 kann delegierte Autorisierung bereitstellen, und der MCP-Client kann anschließend ein Zugriffstoken erhalten, das eine dem Client für eine bestimmte Ressource erteilte Autorisierung darstellt. Konzeptionell sieht es so aus.

Es besteht jedoch weiterhin eine konzeptionelle Lücke: Die Authentifizierung des Benutzers autorisiert nicht jede Entscheidung des Agenten. Ein Benutzer könnte einer Anwendung erlauben, seine E-Mails zu lesen – das ist jedoch nicht dasselbe wie einem KI-Agenten zu erlauben, selbstständig beliebige E-Mails zu senden. Das ist ein Richtlinienproblem.

Das Problem mit Scopes

Scopes werden oft als Lösung dargestellt. Eine „Calendar-Read“-Autorisierung sieht so aus.

scope=calendar.read

und eine solche Zuschusszusage.

scope=email.send

Aber agierende Systeme zeigen, wie grob die Gültigkeitsbereiche sind. Nehmen wir beispielsweise die einfache Erlaubnis zum Versenden von E-Mails.

email.send

Lässt es die KI jemandem E-Mails schicken? Unbegrenzte Nachrichten senden? Finanzdokumente oder vertrauliche Unternehmensdaten versenden? Den Benutzer vortäuschen? Ohne Bestätigungsanfrage senden? Daraus geht es nicht hervor. Die eigentliche Entscheidung erfordert möglicherweise mehr Kontext in dieser Richtung.

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

Das sieht weniger nach traditionellen OAuth2-Scope-Definitionen aus und eher nach autorisierungsbasierten Richtlinien. Mit anderen Worten: Es handelt sich um den Unterschied zwischen grobkörnigen und feinkörnigen Entscheidungen bezüglich der Autorisierung.

Der Agent als neuer Sicherheitsprinzipal

Das könnte der wichtigste konzeptionelle Wandel sein. Traditionelle Anwendungen haben in der Regel eine recht stabile Identität. Ein KI-Agent hingegen kann dynamisch aus mehreren Komponenten gleichzeitig zusammengestellt werden.

Wer ist also der Sicherheitsprinzipal? Möglicherweise alle diese Komponenten. Das Autorisierungssystem muss möglicherweise mehr als nur „Alice darf auf Salesforce zugreifen“ angeben. Es muss ausdrücken, dass Alice diesen bestimmten Agenten, der über diese bestimmte Anwendung läuft, autorisiert hat, bestimmte Aktionen gegen diesen Salesforce-Tenant unter Berücksichtigung bestimmter Richtlinien durchzuführen. Das ist eine weitaus ausführlichere Angabe.

Es ist auch wie bei jedem System, das viele Zugriffstoken aus einer großen Gruppe von Benutzern – sowohl Menschen als auch Anwendungen – speichert, um auf zahlreiche downstream-Ressourcen zuzugreifen. Die Frage ist, ob dem Agenten vertraut werden kann, diese Token zu schützen und das richtige auszuwählen, wenn es an der Zeit ist, im Namen eines bestimmten Benutzers zu handeln.

Ist OAuth2 für Agenten fehlerhaft?

Diese Schlussfolgerung ist nicht gerechtfertigt. Eine bessere Formulierung lautet, dass OAuth2 nur einen Teil des Autorisierungsproblems bei Agenten löst, während das gesamte Problem größer ist als OAuth2. Es ist sehr gut im Delegierten Zugriff, den es auf diese Weise ermöglicht.

Ein Agentenökosystem benötigt mehr Antworten als das: Welcher Agent handelt im Namen welcher Person, mit welchem Tool, zu welchem Zweck, auf welcher Ressource, unter welcher Autorität und welcher Richtlinie, für wie lange, innerhalb welcher Transaktionsgrenzen und mit welcher menschlichen Genehmigung. Das Besitzen eines Zugriffstokens beseitigt keine dieser Fragen.

Neue Vorschläge

Mehrere Richtungen ergeben sich.

GNAP

Der offensichtlichste Kandidat auf Basis von Standards ist GNAP, das Grant Negotiation and Authorization Protocol. Es wurde entwickelt, um die Grenzen der Autorisierung und Delegation im OAuth2-Stil zu überwinden, indem es eine Möglichkeit bietet, die Autorisierung an Software zu delegieren und die daraus resultierenden Daten an diese weiterzuleiten – sowohl für den API-Zugriff als auch für Informationen über die betroffenen Subjekte. Sein Design ermöglicht eine umfassendere Delegation als OAuth2. GNAP ist mittlerweile als IETF Proposed Standard unter RFC 9635 dokumentiert, und RFC 9767 befasst sich mit Verbindungen zu Ressourcenservern. Es beantwortet zwar die Frage, ob jemand etwas über OAuth2 hinaus vorgeschlagen hat, doch es handelt sich dabei nicht um einen Ersatz speziell für MCP, und OAuth2 bleibt weiterhin dominierend.

Sicherheitsprotokolle speziell für MCP

Forscher schlagen außerdem Protokolle vor, die auf MCP und agiler KI basieren. Das Secure Model Context Protocol (SMCP) würde MCP um einheitliche Identitätsverwaltung, gegenseitige Authentifizierung, Übertragung von Sicherheitskontexten, feingranulare Richtlinienumsetzung sowie Auditing erweitern. Ein weiterer Vorschlag, MCPSec, sieht die Einführung von Fähigkeitszertifizierung und Nachrichtenauthentifizierung vor, um MCP-spezifische Bedrohungen entgegenzuwirken. Diese Bemühungen erkennen an, dass Authentifizierung nicht das einzige Problem ist. Ein Agentenökosystem muss nicht nur feststellen, wer jemand ist, sondern auch, welche Fähigkeiten er beansprucht und ob diese Ansprüche kryptografisch überprüft werden können. Das führt zu einer sicherheitsbasierten Herangehensweise, die auf Fähigkeiten beruht.

Befugnisvergabe auf Basis von Fähigkeiten

Dies könnte wichtiger sein als der Ersatz von OAuth. Anstatt einem Agenten den Scope email.send zu geben, könnte das System ihm eine eng definierte Fähigkeit zur Verfügung stellen.

Capability:
    Principal: Agent-472
    Subject: Alice
    Action: send-email
    Resource: alice@example.com
    Destination: bob@example.com
    Maximum: 1 message
    Expiration: 10 minutes

Der Agent besitzt ein kryptografisch überprüfbares Autorisierungsobjekt und darf diese Befugnis nicht für etwas anderes wiederverwenden. Das kommt dem viel näher, was agentbasierte Systeme benötigen, denn der Agent wird nicht nur authentifiziert – ihm wird eine spezifische Autorität übertragen.

OAuth2 plus etwas anderes

Die endgültige Architektur wird wahrscheinlich nicht behaupten, dass OAuth2 obsolet ist. Sie wird eher so aussehen.

OAuth2 stellt weiterhin Zugriffstoken aus, OIDC sichert die Identität des Benutzers, MCP bietet das Tool-Protokoll, ein Fähigkeits- oder Richtliniensystem begrenzt, was der Agent tatsächlich tun darf, und ein Richtlinien-Implementierungs-Punkt trifft die endgültige Entscheidung.

Das fehlende Element: Absicht

Intent ist etwas, womit herkömmliche Autorisierungsmechanismen nicht umgehen konnten. Nehmen wir an, ein Benutzer bittet einen Agenten, einen Flug nach Manila für unter 1.000 Dollar zu finden und zu buchen. Dabei könnte der Agent Fluggesellschaften durchsuchen, Preise vergleichen, den Kalender prüfen, Passdaten einsehen, einen Sitz reservieren und bezahlen. Der Benutzer hat nie jede dieser API-Anfragen einzeln genehmigt. Er hat lediglich einen Intent genehmigt, was sich stark von herkömmlicher Web-Autorisierung unterscheidet, da der Agent eine allgemeine Anweisung in eine Abfolge von Maschinenaktionen umwandelt. Das Sicherheitssystem muss hierbei entsprechend berücksichtigen, was geschieht.

Deshalb hat die Behauptung, dass OAuth2 für Agenten nicht funktioniert, einen gewissen Kern von Wahrheit – vorausgesetzt, die Kritik wird richtig verstanden. OAuth2 kann jede einzelne Anfrage autorisieren, bietet aber nicht von vornherein eine vollständige Möglichkeit, zu beurteilen, ob diese Anfragen zum Intent des Benutzers sowie zur dem Agenten übertragenen Befugnis passen.

MCP als Testfall

MCP zwingt die Gemeinschaft rund um Identität und Sicherheit, sich mit einem Problem auseinanderzusetzen, das sich bereits seit Jahren angesammelt hat. OAuth2 wurde um diese Kette herum konzipiert.

Agentic AI bringt etwas anderes mit sich.

Die Kette wird dynamisch – Teilnehmer können sich ändern, der Agent trifft Entscheidungen, Tools werden im Lauf der Zeit entdeckt, und der nachgelagerte Dienst hat möglicherweise noch nie vom ursprünglichen Benutzer gehört. Dennoch muss das System weiterhin beantworten, wer die Aktion autorisiert hat – was eine weitaus schwierigere Frage ist.

OAuth2 wird nicht verschwinden

Es ist verlockend zu behaupten, OAuth2 sei älter als KI und daher nicht für sie geeignet. Das ist zu einfach. OAuth2 hat enorme Veränderungen im Internet überlebt, weil es ein wirklich nützliches Delegierungsframework ist, und die MCP-Spezifikation basiert ausdrücklich auf OAuth 2.1 und gibt dieses nicht auf. Die wahrscheinlichere Zukunft sieht eine Weiterentwicklung vor:

• OAuth2 als Grundlage
• OIDC für Identitäten
• MCP für die Standardinteraktion mit Tools
• DPoP und verwandte Mechanismen für eine stärkere Bindung von Tokens
• Ressourcenindikatoren, um Tokens mit ihren vorgesehenen Ressourcen zu verknüpfen
• Fähigkeitssysteme, um einzuschränken, was Agenten tun dürfen
• Policy-Engines zur Bewertung des Kontexts
• Neuere Protokolle wie GNAP für erweiterte Delegationssemantiken

Die Veränderung in einer Idee

Agentenbasierte KI erzeugt nicht in erster Linie ein neues Authentifizierungsproblem. Das neue Problem sind Autorisierung und Delegation. Bei der Authentifizierung wird gefragt, wer man ist, während OAuth2 fragt, auf was man Zugriff haben darf. Bei der agentenbasierten Autorisierung muss geklärt werden, welche Befugnisse diesem Agenten übertragen wurden, im Namen wessen, gegenüber welchen Ressourcen und unter welchen Einschränkungen, sowie ob eine bestimmte Aktion dazu gehört. Das ist eine umfassendere Frage, und sie erfordert vermutlich ein umfassenderes Sicherheitsmodell.

Die Zukunft wird wahrscheinlich nicht zwischen OAuth2 und etwas Neuem entscheiden. Vielmehr werden OAuth2, OIDC, MCP, Fähigkeitsmodelle, Richtlinien, stärkere kryptografische Verbindungen sowie delegierte Aufgabenverwaltung, die auf Agenten basieren, zusammenwirken. MCP sorgt einfach dafür, dass die Grenzen der bestehenden Identitätsarchitekturen nicht mehr ignoriert werden können, was zu seinen wichtigsten Beiträgen für das KI-Ökosystem gehören könnte.