ERP-Sicherheit hat Mühe, mit KI-Agenten Schritt zu halten

BankInfoSecurity hat über Google News einen unangenehmen Konflikt ins Blickfeld gerückt: ERP-Sicherheitskontrollen haben Mühe, Schritt zu halten, während KI-Agenten operative Befugnisse erhalten.

Die Frage ist nicht, ob ein Assistent eine Rechnung zusammenfassen oder eine Beschaffungsfrage beantworten kann. Das Risiko beginnt, wenn ein Agent Datensätze abrufen, Tools aufrufen, Transaktionen ändern und Aktionen über mehrere Unternehmenssysteme hinweg koordinieren kann.

SAP, Oracle, Microsoft und Workday entwickeln ERP-Software in Richtung dieses Modells. Ihre Agenten sollen repetitive Arbeit in Finanzwesen, Beschaffung, Personalwesen und Lieferketten reduzieren. Die Kontrollen rund um diese Agenten beruhen jedoch weiterhin auf Annahmen, die für menschliche Mitarbeitende und vorhersehbare Anwendungen entwickelt wurden.

Diese Diskrepanz schafft das zentrale Sicherheitsproblem. Traditionelle ERP-Governance fragt, welche Person eine Rolle hat und welche Transaktionen diese Rolle erlaubt. Agentische Systeme bringen delegierte Ziele, wechselnde Kontexte, Tool-Auswahl und Übergaben von Maschine zu Maschine mit sich.

Ein Agent kann über gültige Zugangsdaten verfügen und dennoch eine unsichere Aktion ausführen. Er kann zudem mehrere einzeln zulässige Schritte zu einem Ergebnis kombinieren, das kein Administrator beabsichtigt hat.

ERP-Anbieter ergänzen Identitätskontrollen, Genehmigungsschranken und Audit-Funktionen. Diese Maßnahmen sind wichtig, lösen aber nicht den tiefer liegenden Konflikt zwischen Agentenautonomie und deterministischen Unternehmenskontrollen.

Die Google-News-Warnung betrifft Befugnisse, nicht Chatbots

Die entscheidende Veränderung besteht darin, dass ERP-KI-Agenten von der Analyse von Geschäftsdaten zu deren Verarbeitung übergehen.

Der über Google News veröffentlichte ERP-Sicherheitsbericht beschreibt das Problem als Wettlauf zwischen wachsenden Agentenfähigkeiten und einer langsameren Anpassung der Sicherheit.

Diese Einordnung ist wichtig, weil ERP-Systeme die operative Wahrheit eines Unternehmens enthalten. Sie speichern Zahlungsanweisungen, Mitarbeiterdaten, Lieferantenkonditionen, Lagerbestände, Kundensalden und Finanzfreigaben.

Ein herkömmlicher Chatbot kann eine falsche Antwort erzeugen. Ein ERP-Agent mit Ausführungsrechten kann aus einer falschen Antwort einen gebuchten Journaleintrag oder eine genehmigte Lieferantenänderung machen.

Agentische KI bezeichnet Software, die ein Ziel interpretieren, einen Plan erstellen, Tools auswählen und mehrere Schritte mit begrenzter Aufsicht ausführen kann. Das unterscheidet sie von fester Automatisierung, die einem vordefinierten Pfad folgt.

Ein traditioneller Workflow könnte eine Rechnung stets ablehnen, wenn eine Bestellung fehlt. Ein Agent kann die Abweichung untersuchen, Korrespondenz abrufen, Lieferunterlagen vergleichen und eine Ausnahme empfehlen.

Diese Flexibilität schafft Wert, weil reale Geschäftsprozesse Mehrdeutigkeiten enthalten. Sie schwächt jedoch auch die Vorhersehbarkeit, von der viele bestehende Sicherheitskontrollen abhängen.

Sicherheitsteams können einen festen Workflow vor der Bereitstellung prüfen. Sie wissen, welche Felder er liest, welche Systemaufrufe er ausführt und welche Bedingungen eine Genehmigung auslösen.

Ein Agent kann jedes Mal eine andere Abfolge wählen. Sein Verhalten kann sich mit dem Prompt, verfügbaren Tools, abgerufenen Dokumenten, der Modellversion oder dem umgebenden Gespräch ändern.

Das bedeutet, dass Autorisierung nicht beim Login enden kann. Die Sicherheit muss die Identität des Agenten, den delegierten Zweck, den aktuellen Kontext, das ausgewählte Tool, die angeforderten Daten und die beabsichtigte Wirkung bewerten.

