Welche Prozessschritte darf Ihr Agent auslösen?

Agentische KI macht aus einer Modellfrage eine Berechtigungsfrage, und die meisten Organisationen beantworten noch die erste

Management Summary

Ausgangslage

Situation. Unternehmen holen KI-Agenten aus den Pilotprojekten und setzen sie in Prozesse, die Fertigungsaufträge freigeben, Zahlungen abgleichen und Bestände anpassen. Die Sicherheitsdiskussion dazu dreht sich überwiegend um das Modell: Prompt Injection, Jailbreaks, Datenabfluss ins Training, Herkunft des Modells.

Komplikation. Diese Themen sind real, aber sie sind nicht die bindende Beschränkung. Ein Agent, der einen Fertigungsauftrag freigeben kann, ist ein Prozessakteur mit Rechten. Über sein Risiko entscheidet nicht die Härte des Modells, sondern welche Schritte er auslösen darf, ab welcher Schwelle, wer gegenzeichnet und wie eine falsche Entscheidung auffällt. Diese Fragen leben auf einer Prozesskarte. Die meisten Organisationen haben nur eine Systemkarte.

Frage. Was muss entschieden sein, bevor ein Agent Rechte in einem wertschöpfenden Prozess bekommt, und wer entscheidet das?

Kernbefunde

1. Modellhärtung und Prozessautorisierung sind unterschiedliche Kontrollen für unterschiedliche Fehlerfälle. Härtung adressiert einen Agenten, der zu etwas verleitet wurde. Autorisierung adressiert einen Agenten, der genau das tut, wofür er gebaut wurde, in einem Fall, in dem das falsch war. Und deshalb? Ein Programm, das nur gehärtet hat, hat die kleinere der beiden Gefährdungen bearbeitet und hält für gewöhnlich beide für erledigt.

2. Vier Fragen entscheiden über das Agentenrisiko, und keine davon ist auf einer Systemkarte beantwortbar. Welche Prozessschritte darf der Agent verändern, welche Schwellen gelten, wo zeichnet ein Mensch gegen, wie wird eine falsche Entscheidung erkannt und zurückgerollt. Und deshalb? Wenn Ihre Architekturdokumentation systemzentriert ist, können Sie die Fragen, die Ihre Agenten regieren, derzeit nicht beantworten, ganz gleich wie gut diese Dokumentation ist.

3. Das Werkzeug liefert die Karte, nicht die Entscheidung. Geprüft an der Produktdokumentation, nicht am Marketingmaterial: SAP LeanIX dokumentiert Versions-Clustering, die Erkennung, welche Eigenentwicklungen auf welchen Standard-Stacks laufen, sowie Lebenszyklusdaten. Als benannte Fähigkeit beschreibt es kein Dependency Mapping und keine direkten Konnektoren zu Sicherheitswerkzeugen. SAP Signavio beschreibt ein vierstufiges Vorgehen für Risiken und Kontrollen und nennt SOX, Basel und Dodd-Frank unter den unterstützten Rahmenwerken. Benannte Funktionen für die Verknüpfung einzelner Risiken mit Sicherheitskontrollen führt es nicht auf. Und deshalb? Prozessmodellierung und Enterprise Architecture einzukaufen kauft keine Agentenautorisierung. Es kauft die Grundlage, auf der Menschen diese Entscheidung treffen können.

4. Die bindende Beschränkung ist organisatorisch und billig zu beheben. Wer entscheidet sonntags um 03:00 Uhr über den Stopp eines Agenten, und ab welcher Schwelle? Wo das ungeklärt ist, eskaliert die Organisation, statt zu handeln, und Eskalation im Vorfall verbraucht genau die Stunden, die über seine Größe entscheiden. Und deshalb? Eine vorab vereinbarte Entscheidungsmatrix mit benannten Rollen kostet nichts und fehlt regelmäßig. Sie ist das Artefakt mit dem besten Verhältnis von Wirkung zu Aufwand im ganzen Programm.

