Einen begrenzten KI-Assistenten mit Werkzeugen, Berechtigungen und Kontextgrenzen gestalten

Die tatsächliche Grenze eines KI-Assistenten ist der ausführbare Servicevertrag rund um das Modell, nicht eine Verbotsliste im System-Prompt. Verfügt das System über ein Versandwerkzeug und passende Zugangsdaten, verhindert die bloße Anweisung „nicht senden“ keinen technisch möglichen Versand. Deshalb braucht jede sichtbare Fähigkeit eine eigene Informationshülle, Identität, Berechtigung, Aktionsgrenze, Nachweisspur und Stoppbedingung. Erst dieses Zusammenspiel macht aus einer flüssigen Unterhaltung einen kontrollierbaren betrieblichen Service.

Was darf der Assistent tatsächlich tun?

Das Team sollte zuerst einen einzeiligen Serviceauftrag schreiben und ihn danach in konkrete, für Benutzer sichtbare Fähigkeiten zerlegen. Eine brauchbare Form lautet: „Für berechtigte Benutzer darf der Assistent eine festgelegte Aufgabenfamilie mit freigegebenen Informationen bearbeiten und ein definiertes Ergebnis erzeugen; ausdrücklich ausgeschlossene Entscheidungen oder Folgen darf er nicht herbeiführen.“ Der NIST AI RMF Core stützt die Dokumentation von Zweck, Einsatzumfeld, Aufgaben, Wissensgrenzen, Anwendungsbereich, Aufsicht und Risikotoleranz, schreibt dieses redaktionell entwickelte Format aber nicht vor.

Verben wie „helfen“, „betreuen“ oder „verwalten“ sind dafür zu grob. Aus „Kundenfälle verwalten“ werden etwa „einen berechtigten Fall suchen“, „freigegebene Inhalte zusammenfassen“, „eine Antwort entwerfen“ und „eine freigegebene Antwort senden“. Jede Operation bekommt eigene Nicht-Ziele, einen fachlich verantwortlichen Service Owner und eine technisch überprüfbare Grenze. Das entspricht dem OWASP-Prinzip, nur die minimal benötigte Werkzeugfunktion bereitzustellen und eine enge Operation einer offenen Erweiterung vorzuziehen.

• Berechtigte Benutzer und verlässliche Authentifizierung benennen.
• Einsatzumfeld, unterstützte Aufgaben und erlaubte Ergebnisse festhalten.
• Wissens- und Datengrenzen vor dem Anschluss von Werkzeugen definieren.
• Menschliche Aufsicht, Risikoverantwortung und Übergabeziele zuordnen.
• Verbotene Entscheidungen und ausdrücklich nicht angebotene Funktionen nennen.

Welche Informationen darf jede Fähigkeit verwenden?

Eine Kontextgrenze ist eine Informationshülle und nicht bloß das Token-Limit eines Modells. Für jede Fähigkeit muss sie zulässige Systeme, Datensatzarten, Klassifikationen, Objektfilter, Zeiträume, Aktualitätsanforderungen, Benutzerrechte und verbotene Daten bestimmen. Ist ein erforderlicher Beleg nicht zugänglich, fehlt er oder ist er veraltet, soll der Assistent die Antwort begrenzen oder ablehnen. Ein größeres Kontextfenster erweitert weder die Berechtigung noch macht es unbelegte Informationen wahr; NIST fordert entsprechend dokumentierte Wissensgrenzen und einen gezielten Anwendungskontext.

Abgerufene Dokumente, Anhänge, externe Nachrichten und API-Antworten bleiben Daten mit eigener Vertrauensklasse. OWASP empfiehlt, solche Inhalte als nicht vertrauenswürdig zu behandeln und von Serviceanweisungen zu trennen, damit ein Satz in einem Anhang nicht still zur neuen Betriebsregel wird. Sitzungshistorie und persistenter Speicher brauchen getrennte Regeln: Was darf hinein, wie werden Benutzer und Sitzungen isoliert, was wird vor dem Speichern validiert, wann läuft ein Eintrag ab und welche Information darf niemals dauerhaft gespeichert werden?