Das Problem wird schwieriger, wenn ein Agent Anwendungsgrenzen überschreitet. Ein Finanzagent kann E-Mails, Beschaffungsunterlagen, Kundendaten und ein Zahlungssystem konsultieren, bevor er eine Aufgabe abschließt.

Jede Verbindung erweitert die Angriffsfläche. Sie erschwert zudem die Zuweisung von Verantwortung, wenn mehrere Komponenten zu einem unsicheren Ergebnis beitragen.

Google-News-Leser könnten die Geschichte zunächst als weitere Warnung vor der Genauigkeit generativer KI interpretieren. Das zugrunde liegende Problem ist folgenreicher.

ERP-Sicherheitsteams müssen Software steuern, die weniger wie eine passive Anwendung und mehr wie eine hochgradig vernetzte Arbeitskraft agiert. Diese Arbeitskraft kann kontinuierlich, mit Maschinengeschwindigkeit und über organisatorische Grenzen hinweg arbeiten.

Die Veränderung setzt Chief Information Security Officers, ERP-Administratoren, Identitätsteams, interne Auditoren und Verantwortliche für Geschäftsprozesse unter Druck. Keine dieser Gruppen kann das Risiko allein steuern.

Sicherheitsteams verstehen Zugriffskontrollen, verfügen aber möglicherweise nicht über detaillierten Prozesskontext. Finanzverantwortliche verstehen wesentliche Folgen, sehen aber möglicherweise nicht jede technische Abhängigkeit.

ERP-Administratoren verstehen Rollen und Transaktionen. Sie kontrollieren möglicherweise keine externen Modelle, Agenten-Frameworks oder Drittanbieter-Tools, die an den Workflow angebunden sind.

Die unmittelbare Herausforderung ist daher organisatorischer ebenso wie technischer Natur. Unternehmen benötigen ein Kontrollmodell, das einem Agenten von der ersten Anweisung bis zu jeder daraus resultierenden Aktion folgt.

ERP-KI-Agenten durchbrechen das Modell menschlicher Identitäten

Eine gültige Identität beweist nicht länger, dass eine Aktion angemessen ist, wenn Software Ziele neu interpretieren und ihren eigenen Ausführungspfad wählen kann.

ERP-Kontrollen konzentrierten sich traditionell auf namentlich bekannte Nutzer, zugewiesene Rollen und Funktionstrennung. Die Funktionstrennung verhindert, dass eine Person unvereinbare Phasen eines sensiblen Prozesses kontrolliert.

Beispielsweise sollte ein Mitarbeiter, der einen Lieferanten anlegt, Zahlungen an diesen Lieferanten nicht eigenständig genehmigen. Die Regel begrenzt Betrug und verringert die Auswirkungen kompromittierter Zugangsdaten.

Agenten verkomplizieren dieses Modell, weil Befugnisse mehrere Ebenen durchlaufen können. Eine Person weist einen Agenten an, der Agent ruft einen weiteren Agenten auf, und dieser Agent ruft eine Geschäftsanwendung auf.

Das finale System sieht möglicherweise nur eine authentifizierte Dienstidentität. Es erhält möglicherweise nicht den ursprünglichen Nutzer, Zweck, Nachweise oder die mit der Anfrage verbundenen Grenzen.

Dadurch entsteht ein Problem der Delegationskette. Jedes System erkennt seinen unmittelbaren Aufrufer, während die vollständige Herkunft und Absicht der Aktion schwerer zu rekonstruieren sind.

Gemeinsam genutzte Agenten-Zugangsdaten verschärfen das Problem. Wenn mehrere Workflows ein Dienstkonto verwenden, könnten Ermittler Schwierigkeiten haben, legitime Automatisierung von Missbrauch zu unterscheiden.

Dauerhafte Zugangsdaten ermöglichen zudem, dass Befugnisse ihren ursprünglichen Zweck überdauern. Ein Agent, der für ein zeitlich begrenztes Abstimmungsprojekt erstellt wurde, könnte Zugriff behalten, nachdem diese Arbeit beendet ist.

Überprüfungen menschlicher Zugriffe orientieren sich typischerweise an Beschäftigungsereignissen und festen Rollen. Agenten können wesentlich schneller als Mitarbeitende entstehen, sich verändern, vervielfältigen und verschwinden.

Sie können auch außerhalb formaler Entwicklungsprozesse zusammengestellt werden. Ein Geschäftsteam kann ein Modell mit einem genehmigten Tool verbinden, ohne zu erkennen, dass die Kombination eine neue privilegierte Identität schafft.