5. Quantifizierung gehört an das Ende des Weges, nicht an den Anfang. Der Reifegradpfad lautet systemzentriert, Bestandsaufnahme, Prozesskopplung, prozessgeführt, wertgesteuert. Wer mit der Risikoquantifizierung beginnt, beantwortet Stufe fünf, während seine Agenten auf Stufe eins arbeiten. Und deshalb? Eine Risikozahl, die vor der Prozesszuordnung entsteht, misst die Qualität der Schätzung, nicht die Gefährdung.

Zentrale Empfehlungen

Priorität	Empfehlung	Aufwand	Zeitraum
Hoch	Für jeden Agenten im oder nahe am Produktivbetrieb schriftlich festhalten, welche Prozessschritte er auslösen darf	Gering	Sofort
Hoch	Gegenzeichnungsschwelle je Schritt definieren und die zuständige Rolle benennen	Gering	Sofort
Hoch	Die Stopp-Entscheidung und ihren Inhaber vor dem Vorfall schriftlich vereinbaren	Gering	Ein Monat
Mittel	Erkennung und Rücknahme für formal korrekte, inhaltlich falsche Agentenentscheidungen aufbauen	Hoch	Ein bis zwei Quartale
Mittel	Wertkritische Prozesse auf ausführende Systeme abbilden und je Prozess einen Inhaber benennen	Hoch	Zwei Quartale
Gering	Risikoquantifizierung zurückstellen, bis die Prozesskopplung existiert	Gering	Laufend

Fazit

Die Agentenfrage, auf die es ankommt, lautet nicht „ist das Modell sicher“. Sie lautet „was darf dieses Ding tun, ohne zu fragen, und wer merkt es, wenn es falsch war“. Diese Frage hat einen Inhaber, eine Schwelle und einen Rückweg, oder sie hat keine Antwort.

Wo die Debatte gerade steht

Die öffentliche Diskussion über Agentensicherheit ist weitgehend eine Modelldiskussion. Das ist nachvollziehbar: Das Modell ist die neue Komponente, die Angriffe darauf lassen sich vorführen, und die Anbieter mit der lautesten Stimme verkaufen Kontrollen auf der Modellebene.

Sie ist auch auf eine bestimmte Weise unvollständig. Modellhärtung fragt, ob der Agent zu etwas gebracht werden kann, das er nicht tun sollte. Prozessautorisierung fragt, was passiert, wenn der Agent genau das tut, wofür er gebaut wurde, in einer Lage, die beim Entwurf niemand vorgesehen hat. Der zweite Fall erzeugt keine Anomalie, keine Injection-Signatur und keinen Alarm. Er erzeugt eine korrekt aussehende Transaktion mit einem falschen Geschäftsergebnis.

Diese beiden Fehlerfälle brauchen unterschiedliche Kontrollen, unterschiedliche Verantwortliche und unterschiedliche Nachweise. Wer Agentensicherheit als Modellproblem behandelt, lässt den zweiten Fall unbearbeitet und, schlimmer, ungemessen.

Befund 1: Die vier Fragen

Ein Agent, der Fertigungsaufträge freigibt oder Zahlungen abgleicht, ist in erster Linie kein Fall für Modellsicherheit. Vier Fragen regieren ihn:

Welche Prozessschritte darf er verändern? Nicht welche Systeme er erreicht, sondern welche Schritte er im Zustand verändern darf.
Welche Schwellen gelten? Wert, Menge, Häufigkeit, Abweichung von einer Norm. Die Schwelle trennt einen handelnden von einem fragenden Agenten.
Wo zeichnet ein Mensch gegen? Nicht als Formalie, sondern als definierter Schritt mit benannter Rolle und einer Reaktionszeit.
Wie wird eine falsche Entscheidung erkannt und zurückgerollt? Einschließlich des Falls, in dem die Entscheidung formal gültig war.

