Laravel MCP absichern: Checkliste vor dem Livegang

Ein MCP-Endpunkt kann erreichbar sein, ein Token kann gültig sein und ein Agent kann die vorgesehenen Tools erkennen. Für den Produktiveinsatz reicht das nicht aus. Für jede Aktion muss feststehen, welche Identität sie auslöst, auf welche Daten sie zugreifen darf und wann eine technische Freigabe erforderlich ist.

Ein Laravel-AI-Agent ist erst dann produktionsreif, wenn jede erreichbare Aktion einer bekannten Identität, einem begrenzten Datenbereich und einer überprüfbaren Freigaberegel zugeordnet ist. Das Framework liefert dafür Bausteine. Die fachlichen Grenzen entstehen jedoch erst durch deine Anwendung.

Warum AI- und MCP-Funktionen eine eigene Sicherheitsprüfung brauchen

Ein klassischer API-Client ruft meist einen bekannten Endpunkt mit vorhersehbaren Parametern auf. Ein AI-Agent entscheidet dagegen anhand von Anweisungen, Modellantworten und bereitgestelltem Kontext, welches Tool er verwendet. Ein Tool ist dabei eine vom Agent aufrufbare Funktion, etwa eine Kundensuche, das Erstellen eines Angebots oder das Auslösen einer E-Mail.

Das vergrößert den prüfbaren Bereich. Du musst nicht nur den MCP-Server und seine Anmeldung betrachten, sondern auch die Tool-Auswahl, die übergebenen Parameter, externe Inhalte im Modellkontext und mögliche Folgewirkungen. Eine manipulierte Eingabe darf den Agent beispielsweise nicht dazu bringen, Datensätze außerhalb des erlaubten Mandanten zu lesen oder eine eigentlich freigabepflichtige Aktion direkt auszuführen.

Der aktuelle Ausbau des Laravel-Ökosystems macht diese Trennung wichtiger. Das Laravel AI SDK v1.0 wurde am 23. September 2026 veröffentlicht und bringt unter anderem Agents, Tool-Freigaben, Streaming und Konversationsspeicherung mit. Solche Funktionen erleichtern die Umsetzung. Sie beantworten aber nicht automatisch, welche Daten und Aktionen dein konkreter Agent erreichen darf.

Erstelle zuerst eine vollständige Verbindungskarte

Bevor du über OAuth oder Tokens entscheidest, musst du wissen, welche Verbindungen tatsächlich existieren. Eine reine Liste der MCP-Tools reicht dafür nicht. Relevant ist der gesamte Weg von der auslösenden Person bis zur fachlichen Nebenwirkung.

Halte für jeden Agent und MCP-Server mindestens folgende Angaben fest:

Auslöser: Startet ein eingeloggter Mitarbeiter, ein externer Kunde, ein Zeitplan oder ein anderes System die Aktion?
Identität: Unter welchem Benutzer, Mandanten oder technischen Konto läuft der Aufruf?
Tools: Welche lesenden und schreibenden Funktionen stehen tatsächlich zur Verfügung?
Datenquellen: Greift der Agent auf die Laravel-Datenbank, hochgeladene Dokumente, E-Mails oder externe APIs zu?
Folgewirkungen: Werden Nachrichten verschickt, Dateien erzeugt, Zahlungen vorbereitet oder interne Status geändert?
Externe Anbieter: Welche Prompts, Dokumente, Metadaten oder Tool-Ergebnisse verlassen deine Anwendung?
Freigaben: Welche Aktion darf automatisch laufen und welche braucht eine ausdrückliche Bestätigung?

Diese Verbindungskarte verhindert eine typische Lücke: Ein einzelnes Tool wirkt harmlos, erhält aber zusammen mit einem breit berechtigten technischen Konto Zugriff auf wesentlich mehr Daten als vorgesehen. Wenn du noch klärst, welche Funktion überhaupt als erster Anwendungsfall geeignet ist, hilft die Einordnung zum ersten sinnvollen MCP-Use-Case in Laravel.

