MCP Autorisierung: Tools sind keine Autorität

12 Minuten Lesezeit

MCP-Autorisierung beginnt dort, wo Tool Discovery endet. Ein MCP-Server kann ein Tool namens issue_refund Mit einem klaren Schema und einer ausgezeichneten Dokumentation. Ein fähiger Agent kann es entdecken, gültige Argumente vorbringen und es nennen. Nichts davon beantwortet die Frage, die ein Unternehmen beantworten muss, bevor sich Geld bewegt: Ist es diesem Agenten erlaubt, diesen Auftrag für diesen Betrag im Namen dieser Geschäftsfunktion zu erstatten, jetzt?

Werkzeugerkennung und Werkzeugautorisierung sind unterschiedliche Systeme. Wenn man sie so behandelt, dass man eine gefährliche Verknüpfung erzeugt, beweist die Authentifizierung, welche Berechtigung den Server erreicht hat. Ein Werkzeugschema beschreibt gültige Eingaben.

In diesem Artikel wird eine Autorisierungsgrenze für MCP entwickelt. Die Beispiele verwenden ein Rückerstattungstool, aber die gleiche Struktur gilt für Beschaffung, Cloud-Sanierung, Schadenbearbeitung, Kundendatensätze und jede Operation mit wesentlichen Konsequenzen.

MCP-Autorisierung benötigt vier Antworten für jeden Tool Call

Betrachten Sie diesen Antrag:

{
  "name": "issue_refund",
  "arguments": {
    "order_id": "ord_8421",
    "amount": "480.00",
    "currency": "EUR",
    "reason": "duplicate_charge"
  }
}

Ein Produktionsservice benötigt vier separate Antworten.

Wer ruft an? Lösen Sie den Laufzeitnachweis für einen Agenten und seine rechenschaftspflichtige Organisation.
Was wurde delegiert? Finden Sie einen laufenden Zuschuss, der die Maßnahme, die Ressourcen, den Zweck, den Betrag und den jeweiligen Geschäftspartner abdeckt.
Erlaubt die Richtlinie diese Transaktion? Bewerten Sie Geschäftsregeln, Genehmigungsschwellen, Aufgabentrennung und den aktuellen Risikozustand.
Was ist passiert? Binden Sie das Entscheidungs- und Ausführungsergebnis an die genaue Anfrage, damit eine andere Partei die Aufzeichnung später überprüfen kann.

Viele MCP-Bereitstellungen beantworten nur die erste Frage. Ein Bearer-Token identifiziert einen Client, dann ordnet der Server diesen Client einer breiten Rolle zu. Dies ist vertraut und manchmal ausreichend für risikoarme Lesevorgänge. Es wird spröde, wenn Agenten über mehrere Workflows hinweg arbeiten, Subagenten hervorbringen, Arbeit wiederholen und Werkzeugargumente dynamisch auswählen.

Die Autorisierung gehört an die Werkzeuggrenze, wo der Server den Aufruf ablehnen oder einschränken kann, unabhängig davon, was das Modell sagt.

Beginnen Sie mit Identität, dann weigern Sie sich, dort zu stoppen

OAuth, mTLS, SPIFFE-Identitäten und signierte Token sind nützliche Grundlagen. Sie können feststellen, dass eine Anfrage von einer bekannten Workload stammt. Sie erklären nicht, warum die Workload diese Anfrage stellt.

Angenommen, ein OAuth-Client gehört customer-operations-agentDieser Agent kann mehrere legitime Jobs haben:

Lesen Sie einen Fall, um es zusammenzufassen;
Entwurf eines Entschließungsentwurfs;
Erstattung kleiner Doppelgebühren;
Route größere Erstattungen an einen Vorgesetzten.

Eine Rolle wie refund_agent Diese Unterscheidungen werden zu einem Etikett komprimiert. Einmal zugewiesen, neigt es dazu, ständige Autorität zu werden. Das Etikett drückt selten die Reihenfolge, den Fall, den Zweck, den Höchstbetrag, den Ablauf oder das Ziel aus, die den Vorgang einschränken sollten.

Bewahren Sie die Workload-Identität, die organisatorische Rechenschaftspflicht und die delegierte Befugnis als separate Aufzeichnungen auf. Der Laufzeitnachweis authentifiziert den aktuellen Anrufer. Ein Agentenpass oder ein vergleichbares Ausweisdokument verbindet ihn mit einer Organisation. Ein kurzlebiges Mandat gibt an, was ein Auftraggeber für eine begrenzte Aufgabe delegiert hat.