• Zulässige Quellen und Datensatzarten
• Berechtigungen und Objektfilter des Benutzers
• Zeitraum, Aktualität und Nachweisstatus
• Vertrauensklasse externer Inhalte
• Zulässige Sitzungshistorie
• Validierung, Isolation, Ablauf und Löschung von Speicher
• Ausdrücklich verbotene Daten

Wie erzwingen Identität, Werkzeuge und Berechtigungen die Grenze?

Authentifizierung, Autorisierung und Freigabe sind drei getrennte Entscheidungen, die außerhalb des Sprachmodells durchgesetzt werden müssen. Authentifizierung klärt, welcher Benutzer, Client oder Workload anwesend ist. Autorisierung entscheidet, ob diese Identität eine bestimmte Operation auf einer geschützten Ressource ausführen darf. Eine Freigabe akzeptiert hingegen genau eine vorgeschlagene Aktion. Die MCP-Autorisierungsspezifikation veranschaulicht diese Trennung für geschützte MCP-Verbindungen durch Clients, Ressourcen- und Autorisierungsserver; sie ist keine universelle Architekturvorgabe für alle Werkzeuge.

Das Ausführungsdesign muss ausdrücklich zwischen delegierter Benutzerberechtigung und einer kontrollierten Workload-Identität wählen. Ein Assistent darf nicht still die weitreichenden Rechte eines privilegierten Betreiberkontos erben. Werkzeug-Gateways und Zielsysteme begrenzen Verben, Ressourcen, Objekte, Felder, Ziele, Token-Empfänger und Gültigkeit; Parameter werden vor der Ausführung validiert. OWASP verlangt minimale nachgelagerte Rechte, Erhaltung des Benutzerkontexts und vollständige Vermittlung durch das Zielsystem. Prompts und natürlichsprachliche Guardrails können Verhalten lenken, sind aber keine Autorisierungskontrollen.

• Nur enge Operationen statt allgemeinem Mailbox-, Datenbank-, Browser- oder Shell-Zugriff anbieten.
• Berechtigungen nach Fähigkeit vergeben und bei Bedarf schrittweise erweitern.
• Zugriffstokens an den vorgesehenen Ressourcenserver und Zweck binden.
• Rate, Wiederholungen, Kettentiefe, Stapelgröße, Laufzeit und Kosten servicespezifisch begrenzen.
• Idempotenz, Rollback und externe Sicherungen passend zur möglichen Auswirkung vorsehen.

Ein Gespräch darf durchgehend wirken, seine Autorität muss dennoch in kleine, unabhängig erzwungene Fähigkeiten zerlegt sein.

ModelFold Editorial Team

Wie viel Handlungsspielraum darf eine Fähigkeit haben?

Jede Fähigkeit braucht eine explizite Aktionsgrenze; je stärker sie externen Zustand verändert, desto unabhängiger müssen die Kontrollen werden. Eine praktische redaktionelle Leiter unterscheidet Antworten oder Zusammenfassungen, Empfehlungen oder Vorschläge, Entwürfe, begrenzte reversible Änderungen, folgenreiche externe Aktionen und grundsätzlich verbotene Entscheidungen. Sie ist kein OWASP- oder NCSC-Standard, überträgt aber deren Prinzipien minimaler Rechte, getrennter Entscheidung und Ausführung sowie externer Sicherungen in eine prüfbare Servicegestaltung.