Wähle die Authentifizierung nach dem Verbindungstyp

OAuth 2.1, Sanctum und Bearer Tokens sind keine austauschbaren Etiketten. Sie lösen unterschiedliche Teile des Zugriffsproblems. Zudem ist „Bearer“ zunächst eine Art, ein Token beim Request zu übertragen. Auch ein per OAuth ausgestelltes Access-Token kann als Bearer Token gesendet werden.

Laravel MCP unterstützt für geschützte Server unter anderem OAuth 2.1 und Sanctum. Zusätzlich lassen sich Zugriffe über Middleware kontrollieren. Welche Variante passt, hängt davon ab, wer den MCP-Client betreibt und wie Identitäten, Ablaufzeiten und Widerrufe verwaltet werden sollen.

OAuth 2.1 für delegierte Zugriffe

OAuth 2.1 passt, wenn ein externer oder eigenständiger Client im Namen eines Benutzers auf deinen MCP-Server zugreifen soll. Der Benutzer kann einen Zugriff autorisieren, ohne sein Passwort an den Client weiterzugeben. Außerdem lassen sich Zugriffsrechte, Laufzeiten und Widerrufe in einen geregelten Autorisierungsprozess einbinden.

Die Einführung lohnt sich allerdings nur, wenn du den vollständigen Ablauf kontrollierst. Dazu gehören erlaubte Redirect-URIs, registrierte Clients, Token-Laufzeiten, Widerruf und eine eindeutige Zuordnung zum Benutzer und Mandanten. Ein erfolgreich ausgestelltes Token ersetzt weiterhin keine Berechtigungsprüfung am Tool.

Sanctum für kontrollierte Laravel-Clients

Sanctum ist häufig passend, wenn deine Laravel-Anwendung und der zugreifende Client unter gemeinsamer Kontrolle stehen. Das gilt beispielsweise für eine eigene Oberfläche oder eine interne Integration mit persönlichen API-Tokens. Du kannst Fähigkeiten am Token hinterlegen, solltest sie aber als erste Schranke verstehen.

Eine Fähigkeit wie customers:read erlaubt noch nicht automatisch den Zugriff auf jeden Kunden. Die Anwendung muss zusätzlich prüfen, ob der aktuelle Benutzer den angefragten Datensatz innerhalb seines Unternehmens oder Mandanten sehen darf.

Statische Bearer Tokens nur für eng begrenzte Verbindungen

Ein manuell vergebenes Bearer Token kann für eine einzelne technische Verbindung vertretbar sein, wenn beide Seiten von dir kontrolliert werden und der Funktionsumfang klein bleibt. Das Token braucht einen eindeutigen Besitzer, minimale Rechte, eine geregelte Rotation und eine sofortige Widerrufsmöglichkeit.

Problematisch wird ein gemeinsam verwendetes Token ohne Ablauf oder Herkunftszuordnung. Im Protokoll siehst du dann zwar, dass „die Integration“ gehandelt hat, aber nicht, welcher Benutzer die Aktion ausgelöst hat. Für Zugriffe im Namen wechselnder Personen ist ein statisches Token deshalb eine schlechte Abkürzung.

Prüfe Berechtigungen innerhalb jedes MCP-Tools

Route-Middleware schützt den Eingang des MCP-Servers. Die eigentliche Autorisierung gehört zusätzlich in die fachliche Aktion. Dafür kannst du in Laravel Policies oder Gates verwenden. Eine Policy bündelt die Regel, ob ein Benutzer eine bestimmte Aktion an einem konkreten Modell ausführen darf.

Ein Tool zur Kundensuche sollte den Mandanten nicht einfach als vertrauenswürdigen Parameter übernehmen. Der erlaubte Mandant muss aus der authentifizierten Identität oder einer serverseitig geprüften Zuordnung folgen. Dasselbe gilt für Projekt-IDs, Dateipfade, Empfängeradressen und andere Objektbezüge.