Das agentische Sicherheitsframework von OWASP nennt Identitäts- und Privilegienmissbrauch als zentrale Risiken. Es hebt zudem Zielübernahme, Tool-Missbrauch und Schwachstellen in der agentischen Lieferkette hervor.

Eine Zielübernahme tritt auf, wenn bösartige oder nicht vertrauenswürdige Inhalte verändern, was ein Agent zu erreichen versucht. Die schädliche Anweisung kann sich in einem Dokument, einer Nachricht, einer Webseite oder einer Tool-Antwort befinden.

Innerhalb eines ERP-Systems ist dies gefährlicher als bei einem eigenständigen Assistenten. Der Agent kann bereits Zugriff auf vertrauliche Datensätze und Transaktionsfunktionen besitzen.

Man denke an einen Beschaffungsagenten, der Lieferanten-E-Mails liest. Eine kompromittierte Nachricht könnte das Modell anweisen, ein vom Angreifer kontrolliertes Bankkonto zu priorisieren oder interne Einkaufsdaten offenzulegen.

Die Anfrage könnte dem ursprünglichen Ziel des Nutzers widersprechen. Dennoch könnte der Agent den eingebetteten Text als relevanten operativen Kontext behandeln, sofern Schutzmaßnahmen Daten nicht von Anweisungen trennen.

Das Prinzip der minimalen Rechte bleibt notwendig, seine Umsetzung muss jedoch präziser werden. Ein Agent sollte nur die Berechtigungen erhalten, die für einen Zweck und einen begrenzten Zeitraum erforderlich sind.

Oracles Leitfaden für sichere Betriebsabläufe macht diese Unterscheidung ausdrücklich. Ein Analyseagent benötigt keine Beschaffungsfreigaberechte, nur weil beide an einem Workflow beteiligt sind.

Dieses Prinzip klingt vertraut, doch Agenten erschweren seine Durchsetzung. Ihre Pläne können sich nach Beginn einer Aufgabe weiterentwickeln, und sie können während der Ausführung zusätzliche Tools anfordern.

Statische Rollen können Bedingungen wie Zweck, Transaktionswert, Datensensibilität, Vertrauen oder die Frage, ob ein anderer Agent die Anfrage initiiert hat, nicht vollständig ausdrücken.

Unternehmen benötigen daher Richtlinienprüfungen im Moment der Aktion. Diese Prüfungen sollten sowohl die angeforderte Operation als auch den sie umgebenden Kontext bewerten.

Aktionen mit hoher Auswirkung erfordern außerdem stärkere Belege für menschliche Absicht. Ein Bestätigungsbutton reicht nicht aus, wenn der Prüfer nur eine ausgefeilte Zusammenfassung sieht, die vom selben Agenten erstellt wurde.

Der Prüfer benötigt die ursprünglichen Nachweise, vorgeschlagene Änderungen, Richtlinienausnahmen und die erwarteten Geschäftsauswirkungen. Andernfalls wird menschliche Aufsicht zu einer bloßen Formalität.

Der eigentliche Zielkonflikt besteht zwischen Autonomie und Kontrolle

Jede Ausweitung der Agentenautonomie erhöht den Aufwand für Identität, Richtliniendurchsetzung, Beobachtbarkeit und Wiederherstellung.

ERP-KI-Agenten werden nützlich, wenn sie Ausnahmen bearbeiten können. Ausnahmen sind jedoch genau die Bereiche, in denen deterministische Kontrollen die geringste Abdeckung bieten.

Eine feste Automatisierung folgt Pfaden, die Entwickler im Voraus definieren. Ein Agent interpretiert unvollständige Informationen und entscheidet, welcher Pfad angemessen erscheint.

Diese Unterscheidung schafft einen Sicherheitskonflikt. Wird ein Agent zu stark eingeschränkt, wird er zu einer teuren Schnittstelle für bestehende Workflows. Erhält er umfassendere Befugnisse, haben seine Fehler operative Folgen.

Der Konflikt verschwindet nicht, wenn ein Agent innerhalb der Cloud eines Anbieters bleibt. Eine kontrollierte Umgebung kann die Exposition verringern, doch die Geschäftslogik bestimmt weiterhin, ob eine Aktion akzeptabel ist.

Ein Agent kann berechtigt sein, Lieferantendatensätze zu aktualisieren. Diese Berechtigung bedeutet nicht, dass jede Lieferantenaktualisierung einem legitimen Zweck dient.

Ein Agent kann auch Fähigkeiten mit geringem Risiko zu einer Abfolge mit hohem Risiko kombinieren. Rechnungen lesen, Lieferanten anlegen und Zahlungen vorbereiten erscheinen bei getrennter Bewertung beherrschbar.