Ein Entwurf ist daher nicht dasselbe wie ein Versand, eine reversible Feldänderung nicht dasselbe wie Löschen und ein Vorschlag nicht dasselbe wie eine verantwortete Entscheidung. Vor einer folgenreichen Aktion muss der Mensch eine prüfbare Vorschau erhalten. Die Freigabe wird an Akteur, Werkzeug, Zielressource, normalisierte Parameter, Zeitpunkt und Ablauf gebunden und unmittelbar vor der Ausführung geprüft. Sie liefert weder fehlende Autorisierung noch erweitert sie bestehende Rechte; ändert sich Empfänger oder Inhalt, ist die frühere Zustimmung nicht mehr passend.

1. Antworten oder Zusammenfassen ohne externen Zustandswechsel
2. Empfehlen oder einen prüfbaren Vorschlag erzeugen
3. Einen bearbeitbaren Entwurf in einem nicht finalen Bereich anlegen
4. Eine eng begrenzte und reversible Änderung ausführen
5. Eine folgenreiche externe Aktion nur mit unabhängigen Kontrollen auslösen
6. Eine verbotene Entscheidung technisch ausschließen und an einen qualifizierten Prozess übergeben

Was geschieht, wenn der Assistent an seine Grenze stößt?

Ablehnung, sichere Teilhilfe, menschliche Übergabe und Sicherheitseskalation müssen als eigene Serviceergebnisse mit echten Stoppbedingungen gestaltet werden. Der Assistent soll die Grenze verständlich nennen, ohne vertrauliche Richtliniendetails offenzulegen, und niemals behaupten, eine Quelle, Freigabe, Werkzeugaktion oder Änderung sei erfolgreich gewesen, wenn das nicht feststeht. NIST nennt sicheres Scheitern jenseits dokumentierter Wissensgrenzen als Evaluierungsziel. Die Entscheidung darf außerdem nicht allein von einer selbst gemeldeten Modellkonfidenz abhängen.

Soweit gefahrlos möglich, kann der Service einen Entwurf liefern, fehlende Angaben anfordern oder eine Checkliste vorbereiten. Für die Übergabe bündelt er ursprüngliches Ziel, nicht sensible Kontextdaten, versuchte Fähigkeit, Grund, verfügbare oder fehlende Nachweise, nächsten Schritt und Trace-Kennung. Eine normale Benutzerübergabe, geschäftliche Freigabe und Sicherheitsreaktion bleiben getrennte Wege mit unterschiedlichen Eigentümern. Bei Signalen wie Rechteausweitung, Datenabfluss, Speichervergiftung, Freigabeumgehung oder rekursivem Werkzeugmissbrauch stoppt die Ausführung und folgt dem Vorfallsplan.

• Aufgabe außerhalb des Umfangs
• Information nicht zulässig
• Autorisierung unzureichend
• Freigabe erforderlich
• Nachweis fehlt oder ist veraltet
• Fachurteil erforderlich
• Werkzeug oder Abhängigkeit nicht verfügbar
• Betriebliches Limit erreicht
• Sicherheitssignal erkannt

Wie werden die Grenzen zu einem betriebsfähigen Design?

Teams sollten für jede sichtbare Operation eine eigene Zeile in einem Fähigkeits-Canvas ausfüllen und diese mit durchsetzbaren Kontrollen, Nachweisen, Tests, Kennzahlen und verantwortlichen Personen verbinden. Erfasst werden Akteur und Authentifizierung, Informationshülle, Sitzungs- und Speicherregeln, enge Werkzeugoperation, handelnde Identität, Ressourcenumfang, Aktionsgrenze, Freigabe, Betriebsgrenzen, Ablehnung, Protokollnachweis, Evaluierung und Eigentümer. Das Canvas ist praktische redaktionelle Synthese aus NIST-, OWASP- und NCSC-Prinzipien, kein vorgeschriebener Standard.