Auf einer Systemkarte sind diese Fragen nicht beantwortbar, denn eine Systemkarte hält fest, was womit verbunden ist, nicht was von wem unter welcher Bedingung verändert werden darf. Auf einer Prozesskarte sind sie beantwortbar. Deshalb ist der prozesszentrierte Rahmen hier keine philosophische Vorliebe, sondern eine praktische Voraussetzung.

Befund 2: Was der Bezugsrahmen verändert

Die Verschiebung betrifft nicht die Zuständigkeit. Sie verändert den Bezugsrahmen für jede einzelne Maßnahme.

Dimension	Bisheriger Bezugsrahmen	Prozesszentrierter Bezugsrahmen
Berechtigungsdesign	Rolle und Transaktion	Prozessschritt und die dort getroffene Entscheidung
Patch-Priorisierung	CVSS-Wert des Systems	Kritikalität der darauf laufenden Prozesse
KI-Agenten	Härtung von Modell und Plattform	Welche Prozessschritte der Agent auslösen darf und wer das Ergebnis prüft
Schnittstellen	technische Bestandsliste	Prozessabhängigkeit: welcher Wertstrom bricht bei Ausfall
Vorfallsbewertung	betroffene Systeme	unterbrochene Prozesse und ihr Beitrag zum Ergebnis

Jede Zeile ist eine Entscheidung, die die Organisation bereits stillschweigend getroffen hat. Sie zuerst für Agenten explizit zu machen, ist der günstigste Einstieg, weil Agenten neu genug sind, dass keine gewachsene Regelung aufgelöst werden muss.

Befund 3: Das Werkzeug liefert die Karte, nicht die Entscheidung

Eine verbreitete Antwort lautet, es brauche kein neues Werkzeug, weil Prozessmodellierung und Enterprise Architecture ohnehin im Haus seien. Das stimmt zur Hälfte, und die andere Hälfte ist die wichtige.

Geprüft an der Produktdokumentation statt an Positionierungsmaterial: SAP LeanIX dokumentiert im Bereich Technology Risk and Compliance Versions-Clustering, die Erkennung, welche Eigenentwicklungen auf welchen Standard-Stacks laufen, sowie Lebenszyklusdaten zu Supportarten und Richtlinien. Dependency Mapping als benannte Fähigkeit beschreibt es nicht, direkte Konnektoren zu Sicherheitswerkzeugen ebenfalls nicht. SAP Signavio beschreibt ein vierstufiges Vorgehen aus dokumentieren, Risiken erkennen, Kontrollen umsetzen, fortlaufend überwachen, und nennt SOX, Basel und Dodd-Frank unter den unterstützten Rahmenwerken. Benannte Funktionen zur Verknüpfung einzelner Risiken mit Sicherheitskontrollen führt es nicht auf.

Keiner der beiden Anbieter behauptet etwas anderes. Die Überdehnung stammt nicht von ihnen.

Das Repository macht Kritikalität diskutierbar. Es erzeugt keine Sicherheitsentscheidung, und keine Beschaffung wird daran etwas ändern. Die Entscheidung verlangt Menschen, die den Prozess und seine technischen Abhängigkeiten verstehen und zusammenarbeiten. Das ist ein organisatorischer Aufwand, den keine Lizenz abdeckt.

Befund 4: Das 03:00-Uhr-Problem

Einen Host isolieren, eine Partnerschnittstelle abschalten, einen Agenten mitten im Lauf anhalten: technisch trivial, organisatorisch in den meisten Häusern ungeklärt.

Wenn niemand vorher vereinbart hat, wer sonntags um 03:00 Uhr entscheidet und ab welcher Schwelle, eskaliert die Organisation, statt zu handeln. Eskalation im laufenden Vorfall verbraucht genau die Stunden, die über seine spätere Größe entscheiden.

Das Gegenmittel ist eine Entscheidungsmatrix mit benannten Rollen, vereinbart und abgezeichnet, bevor etwas passiert. Sie braucht kein Budget, keine Beschaffung und keine Technologie. Sie fehlt regelmäßig, und ihr Fehlen ist unsichtbar bis zu der Nacht, in der es darauf ankommt.