Dieses Mandat könnte so aussehen. Das Beispiel ist illustrativ, keine Kopie eines MCP-Protokollobjekts:

{
  "id": "mandate:refund:case-773",
  "subject": "agent:customer-ops:17",
  "issuer": "org:retailer:customer-care",
  "purpose": "resolve_duplicate_charge",
  "actions": ["orders.read", "refunds.create"],
  "resources": ["order:ord_8421"],
  "constraints": {
    "currency": "EUR",
    "max_amount": "500.00",
    "destinations": ["original_payment_method"],
    "max_uses": 1
  },
  "not_before": "2026-08-10T10:00:00Z",
  "expires_at": "2026-08-10T10:15:00Z"
}

Die werkzeugbeschreibung sagt dem modell immer noch, wie man anruft. issue_refundDas Mandat teilt der Durchsetzungsschicht mit, ob diese Instanz des Agenten für die vorgeschlagene Aufforderung zuständig ist.

Legen Sie einen Autorisierungsumschlag um die MCP-Anfrage

MCP sollte das Werkzeugprotokoll bleiben. Die Autorisierungsschicht sollte einen Folgeaufruf in einen Transaktionsumschlag vor der Ausführung normalisieren.

type ToolTransaction = {
  transactionId: string
  agentId: string
  organisationId: string
  mandateId: string
  tool: string
  action: string
  resource: string
  purpose: string
  audience: string
  requestDigest: string
  issuedAt: string
  nonce: string
}

async function authorizeMcpCall(call: ToolCall, context: RuntimeContext) {
  const identity = await verifyRuntimeProof(context.proof)
  const mandate = await resolveMandate(context.mandateId)
  const tx = normalizeToolCall(call, identity, mandate)

  verifySignature(context.signedEnvelope, tx)
  verifyAudienceAndTime(tx, context.expectedAudience)
  const receivedDigest = digestMcpCall(call)
  assert(receivedDigest === tx.requestDigest)
  await replayStore.claim(tx.transactionId, tx.nonce)
  assertMandateCoversTransaction(mandate, tx)

  return policy.evaluate({ identity, mandate, transaction: tx })
}

Die requestDigest Wenn ein Proxy, Modell oder eine Anwendung die Bestell-ID, den Betrag, das Ziel oder den Grund nach der Autorisierung ändert, stimmt der Digest nicht mehr überein. Eine Unterschrift über eine vage Aussage wie "Call-Refund-Tool" reicht nicht aus.

Die gewöhnliche JSON-Serialisierung ist riskant, da Schlüsselbestellung, Zahlenformatierung und Unicode-Handling unterschiedlich sein können. Das OATI-Entwicklervorschauprofil verwendet aus diesem Grund RFC 8785 JSON Canonicalization Scheme Nutzlasten und gemeinsame Konformitätsvektoren.

Bewerten Sie Einschränkungen als Daten, nicht Prosa

Fragen Sie kein Sprachmodell, ob das Mandat die Erstattung zulässt, sondern die Antwort muss deterministisch und wiederholbar sein.

function evaluateRefund(m: Mandate, call: RefundCall): Decision {
  if (m.status !== "active") return deny("mandate_inactive")
  if (Date.now() >= Date.parse(m.expiresAt)) return deny("mandate_expired")
  if (!m.actions.includes("refunds.create")) return deny("action_not_allowed")
  if (!m.resources.includes(`order:${call.orderId}`)) return deny("resource_not_allowed")
  if (call.currency !== m.constraints.currency) return deny("currency_mismatch")
  if (decimal(call.amount).gt(decimal(m.constraints.maxAmount))) {
    return requireApproval("amount_above_autonomous_limit")
  }
  if (call.destination !== "original_payment_method") {
    return deny("destination_not_allowed")
  }
  return allow()
}

Verwende Dezimalarithmetik für Geld, prüfe den aktuellen Status und Widerruf, nicht nur den Ablauf von Dokumenten, beanspruche Nutzung und Wiedergabezustand atomar vor der Ausführung, wenn die Entscheidung von einem Paket von Geschäftsrichtlinien abhängt, notiere seinen Digest und seine Version.

Das OATI-Entscheidungsschema kann allow, deny, transform und approval_required, während der aktuelle Referenzbewerter allow oder deny. Ein Produktionsorchestrator kann Transformations- und Genehmigungsbehandlungen um diesen Bewerter herum hinzufügen. Eine Transformation kann optionale Felder entfernen oder ein angefordertes Limit senken. Sie darf niemals stillschweigend die geschäftliche Bedeutung der Transaktion ändern.