Zusammen können diese Fähigkeiten einen vollständigen Betrugsweg nachbilden. Dies wird mitunter als kompositionelles Risiko bezeichnet, bei dem sicher wirkende Komponenten ein unsicheres Gesamtergebnis erzeugen.

Sicherheitstools prüfen häufig einzelne API-Aufrufe. Sie können jeden Schritt genehmigen und dabei den übergeordneten Plan übersehen, der sie verbindet.

Das Agentengedächtnis schafft eine weitere Schwierigkeit. Es ermöglicht Software, Aufgabenkontext, Präferenzen oder frühere Beobachtungen über Interaktionen hinweg zu behalten.

Diese Kontinuität kann die Leistung verbessern. Sie kann jedoch auch bösartige Anweisungen, sensible Daten oder falsche Annahmen über die Sitzung hinaus bewahren, in der sie in das System gelangten.

Retrieval-Augmented Generation, kurz RAG, stellt einem Modell bei der Beantwortung oder Ausführung einer Aufgabe ausgewählte Unternehmensinformationen bereit. Seine Sicherheit hängt von der Quelle, den Berechtigungen, der Qualität und der Aktualität des abgerufenen Materials ab.

Eine manipulierte Wissensquelle kann spätere Entscheidungen verzerren, ohne das zugrunde liegende Modell direkt zu kompromittieren. Ein veraltetes Richtliniendokument kann durch gewöhnliches operatives Versagen ein ähnliches Ergebnis erzeugen.

Damit wird Informations-Governance zu einem Teil der Sicherheit von KI-Agenten. Teams müssen wissen, welche Quellen ein Agent verwendet, wer sie ändern kann und wie abgerufene Nachweise Entscheidungen beeinflussen.

Mitarbeiter, die interne Workflows entwickeln, benötigen ebenfalls verlässliche Dokumentation. Eine durchsuchbare Wissensdatenbank kann Teams dabei helfen, Designentscheidungen, Bedrohungsmodelle und Genehmigungsanforderungen rund um Agenten-Deployments festzuhalten.

Dokumentation kann technische Kontrollen nicht ersetzen. Sie kann jedoch das Risiko verringern, dass kritische Annahmen verloren gehen, wenn ein Agent den Besitzer wechselt oder vom Pilotprojekt in den Produktionsbetrieb übergeht.

Der Zugriff auf Tools schafft ein paralleles Risiko. Tools übersetzen Modellausgaben in Aktionen, etwa Datenbankabfragen, das Versenden einer Nachricht oder die Änderung eines Geschäftseintrags.

Das Modell benötigt keine direkten Datenbankzugangsdaten, wenn ein verbundenes Tool diese bereits besitzt. Das Tool wird damit Teil der effektiven Berechtigungsgrenze des Agenten.

Sicherheitsprüfungen müssen Tool-Schemata, Eingabevalidierung, Speicherung von Zugangsdaten, Ausgabefilterung und Fehlerverhalten untersuchen. Wer nur das Modell prüft, übersieht den Großteil des Ausführungspfads.

Multi-Agenten-Systeme erhöhen die Unsicherheit zusätzlich. Ein Agent kann Recherche delegieren, ein anderer Richtlinien auslegen und ein dritter die Transaktion ausführen.

Bei jeder Übergabe können Kontext verloren gehen oder nicht vertrauenswürdige Ausgaben eingebracht werden. Zudem kann dadurch verschleiert werden, welche Komponente die schädliche Entscheidung getroffen hat.

Die veröffentlichte Sicherheitsarchitektur von SAP verfolgt Agentenanfragen über Identitätsprüfung, KI-Verarbeitung, Geschäftsausführung und forensische Protokollierung hinweg.

Diese End-to-End-Perspektive weist in die richtige Richtung. Architekturschaubilder belegen jedoch nicht, dass jede Kundeneinführung die Kontrollen konsistent anwendet.

ERP-Umgebungen enthalten kundenspezifischen Code, Legacy-Integrationen, übernommene Systeme, externe Partner und langjährige Ausnahmen. Diese Unterschiede können das Standardsicherheitsmodell eines Anbieters schwächen.

Die schwierigsten Einführungen werden hybride Landschaften betreffen. Ein Agent kann in einem modernen Cloud-Service beginnen, aber über ältere Anwendungen mit groben Berechtigungen und begrenzter Telemetrie handeln.