Von allem in diesem Artikel hat dieser Punkt das beste Verhältnis von Folgen zu Kosten. Er ist in einem Workshop zu erledigen.

Befund 5: Quantifizierung kommt zuletzt

Der Reifegradpfad läuft in einer bestimmten Reihenfolge:

Systemzentriert. Sicherheit endet an der Systemgrenze.
Bestandsaufnahme. Architektur und Abhängigkeiten bekannt.
Prozesskopplung. Systeme auf Prozesse abgebildet, Kritikalität klar.
Prozessgeführt. Priorisierung und Agentenrechte folgen dem Prozess.
Wertgesteuert. Risiko in Geschäftszahlen, Governance angeschlossen.

Die Quantifizierung sitzt auf Stufe fünf. Wer dort beginnt, weil der Vorstand eine quantifizierte Risikozahl verlangt hat, erzeugt eine Zahl, deren Genauigkeit von einer Zuordnung abhängt, die es noch nicht gibt.

Die Reihenfolge ist keine Bürokratie. Jede Stufe ist die Eingabe der nächsten, und der Sprung ans Ende erzeugt eine Zahl, die den Schätzenden misst und nicht die Gefährdung.

Was das für die Geschäftsleitung bedeutet

Agentenautorisierung ist eine Geschäftsentscheidung, die derzeit keinen Inhaber hat. Die Sicherheit kennt den Prozess nicht, der Prozessverantwortliche kennt die Systeme nicht, und die Enterprise Architecture pflegt das Repository aus Gründen, die mit Sicherheit nichts zu tun haben. Die Zuordnung ist die Arbeit, und sie ist niemandes Aufgabe, bis jemand sie zuweist.

Zuständigkeit zu erklären, ohne sie auszustatten, verschiebt Papier, nicht Risiko. Einem Prozessverantwortlichen die Verantwortung für ein Risiko zu geben, für das er weder Budget noch Fachwissen hat, ist der häufigste Weg, prozesszentrierte Absichten wirkungslos zu machen. Der Rahmen ändert sich, die Ausstattung nicht.

Fortschritt verlangt zwei unbequeme Eingeständnisse. Die Sicherheit muss sagen, dass sie die Prozesse nicht kennt, und das Geschäft muss sagen, dass seine Dokumentation nicht dem entspricht, was läuft. Beides ist beruflich unangenehm, und deshalb bleiben Programme beim Zuordnungsschritt stehen und werden als Werkzeugauswahl neu gestartet.

Empfehlungen

Empfehlung	Begründung	Inhaber	Aufwand
Die Prozessschritte je Produktivagent auflisten	Aus einer Systemkarte nicht ableitbar, muss aufgeschrieben werden	Prozessverantwortung mit Sicherheit	Gering
Gegenzeichnungsschwelle je Schritt mit benannter Rolle festlegen	Trennt Handeln von Fragen, die Kernkontrolle	Prozessverantwortung	Gering
Schriftlich vereinbaren, wer einen Agenten stoppen darf und ab wann	Eskalation im Vorfall kostet die Stunden, auf die es ankommt	CISO und COO	Gering
Erkennung und Rücknahme für formal gültige, falsche Entscheidungen bauen	Der Fehlerfall, der keinen Alarm erzeugt	Security Engineering	Hoch
Je wertkritischem Prozess einen Inhaber benennen, der die technischen Abhängigkeiten kennt	Die Zuordnung hat heute keinen natürlichen Inhaber	Vorstandspate	Hoch
Quantifizierung bis Stufe drei zurückstellen	Eine frühere Zahl misst die Schätzung	Risikomanagement	Gering

Übersicht für die Geschäftsleitung

