Absicherung von KI-Agenten mit Laravel MCP-Tools
Einem KI-Agenten über MCP Zugriff auf Ihre App zu geben, ist so, als würde man jemandem einen Schlüsselbund übergeben. Wenn Sie keine Regeln festlegen, öffnet er möglicherweise die falschen Türen.
Ich habe vor Kurzem MCP-Tools für eine Multi-Tenant-Laravel-App entwickelt. Mein Ziel war klar: Der Agent soll die App steuern können, ohne Zugriff auf die Daten anderer Nutzer zu erhalten.
Das Problem mit MCP-Tools
Jedes MCP-Tool ist ein Endpunkt. Ein Agent ruft ein Tool auf, und Ihr Server führt Code aus. In einer Multi-Tenant-App muss jedes Tool zwei Fragen beantworten:
- Sind Sie berechtigt, dies zu tun?
- Sind Sie berechtigt, dies in dieser spezifischen Organisation zu tun?
Wenn Sie eine davon vergessen, kommt es zu einem Datenleck.
Warum Standard-Multi-Tenancy hier scheitert
In einer normalen Web-App arbeiten Sie mit Sessions. Sie verwenden Global Scopes, um Daten nach der Organisations-ID zu filtern. Das funktioniert, weil die "aktuelle Organisation" immer in der Session vorhanden ist.
MCP-Tools nutzen keine Sessions. Sie nutzen Token. Es gibt keine Middleware, die den Tenant-Kontext setzt. Wenn Sie sich auf einen Global Scope verlassen, der nach einer Session sucht, wird dieser nichts finden. Das könnte dazu führen, dass alle Zeilen Ihrer Datenbank zurückgegeben werden. Das ist ein stilles Datenleck.
Die Lösung: Explizite Filterung
Verlassen Sie sich bei Token-Authentifizierung niemals auf einen impliziten Scope (ambient scope). Filtern Sie jedes Mal explizit.
Ich habe ein einzelnes Trait erstellt, um dies zu handhaben:
trait ResolvesOrgEvents
{
protected function resolveOrgEvent(Authenticatable $user, string $uuid): ?Event
{
if (empty($user->organization_id)) {
return null;
}
return Event::query()
->withOrganization($user->organization_id)
->where('uuid', $uuid)
->first();
}
}
Dieser Ansatz folgt vier Regeln:
- Verwenden Sie UUIDs: Nutzen Sie niemals Auto-Increment-IDs. Agenten sollten IDs nicht durch einfaches Ändern einer Zahl erraten können.
- Single Source of Truth: Der Organisationsfilter ist in einem einzigen Trait definiert. Jedes Tool nutzt ihn.
- Berechtigungen wiederverwenden: Erfinden Sie keine neuen Berechtigungen für Agenten. Verwenden Sie dieselben Permission-Strings, die auch Ihre Web-App nutzt. Dies verhindert, dass der Agent mehr Rechte erhält als der menschliche Nutzer.
- Nebenwirkungen kennzeichnen: Verwenden Sie Annotationen, um anzuzeigen, ob ein Tool schreibgeschützt (read-only) oder beschreibbar (write-enabled) ist.
Die Grenzen testen
Sie müssen den negativen Pfad testen. Testen Sie nicht nur, ob das Tool funktioniert. Testen Sie, dass ein Nutzer aus Organisation A keine Daten von Organisation B sehen kann.
Wenn ein Agent versucht, auf eine UUID eines anderen Tenants zuzugreifen, sollte das Tool "not found" zurückgeben. Es sollte dem Agenten nicht mitteilen, dass die Daten existieren, aber jemand anderem gehören.
Behandeln Sie jedes KI-Tool wie einen nicht vertrauenswürdigen Endpunkt. Disziplin ist der einzige Weg, um Ihre Daten sicher zu halten.