In diesen Umgebungen kann die neueste Komponente die schwächste Kontrolle der Kette übernehmen. Die Autonomie von Agenten verstärkt dann technische Schulden, die Unternehmen bereits nur schwer beherrschen konnten.

Audit-Protokolle können nicht jede Agentenentscheidung erklären

ERP-Sicherheit benötigt Belege, die Nutzerabsicht mit Agentenlogik, Tool-Aufrufen, Datenänderungen und Geschäftsergebnissen verknüpfen.

Traditionelle Audit-Protokolle beantworten vertraute Fragen. Sie zeigen, welches Konto auf ein System zugegriffen hat, wann eine Transaktion stattfand und welches Feld geändert wurde.

Agentische Workflows erfordern eine längere Beweiskette. Ermittler benötigen den auslösenden Nutzer, das delegierte Ziel, die Modellversion, den abgerufenen Kontext, Richtlinienentscheidungen, Tool-Aufrufe und das Endergebnis.

Möglicherweise müssen sie auch wissen, was der Agent abgelehnt hat. Wiederholte abgelehnte Anfragen können auf Ausforschung, Fehlkonfiguration oder eine kompromittierte Quelle hinweisen.

Jeden Prompt und jede Antwort zu protokollieren, ist keine einfache Lösung. Prompts können Gehaltsdaten, Verträge, personenbezogene Daten, Zugangsdaten und andere eingeschränkte Informationen enthalten.

Ein vollständiges Protokoll kann daher ein weiteres sensibles Repository schaffen. Regeln für Aufbewahrung, Zugriff, Verschlüsselung und Schwärzung müssen zu den zugrunde liegenden Geschäftsdaten passen.

Die Modelllogik bringt eine weitere Komplikation mit sich. Eine generierte Erklärung kann schlüssig klingen, ohne zuverlässig widerzugeben, wie das System zu seiner Ausgabe gelangt ist.

Sicherheitsteams sollten eine narrative Erklärung nicht als Beweis behandeln. Sie benötigen überprüfbare Aufzeichnungen über Eingaben, Tool-Anfragen, Richtlinienbewertungen und daraus resultierende Zustandsänderungen.

Das verändert die Bedeutung von Observability. Das Monitoring muss das Verhalten über den gesamten Workflow hinweg erfassen, nicht nur die Modellverfügbarkeit oder API-Fehler.

Nützliche Signale umfassen unerwartete Tool-Auswahl, ungewöhnliches Transaktionsvolumen, Zugriffe außerhalb des normalen Geschäftsumfangs, wiederholte Richtlinienablehnungen und Änderungen an sensiblen Datensätzen.

Auch Baselines müssen den zugewiesenen Zweck eines Agenten widerspiegeln. Ein Agent für Gehaltsabstimmungen und ein Beschaffungsagent sollten nicht dasselbe Profil normalen Verhaltens teilen.

Ratenbegrenzungen können den Schadensradius von Fehlern verringern. Sie können jedoch nicht bestimmen, ob eine kleine Anzahl hochwertiger Aktionen legitim ist.

Transaktionsschwellen bieten eine weitere Ebene. Angreifer können Aktivitäten jedoch in kleinere Aktionen aufteilen oder Prozesse ausnutzen, bei denen eine geringwertige Änderung einen späteren Verlust ermöglicht.

Unternehmen benötigen Kontrollen an mehreren Stellen. Die Agentenlaufzeit sollte Tools beschränken, die Identitätsebene sollte Befugnisse begrenzen und das ERP sollte Geschäftsregeln validieren.

Unabhängiges Monitoring sollte anschließend überprüfen, was tatsächlich passiert ist. Sich darauf zu verlassen, dass derselbe Agent handelt, bewertet und über sein eigenes Verhalten berichtet, bündelt zu viel Vertrauen.

Menschliche Genehmigung bleibt für irreversible oder wesentliche Aktionen wertvoll. Prüfer benötigen jedoch ausreichend Zeit und Kontext, um Manipulation zu erkennen.

Genehmigungsmüdigkeit kann eine Schutzmaßnahme in eine Formalität verwandeln. Agenten, die mit Maschinengeschwindigkeit arbeiten, können mehr Prüfungsanfragen erzeugen, als Mitarbeiter sorgfältig bewerten können.

Risikogestufte Autonomie bietet ein praktikableres Modell. Aufgaben mit geringen Auswirkungen und reversiblen Ergebnissen können automatisch fortgesetzt werden, während sensible Aktionen eine unabhängige Validierung erfordern.