Prüfe pro Tool diese Ebenen:

Zugriff auf das Tool: Darf die Identität diese Funktion grundsätzlich aufrufen?
Zugriff auf das Objekt: Gehört der angefragte Datensatz zum erlaubten Bereich?
Zulässige Parameter: Stimmen Format, Wertebereich und erlaubte Auswahl?
Zulässiger Zustandswechsel: Darf das Objekt aus seinem aktuellen Status in den gewünschten Status wechseln?
Freigabestatus: Liegt für eine sensible Aktion eine gültige Bestätigung vor?

Behandle Tool-Parameter dabei wie normale externe Eingaben. Das Modell kann plausible, aber falsche IDs, Beträge oder Empfänger liefern. Eine saubere Laravel-Validierung bleibt deshalb erforderlich. Die Abgrenzung zwischen wiederverwendbarer Validierung und Controller-Logik erklärt der Artikel Laravel Form Request oder Controller-Validierung.

Falls ein Tool seine Arbeit an einen Queue-Job übergibt, sollte der Job die relevante Identität und den fachlichen Kontext nachvollziehbar mitführen. Bei zeitversetzten Schreibzugriffen ist außerdem zu prüfen, ob die Berechtigung zum Ausführungszeitpunkt noch besteht. Eine Freigabe von gestern ist kein Freibrief für einen inzwischen gesperrten Benutzer.

Begrenze Tools nach ihrer möglichen Wirkung

Ein Agent sollte nicht vorsorglich alle verfügbaren Tools erhalten. Stelle für den jeweiligen Prozess nur die Funktionen bereit, die er benötigt. Ein Agent zur Beantwortung interner Produktfragen braucht keinen allgemeinen HTTP-Client, keinen beliebigen Dateizugriff und erst recht keine Funktion zum Ausführen frei formulierter Datenbankabfragen.

Für die praktische Einteilung helfen drei Wirkungsklassen:

Lesend: Ein Tool sucht oder zeigt bereits erlaubte Informationen. Auch hier bleiben Mandanten- und Datenschutzgrenzen notwendig.
Vorbereitend: Ein Tool erstellt einen Entwurf, berechnet einen Vorschlag oder füllt ein Formular vor. Die Wirkung bleibt bis zur Prüfung reversibel.
Ausführend: Ein Tool versendet, veröffentlicht, löscht, bestellt oder verändert einen verbindlichen Status. Dafür sind engere Berechtigungen und häufig eine Freigabe nötig.

Breite Universal-Tools sparen bei der Entwicklung einige Methodennamen, vergrößern aber die Angriffs- und Fehlerfläche. Eine fachlich enge Funktion wie „Angebotsentwurf für freigegebenes Projekt erstellen“ lässt sich besser validieren als „beliebigen Datensatz aktualisieren“.

Baue Freigaben als serverseitige Regel

Eine Anweisung im System-Prompt wie „Frage vor dem Versand nach“ ist keine belastbare Freigabekontrolle. Das Modell kann den Dialog interpretieren, doch die Anwendung muss die Freigabe technisch erzwingen. Der Versand-Endpunkt darf erst arbeiten, wenn eine gültige Bestätigung vorliegt.

Eine brauchbare Freigabe ist an die konkrete Aktion gebunden. Sie sollte mindestens den freigebenden Benutzer, das Tool, das Zielobjekt und die relevanten Parameter erfassen. Änderst du nach der Bestätigung den Empfänger oder Betrag, ist eine neue Freigabe erforderlich. Sinnvoll sind außerdem eine begrenzte Gültigkeit und ein Schutz vor mehrfacher Verwendung.

