Der Prompt ist keine Berechtigung
Aktualisiert: vor 13 Minuten
Inhalt
Ein PHP-Update als Weckruf
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt ein dringendes Sicherheitsupdate. Zwei mit CVSS 9,2 bewertete Schwachstellen konnten unauthentifizierte Remote-Code-Ausführung ermöglichen. Das PHP-Projekt sah das höchste Risiko bei einer Konstellation, in der ein Angriff ausgelöst werden konnte, bevor der eigentliche Anwendungscode überhaupt lief.
Das ist zunächst kein KI-Thema. Genau deshalb ist es für KI-Governance relevant.
KI-Anwendungen laufen nicht außerhalb der normalen IT-Sicherheitswelt. Sie nutzen Webanwendungen, Benutzerkonten, Systemidentitäten, Schnittstellen und Datenbanken. Jede dieser Ebenen kann angegriffen oder missbraucht werden.
Die entscheidende Frage lautet deshalb nicht nur:
Was kann unsere KI im ERP?
Die schwierigere Frage lautet:
Was kann ein Angreifer mit den Fähigkeiten tun, die wir der KI gegeben haben?
Wenn ein Angriff nicht wie ein Angriff aussieht
Montagmorgen, 8:42 Uhr. Ein Angreifer erhält Zugriff auf einen Dienst, der mit einem ERP-Assistenten verbunden ist.
Er verschlüsselt keine Server. Er löscht keine Datenbank. Er erzeugt keinen sofort sichtbaren Systemausfall.
Stattdessen nutzt er vorhandene Fähigkeiten.
Zunächst lässt er offene Lieferanten, Zahlungsbedingungen und vorbereitete Zahlungen auswerten. Danach werden einzelne Stammdaten oder Zahlungsvorschläge verändert. Jede Änderung wirkt für sich plausibel. Beträge bleiben unter auffälligen Grenzen. Die Vorgänge verteilen sich über mehrere Tage.
Die Ausführung erfolgt über ein technisch autorisiertes Systemkonto.
Im Protokoll steht dann möglicherweise nicht „unbekannter Angreifer“.
Im Protokoll steht der Name der Integration.
Das System wurde nicht dazu gebracht, etwas technisch Unmögliches zu tun. Es hat erlaubte Fähigkeiten für einen unerlaubten Zweck verwendet.
Genau darin liegt die neue Qualität des Risikos. Eine KI-Integration kann Daten nicht nur anzeigen. Sie kann Zusammenhänge herstellen, nächste Schritte auswählen und – je nach Freigabe – wirtschaftlich relevante Aktionen vorbereiten oder ausführen.
Ein Prototyp beweist, dass eine KI etwas kann.
Produktionsreife beweist sich daran, was sie unter Angriff, Manipulation oder falscher Identität nicht tun darf.
Drei Wege zum Missbrauch
Ein externer Cyberangriff ist nur eine Möglichkeit. Für eine belastbare Governance müssen mindestens drei Angriffspfade berücksichtigt werden.
Ein berechtigter Benutzer handelt missbräuchlich
Ein Mitarbeiter besitzt legitimen Zugriff, verwendet ihn aber für einen unzulässigen Zweck. Er stellt viele einzeln unauffällige Fragen, kombiniert Ergebnisse oder versucht, aus freigegebenen Kennzahlen geschützte Informationen abzuleiten.
Eine direkte Frage nach vertraulichen Daten kann das System ablehnen. Schwieriger wird es bei indirekten Schlussfolgerungen: Mehrere erlaubte Antworten können gemeinsam einen gesperrten Einzelwert offenlegen. Auch kleine Vergleichsgruppen, wiederholte Abfragen und ungewöhnlich umfangreiche Auswertungen gehören deshalb zur Risikobetrachtung.
Eine Identität oder Anwendung wird kompromittiert
Ein Angreifer übernimmt ein Benutzerkonto, einen Webdienst oder eine Systemidentität. Für nachgelagerte Systeme sehen seine Anfragen zunächst legitim aus.
Eine erfolgreiche Anmeldung darf deshalb nicht automatisch den uneingeschränkten Zugriff auf alle Fähigkeiten einer Rolle eröffnen. Kritische Aktionen können eine erneute Bestätigung, eine zweite Freigabe, Wertgrenzen oder eine zeitlich begrenzte Berechtigung benötigen.
Daten manipulieren die KI
Auch die verarbeiteten Inhalte selbst können zum Angriffsweg werden. Eine E-Mail, ein Dokument, ein Freitextfeld oder ein importierter Datensatz kann Anweisungen enthalten, die für einen Menschen wie normaler Inhalt aussehen, vom Modell aber als Handlungsaufforderung interpretiert werden.
Ein externes Dokument könnte versuchen, eine erlaubte Prüfung in eine unzulässige Abfrage oder Aktion umzulenken. Solche indirekten Anweisungen dürfen niemals Berechtigungen erweitern.
Externe Inhalte sind Daten. Sie sind keine autorisierte Steuerung des Systems.
Besonders kritisch wird es, wenn sich diese Wege verbinden: Eine kompromittierte Anwendung verarbeitet manipulierte Inhalte und verwendet anschließend technisch freigegebene Fähigkeiten für eine wirtschaftlich schädliche Aktion.
Dann wird aus einem hilfreichen Assistenten ein Angriffsverstärker.
Warum der Prompt keine Berechtigung ist
Auch im normalen Betrieb entsteht das Problem bereits bei einer scheinbar harmlosen Frage. Ein Vertriebsmitarbeiter fragt:
„Warum ist unsere Marge bei diesem Kunden im letzten Quartal gesunken?“
Für eine belastbare Antwort müsste das System möglicherweise Verkaufspreise, Einkaufspreise, Sonderkonditionen, Gutschriften, Frachtkosten und Deckungsbeiträge zusammenführen.
Ein Geschäftsführer darf dieses Gesamtbild möglicherweise sehen. Ein Vertriebsleiter vielleicht für seine Region. Ein Vertriebsmitarbeiter nur für die eigenen Kunden – und einzelne Kostenbestandteile überhaupt nicht.
Der Wortlaut der Frage bleibt derselbe.
Die zulässige Antwort nicht.
Noch komplizierter wird der nächste Dialogschritt:
„Vergleiche das bitte mit den anderen Kunden.“
Welche Kunden sind gemeint? Alle Kunden des Unternehmens? Nur die eigene Region? Nur jene, die der Benutzer bereits im ersten Ergebnis sehen durfte? Darf das System aggregierte Werte anzeigen, wenn einzelne Datensätze gesperrt sind?
Eine Prompt-Prüfung kann bestimmte Warnsignale erkennen. Sie kann aber nicht zuverlässig bestimmen, welche Tabellen, Felder, Datensätze und Fähigkeiten für die Antwort tatsächlich verwendet werden.
Der Prompt beschreibt eine Absicht in natürlicher Sprache. Erst der geplante Werkzeug- oder Datenzugriff zeigt, was das System wirklich tun will.
Der Prompt ist keine Berechtigung. Und das Sprachmodell ist keine Sicherheitsinstanz.
Eine Anweisung wie „Beachte die Benutzerrechte“ ersetzt keine technische Zugriffskontrolle. Regeln im Systemprompt dürfen niemals die einzige Barriere zu sensiblen Daten oder kritischen Aktionen sein.
Die Sicherheitsentscheidung fällt vor dem Datenzugriff
Der kritische Zeitpunkt liegt nicht bei der Formulierung der Antwort. Wenn das Modell sensible Daten bereits erhalten hat, kommt eine nachträgliche Filterung zu spät.
Jeder geplante Zugriff muss deshalb geprüft werden, bevor eine API, eine Datenbankabfrage oder eine ERP-Funktion ausgeführt wird.
Vereinfacht ergibt sich folgende Kette:
Identität feststellen: Wer stellt die Anfrage?
Kontext bestimmen: Für welche Rolle, Gesellschaft, Region oder Aufgabe handelt die Person?
Fähigkeit auswählen: Welche fachliche Operation soll verwendet werden?
Richtlinie prüfen: Darf diese Rolle diese Fähigkeit mit diesen Daten und diesem Zweck nutzen?
Daten begrenzen: Welche Datensätze, Felder und Zeiträume dürfen verarbeitet werden?
Aktion einstufen: Wird gelesen, analysiert, vorbereitet oder ausgeführt?
Freigabe einholen: Ist eine menschliche Bestätigung notwendig?
Ausführung protokollieren: Welche Daten und Fähigkeiten wurden tatsächlich verwendet?
Wird eine Prüfung nicht eindeutig bestanden, darf das System den Zugriff nicht einfach ausführen. Es muss die Anfrage begrenzen, eine Freigabe anfordern oder kontrolliert ablehnen.
Die Sicherheitsentscheidung muss fallen, bevor Daten abgerufen werden – nicht nachdem das Modell sie bereits gesehen hat.
Von Datenbankzugriff zu freigegebenen Fähigkeiten
Eine mögliche Grundlage ist eine fähigkeitsbasierte Berechtigungsarchitektur.
Der KI-Assistent erhält nicht pauschal Zugriff auf die gesamte ERP-Datenbank. Stattdessen stehen klar abgegrenzte fachliche Fähigkeiten zur Verfügung, beispielsweise:
- Artikelinformationen abrufen,
- Lagerbestände analysieren,
- Lieferfähigkeit prüfen,
- eine Parameteränderung vorschlagen,
- eine Bestellung vorbereiten.
Für jede Fähigkeit wird festgelegt, welche Rolle sie verwenden darf, welche Daten dafür zugänglich sind und welche Grenzen gelten.
Ein Vertriebsmitarbeiter könnte die Lieferfähigkeit für einen eigenen Kundenauftrag prüfen, ohne vollständigen Zugriff auf Einkaufskonditionen oder fremde Kundenaufträge zu erhalten. Ein Disponent könnte eine Parameteränderung vorbereiten, während die tatsächliche Übernahme eine zusätzliche Freigabe erfordert.
Die Fähigkeit wird damit zur kontrollierten Grenze zwischen Benutzer, KI und ERP-System.
Lesen, vorbereiten, ausführen
Für die Governance reicht ein einfaches „erlaubt“ oder „verboten“ nicht aus. Entscheidend ist auch die Eingriffstiefe.
Stufe | Beispiel | Erforderliche Kontrolle |
Lesen | Bestand und offene Bedarfe anzeigen | Datenzugriff auf Rolle und Zweck begrenzen |
Analysieren | Lieferfähigkeit oder Bestandsrisiko bewerten | Datenbasis und Ergebnis nachvollziehbar machen |
Vorbereiten | Bestellvorschlag oder Parameteränderung erstellen | fachliche Regeln prüfen und Freigabe vorsehen |
Ausführen | Bestellung anlegen oder ERP-Wert verändern | Berechtigung, Geschäftslogik und Transaktion serverseitig erzwingen |
Besonders bei schreibenden Operationen darf die KI keine Abkürzung an der Geschäftslogik des ERP-Systems vorbei erhalten. Direkte Datenbankänderungen können Pflichtfelder, Statuswechsel, Mandantentrennung, Buchungslogik oder Folgeprozesse umgehen.
Schreibende Zugriffe sollten deshalb ausschließlich über kontrollierte und fachlich validierte Geschäftsoperationen erfolgen.
Technisch möglich ist nicht automatisch fachlich zulässig.
Produktionsreife braucht eine Sicherheitskette
Kein einzelner Mechanismus löst das Problem vollständig. Ein Rollenmodell schützt nicht vor dem Missbrauch einer berechtigten Identität. Eine Freigabemaske hilft nicht, wenn das Modell zuvor bereits sensible Daten erhalten hat. Ein Protokoll dokumentiert einen unzulässigen Zugriff, verhindert ihn aber nicht.
Eine belastbare Lösung kombiniert deshalb mehrere Schutzschichten:
Schutzschicht | Aufgabe |
Authentifizierung | Identität eindeutig feststellen |
Rollen- und Richtlinienmodell | zulässige Daten, Fähigkeiten und Zwecke definieren |
Fähigkeitskatalog | nur fachlich begrenzte Operationen bereitstellen |
Datenfilter | Datensätze und Felder vor der Modellverarbeitung begrenzen |
Freigabelogik | riskante oder schreibende Aktionen bestätigen lassen |
Transaktionsschutz | ERP-Geschäftslogik und Konsistenz erhalten |
Protokollierung | Anfrage, Zugriff, Freigabe und Ausführung nachvollziehbar machen |
Überwachung | ungewöhnliche Zugriffe und Serienabfragen erkennen |
Sicherheitstests | Rollenwechsel, indirekte Abfragen und manipulierte Inhalte prüfen |
Zusätzlich braucht es klare Verantwortung: Wer besitzt die Regeln? Wer gibt Änderungen frei? Wer bewertet Warnungen? Und wer kann im Verdachtsfall einzelne Fähigkeiten sofort deaktivieren?
Governance ist deshalb weder ein Prompt noch ein Datenschutzformular. Sie ist das Zusammenspiel aus technischer Zugriffskontrolle, fachlichen Regeln, menschlicher Freigabe und organisatorischer Verantwortung.
Fazit
KI kann den Zugang zu ERP-Daten erheblich vereinfachen. Genau das macht eine neue Governance notwendig.
Wenn natürliche Sprache komplexe Datenabfragen und Systemaktionen auslösen kann, dürfen die dahinterliegenden Grenzen nicht unsichtbar werden. Benutzer sollen nicht deshalb mehr sehen oder ausführen können, weil die neue Oberfläche leistungsfähiger ist als die bisherige ERP-Maske.
Eine produktiv einsetzbare Lösung benötigt deshalb mehr als einen funktionierenden Zugriff. Sie braucht eindeutige Identitäten, begrenzte Fähigkeiten, kontrollierte Datenzugriffe, risikogerechte Freigaben und eine nachvollziehbare Ausführung.
Die entscheidende Erkenntnis lautet:
Technische Machbarkeit ist noch keine betriebliche Freigabe.
Abschluss
Unser Value Pack #04: Governance- und Freigabelogik-Check
Wer KI mit ERP-Daten und Geschäftsprozessen verbindet, sollte Rollen, Grenzen und Verantwortung von Anfang an mitentwickeln.
Die zentrale Leitfrage:
Welche Entscheidungen darf das System vorbereiten, welche darf es ausführen, und wo bleibt der Mensch verbindlich eingebunden?
Im Governance- und Freigabelogik-Check klären wir Datenflüsse, Rollen, Fähigkeiten, Freigaben, Eskalationen und Anforderungen an die Nachvollziehbarkeit.
Als Ergebnis entstehen eine Governance-Skizze, eine Rollen- und Freigabematrix, eine Übersicht kritischer Prozessentscheidungen und erste Leitplanken für Daten, Modellnutzung und Systemaktionen.
Das System bereitet vor. Der Mensch gibt frei.
Lassen Sie uns prüfen, welche Governance- und Freigabelogik Ihr Anwendungsfall benötigt, bevor aus einem technischen Prototyp ein produktiver Prozess wird.
Stop managing ERP. Start thinking with it.
Kommentare