Beispiele für risikoärmere Arbeit sind das Formulieren von Erklärungen, das Sammeln von Belegen und das Kennzeichnen von Anomalien. Risikoärmere Arbeit umfasst das Ändern von Zahlungsdetails, die Freigabe von Geldern oder die Änderung von Zugriffsrechten.

Die Reversibilität sollte das Kontrollniveau beeinflussen. Ein fehlerhafter Bericht kann korrigiert werden, während eine externe Zahlung oder ein gelöschter Datensatz dauerhaften Schaden verursachen kann.

Das NIST-Risikoprofil organisiert die Arbeit an KI-Risiken rund um Governance, Zuordnung, Messung und Management. Dieser Lebenszyklusansatz passt besser zu ERP-Agenten als eine einmalige Genehmigung.

Das Risiko eines Agenten verändert sich, wenn sich seine Tools, sein Modell, seine Datenquellen, Berechtigungen oder sein Geschäftszweck ändern. Jede Änderung sollte eine erneute Bewertung und gezielte Tests auslösen.

Die Tests müssen gegnerische Eingaben und realistische Geschäftsausnahmen einschließen. Eine Demonstration mit sauberen Daten wird nicht zeigen, wie sich ein Agent bei widersprüchlichen Anweisungen verhält.

Teams sollten auch Teilausfälle testen. Ein nachgelagertes System kann eine Zeitüberschreitung melden, nachdem ein Agent einen Schritt abgeschlossen hat, aber bevor er den nächsten protokolliert.

Ohne Idempotenz, die verhindert, dass wiederholte Ausführung doppelte Effekte erzeugt, kann ein Agent dieselbe Transaktion bei der Wiederherstellung erneut übermitteln.

Diese gewöhnlichen Zuverlässigkeitsprobleme werden zu Sicherheitsproblemen, wenn sie Finanzdaten, Zugriffsrechte oder regulierte Daten betreffen. Agentensicherheit kann nicht von Systemengineering getrennt bleiben.

Anbieterleitplanken treffen auf die Realität kundenspezifischer ERP-Systeme

SAP und Oracle können ihre eigenen Agentenplattformen absichern, doch Kunden kontrollieren weiterhin die Integrationen, Rollen, Daten und Ausnahmen, die das praktische Risiko bestimmen.

ERP-Anbieter haben einen strukturellen Vorteil. Sie verstehen ihre Anwendungsmodelle und können Agenten neben bestehenden Identitäts-, Workflow- und Audit-Diensten einbetten.

Native Agenten können Geschäftsmetadaten übernehmen, die einem externen Modell fehlen. Sie können zudem genehmigte Schnittstellen nutzen, statt Nutzeraktionen über einen Bildschirm nachzuahmen.

Oracle rät Kunden, Agentenverantwortlichkeiten zu trennen und bei kooperierenden Agenten das Prinzip der geringsten Berechtigung anzuwenden. SAP beschreibt Identitätsprüfungen, Mandantenisolierung, Ausgabevalidierung und forensische Audit-Trails.

Diese Kontrollen adressieren reale Bedenken. Sie stützen auch das Argument der Anbieter, dass eingebettete Agenten sicherer sind als locker angebundene Automatisierung durch Dritte.

Das Argument hat Grenzen. Die meisten großen Unternehmen betreiben keine einzelne saubere ERP-Umgebung mit Standardkonfigurationen.

Sie betreiben kundenspezifische Prozesse über mehrere Systeme hinweg. Einige Anwendungen bleiben On-Premises, während andere in Public Clouds oder von Anbietern verwalteten Diensten laufen.

Partner, Auftragnehmer, Banken, Logistikdienstleister und übernommene Geschäftseinheiten können mit demselben Prozess verbunden sein. Jede Grenze führt ein anderes Identitäts- und Kontrollmodell ein.

Ein nativer Finanzagent kann weiterhin nicht vertrauenswürdige Inhalte aus E-Mails erhalten. Er kann sich auf einen Dokumentparser eines Drittanbieters stützen oder ein Ergebnis an eine ältere Zahlungsanwendung senden.

Der gesamte Workflow ist nur so vertrauenswürdig wie diese Abhängigkeiten. Die Sicherheitsdokumentation eines Anbieters kann nicht jede Kundenerweiterung berücksichtigen.

Externe Agenten bringen einen anderen Zielkonflikt mit sich. Sie können Arbeit über konkurrierende ERP-, CRM-, Kommunikations- und Analyseplattformen hinweg koordinieren.

Diese Unabhängigkeit kann Vendor Lock-in verringern und umfassendere Workflows unterstützen. Sie platziert jedoch eine weitere Identität, Orchestrierungsebene und ein Tool-Ökosystem zwischen Nutzern und Geschäftsdaten.

