Tech-USP: Der Assistant bekommt keine eigene Tür in Eure Daten. Er benutzt die, die schon da ist, mit den Rollen des fragenden Users, den vorhandenen Zugriffsregeln und einem Audit-Eintrag pro ausgeführtem Tool-Call.
Käufer-Sicht: Im Review geht es darum, was passiert, wenn jemand die KI überredet. Bei Kumiko: nichts, das der Mensch am Bildschirm nicht ohnehin gedurft hätte. Alles, was passiert ist, steht im Audit-Trail.
Das Problem: „Bitte ignoriere deine Anweisungen”
Viele KI-Assistenten sichern sich im System-Prompt ab: „Lösche niemals Daten”, „frage vor Änderungen nach”. Das ist eine Bitte an ein Sprachmodell, keine Grenze. Wer den Prompt umformuliert, umformuliert die Regel mit, und der Assistent hat trotzdem den technischen Zugriff, den man ihm beim Einrichten gegeben hat: meist einen Service-Account mit weiten Rechten, weil er ja für alle Nutzer funktionieren soll.
Wie Kumiko das löst
Der Katalog gehört dem Aufrufer, nicht dem Modell
Der Tool-Katalog wird pro Anfrage neu gebaut: aus der Registry, die der Server ohnehin komponiert hat, gefiltert nach den Rollen des aufrufenden Users, danach gefiltert nach dessen Freigabe-Regeln und dem Modus des Mandanten. Ein Handler, den dieser User nicht aufrufen darf, taucht in seinem Katalog nicht auf. Das Modell kennt ihn nicht und kann ihn deshalb auch nicht vorschlagen.
Die Sichtbarkeit ist zusätzlich fail-closed: ein Handler ohne Beschreibung bleibt unsichtbar, egal welche Rollen der Aufrufer hat. Ein neues Feature landet also nicht versehentlich im Katalog, weil jemand vergessen hat, es abzusichern.
Dispatch läuft als echter User, nicht als Service-Account
Jeder Tool-Call geht durch dieselben Query- und Write-Pfade wie ein Klick in der Oberfläche, mit der Identität des Aufrufers, nie als System-User. Zugriffsregeln, Validierung, Hooks und Projektionen laufen wie immer. Es gibt keinen zweiten, privilegierteren Weg in die Daten, den man separat absichern müsste.
Auch der Rückweg ist abgesichert: nach einem erfolgreichen Schreibzugriff liest der Agent den Datensatz über die gewöhnliche Detail-Abfrage zurück, damit feldweise Leserechte greifen, bevor das Modell etwas sieht. Das rohe Schreibergebnis geht nie zurück ans Modell.
Freigabe pro Aktion: vier Antworten statt eines Schalters
Im Default-Modus ist ein vorgeschlagener Schreibzugriff noch kein Schreibzugriff. Er wird zur Karte:
| Antwort | Was passiert |
|---|---|
| Ausführen | Der Handler wird einmal ausgeführt, als der aufrufende User |
| In der Maske prüfen | Die Bearbeitungsmaske der App öffnet sich vorbefüllt; Speichern oder Abbrechen meldet zurück an die Karte. Dazwischen wird nichts geschrieben |
| Immer erlauben | Speichert eine Dauer-Freigabe für diesen Handler, der nächste Aufruf überspringt die Karte. Für Handler mit risk: "high" verweigert, und das Edit-Add-on muss gemountet sein, damit die Regel gespeichert wird |
| Verwerfen | Nichts läuft, das Gespräch geht weiter |
Die Einstellungen in der Chat-Schicht zeigen dem User, was er freigegeben hat, löschen eine einzelne Regel oder setzen alle zurück. Regeln gibt es auf User- und Mandanten-Ebene, never schlägt alles, und ohne Regel gilt ask. Ein Mandant kann seine Policy also vorab schreiben, statt zu warten, bis jemand die erste Karte beantwortet.
Der Mandant setzt die Decke, der Client kann sie nur senken
| Modus | Was der Agent darf |
|---|---|
read-only |
Nur Abfragen. Kein Schreibzugriff erreicht je eine Karte |
approval |
Abfragen, plus Schreibzugriffe als Vorschlag, den ein Mensch beantwortet. Der Default |
edit |
Ein Schreibzugriff mit Dauer-Freigabe und einem Risiko unterhalb von high läuft ohne Karte. Alles andere fragt weiter |
edit ist kein Config-Wert, den man einfach hinschreibt: Die Option existiert nur, wenn das Feature entsprechend gemountet und das kostenpflichtige Edit-Add-on in der Registry ist. Fehlt eines von beidem, bricht der Start ab, statt still im schwächeren Modus weiterzulaufen. In die andere Richtung klemmt der Server: der Client darf den Modus für ein Gespräch enger machen, nie weiter.
Jeder ausgeführte Tool-Call ist auditiert
Ein ausgeführter Tool-Call landet als eigener Audit-Datensatz neben dem Audit-Eintrag des Handlers, den er aufgerufen hat. „Was hat der Assistant hier gemacht?” ist damit im Nachhinein beantwortbar, mit Zeitpunkt, User und Handler.
Die Gesprächsverläufe selbst sind als personenbezogene Daten deklariert und an ihren Autor gekoppelt. Eine DSGVO-Anonymisierung crypto-shreddet sie, statt alte Prompts lesbar liegen zu lassen; Auskunft und Löschung werden wie bei jedem anderen nutzerbezogenen Datenbestand bedient.
Was es nicht ist
- Kein autonomer Agent: Ein Turn startet immer daran, dass ein Mensch in der Chat-Schicht tippt oder spricht. Kein Scheduler, kein Job, kein Webhook startet einen; nichts läuft, während niemand hinschaut
- Kein Undo: Ein ausgeführter Tool-Call ist ein gewöhnlicher Schreibzugriff mit gewöhnlichen Folgen. Rückgängig machen heißt: dieselben Handler benutzen, die ein Mensch benutzen würde. Deshalb kann
risk: "high"nie mit „Immer erlauben” beantwortet werden - Kein Gedächtnis über Gespräche hinweg: Das Modell sieht die Turns des Gesprächs, in dem es steckt, und sonst nichts. Es lernt die Gewohnheiten Eures Mandanten nicht zwischen Sitzungen
- Kein Ersatz für Rollen-Design: Der Katalog ist so eng wie die Rollen, die Ihr vergeben habt. Wer allen Nutzern Admin gibt, gibt auch dem Assistant Admin
Wo das im Pitch landet
- IT-Entscheider: Der Assistant erweitert die Angriffsfläche nicht. Er nutzt dieselben Pfade, dieselben Rollen, dasselbe Audit. Die bestehende Berechtigungs-Analyse gilt weiter, es kommt keine zweite dazu
- Datenschutz: Gesprächsverläufe sind personenbezogene Daten mit Auskunft, Löschung und Crypto-Shredding, kein Schatten-Datenbestand neben der DSGVO-Strecke
- Betriebsrat / Fachbereich: Freigabe pro Aktion heißt, dass niemand ungefragt beschrieben wird. Der Default fragt, und wer nicht fragen will, muss das aktiv und pro Handler entscheiden