Anmeldeinformationen außerhalb der Reichweite des Modells halten

Selbst ein gut autorisierter Agent sollte in seinem Kontext keine langlebige Zahlungs- oder Dienstanmeldeinformationen erhalten.Das Gateway kann nach der Entscheidung eine kurzlebige Anmeldeinformationen erhalten, diese nach Möglichkeit an den Zieldienst binden und in die ausgehende Anfrage einspeisen.

MCP client
  -> MCP authorization gateway
  -> identity and mandate verification
  -> deterministic policy decision
  -> temporary credential broker
  -> existing refund API
  -> response filter
  -> signed receipt

Wenn jeder Folgepfad die Durchsetzung durchläuft, kann bösartiger Text das Modell dazu überreden, einen nicht autorisierten Anruf zu versuchen, aber das Modell sollte nicht in der Lage sein, Autorität zu prägen, Richtlinien zu erweitern oder einen Nachweis zu liefern, den es nie erhält.

Bindende Beweise für die beobachtete Ausführung

Der Dienst sollte sowohl erlaubte als auch abgelehnte Versuche aufzeichnen, und für einen zulässigen Anruf sollte die Quittung den Agenten, die Organisation, das Mandat, die Transaktion, die Entscheidung und das beobachtete Ergebnis verbinden.

{
  "id": "receipt:refund:tx-9912",
  "transaction_id": "tx:refund:9912",
  "agent_id": "agent:customer-ops:17",
  "organisation_id": "org:retailer",
  "mandate_id": "mandate:refund:case-773",
  "decision": "allow",
  "outcome": "succeeded",
  "request_digest": "sha256:...",
  "policy_digest": "sha256:...",
  "external_reference": "refund_provider:rf_317",
  "occurred_at": "2026-08-10T10:04:31Z"
}

Die Unterschrift beweist, was der Emittent über seinen Aufzeichnungs- und Kontrollpfad bestätigt hat. Sie beweist nicht, dass es keine Umgehung gab, dass der Anspruch des Kunden wahrheitsgemäß war oder dass der externe Datensatz des Zahlungsdienstleisters korrekt ist.

Wählen Sie den Durchsetzungspunkt, den Sie verteidigen können

Es gibt drei praktische Orte, um dieses Design durchzusetzen. Ein MCP-Server kann die Verifizierung direkt in jeden sensiblen Handler einbetten. Das hält die Entscheidung kurz vor der Ausführung, aber duplizierte Bibliotheken und Richtlinienkonfigurationen können über Server hinweg driften. Ein freigegebenes MCP-Gateway kann Anrufe abfangen, bevor sie bestehende Server erreichen. Das zentralisiert die Normalisierung und Richtlinie, obwohl es zu einer hochwertigen Komponente wird, die eine Mandantenisolierung, Wiedergabeschutz und sorgfältige Verfügbarkeitstechnik erfordert. Ein Dienst kann auch seine gewöhnliche HTTP- oder gRPC-API durchsetzen, nachdem der MCP-Server den Anruf übersetzt hat. Dies schützt jeden Anrufer, nicht nur MCP-Clients, sondern erfordert die Übersetzungsschicht, um den signierten Transaktionskontext zu erhalten.

Für eine wesentliche Aktion, verwenden Sie Verteidigung in der Tiefe. Lassen Sie das Gateway den Anrufer und die Reservenutzung überprüfen, dann lassen Sie den Dienst den Transaktionsverdau und die Entscheidung bestätigen, bevor Sie die Operation ausführen. Vermeiden Sie zwei unabhängige Richtlinienimplementierungen. Der Dienst sollte ein authentifiziertes Entscheidungsartefakt überprüfen oder den gleichen deterministischen Bewerter mit dem gleichen signierten Richtlinienpaket aufrufen.

Die lokale Auswertung ändert auch die Ausfall-Story. Ein kundenseitiges Gateway kann mit signierten Richtlinienpaketen und einem neuen Widerrufszustand fortfahren, wenn die Steuerungsebene nicht erreichbar ist. Hochrisiko-Schreiben sollten fehlschlagen, wenn der Vertrauens- oder Wiedergabezustand zu alt ist, um eine vertretbare Entscheidung zu unterstützen. Explizit konfigurierte risikoarme Lesevorgänge können eine andere Regel verwenden. Die Klassifizierung gehört in die Richtlinie, nicht in einen generischen "fail open"-Schalter.

