MCP & KI-Agenten
Ein MCP-Server, der Ihre Rechte durchreicht statt sie zu umgehen
Ein KI-Agent auf Unternehmensdaten scheitert selten am Modell. Er scheitert an der Frage, mit welchen Rechten er eigentlich arbeitet. Die üblichen Antworten sind beide schlecht: ein Serviceaccount, der alles darf, oder ein Agent, der nichts Nützliches darf.
- Protokoll
- Model Context Protocol
- Rechte
- delegiert, kein eigener Account
- Schutz
- Gate → Audit → Ausführung
- Modell
- Ihre Wahl
Woran Agenten auf Unternehmensdaten scheitern
Wenn ein Assistent mit einem technischen Sammelkonto auf das Warehouse zugreift, sieht er alles – und damit sieht jeder, der ihn geschickt fragt, alles. Die Antwort darauf ist meist ein zweites Rechtemodell nur für den Agenten, das neben dem eigentlichen liegt und irgendwann auseinanderläuft.
lavalake nimmt einen anderen Weg: der Agent bekommt kein eigenes Konto. Er arbeitet mit demselben eingetauschten Token wie Sie. Was Sie nicht sehen dürfen, sieht er in Ihrer Sitzung auch nicht – ohne dass dafür eine einzige zusätzliche Regel gepflegt werden muss.
Ein Agent mit eigenen Rechten ist ein zweites Rechtemodell. Zwei Rechtemodelle laufen immer auseinander.
Kuratierte Werkzeuge statt freiem SQL
Der Agent bekommt keine offene Datenbankverbindung, sondern eine Liste von Werkzeugen. Katalog und Schema erkunden, Tabellen beschreiben, lesend abfragen, semantisch suchen, Kennzahlen der Semantikschicht abrufen, Dashboards anlegen, Rollen in Keycloak verwalten, Importe starten.
trino_list_catalogs lesend
trino_list_schemas lesend
trino_describe_table lesend
trino_run_readonly_query lesend
semantic_search lesend
query_semantic_metric lesend
list_semantic_metrics lesend
inspect_csv / import_csv verändernd
define_semantic_metric verändernd
create_dashboard verändernd
add_dashboard_tile verändernd
keycloak_assign_role verändernd
trino_drop_table löschend
delete_dashboard löschend
delete_semantic_metric löschend
trino_execute_statement je Anweisung eingestuft
platform_pod_status lesendWeil die Werkzeuge benannt sind, ist auch nachvollziehbar, was ein Agent getan hat. Ein Protokoll aus freiem SQL beantwortet die Frage „was ist hier passiert“ schlecht; ein Protokoll aus Werkzeugaufrufen beantwortet sie gut.
Gate, Audit, Ausführung
Jeder Werkzeugaufruf läuft durch drei Stufen. Zuerst die Einstufung: ist das lesend, verändernd oder löschend? Bei freiem SQL entscheidet das ein Klassifizierer je Anweisung, nicht der Werkzeugname. Dann der Protokolleintrag. Erst dann die Ausführung – und bei verändernden und löschenden Schritten erst nach Ihrer Bestätigung.
| Stufe | Was passiert | Ergebnis |
|---|---|---|
| Gate | Anweisung einstufen | erlauben, rückfragen, ablehnen |
| Audit | Eintrag in die Hash-Kette | prüfbar, nicht stillschweigend änderbar |
| Ausführung | unter Ihrem Token in Trino | Policies greifen |
Das Modell bleibt Ihre Entscheidung
Mit der Plattform wird kein Modellschlüssel ausgeliefert. Sie wählen die Anbindung: ein eigener API-Schlüssel, ein selbst gehostetes Modell mit OpenAI-kompatibler Schnittstelle, oder eine Claude-Anmeldung je Nutzer. Für die semantische Suche brauchen Sie ohnehin keine Anbindung – das Einbettungsmodell läuft lokal mit.
- Eigener API-Schlüssel für einen externen Anbieter
- Selbst gehostetes Modell über eine OpenAI-kompatible Adresse
- Claude-Anmeldung je Nutzer, Gates bleiben erhalten
- Einbettungen immer lokal, ohne Schlüssel
- AWS Bedrock als AnbieterIn Entwicklung
- Natürliche Sprache zu SQL gegen geprüfte MetrikenIn Entwicklung
Der Agent kann das Modell selbst aufbauen
Weil der Assistent Katalog und Schemata lesen und Kennzahlen definieren darf, kann er die Semantikschicht aus Ihren Daten heraus vorschlagen und anlegen – jeder Schritt mit Rückfrage, jeder Schritt im Protokoll. Das ist der Teil, der sonst monatelang liegen bleibt, weil niemand Zeit hat, Metriken zu definieren.
Sehen, statt nachzulesen
In einer halben Stunde zeigen wir die Plattform an Ihren Fragen – Ingestion, Rechte, Suche, Agent. Ohne Folien.
Live-Demo buchen