Risikomodell & Schutzklassen

Vollständige Agentenfähigkeit bedeutet nicht, dass ein Agent alles tun darf. Es bedeutet, dass das System jeden seiner Zustände und jede seiner Fähigkeiten strukturiert beschreiben kann, einschließlich der Fähigkeiten, die einem Agenten grundsätzlich verwehrt bleiben. Das Risikomodell ist das Werkzeug, das diese Grenze zieht: präzise, maschinenlesbar und ohne Ausnahmen.

Sensible Bereiche

Einige Teile eines Systems erfordern einen höheren Schutz, nicht nur vor externen Angreifern, sondern auch vor internen Agents. Ein häufiger Irrtum lautet:

Der Benutzer darf es sehen, also darf die KI es auch sehen.

Das stimmt nicht. Effektiver KI-Zugriff ergibt sich aus der Schnittmenge von Nutzer-Permission, Agent-Permission, Client Trust Level, Ressourcensensitivität, Zweck und Bestätigungsstatus. Jedes dieser Elemente ist eine eigene Schranke, nicht nur die Nutzerrolle.

Zu den sensiblen Bereichen, die besonders geschützt werden müssen, gehören:

• Finanzdaten, Bankverbindungen, Zahlungsdaten, Abrechnungsdetails
• Gesundheitsdaten, medizinische Dokumente, Krankenakten, Atteste
• Gehaltsdaten, Lohn, Boni, Gehaltshistorie, Payroll-Läufe
• Personalakten, Verträge, Bewerbungsunterlagen, interne Bewertungen
• Zugangsdaten & API Keys, Passwörter, Private Keys, Access Tokens
• Lösch- und Massenfunktionen, Benutzer löschen, Mandant löschen, Bulk-Export
• Rechteverwaltung, Berechtigungen vergeben und entziehen, Rollen ändern
• Sicherheitslogs, Audit-Trails, Security-Events, aktive Sessions
• Private Kommunikation, vertrauliche Notizen, interne Einschätzungen
• Steuerdaten und Verträge, steuerrelevante Dokumente, rechtswirksame Verträge
• Personenbezogene Daten nach DSGVO, alle Daten, die eine natürliche Person identifizieren

Sechs Schutzklassen

Jede Resource und jedes Tool wird einer von sechs Schutzklassen zugeordnet. Die Klasse bestimmt, wer Zugriff erhält, ob ein Agent das Tool in der Discovery überhaupt sieht, und welche Freigabe vor der Ausführung erforderlich ist.

Public

Öffentlich zugängliche Inhalte ohne Einschränkung. Keine Authentifizierung, keine besondere Rolle, keine Bestätigung erforderlich. Geeignet für Hilfe-Artikel, Produktinformationen und dokumentierte System-Fähigkeiten.

help.article.read
public.product_info.read

Internal

Nur für eingeloggte Benutzer. Die Authentifizierung genügt; keine Sonderrechte notwendig. Typisch für Listenabfragen, Suchen und allgemeine Arbeitsansichten des eigenen Kontexts.

project.list
contact.search

Confidential

Nur mit expliziter Rolle und zugewiesenem Scope zugänglich. Ein einfacher Login reicht nicht. Die Daten sind intern, aber nicht für alle Mitarbeitenden bestimmt.

contract.read
customer_private_note.read

Sensitive

Nur mit zusätzlicher Freigabe oder eingeschränkter Kontextweitergabe. Ein Agent darf diese Daten nicht ungeprüft in seinen Kontext laden. Bei Übergabe an eine KI muss der Umfang eng begrenzt und der Zweck dokumentiert sein.

salary.read
bank_account.read
health_document.read

Critical

Die KI darf in dieser Klasse nicht autonom handeln. Jede Ausführung erfordert eine explizite Benutzerfreigabe, häufig Step-up Authentication. Die Aktionen erzeugen externe Wirkung, sind schwer rückgängig zu machen oder betreffen Dritte direkt.

payment.execute
user.delete
contract.send
email.send_external
security.change_permissions

Forbidden for AI

Diese Klasse ist eine harte Grenze, keine Policy-Entscheidung. Tools und Resources dieser Klasse werden bei der Tool Discovery für Agents vollständig ausgeblendet. Ein Agent kann sie weder lesen noch aufrufen noch als Referenz verwenden.

password.read
private_key.read
full_database_export
raw_access_token.read

Das Risikomodell

Das Risikomodell übersetzt die Schutzklassen in operative Regeln für jeden Ausführungsfall. Es legt fest, ob Autonomie erlaubt ist, ob Bestätigung nötig ist und welche Art von Freigabe verlangt wird.

Low

Rein lesende Operationen oder Aktionen ohne dauerhafte Außenwirkung. Agents dürfen diese Tools autonom aufrufen.

Medium

Daten oder Zustände werden erstellt oder geändert, aber innerhalb eines eng definierten Scopes ohne externe Wirkung. Autonome Ausführung ist erlaubt, wenn Scope und Kontext eindeutig aus dem Workflow hervorgehen.

High

Aktionen, die relevante Systemzustände verändern oder andere Nutzer und externe Ressourcen betreffen. Eine explizite Bestätigung ist in der Regel erforderlich.

Critical

Externe Kommunikation, Zahlungen, Löschvorgänge, Berechtigungsänderungen. Immer Bestätigung, häufig Step-up Auth. Autonome Ausführung ist nicht erlaubt.

Forbidden

Vollständig gesperrt für AI Agents, weder lesend noch schreibend. Nicht in Discovery sichtbar, nicht aufrufbar, nicht als Referenz verwendbar.

Approval UX

Das technische Risikomodell greift erst dann vollständig, wenn auch die Benutzeroberfläche ihrer Rolle gerecht wird. Eine Bestätigung ist nur so gut wie die Information, auf deren Grundlage sie erteilt wird.

Bevor ein Mensch eine kritische Agentenaktion bestätigt, muss er sieben Dinge klar erkennen können:

1. Was will der Agent tun?, Die konkrete Aktion, nicht die Absicht des Agents in eigenen Worten.
2. Warum will der Agent das tun?, Welcher Intent oder Auftrag hat diese Aktion ausgelöst.
3. Welche Daten werden verwendet?, Empfänger, Anhänge, referenzierte Entitäten.
4. Welche externen Effekte entstehen?, Was verändert sich außerhalb des Systems: E-Mail wird versendet, Zahlung wird ausgelöst, Dokument wird übermittelt.
5. Wer ist betroffen?, Personen, Firmen, Mandanten, externe Parteien.
6. Kann die Aktion rückgängig gemacht werden?, Klare Aussage: reversibel oder irreversibel.
7. Was passiert bei Bestätigung?, Vollständige Beschreibung der nächsten Systemzustände.

Das folgende Beispiel zeigt, wie eine vollständige Approval-Karte für das Tool emails.send_external aussieht:

Der Agent wartet auf die Entscheidung des Benutzers. Er darf die Bestätigung nicht vorwegnehmen, keine Standardaktion setzen und die Ausführung nicht auf dem Zeitstempel einer früheren Freigabe basieren.