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

Die reale Grenze eines KI-Assistenten ist ein technisch durchsetzbarer Dienstvertrag, nicht eine Verbotsliste im System-Prompt. Ein Modell kann angewiesen werden, keine Nachricht zu senden, während das angeschlossene Werkzeug und dessen Zugangsdaten genau dies weiterhin erlauben. Deshalb muss die Ausführungsumgebung festlegen, welche Person welche Fähigkeit nutzen darf, welche Informationen hineingelangen und welche Zustandsänderung möglich ist. Werden Rechte pauschal an das gesamte Produkt vergeben, kann eine harmlose Anfrage unnötig weitreichende Daten- und Aktionspfade erben.

Was darf der Assistent überhaupt tun?

Das Team sollte zuerst einen einzeiligen Dienstauftrag schreiben und ihn anschließend in sichtbare Einzelfähigkeiten zerlegen. Eine brauchbare Form lautet: „Für [berechtigte Nutzer] darf der Assistent [erlaubte Aufgabenfamilie] anhand [freigegebener Informationen] ausführen und [zulässiges Ergebnis] erzeugen, aber nicht [ausdrückliche Nicht-Ziele oder folgenreiche Entscheidungen].“ So werden Zielgruppe, Einsatzumgebung, Wissensgrenzen, menschliche Aufsicht und Risikoverantwortung prüfbar, bevor irgendein Werkzeug angeschlossen wird.

Verben wie „helfen“, „betreuen“ oder „verwalten“ sind dafür zu unbestimmt. Sie müssen in Suchen, Zusammenfassen, Empfehlen, Entwerfen, Aktualisieren, Senden, Löschen oder Freigeben aufgeteilt werden. OWASP empfiehlt minimale Werkzeugfunktionen und schmale statt offener Operationen; der AI RMF des NIST hebt dokumentierte Zwecke, Aufgaben und Grenzen hervor. Die hier verwendete Zerlegung ist jedoch eine praktische redaktionelle Methode, keine verbindliche Vorgabe dieser Organisationen.

• Berechtigte Nutzer und das Verfahren, mit dem ihre Identität festgestellt wird
• Unterstützte Aufgaben, erlaubte Ergebnisse und ausdrücklich ausgeschlossene Entscheidungen
• Zulässige Systeme, Datenklassen und Wissensgrenzen
• Form der menschlichen Aufsicht sowie zuständige Dienst- und Risikoverantwortliche
• Fähigkeiten, die bis zu einer gesonderten Prüfung technisch ausgeschaltet bleiben

Welche Informationen darf jede Fähigkeit verwenden?

Eine Kontextgrenze ist ein Informationsraum mit festgelegter Zulässigkeit und Vertrauensgrenze, nicht bloß die Tokenzahl des Modells. Für jede Fähigkeit gehören die freigegebenen Systeme, Datensatzarten, Klassifikationen, Objektfilter, Zeiträume, Aktualitätserwartungen und Nutzerrechte hinein. Ebenso wichtig ist die Negativliste: fremde Kundenkonten, verdeckte Verwaltungsnotizen, Geheimnisse oder andere Daten, die selbst dann nicht in den Kontext gelangen dürfen, wenn Suche oder Modell technisch darauf zugreifen könnten.

Abgerufene Dokumente, Anhänge, externe Nachrichten und API-Antworten bleiben Daten und dürfen nicht unbemerkt zu Dienstanweisungen werden. OWASP empfiehlt, solche Inhalte als nicht vertrauenswürdig zu behandeln und von Anweisungen zu trennen. Fehlen erforderliche Belege, sind sie veraltet oder für die anfragende Person unzugänglich, muss die Antwort dies benennen, sich auf den belegten Teil beschränken oder stoppen. Ein größeres Kontextfenster schafft weder zusätzliche Berechtigung noch verlässlichere Tatsachen.

• Sitzungsverlauf und dauerhafter Speicher erhalten getrennte Regeln.
• Persistente Einträge werden vor dem Speichern geprüft und nach Nutzer sowie Sitzung isoliert.
• Größe, Ablauf, Löschung und Integrität werden dienstspezifisch festgelegt.
• Geheimnisse, Zugangsdaten und unzulässige sensible Inhalte werden nicht im Assistentenspeicher abgelegt.

Wie setzen Identität, Werkzeuge und Rechte die Grenze durch?

Authentifizierung, Autorisierung und Freigabe müssen als drei getrennte Entscheidungen behandelt werden. Die Authentifizierung stellt fest, wer als Nutzer, Client oder Workload auftritt. Die Autorisierung entscheidet, ob diese Identität eine bestimmte Operation auf einer geschützten Ressource ausführen darf. Eine Freigabe akzeptiert dagegen genau eine vorgeschlagene Aktion. Werkzeug-Gateway und Zielsystem müssen Objekt- und Operationsgrenzen durchsetzen; ein Prompt, eine Modellrichtlinie oder eine natürlichsprachliche Schutzregel ist keine Zugriffskontrolle.