Für sensible Vorgänge ist ein Entwurfsprinzip meist robuster: Der Agent bereitet das Ergebnis vor, ein Mensch prüft es, und erst eine separate Laravel-Aktion führt es aus. So bleibt die fachliche Entscheidung außerhalb der Modellantwort nachvollziehbar.

Prüfe beim Upgrade von Laravel MCP 0.x auf 1.x die Protokollgrenzen

Ein Versionswechsel am MCP-Paket ist keine gewöhnliche Abhängigkeitsaktualisierung, wenn externe Clients mit deinem Server verbunden sind. Laut offiziellem Upgrade Guide für Laravel MCP kann der Wechsel auf Version 1.0 Anpassungen am Protokoll-Handshake, an Client-ID-Metadaten und an der Speicherung optionaler Client-Secrets erfordern.

Inventarisiere deshalb vor dem Upgrade alle verbundenen Clients und teste jeden davon gegen eine nicht produktive Umgebung. Entscheidend ist nicht allein, ob die Verbindung aufgebaut wird. Prüfe auch, ob die erwartete Client-Identität ankommt, bestehende Tokens korrekt behandelt werden und unbekannte oder unvollständig registrierte Clients abgewiesen werden.

Ändert sich die Speicherung von Client-Secrets, gehören vorhandene Daten, Verschlüsselung, Backups und Widerrufsprozesse ebenfalls in die Prüfung. Alte Secrets sollten nicht nur deshalb weiter gültig bleiben, weil ihre Abschaltung unbequem wäre. Plane vor der Umstellung, wie du fehlerhafte Clients zurücksetzt oder vorübergehend auf die bisherige Version zurückgehst.

Teste Missbrauchsszenarien statt nur den Idealablauf

Ein erfolgreicher End-to-End-Test belegt lediglich, dass der vorgesehene Ablauf funktioniert. Für den Livegang brauchst du zusätzlich negative Tests, bei denen Laravel den Zugriff ausdrücklich verweigern muss.

Mindestens diese Fälle sollten reproduzierbar geprüft werden:

Ein Request ohne Token oder mit widerrufenem Token erreicht kein geschütztes Tool.
Ein gültiger Benutzer kann keine Daten eines anderen Mandanten abrufen.
Ein lesend berechtigter Client kann kein schreibendes Tool ausführen.
Manipulierte IDs, Dateipfade, URLs und Empfänger werden serverseitig abgelehnt.
Eine Freigabe kann nicht für geänderte Parameter oder eine zweite Ausführung wiederverwendet werden.
Inhalte aus Dokumenten oder E-Mails können keine zusätzlichen Tools freischalten.
Ein gesperrter Benutzer verliert auch den Zugriff über bereits gestartete Hintergrundprozesse.
Ein nicht registrierter oder falsch konfigurierter MCP-Client scheitert kontrolliert.

Solche Tests gehören möglichst in die automatisierte Test-Suite. Für besonders kritische Aktionen ist zusätzlich ein manueller Abnahmetest sinnvoll, weil dabei auch Oberfläche, Freigabetext und tatsächliche Nebenwirkungen geprüft werden können.

Die Prüfung für Deployment und laufenden Betrieb

Vor der produktiven Freigabe sollte eine verantwortliche Person die folgende Liste mit konkreten Nachweisen durchgehen. Jeder Punkt benötigt einen zugehörigen Test, Konfigurationseintrag oder eine dokumentierte Entscheidung.