Ein interner Support-Assistent zeigt, warum die Gesprächsoberfläche nicht die Kontrollgrenze sein darf. Fallzusammenfassung, Antwortentwurf und freigegebener Versand können im selben Dialog erscheinen, benötigen aber getrennte Datenzugriffe, Werkzeuge, Grants, Tests, Kennzahlen und Übergaben. Protokolle sollen Entscheidungen, Werkzeugaufrufe, Autorisierung, Freigabekennung, Richtlinienversion, Ergebnis und auffällige Muster rekonstruierbar machen, ohne Geheimnisse oder unbegrenzten Rohkontext zu speichern. Service-, Zugriffs-, Fach- und Sicherheitsverantwortung werden ausdrücklich zugeordnet.

Welche Nachweise braucht die Freigabe und der laufende Betrieb?

Eine Freigabe braucht Nachweise, dass erlaubte Leistungen und erwartete Ablehnungen unter einsatznahen Bedingungen funktionieren. Neben positiven Aufgaben gehören kontoübergreifender Zugriff, unerlaubte Werkzeuge, veraltete oder vergiftete Inhalte, verbotene Daten, umgangene Freigaben, geänderte Parameter, doppelte Wiederholungen, Ausfälle, Datenabflussversuche und ausufernde Werkzeugketten in die Testauswahl. NIST verlangt einsatznahe Evaluierung, sicheres Scheitern und Produktionsmonitoring; das NCSC empfiehlt eine angemessene Sicherheitsbewertung sowie die verständliche Kommunikation bekannter Grenzen vor der Freigabe.

Die Nachweisspur muss rekonstruieren, wer was verlangte, welche Fähigkeit und Richtlinienversion galt, welche Quellen- und Werkzeugklassen beteiligt waren, welche Autorisierungs- und Freigabeentscheidung fiel und welches Ergebnis entstand. Geheimnisse und unnötiger sensibler Kontext gehören nicht in das Protokoll. Im Betrieb werden je Fähigkeit unerwartete Werkzeugnutzung, wiederholte Ablehnungen, Autorisierungsfehler, Freigabeänderungen, auffällige Aktionsfolgen, Drift, Laufzeit, Ressourcenverbrauch und Ausfälle nach den Risiko- und Datenschutzanforderungen der Organisation beobachtet.

Wesentliche Änderungen an Modellen, Prompts, Retrieval, Speicher, Werkzeugen, Berechtigungen, Richtlinien, Daten, Anbietern oder Einsatzumfeld öffnen die betroffenen Tests und Freigabenachweise erneut. Das NCSC weist ausdrücklich darauf hin, dass Änderungen an Daten, Modellen und Prompts das Verhalten verändern können. Eigentümer für Serviceverhalten, Zugriffsvergabe, fachliche Übergaben und Sicherheitsvorfälle benötigen daher die Befugnis, eine Fähigkeit zu pausieren, enger zu fassen oder außer Betrieb zu nehmen.

• Mit der kleinsten nützlichen Fähigkeit beginnen.
• Erlaubte Aufgaben und erwartete Ablehnungen gemeinsam testen.
• Berechtigungen, Freigaben und Protokolle je Fähigkeit prüfen.
• Bekannte Grenzen für Benutzer und Betrieb transparent machen.
• Nach wesentlichen Änderungen betroffene Evaluierungen wiederholen.
• Autorität nur über geprüfte Änderungen und nicht allein über Prompt-Anpassungen erweitern.

Sobald sensible Informationen, persistenter Speicher, privilegierter Zugriff, externe Verpflichtungen, destruktive Änderungen oder Vorfallsreaktionen betroffen sind, müssen Security-, Identity-, Datenschutz-, Records-, Risiko- und Serviceverantwortliche eingebunden werden. Zahlungen, Zugriffsvergaben, produktive Änderungen und andere folgenreiche Handlungen bleiben unter geeigneter menschlicher Verantwortung und deterministischer Ausführungsrichtlinie. Rechtliche, regulatorische oder andere hochriskante Fachurteile gehören zu qualifizierten Spezialisten und in einen gesondert gesteuerten Prozess, nicht in die Autorität des Assistenten.