Das Team wählt ausdrücklich zwischen delegierten Nutzerrechten und einer kontrollierten Workload-Identität. Es darf nicht stillschweigend das weitreichende Konto eines Administrators erben. Eine Werkzeugoperation sollte nur die benötigten Parameter annehmen und Verben, Ressourcen, Objekte, Felder, Ziele, Laufzeit der Zugangsdaten und Token-Zielgruppe begrenzen. Für geschützte MCP-Integrationen illustrieren minimale Scopes und ressourcengebundene Token dieses Prinzip; die MCP-Spezifikation ist jedoch keine universelle Architekturvorgabe.

• Lese-, Entwurfs- und Sendeoperationen erhalten getrennte Endpunkte und Berechtigungen.
• Parameter werden typisiert, normalisiert und vor der Ausführung validiert.
• Rate, Wiederholungen, Kettentiefe, Stapelgröße, Kosten und Laufzeit folgen dem konkreten Dienst.
• Idempotenz, Rücknahme und Sicherungsabschaltung begrenzen doppelte oder außer Kontrolle geratene Ausführungen.

Ein Gespräch darf durchgängig wirken, seine Befugnis sollte aber in kleine, unabhängig durchgesetzte Fähigkeiten zerlegt sein.

Wie weit darf eine Fähigkeit selbst handeln?

Jede Fähigkeit braucht eine ausdrückliche Aktionsobergrenze; mit zunehmender Außenwirkung werden unabhängige Kontrollen stärker. Eine praktische redaktionelle Stufenleiter reicht vom Antworten oder Zusammenfassen über Vorschlagen und Entwerfen bis zu einer begrenzten, umkehrbaren Änderung und einer folgenreichen externen Aktion. Eine verbotene Entscheidung bildet die letzte Grenze. Diese Leiter ist keine OWASP- oder NCSC-Norm, sondern übersetzt deren Prinzipien zu minimalen Rechten, Aktionsbeschränkungen und externen Sicherungen in eine Arbeitsform.

1. Antworten oder zusammenfassen, ohne externen Zustand zu verändern
2. Eine Empfehlung oder einen prüfbaren Aktionsvorschlag erstellen
3. Ein bearbeitbares Artefakt in einem nicht finalen Bereich entwerfen
4. Freigegebene Felder innerhalb eines umkehrbaren Ablaufs ändern
5. Eine externe Wirkung wie Senden, Veröffentlichen, Löschen oder Berechtigen auslösen
6. Auf eine Entscheidung treffen, die dieser Dienst grundsätzlich nicht treffen darf

Vor einer folgenreichen Aktion braucht die verantwortliche Person eine verständliche Vorschau. Die Freigabe wird an Akteur, Werkzeug, Zielressource, normalisierte Parameter, Zeitpunkt und Ablauf gebunden und unmittelbar vor der Ausführung erneut geprüft. Ändern sich Empfänger, Inhalt oder Ziel, ist eine neue Prüfung nötig. Die Freigabe erweitert weder die bestehenden Rechte noch erlaubt sie eine ausgeschlossene Entscheidung. Zahlungen, Zugangsvergaben, destruktive Änderungen, Produktivänderungen und wesentliche externe Zusagen bleiben unter geeigneter menschlicher Verantwortung und deterministischer Richtlinienkontrolle.

Was geschieht, wenn der Assistent eine Grenze erreicht?

Ablehnung, begrenzte Teilhilfe, menschliche Übergabe und Sicherheitseskalation müssen eigenständige Dienstergebnisse mit echten Stoppbedingungen sein. Geeignete Gründe sind eine nicht unterstützte Aufgabe, unzulässige Informationen, fehlende Autorisierung, erforderliche Freigabe, fehlende oder veraltete Belege, notwendiges Fachurteil, eine ausgefallene Abhängigkeit, ein erreichtes Betriebslimit oder ein Sicherheitssignal. Der Assistent benennt die Grenze verständlich, ohne interne Schutzdetails offenzulegen, und behauptet niemals eine erfolgreiche Prüfung oder Ausführung, die nicht stattgefunden hat.

• Nur den sicheren Teil liefern, etwa einen Entwurf, eine Checkliste oder eine Bitte um fehlende Angaben
• Ziel, nicht sensiblem Kontext, versuchter Fähigkeit und Ablehnungsgrund eine Trace-Kennung zuordnen
• Vorhandene und fehlende Belege sowie den vorgeschlagenen nächsten Schritt festhalten
• Routineübergabe, geschäftliche Freigabe und Sicherheitsvorfall an unterschiedliche Verantwortliche leiten
• Die Ausführung bis zur Entscheidung stoppen und geänderte Aktionen vollständig neu validieren