Die praktische Wahl lautet daher nicht sichere native Software gegenüber unsicherer externer Software. Beide Ansätze schaffen Risiken, konzentrieren diese jedoch an unterschiedlichen Stellen.

Native Agenten bündeln Vertrauen im Plattform-, Cloud- und Governance-Modell des ERP-Anbieters. Externe Agenten verteilen Vertrauen über Konnektoren, Zugangsdaten, Modelle und Orchestrierungstools.

Sicherheitsteams sollten den vollständigen Aktionspfad bewerten, statt Kategorienbezeichnungen zu akzeptieren. Ein natives Produkt kann durch weitreichende Konfiguration unsicher werden.

Ein externes Produkt kann Risiken verringern, wenn es eng begrenzte, kurzlebige Befugnisse erhält und sensible Transaktionen nicht direkt abschließen kann.

Beschaffungsprüfungen müssen diese Unterschiede berücksichtigen. Standardisierte Softwarefragebögen erfassen selten Delegierungstiefe, Speicherverhalten, Prompt-Verarbeitung oder Berechtigungen auf Tool-Ebene.

Käufer sollten fragen, welche Identität im ERP-Protokoll erscheint und ob sie den ursprünglichen Nutzer identifiziert. Sie sollten auch fragen, wie Richtlinien einer Aufgabe über Agentenübergaben hinweg folgen.

Weitere wesentliche Fragen betreffen Modellupdates, gespeicherten Kontext, Datenresidenz, Incident Response und den Kundenzugriff auf detaillierte Telemetrie.

Der Anbieter sollte erläutern, wie Administratoren einen Agenten sofort aussetzen können. Diese Kontrolle muss aktive Zugangsdaten widerrufen und ausstehende Aktionen unterbrechen, nicht nur die Oberfläche ausblenden.

Kunden benötigen zudem Nachweise zum Änderungsmanagement. Das Verhalten eines Agenten kann sich ändern, nachdem sich ein Modell, System-Prompt, eine Tool-Definition oder eine Abrufquelle ändert.

Ein traditionelles Anwendungsupdate verändert normalerweise deterministischen Code. Ein Modellupdate kann Entscheidungen verändern, selbst wenn der umgebende Workflow unverändert bleibt.

Sicherheitstests müssen daher nach der Bereitstellung fortgesetzt werden. Teams sollten repräsentative Aufgaben und Missbrauchsfälle ausführen, wann immer sich eine wesentliche Komponente ändert.

Sie sollten Ergebnisse über Versionen hinweg vergleichen und ausreichend Belege aufbewahren, um Regressionen zu untersuchen. Ein bestandener Test von vor sechs Monaten sagt wenig über einen veränderten Agenten aus.

Wettbewerbsdruck kann diese Disziplin untergraben. ERP-Anbieter möchten, dass Kunden Agenten einsetzen, während Geschäftsverantwortliche messbare Produktivitätsverbesserungen wünschen.

Sicherheitsteams könnten unter Druck geraten, weitreichende Pilotprojekte zu genehmigen, bevor Identitäts- und Monitoringsysteme bereit sind. Diese Reihenfolge macht Governance zu einem Reparaturprojekt.

Ein sichererer Rollout beginnt mit begrenzten Aufgaben und beobachtbaren Ergebnissen. Befugnisse werden erst erweitert, nachdem die Organisation das Verhalten des Agenten erklären, erkennen und rückgängig machen kann.

Drei Signale werden zeigen, ob die ERP-Sicherheit aufholt

Die nächste Phase wird durch agentenspezifische Identitäten, Durchsetzung auf Aktionsebene und Erkenntnisse aus realen Produktionsvorfällen entschieden.

Das erste Signal ist, ob ERP-Plattformen für jeden Agenten und jede delegierte Aufgabe eigenständige, kurzlebige Identitäten einführen. Gemeinsame Dienstkonten sollten zur Ausnahme werden.

Ein ausgereiftes Design wird den ursprünglichen Nutzer, die Agentenidentität, den Zweck und die Befugnis über den gesamten Workflow hinweg bewahren. Nachgelagerte Anwendungen sollten diesen Kontext erhalten, bevor sie Aktionen zulassen.

Dies würde die These stärken, dass ERP-KI-Agenten innerhalb etablierter Rechenschaftsstrukturen arbeiten können. Die fortgesetzte Abhängigkeit von weitreichenden Zugangsdaten würde sie schwächen.