Frage	Heute beantwortbar?	Wo die Antwort liegt
Welche Prozessschritte darf jeder Agent auslösen?	Meist nein	Prozesskarte, nicht Systemkarte
Ab welcher Schwelle geht es an einen Menschen?	Meist nein	Berechtigungsdesign je Schritt
Wer zeichnet gegen, mit welcher Reaktionszeit?	Selten	Benannte Rolle, keine Funktion
Wie wird eine gültige, aber falsche Entscheidung erkannt?	Selten	Erkennungsdesign, der schwerste Punkt
Wer stoppt sonntags um 03:00 Uhr einen Agenten?	Selten	Entscheidungsmatrix, der billigste Punkt
Entsteht unsere Risikozahl nach der Zuordnung?	Oft nein	Reifegrad drei vor fünf

Anhang: Methodik

Art der Untersuchung. Fortschreibung einer Position. Der Beitrag entwickelt eine Empfehlung aus unserem eigenen veröffentlichten Artikel und führt keine neuen externen Behauptungen ein.

Angewandte Rahmen. SCQA für die Rahmung, ein Reifegradmodell für die Reihenfolge, ein Bezugsrahmenvergleich für die einzelnen Maßnahmen. Alle drei stammen aus der veröffentlichten Position.

Geprüfte und verworfene Rahmen. Porter, BCG-Matrix, Wertkette und PESTEL wurden verworfen: Dies ist eine Frage des Betriebsmodells, nicht der Branchenstruktur, der Portfolioallokation, der Kostenstruktur oder des Makroumfelds. Die Technologieadoptionskurve wurde verworfen, weil zur Verbreitung von Agentenautorisierungspraktiken keine belastbaren Daten vorliegen und eine konstruierte Kurve Schätzung als Beleg ausgeben würde.

Belegstatus, ausdrücklich getrennt.

Belegt. Die vier Fragen, die Bezugsrahmentabelle, der Reifegradpfad und die Werkzeugbewertung stammen aus dem veröffentlichten Artikel und der zugrunde liegenden kanonischen Notiz. Die Werkzeugbewertung entstand durch das Lesen der Produktdokumentation von SAP LeanIX und Signavio und ist die empirisch stärkste Passage.
Erfahrungsaussagen, nicht belegt. Die organisatorischen Befunde, das 03:00-Uhr-Problem, die Zuständigkeitslücke, die zwei Eingeständnisse, stammen aus der Praxis und sind in der zugrunde liegenden Notiz als solche gekennzeichnet (Reifegrad `draft`). Sie werden als Argument angeboten, nicht als Beleg.

Konfidenz. Hoch für die Befunde 1 bis 3 und 5, die auf der veröffentlichten Position und auf direkt gelesener Dokumentation beruhen. Mittel für Befund 4, eine Erfahrungsaussage.

Grenzen.

Der Referenzfall hinter der veröffentlichten Position ist eine Verkehrsverwaltung des öffentlichen Sektors mit vorgeschriebener Prozesslandschaft, also nahe am günstigsten denkbaren Fall. Ein Machbarkeitsnachweis, kein Beleg für allgemeine Übertragbarkeit.
Die Ursprungsquelle der prozesszentrierten Lesart ist die öffentliche Aussage eines einzelnen Sicherheitsmanagers, kein veröffentlichtes Rahmenwerk. Sie trägt als Denkrichtung, nicht als Beschaffungsgrundlage.
Es wurden keine veröffentlichten Daten gefunden, die den Reifegrad einer Entscheidungsmatrix mit der Reaktionsgeschwindigkeit in Beziehung setzen. Die Behauptung, vorab getroffene Entscheidungen verkürzten Vorfälle, ist plausibel und unbewiesen.

Was offen bleibt. Ob Organisationen, die die Entscheidungsmatrix gut beherrschen, sie üben, und wie oft. Das ist die Frage, die einer Fachgruppe zu stellen wäre, und deshalb endet dieser Artikel mit einer Bitte statt mit einem Schluss.