Ein normaler Übergabefall darf nicht automatisch den Incident-Prozess auslösen; umgekehrt darf ein mögliches Sicherheitsereignis nicht in einer gewöhnlichen Servicewarteschlange verschwinden. Das NCSC empfiehlt vorbereitete Reaktions-, Eskalations- und Behebungsszenarien mit geschulten Zuständigen und aussagekräftigen Prüfprotokollen. OWASP nennt unter anderem Freigabeumgehung, Rechteausweitung, Datenabfluss, Speichervergiftung und rekursiven Werkzeugmissbrauch. Für solche Signale braucht der Dienst einen separaten Weg zum Sicherheitsteam und die Möglichkeit, betroffene Fähigkeiten auszusetzen.

Wie werden die Grenzen zu einem betriebsfähigen Entwurf?

Teams sollten für jede sichtbare Operation eine eigene Zeile im Fähigkeits-Canvas ausfüllen und sie mit technischen Kontrollen, Nachweisen, Tests, Betriebskennzahlen und einem verantwortlichen Eigentümer verbinden. Die Zeile nennt berechtigte Akteure, Authentifizierung, Informationsraum, Sitzungs- und Speicherregeln, schmale Werkzeugoperation, handelnde Identität, Ressourcenbereich, Aktionsobergrenze, Freigabe, Betriebslimits, Ablehnungsverhalten und Eskalationsziel. „Der Assistent hat CRM-Zugriff“ ist keine brauchbare Zeile; „berechtigten Supportfall zusammenfassen“ ist eine prüfbare Fähigkeit.

Ein Canvas ist nur dann nützlich, wenn seine Felder im Betrieb wieder auftauchen. Protokolle müssen rekonstruieren können, welche Fähigkeit und Richtlinienversion galten, welche Quellen- und Werkzeugklassen beteiligt waren und wie Autorisierung, Freigabe und Ergebnis ausfielen. Geheimnisse oder vollständige sensible Kontexte gehören nicht pauschal hinein. OWASP empfiehlt strukturierte Ereignisse mit geschwärzten sensiblen Daten; der NIST-Rahmen betont klare Rollen, laufende Überwachung und regelmäßige Überprüfung.

Welche Nachweise braucht die Freigabe und der laufende Betrieb?

Eine Freigabe erfordert Nachweise dafür, dass erlaubte Leistungen und erwartete Ablehnungen unter einsatzähnlichen Bedingungen funktionieren. Positive Alltagsszenarien allein reichen nicht. Der Testsatz muss die tatsächlichen Fähigkeiten, Daten- und Identitätsgrenzen sowie externe Abhängigkeiten abbilden. NIST nennt einsatznahe Evaluierung, sicheres Scheitern und Produktionsüberwachung; das NCSC empfiehlt eine angemessene Sicherheitsprüfung vor der Bereitstellung und eine verständliche Kommunikation bekannter Grenzen und Fehlermöglichkeiten.

• Berechtigte Aufgabe mit vollständigen und aktuellen Belegen
• Kontoübergreifender Zugriff, unzulässiges Werkzeug und ausgeschlossene Daten
• Veralteter Kontext, manipulierte Abrufinhalte und versuchter Datenabfluss
• Umgangene Freigabe, nachträglich veränderte Parameter und doppelte Wiederholung
• Ausfall einer Abhängigkeit, ungewöhnliche Aktionsfolge und außer Kontrolle geratene Werkzeugkette
• Korrekte Ablehnung, sichere Teilhilfe und Übergabe an das richtige Ziel

Im Betrieb sollten Kennzahlen je Fähigkeit unerwartete Werkzeugnutzung, wiederholte Ablehnungen, Autorisierungsfehler, geänderte Freigaben, auffällige Aktionsfolgen, Drift, Latenz, Ressourcenverbrauch und Ausfälle sichtbar machen. Überwachung bleibt datensparsam und folgt den Datenschutz-, Sicherheits- und Aufbewahrungsregeln der Organisation. Benannte Verantwortliche für Dienstverhalten, Zugriffsvergaben, geschäftliche Übergaben und Sicherheitsvorfälle benötigen die Befugnis, eine Fähigkeit zu pausieren, zu überarbeiten oder außer Betrieb zu nehmen.

Wesentliche Änderungen an Modell, Prompt, Abruf, Speicher, Werkzeugen, Rechten, Richtlinien, Daten, Anbietern oder Einsatzumgebung öffnen die betroffenen Prüfungen und Freigaben erneut. Das NCSC weist ausdrücklich darauf hin, dass Änderungen an Daten, Modellen und Prompts das Verhalten beeinflussen können. Teams beginnen deshalb mit der kleinsten nützlichen Fähigkeit und erweitern Befugnisse nur über geprüfte Änderungen. Bei sensiblen Daten, privilegiertem Zugriff, destruktiven Änderungen oder externen Verpflichtungen werden Sicherheits-, Identitäts-, Datenschutz-, Records-, Risiko- und Dienstverantwortliche einbezogen; rechtliche oder andere hochriskante Fachurteile gehören in einen separat gesteuerten Prozess mit qualifizierten Fachleuten.