Das zweite Signal ist, ob Anbieter und Kunden Richtlinien auf Transaktionsebene durchsetzen. Die Berechtigung, ein Tool zu nutzen, darf nicht zur Berechtigung für jedes mögliche Tool-Ergebnis werden.

Kontrollen sollten Transaktionstyp, Wert, Ziel, Quellnachweise und Reversibilität berücksichtigen. Sensible Vorgänge sollten unabhängige Prüfungen außerhalb des handelnden Modells erfordern.

Sicherheitsteams sollten Produktveröffentlichungen auf konkrete Durchsetzungsfunktionen prüfen. Marketingaussagen zu verantwortungsvoller KI sind weniger nützlich als konfigurierbare Kontrollen und exportierbare Protokolle.

Sie sollten zudem untersuchen, ob diese Kontrollen über verbundene Anwendungen hinweg funktionieren. Schutz, der auf die Oberfläche eines einzelnen Anbieters beschränkt ist, deckt keinen plattformübergreifenden Workflow ab.

Das dritte Signal ist die Qualität öffentlicher Berichte über Vorfälle. Ausfälle im Produktivbetrieb werden zeigen, wo theoretische Architekturen unter realen Geschäftsbedingungen versagen.

Nützliche Offenlegungen benennen die kompromittierte Identität, manipulierte Eingaben, betroffene Tools, nicht autorisierte Aktionen und die Methode zur Eindämmung. Vage Verweise auf einen KI-Fehler helfen Verteidigern nicht weiter.

Vorfälle sollten außerdem klarstellen, ob eine menschliche Genehmigung vorhanden war und warum sie versagt hat. Diese Belege zeigen, ob Aufsicht das Risiko reduziert oder lediglich Verantwortung verlagert.

Die zentrale These hinter der Warnung von Google News wird stärker, wenn sich Agenten schneller ausbreiten als diese drei Kontrollen. Sie wird schwächer, wenn Identität, Durchsetzung und Nachweise gemeinsam reifen.

Unternehmen sollten nicht erst auf einen großen Verlust warten, bevor sie ihre eigene Angriffsfläche erfassen. Sie können damit beginnen, jeden Agenten aufzulisten, der mit einem ERP-Prozess verbunden ist.

Dieses Inventar sollte Eigentümer, Zweck, Modell, Tools, Datenquellen, Zugangsdaten, Genehmigungspunkte und Abschaltverfahren enthalten. Unbekannte Einträge verdienen eine sofortige Untersuchung.

Anschließend sollten Teams einige wirkungsstarke Workflows von der Anweisung bis zur endgültigen Transaktion nachverfolgen. Änderungen von Zahlungen, Zugriffsgewährungen, Buchungssätze und Aktualisierungen von Mitarbeiterdaten sind gute Ausgangspunkte.

Die Übung wird fehlenden Kontext zwischen Systemen aufdecken. Sie zeigt außerdem, wo eine einzelne Zugangsdatenkombination oder ein Tool über mehr Befugnisse verfügt, als die Geschäftsaufgabe erfordert.

Unternehmen sollten Aktionen dann nach Auswirkung und Reversibilität klassifizieren. Reine Lese-Recherche benötigt nicht dieselben Kontrollen wie die Freigabe von Geldern oder die Änderung von Stammdaten.

Schließlich sollten Sicherheitsverantwortliche testen, wie die Organisation reagiert, wenn sich ein Agent fehlerhaft verhält. Erkennung ohne Eindämmung lässt die wichtigste Frage unbeantwortet.

Können Administratoren den Agenten stoppen, seine Befugnisse widerrufen, Beweise sichern, die Aktion rückgängig machen und betroffene Datensätze identifizieren, bevor sich der Schaden ausbreitet?

ERP-Sicherheit muss Autonomie nicht abschaffen. Sie muss sicherstellen, dass Autonomie niemals zu unbegrenzter Autorität wird.

Der praktische nächste Schritt ist einfach: Wählen Sie einen aktiven oder geplanten Agenten-Workflow und verfolgen Sie jede Identität, jedes Tool, jede Datenquelle und jede Genehmigung, die er berührt. Wenn Ihr Team diese Kette nicht erklären kann, ist der Agent nicht bereit für weitergehenden Zugriff.

Fragen Sie, wer ihn stoppen kann, welche Beweise erhalten bleiben und welche Aktionen rückgängig gemacht werden können. Diese Antworten sind wichtiger als eine weitere überzeugende Demonstration.

Google News hat die Warnung sichtbar gemacht. Enterprise-Teams müssen nun entscheiden, ob ihre ERP-Kontrollen Agenten ebenso sorgfältig steuern wie Menschen.