KI-Agenten-Berechtigungen sollten standardmäßig nur einen Lesezugriff erlauben. Schreibrechte werden getrennt, zweckgebunden, zeitlich begrenzt und nur für klar definierte Aktionen vergeben. Ein Agent darf nicht pauschal auf ein System zugreifen, sondern erhält nur die Rechte, die eine konkrete Aufgabe tatsächlich erfordert.
In meiner Arbeit mit KMU erlebe ich häufig zwei Extreme: Entweder darf ein KI-Assistent aus Sorge vor Fehlern überhaupt nichts tun, oder eine technische Integration erhält vorschnell weitreichende Rechte. Sinnvoller ist ein schrittweiser Übergang: zuerst kontrolliert lesen, anschließend Entwürfe erstellen und erst danach ausgewählte Aktionen mit klarer Freigabe ausführen.
KI-Agenten-Berechtigungen: vom Lesen zum kontrollierten Handeln
KI-Agenten-Berechtigungen definieren, welche Daten ein Agent sehen, welche Funktionen er aufrufen und welche Änderungen er unter welchen Bedingungen ausführen darf. Die Berechtigung betrifft nicht nur die Verbindung zu einem System, sondern auch einzelne Datensätze, Felder, Aktionen, Zeiträume und Freigaberegeln.
Technisch kommunizieren Agenten häufig über eine Programmierschnittstelle, kurz API, mit Websites, Warenwirtschaft, Buchungssystemen oder internen Anwendungen. Für den Betrieb ist entscheidend, welche Informationen und Aktionen über die Schnittstelle tatsächlich freigegeben werden. Diese Zugriffskontrolle für Agenten muss vor der technischen Anbindung festgelegt werden.
Die aktuellen OWASP-Leitlinien für agentische Systeme führen Werkzeugmissbrauch, Identitäts- und Privilegienmissbrauch sowie eigenmächtig oder fehlgeleitet handelnde Agenten als konkrete Risiken auf. Eine belastbare Agent-Zugriffskontrolle muss deshalb sowohl technische Berechtigungen als auch einzelne Aktionen begrenzen. Die vollständige Quelle findest Du am Ende des Artikels.
Das Drei-Zonen-Modell für Lese- und Schreibrechte
Für kleine und mittlere Unternehmen empfehle ich ein Drei-Zonen-Modell. Das Modell trennt öffentliche Informationen, interne Daten und schreibende Aktionen. Dadurch werden die technische Umsetzung und die betriebliche Verantwortung klarer.
Zone 1: Öffentliche Fakten
Zur ersten Zone gehören Informationen, die ohnehin öffentlich auf der Website stehen: Leistungen, Öffnungszeiten, Standorte, Ansprechpartner, öffentlich ausgewiesene Verfügbarkeiten oder veröffentlichte Preise. Ein Agent kann diese Daten anonym oder mit einem niedrig privilegierten Lesezugriff abrufen.
- Erlaubte Aktion: lesen, suchen und zusammenfassen
- Nicht erlaubt: Inhalte verändern, Kontaktdaten ergänzen oder interne Datensätze aufrufen
- Betrieblicher Nutzen: Der Agent beantwortet Standardfragen, ohne Zugriff auf das Verwaltungssystem zu erhalten.
Auch öffentlich zugängliche Daten brauchen Regeln. Ein Agent sollte nicht unbegrenzt vollständige Datenbestände exportieren können, wenn für eine Antwort ein einzelner Datensatz genügt.
Zone 2: Interne oder personenbezogene Daten
Die zweite Zone umfasst Daten, die nicht öffentlich sind: konkrete Anfragen, Buchungsdetails, Vertragsinformationen, individuelle Preise, interne Dokumente oder Notizen. Der Zugriff setzt eine authentifizierte Identität und einen gefilterten Lesezugriff voraus.
- Erlaubte Aktion: benötigte Datensätze lesen, sofern Rolle und Zweck übereinstimmen
- Zusätzliche Begrenzung: nur relevante Datensätze und Felder ausgeben
- Betrieblicher Nutzen: Mitarbeitende erhalten Unterstützung, ohne dass der Agent den gesamten Datenbestand einsehen kann.
Datenminimierung gilt nicht nur für die Speicherung, sondern auch für einzelne Abfragen. Artikel 5 der DSGVO verlangt, personenbezogene Daten auf das für den Zweck notwendige Maß zu beschränken. Artikel 32 verpflichtet Verantwortliche und Auftragsverarbeiter zu risikogerechten technischen und organisatorischen Schutzmaßnahmen.
Ein Rollen- und Berechtigungsmodell kann diese Anforderungen unterstützen, erfüllt aber nicht automatisch sämtliche rechtlichen Vorgaben. Eine weiterführende Einordnung bietet unser Beitrag zur DSGVO-Entscheidungslogik beim KI-Einsatz. Bei sensiblen oder rechtlich relevanten Prozessen solltest Du zusätzlich fachkundigen Datenschutz- und Rechtsrat einholen.
Zone 3: Schreibende und transaktionale Aktionen
Die dritte Zone beginnt, sobald der Agent Daten anlegt, verändert, veröffentlicht, versendet, reserviert oder eine Zahlung vorbereitet. Jeder Schreibzugriff braucht einen engeren Zweck als ein Lesezugriff. „Darf Buchungen verwalten“ ist zu weit gefasst. „Darf einen Reservierungsentwurf für den angefragten Zeitraum anlegen“ ist klarer begrenzt.
- Erlaubte Aktion: genau definierte Entwürfe oder Transaktionen ausführen
- Begrenzung: nur vorgesehene Felder, Wertebereiche und Datensätze verändern
- Freigabe: abhängig von Risiko, Betrag und möglicher Auswirkung
- Betrieblicher Nutzen: Automatisierung spart Arbeit, ohne die Entscheidungshoheit unkontrolliert abzugeben.
Wie eine Website technisch auf solche Abläufe vorbereitet werden kann, beschreibe ich im Beitrag über kontrollierte Buchungsaktionen durch KI-Agenten. Eine transaktionsfähige Website braucht klar definierte Schreibrechte, Freigaben und Rücksetzungswege.
Ein Rollenmodell für kleine Teams
Ein praxistaugliches Rollenmodell beginnt nicht mit Softwarebezeichnungen, sondern mit Aufgaben. Jede Rolle erhält nur die minimal erforderlichen Rechte. Dieses Prinzip heißt Least Privilege.
NIST führt Least Privilege und die Trennung von Funktionen als anerkannte Sicherheitskontrollen. Zugriffe sollen nur erlaubt werden, wenn sie zur Erfüllung einer zugewiesenen Aufgabe erforderlich sind. Die vollständige Quelle findest Du am Ende des Artikels.
Öffentlicher Leser
- Daten: veröffentlichte Leistungen, Standorte, Öffnungszeiten und allgemeine Informationen
- Aktion: ausschließlich lesen
- Laufzeit: Sitzung oder begrenzte Abfrage
- Freigabe: keine, sofern nur öffentliche Fakten ausgegeben werden
- Protokollierung: technische Anfrage, Zeitpunkt und Ressource
Interner Assistent
- Daten: freigegebene interne Dokumente und zugewiesene Vorgänge
- Aktion: lesen, suchen, zusammenfassen und Vorschläge erstellen
- Laufzeit: begrenzte Arbeitssitzung
- Freigabe: erforderlich, bevor ein Vorschlag eine externe Wirkung entfaltet
- Protokollierung: Identität, Zweck, verwendete Quellen und Ergebnisstatus
Inhaltsredakteur
- Daten: ausgewählte Inhaltsbereiche
- Aktion: Entwürfe anlegen und definierte Felder bearbeiten
- Nicht erlaubt: eigenständig veröffentlichen, Benutzerrechte ändern oder bestehende Inhalte löschen
- Freigabe: Veröffentlichung durch eine berechtigte Person
- Protokollierung: geänderte Felder, Versionen und Freigabeperson
Transaktionsagent
- Daten: nur der Vorgang, für den eine Aktion angefragt wurde
- Aktion: beispielsweise einen Reservierungsentwurf, eine Bestellanfrage oder einen Terminvorschlag anlegen
- Nicht erlaubt: Preise frei verändern, Zahlungen eigenständig auslösen oder fremde Vorgänge einsehen
- Freigabe: abhängig von Risiko und finanzieller Wirkung
- Protokollierung: vollständige Entscheidungskette ohne unnötige sensible Inhalte
Menschliche Freigaberolle
- Aufgabe: vorgeschlagene Änderungen prüfen, bestätigen oder ablehnen
- Rechte: nur der für die Freigabe notwendige Zugriff
- Kontrolle: bei besonders kritischen Aktionen Vier-Augen-Prinzip
- Verantwortung: jede Entscheidung muss einer konkreten Person zugeordnet werden können
Die Trennung der Rollen verhindert, dass ein einzelner Agent den gesamten Ablauf von der Dateneinsicht bis zur irreversiblen Aktion kontrolliert. Dadurch sinken das Risiko von Fehlbedienung und Missbrauch sowie der Aufwand für die spätere Ursachenanalyse.
Zugriffskontrolle bis auf Datensatz und Feld
Ein häufiger Planungsfehler besteht darin, Berechtigungen nur auf vollständige Schnittstellen oder Systembereiche anzuwenden. Ein Agent darf dann entweder auf das gesamte CRM zugreifen oder gar nicht. Für betriebliche Abläufe ist diese Entscheidung zu grob.
Eine belastbare Zugriffskontrolle prüft mindestens drei Ebenen:
- Endpunkt: Welche Funktion darf aufgerufen werden?
- Datensatz: Welcher konkrete Vorgang darf gelesen oder verändert werden?
- Feld: Welche Bestandteile des Datensatzes darf der Agent sehen oder bearbeiten?
Besonders sensible Felder benötigen eigene Regeln. Dazu können Kontaktdaten, individuelle Preise, Bankdaten, Gesundheitsdaten, Personalinformationen und interne Notizen gehören. Je nach Aufgabe werden solche Felder gesperrt, teilweise maskiert oder nur einer besonders geschützten Rolle angezeigt.
Ein Verfügbarkeitsagent benötigt möglicherweise Zimmerkategorie, Zeitraum und Belegungsstatus. Der Agent benötigt aber weder die Bankverbindung früherer Gäste noch interne Notizen zu Beschwerden. Feldgenaue Regeln reduzieren den Datenzugriff und begrenzen mögliche Schäden.
Kurzlebige Tokens und getrennte Agenten-Identitäten
Jeder Agent sollte eine eigene technische Identität erhalten. Gemeinsam genutzte Dauerschlüssel erschweren die Zuordnung von Aktionen. Wird ein solcher Schlüssel kompromittiert, müssen möglicherweise mehrere Prozesse gleichzeitig abgeschaltet werden.
Kurzlebige Tokens sind zeitlich begrenzte Zugangsdaten. Ein Token sollte zusätzlich an einen konkreten Zweck, eine Rolle und möglichst an eine definierte Ressource gebunden sein.
- Ein Agent für öffentliche Informationen erhält keinen Token mit Schreibrecht.
- Ein Reservierungsagent erhält nicht automatisch Zugriff auf Buchhaltung oder Personalverwaltung.
- Ein Token für einen einzelnen Vorgang gilt nur so lange, wie die Aktion voraussichtlich dauert.
- Nach Abschluss oder bei Auffälligkeiten muss ein sofortiger Widerruf möglich sein.
- Neue Rechte werden nicht stillschweigend in bestehende Tokens aufgenommen.
Es gibt keine einheitlich passende Laufzeit für alle Systeme. Als praktische Grundregel gelten für einzelne Aktionen eher Minuten und für begrenzte Arbeitssitzungen eher Stunden. Unbegrenzt gültige Zugangsdaten solltest Du vermeiden. Die konkrete Laufzeit richtet sich nach Risiko, System und Wiederherstellbarkeit.
Schreibaktionen nach Risiko staffeln
Nicht jeder Schreibzugriff hat dieselbe Wirkung. Ein gespeicherter Textentwurf ist leichter rückgängig zu machen als eine veröffentlichte Preisliste oder eine ausgelöste Zahlung. Deshalb sollte die menschliche Freigabe nach dem möglichen Schaden gestaffelt werden.
Niedriges Risiko: Entwurf ohne vorherige Freigabe
Der Agent darf einen Entwurf anlegen, aber nicht veröffentlichen oder versenden. Beispiele sind Antwortvorschläge, Terminentwürfe oder vorbereitete Produktbeschreibungen. Die Entscheidung bleibt beim Menschen.
Mittleres Risiko: Aktion nach menschlicher Freigabe
Der Agent bereitet die Änderung vor. Eine berechtigte Person prüft Inhalt, Ziel und Folgen und bestätigt anschließend die Ausführung. Beispiele sind Veröffentlichungen, externe E-Mails oder verbindliche Reservierungsbestätigungen.
Hohes Risiko: starke Authentifizierung und Vier-Augen-Prinzip
Irreversible, finanzielle oder sicherheitsrelevante Aktionen brauchen eine stärkere Kontrolle. Dazu gehören Zahlungen, Preisänderungen mit großer Reichweite, Löschvorgänge, Vertragsabschlüsse oder Änderungen an Berechtigungen. Bei solchen Aktionen sollten zwei getrennte, berechtigte Personen zustimmen.
Was ein vollständiges Audit-Log enthalten sollte
Ein Audit-Log dokumentiert die Entscheidungskette einer Aktion. Dadurch kannst Du Fehler untersuchen, Rechte anpassen und bei einem Sicherheitsvorfall gezielt reagieren.
Für eine Agentenaktion sollten mindestens folgende Angaben protokolliert werden:
- eindeutige Identität des Agenten und gegebenenfalls des auslösenden Nutzers
- Zeitpunkt und technische Sitzung
- angefragte Ressource und beabsichtigte Aktion
- betroffener Datensatz
- gelesene oder geänderte Felder
- Entscheidung der Zugriffskontrolle: erlaubt, abgelehnt oder zur Freigabe vorgelegt
- Identität der Freigabeperson
- Ergebnis der Aktion und mögliche Fehlermeldung
- Widerruf, Rücksetzung oder nachträgliche Korrektur
Das Audit-Log darf nicht zu einer zweiten ungeschützten Datensammlung werden. Vollständige E-Mail-Inhalte, Bankdaten, Gesundheitsinformationen oder geheime Zugangsdaten gehören nicht ungefiltert in das Protokoll. Häufig reichen Datensatz-ID, Feldname, Status und eine technische Prüfsumme.
Auch die Aufbewahrungsdauer muss festgelegt werden. Sie hängt vom Prüfzweck, von gesetzlichen Pflichten und vom betrieblichen Risiko ab. Eine unbegrenzte Speicherung auf Vorrat widerspricht dem Grundsatz der Datenminimierung.
Praxisbeispiel: vom Systemzugang zum Reservierungsentwurf
In meiner Beratung mit Südtiroler KMU begegnet mir regelmäßig ein ähnliches Muster. Das folgende Beispiel fasst einen typischen, anonymisierten Ablauf aus Tourismus- und Dienstleistungsprojekten zusammen.
Vorher: ein Zugang für den gesamten Ablauf
Ein Betrieb möchte wiederkehrende Anfragen schneller beantworten. Der geplante Agent erhält deshalb einen allgemeinen Zugang zum Verwaltungssystem. Der Agent kann Verfügbarkeiten lesen, Kontaktdaten sehen, Datensätze verändern und Reservierungen bestätigen.
Dieser pauschale Zugriff verursacht mehrere Probleme:
- Der Agent sieht mehr personenbezogene Daten als für die Anfrage erforderlich.
- Lese- und Schreibrechte sind nicht getrennt.
- Eine missverständliche Nachricht kann eine unerwünschte Buchung auslösen.
- Änderungen lassen sich keiner klar abgegrenzten Agenten-Identität zuordnen.
- Bei einem Vorfall muss der vollständige Zugang gesperrt werden.
Nachher: vier kontrollierte Übergaben
Der überarbeitete Prozess teilt dieselbe Aufgabe in klar begrenzte Schritte:
- 1. Anfrage erfassen: Der Agent liest Zeitraum, Personenzahl und gewünschte Kategorie aus der Nachricht. Bankdaten und historische Gästedaten bleiben unberührt.
- 2. Verfügbarkeit prüfen: Ein reiner Lesezugriff fragt nur passende Kategorien und freie Kontingente ab.
- 3. Reservierungsentwurf anlegen: Ein separater Schreibzugriff legt einen zeitlich begrenzten Entwurf an. Der Agent darf weder Preisregeln ändern noch eine verbindliche Bestätigung versenden.
- 4. Menschlich bestätigen: Eine zuständige Person prüft Verfügbarkeit, Preis, Kontaktdaten und besondere Wünsche. Erst danach wird die Reservierung bestätigt.
Das Team spart weiterhin Zeit. Gleichzeitig sinken das Fehlbuchungsrisiko und der unnötige Datenzugriff, während Änderungen und Verantwortlichkeiten nachvollziehbar bleiben.
btlabs Core als vorbereitetes Fundament
Eine zentrale, strukturierte Datenbasis kann spätere Agentenaktionen technisch vorbereiten. Eine KI-ready Website mit btlabs Core stellt Unternehmenswissen strukturiert aus einer zentralen Inhaltsbasis bereit.
Buchende oder schreibende Agenten sind Ausbaustufen und keine fertige Standardfunktion von btlabs Core. Sobald ein Agent handeln soll, müssen Rollenmodell, Freigaben, Zugriffskontrolle, Protokollierung, Schnittstellen und Widerruf passend zum jeweiligen Betrieb geplant und umgesetzt werden.
Einführungscheckliste für Dein KMU
- Aufgabe begrenzen: Beschreibe in einem Satz, was der Agent tun soll und was ausdrücklich nicht.
- Daten klassifizieren: Trenne öffentliche, interne, personenbezogene und besonders sensible Daten.
- Lesen vor Schreiben: Starte mit einem reinen Lesezugriff und beobachte reale Anfragen.
- Rollen definieren: Gib jedem Agenten und jeder Freigabeperson eine eigene Identität.
- Least Privilege umsetzen: Erlaube nur erforderliche Endpunkte, Datensätze, Felder und Aktionen.
- Tokens begrenzen: Nutze kurzlebige, zweckgebundene Zugangsdaten mit sofortigem Widerruf.
- Schreibrechte staffeln: Unterscheide Entwurf, Veröffentlichung, Transaktion und irreversible Aktion.
- Freigaben festlegen: Bestimme, wann eine menschliche Freigabe oder das Vier-Augen-Prinzip notwendig ist.
- Audit-Log einrichten: Protokolliere Identität, Zweck, Entscheidung, Änderungen und Ergebnis.
- Not-Aus testen: Prüfe, ob Tokens, Agenten und einzelne Schreibfunktionen sofort gesperrt werden können.
- Mit einem Pilotprozess starten: Ein klar abgegrenztes KI-Pilotprojekt für ein Südtiroler KMU liefert belastbarere Erkenntnisse als eine breite Einführung ohne Kontrollpunkte.
- Regelmäßig überprüfen: Entferne nicht mehr benötigte Rechte und werte abgelehnte Aktionen aus.
Kontrollierte Automatisierung schützt alle Beteiligten
Ein klares Berechtigungsmodell macht nachvollziehbar, welche Daten ein Agent verwenden und welche Aktionen er ausführen darf. Mitarbeitende behalten die Entscheidungshoheit, personenbezogene Daten werden gezielter geschützt und der Agent kann die vorgesehene Aufgabe trotzdem übernehmen.
Das entspricht meiner Vorstellung von Win-Win-Win: Der Betrieb gewinnt Zeit und Verlässlichkeit, das Team gewinnt Klarheit und Menschen behalten die Kontrolle über folgenreiche Entscheidungen. Wenn Du einen solchen Ablauf planst, unterstützen wir Dich mit unserer Beratung zu KI und Digitalisierung von der Prozessanalyse bis zur technischen Umsetzung.
Fragen und Antworten zu KI-Agenten-Berechtigungen
Sollte ein KI-Agent grundsätzlich nur lesen dürfen?
Ein neuer Agent sollte mit einem begrenzten Lesezugriff starten. Schreibrechte kommen erst hinzu, wenn Aufgabe, Datenfelder, Fehlerfolgen, Freigaben und Widerruf klar definiert und getestet sind.
Was ist der Unterschied zwischen Lese- und Schreibrechten?
Ein Lesezugriff ruft Informationen ab, während ein Schreibzugriff den betrieblichen Zustand verändert. Schreibrechte brauchen deshalb engere Grenzen, eine stärkere Protokollierung und je nach Auswirkung eine menschliche Freigabe.
Wie lange sollte ein Token für einen KI-Agenten gültig sein?
Ein Token sollte nur so lange gültig sein, wie die konkrete Aufgabe voraussichtlich dauert. Einzelne Aktionen benötigen eher Minuten, begrenzte Arbeitssitzungen eher Stunden. Unbegrenzt gültige Zugangsdaten solltest Du vermeiden.
Wann ist eine menschliche Freigabe notwendig?
Eine menschliche Freigabe ist sinnvoll, sobald eine Aktion externe, rechtliche, finanzielle oder schwer rückgängig zu machende Folgen hat. Bei Zahlungen, Löschungen, Vertragsabschlüssen und Berechtigungsänderungen ist zusätzlich ein Vier-Augen-Prinzip zu prüfen.
Braucht jeder KI-Agent eine eigene Identität?
Ja. Getrennte Identitäten erleichtern Zugriffskontrolle, Protokollierung und Widerruf. Wird ein Agent kompromittiert, kannst Du dessen Zugang gezielt sperren, ohne alle Automatisierungen gleichzeitig abzuschalten.
Was bedeutet ein Not-Aus für KI-Agenten?
Ein Not-Aus beendet aktive Sitzungen, widerruft Tokens und stoppt mindestens alle Schreibaktionen. Der Not-Aus sollte technisch getestet, einer verantwortlichen Person zugeordnet und ohne Hilfe des betroffenen Agenten ausführbar sein.
Was ist bei kompromittierten Zugangsdaten sofort zu tun?
Widerrufe den betroffenen Token, sperre den Agenten und stoppe schreibende Funktionen. Prüfe anschließend das Audit-Log, sichere relevante Nachweise, kontrolliere erfolgte Änderungen und vergib erst nach der Klärung neue Zugangsdaten.
Wie lange sollten Audit-Logs aufbewahrt werden?
Die Aufbewahrungsdauer richtet sich nach Prüfzweck, Risiko und möglichen gesetzlichen Pflichten. Definiere eine nachvollziehbare Frist und lösche Protokolle anschließend kontrolliert, statt sensible Informationen unbegrenzt zu sammeln.
Macht ein Rollenmodell den KI-Einsatz automatisch DSGVO-konform?
Nein. Ein Rollenmodell unterstützt Datenminimierung und Zugriffsschutz, ersetzt aber keine Prüfung von Rechtsgrundlage, Informationspflichten, Verträgen, Speicherfristen und weiteren Anforderungen. Bei personenbezogenen oder sensiblen Daten ist eine fachkundige Einzelfallprüfung sinnvoll.
Wie starte ich ohne bestehende Zugriffskontrolle?
Beginne mit einem kleinen, reversiblen Prozess und einem reinen Lesezugriff. Dokumentiere Datenquellen, Rollen und erlaubte Aktionen, bevor Du Entwürfe oder verbindliche Schreibaktionen freischaltest.