Beobachtbarkeit muss die gleiche Grenze einhalten. Senden Sie Transaktions-IDs, Entscheidungsgründe, Richtlinienversionen und Timings an die zentrale Telemetrie. Bewahren Sie rohe Eingabeaufforderungen, Werkzeugnutzlasten und Geheimnisse in der Kundenumgebung auf, es sei denn, der Kunde hat ihre Veröffentlichung genehmigt. Das Debuggen von Bequemlichkeit ist kein Grund, die Autorisierungsebene in eine Kopie sensibler Geschäftsdaten zu verwandeln.

Bedrohungen, die Ihre Happy-Path-Demo verpassen wird

Mandatsersetzung. Der Anrufer fügt ein gültiges Mandat für einen anderen Fall bei.

Argument mutation. Middleware autorisiert 48 EUR, dann reicht eine nachgelagerte Komponente 480 EUR ein. Binden Sie den kanonischen Request Digest und überprüfen Sie ihn an der endgültigen Ausführungsgrenze.

Publikum Verwirrung. Eine signierte Anfrage, die für einen Testserver bestimmt ist, wird von der Produktion akzeptiert, erfordert die erwartete Zielgruppe und lehnt wiederverwendbare Beweise ab.

Wiederholung. Ein gültiger einmaliger Rückerstattungsaufruf wird zweimal eingereicht. Atomisch beanspruchen Sie die Transaktions-ID, Nonce, Mandatsnutzung und den Provider-Idempotenzschlüssel.

Stale Autorität. Ein zwischengespeichertes Mandat bleibt nach einer Notfall-Aufhebung akzeptiert. Definieren Sie Cache-Alter, Widerrufs-Lookup-Verhalten und ausgefallene Regeln für wesentliche Aktionen.

Tool Aliasing. Zwei MCP-Server veröffentlichen ähnliche Toolnamen mit unterschiedlichen Effekten.

Verwirrter Abgeordneter. Ein Agent mit niedrigem Privileg bittet einen privilegierten Tool-Server, seine eigene breite Berechtigung zu verwenden.Erfordern Sie die delegierte Autorität des Anrufers, auch wenn der Server Ausführungsdaten besitzt.

Ausgabeleckage. Die Aktion ist autorisiert, aber die Antwort enthält Felder, die der Agent möglicherweise nicht erhält.

Eine Implementierungs-Checkliste

Bilden Sie jeden Laufzeitnachweis einem stabilen Agenten und einer verantwortlichen Organisation zu.
Separate Capability Discovery von der transaktionsspezifischen Befugnis.
Definieren Sie stabile Aktions- und Ressourcenkennungen für Folgewerkzeuge.
Normalisieren Sie MCP-Aufrufe in einen kanonischen Transaktionsumschlag.
Binden Sie Signaturen an Publikum, Zeit, Nonce und den genauen Request Digest.
Beheben Sie Emittent, Schlüssel, Status und Widerruf vor der Richtliniebewertung.
Bewerten Sie Mandate und Geschäftspolitik mit deterministischem Code.
Reklamation Replay, Nutzung und Budget Zustand atomar.
Route Ausnahmen durch eine Genehmigung, die die genaue Transaktion verweist.
Broker kurzlebige Anmeldeinformationen nach Genehmigung.
Filtern Sie die Antworten nach Ziel- und Datennutzungsregeln.
Quittungen unterzeichnen und Korrelationsdaten für den Abgleich aufbewahren.
Testsubstitution, Mutation, Wiederholung, abgestandene Cache- und Teilfehlerfälle.

Wo OATI heute passt

OATI modelliert diese Grenze mit Passport, MandatTransaktionsumschlag, Entscheidung und Eingang Objekte. Das öffentliche Entwickler-Vorschau-Framework umfasst JSON Schemas, kanonisches JSON, Signaturverifizierung, deterministische Mandatsbewertung, Lookup und Discovery, TypeScript Middleware und gemeinsame Konformitätsvektoren für TypeScript, Python und Go. Die veröffentlichte Suite enthält derzeit 73 sprachneutrale Fälle.

Der Policy Compiler und der dauerhafte Evidenz- und Streithelfer bleiben unvollständig, und das Kunden-Gateway ist eher eine Referenzintegration als eine vollständig betriebene kommerzielle Flotte.

Der nützliche architektonische Punkt hängt nicht von der Einführung von OATI ab: MCP soll Werkzeugaufrufe beschreiben und übertragen, aber eine unabhängige Autorisierungsschicht erfordern, um zu entscheiden, ob ein bestimmter Agent eine bestimmte Transaktion ausführen kann.