Secrets: API-Schlüssel und Client-Secrets liegen außerhalb des Repositorys, sind nach Umgebung getrennt und können rotiert werden.
Umgebung: Test- und Produktionssystem verwenden getrennte Clients, Tokens, Datenquellen und Callback-Adressen.
Tools: Nur benötigte Funktionen sind registriert; schreibende Aktionen sind gesondert beschränkt.
Autorisierung: Middleware schützt den Server, Policies oder Gates prüfen die konkrete Ressource.
Validierung: Sämtliche Tool-Eingaben werden unabhängig von der Modellantwort geprüft.
Freigaben: Kritische Aktionen lassen sich ohne passende serverseitige Bestätigung nicht ausführen.
Protokollierung: Tool, auslösende Identität, Zielobjekt, Ergebnis und Korrelations-ID werden nachvollziehbar erfasst.
Datenschutz: Prompts, Tool-Ergebnisse und Logs enthalten nur die für den Zweck erforderlichen Daten.
Fehlerverhalten: Fehlermeldungen verraten keine Secrets, internen Pfade oder fremden Datensätze.
Abschaltung: Einzelne Tools, Clients oder der gesamte Agent lassen sich kurzfristig deaktivieren.
Rückfallplan: Für Paket- und Protokolländerungen ist bekannt, wie du auf eine funktionierende Version zurückkehrst.

Im Betrieb solltest du fehlgeschlagene Anmeldungen, verweigerte Autorisierungen, ungewöhnlich häufige Tool-Aufrufe und Fehler bei sensiblen Aktionen sichtbar machen. Protokolliere dafür keine vollständigen Prompts oder Zugangsdaten auf Verdacht. Häufig reichen strukturierte Metadaten, um einen Vorgang zuzuordnen, ohne zusätzliche sensible Inhalte anzusammeln.

Updates am AI SDK, MCP-Paket, Authentifizierungsserver und verwendeten Clients brauchen einen festen Prüfweg. Lies die jeweiligen Upgrade- und Sicherheitshinweise, teste die verbundenen Clients und kontrolliere nach dem Deployment die abgewiesenen sowie erfolgreichen Zugriffe. Bei Schnittstellen mit Schreibrechten sollten automatische Paketupdates erst nach einem Integrationstest in die Produktion gelangen.

Produktionsreif bedeutet begrenzbar und widerrufbar

Ein Laravel-AI-Agent mit MCP ist nicht deshalb produktionsreif, weil er im Test zuverlässig das richtige Tool auswählt. Entscheidend ist, was bei einer falschen Auswahl, manipulierten Eingabe oder kompromittierten Verbindung passiert.

Vor dem Livegang müssen deshalb drei Grenzen nachweisbar sein: Die Identität bestimmt den erlaubten Datenbereich, jedes Tool erzwingt seine fachlichen Berechtigungen, und sensible Wirkungen benötigen eine serverseitige Freigabe. Ergänzt um negative Tests, widerrufbare Zugangsdaten und einen funktionierenden Abschaltweg entsteht eine Integration, deren mögliche Fehler begrenzt bleiben.

Reicht Laravel Sanctum zur Absicherung eines MCP-Servers aus?

Sanctum kann die Identität eines Clients und dessen Token-Fähigkeiten prüfen. Innerhalb jedes MCP-Tools brauchst du trotzdem eine Autorisierung für den konkreten Datensatz, Mandanten und Zustandswechsel.

Wann ist OAuth 2.1 für Laravel MCP sinnvoll?

OAuth 2.1 passt besonders zu eigenständigen oder externen Clients, die im Namen eines Benutzers handeln. Für eine einzelne interne Systemverbindung kann ein eng begrenztes, widerrufbares Token einfacher sein.

Muss jede Aktion eines AI-Agents manuell freigegeben werden?

Nein. Lesende und folgenlose Aktionen können nach sauberer Autorisierung automatisch laufen. Versand, Veröffentlichung, Löschung oder verbindliche Änderungen sollten abhängig vom Risiko eine serverseitig erzwungene Freigabe benötigen.

Was sollte ich beim Upgrade von Laravel MCP 0.x auf 1.x testen?

Prüfe den Protokoll-Handshake, die Client-Identifikation, vorhandene Tokens, Client-ID-Metadaten und die Speicherung optionaler Client-Secrets. Teste jeden verbundenen Client vor dem produktiven Wechsel separat.

Laravel-AI-Agents mit MCP vor dem Livegang absichern