Anlass zur Fortschreibung. Wenn ein veröffentlichtes Rahmenwerk zur Prozessautorisierung von Agenten erscheint oder wenn eine Aufsichtsbehörde Entscheidungsrechte von Agenten unmittelbar adressiert.

Häufige Fragen

Heißt das, Modellhärtung ist sinnlos?

Nein. Härtung adressiert einen realen Fehlerfall, nämlich einen Agenten, der zu einem Handeln außerhalb seiner Absicht gebracht wird. Das Argument lautet, dass dies die kleinere von zwei Gefährdungen ist und dass die größere, eine korrekt aussehende Entscheidung mit falschem Geschäftsergebnis, keinen Alarm erzeugt und meist unbearbeitet bleibt.

Warum wurde die Technologieadoptionskurve nicht verwendet?

Weil es zur Verbreitung von Agentenautorisierungspraktiken keine belastbaren Daten gibt. Den Markt auf einer Kurve zu verorten hieße, eine Schätzung als Beleg auszugeben. Porter, BCG, Wertkette und PESTEL wurden aus einem anderen Grund verworfen: Dies ist eine Frage des Betriebsmodells, nicht der Branchenstruktur, der Portfolioallokation, der Kostenstruktur oder des Makroumfelds.

Was davon ist belegt und was ist Erfahrung?

In der Methodik ausdrücklich getrennt. Die vier Fragen, die Bezugsrahmentabelle, der Reifegradpfad und die Werkzeugbewertung stammen aus der veröffentlichten Position und aus direkt gelesener Produktdokumentation. Die organisatorischen Befunde, darunter das 03:00-Uhr-Problem, sind Erfahrungsaussagen und als solche gekennzeichnet. Sie werden als Argument angeboten, nicht als Beweis.

Wir setzen bereits SAP LeanIX und Signavio ein. Reicht das nicht?

Diese Produkte liefern die Karte, und die ist eine echte Voraussetzung. Keines der beiden beansprucht, die Sicherheitsentscheidung zu erzeugen, und ihre Dokumentation beschreibt das auch nicht. Die Entscheidung braucht Menschen, die den Prozess und seine technischen Abhängigkeiten verstehen, und das deckt keine Lizenz ab.

Wo fangen wir an, wenn wir gar keine Prozesskarte haben?

Nicht bei der Karte. Fangen Sie bei den Agenten an, die bereits laufen: Halten Sie fest, welche Prozessschritte jeder auslösen darf und ab welcher Schwelle ein Mensch gefragt wird. Das ist eine kurze Übung, und sie erzeugt das erste Stück der Karte nebenbei.

Der Vorstand will jetzt eine quantifizierte Cyberrisikozahl. Was sagen wir?

Dass die Zahl die Qualität der Schätzung misst, solange die Prozesskopplung fehlt, und dass Stufe drei des Reifegradpfads die Voraussetzung für Stufe fünf ist. Die Zahl früher zu erzeugen ist möglich, sich auf sie zu verlassen nicht.

Gibt es Belege, dass eine vorab vereinbarte Entscheidungsmatrix Vorfälle verkürzt?

Es wurden keine veröffentlichten Daten gefunden, die den Reifegrad einer Entscheidungsmatrix mit der Reaktionsgeschwindigkeit in Beziehung setzen. Die Behauptung ist plausibel und unbewiesen, und genau so steht sie in der Methodik.

Quellen

Shift Up in der Cybersecurity: vier Lesarten, eine tragfähige. saschatheismann.de, veröffentlicht am 3. Juli 2026 (DE und EN).
Die zugrunde liegende kanonische Notiz einschließlich der Auswertung der Produktdokumentation von SAP LeanIX und SAP Signavio.
Andreas Hauke, Head of the Office of the Chief Security Officer bei SAP, öffentliche LinkedIn-Aussage vom 3. Juli 2026, abgerufen und archiviert am 5. September 2026. Zitiert als öffentliche Aussage eines Managers, nicht als Rahmenwerk.