Bezpieczeństwo ERP nie nadąża za agentami AI

BankInfoSecurity zwrócił w Google News uwagę na niewygodny konflikt: mechanizmy bezpieczeństwa ERP mają trudności z dotrzymaniem kroku agentom AI, którzy zyskują uprawnienia operacyjne.

Nie chodzi o to, czy asystent potrafi podsumować fakturę lub odpowiedzieć na pytanie dotyczące zakupów. Ryzyko zaczyna się wtedy, gdy agent może pobierać rekordy, wywoływać narzędzia, zmieniać transakcje i koordynować działania w kilku systemach przedsiębiorstwa.

SAP, Oracle, Microsoft i Workday kierują oprogramowanie ERP w stronę tego modelu. Ich agenci mają ograniczyć powtarzalną pracę w finansach, zakupach, zasobach ludzkich i łańcuchach dostaw. Jednak kontrole otaczające tych agentów nadal opierają się na założeniach zaprojektowanych dla pracowników i przewidywalnych aplikacji.

Ta niezgodność tworzy główny problem bezpieczeństwa. Tradycyjne zarządzanie ERP pyta, która osoba ma daną rolę i na jakie transakcje ta rola zezwala. Systemy agentowe wprowadzają delegowane cele, zmieniający się kontekst, wybór narzędzi i przekazywanie zadań między maszynami.

Agent może posiadać prawidłowe poświadczenia, a mimo to wykonać niebezpieczne działanie. Może też połączyć kilka indywidualnie dozwolonych kroków w rezultat, którego żaden administrator nie zamierzał osiągnąć.

Dostawcy ERP dodają mechanizmy kontroli tożsamości, bramki zatwierdzania i funkcje audytowe. Środki te są ważne, ale nie eliminują głębszego konfliktu między autonomią agentów a deterministycznymi kontrolami przedsiębiorstwa.

Ostrzeżenie z Google News dotyczy uprawnień, a nie chatbotów

Najważniejsza zmiana polega na tym, że agenci AI w ERP przechodzą od odczytywania danych biznesowych do działania na ich podstawie.

Raport dotyczący bezpieczeństwa ERP, który pojawił się w Google News, przedstawia problem jako wyścig między rosnącymi możliwościami agentów a wolniejszym dostosowywaniem zabezpieczeń.

To ujęcie ma znaczenie, ponieważ systemy ERP zawierają operacyjną prawdę o firmie. Przechowują instrukcje płatnicze, dane pracowników, warunki dla dostawców, stany zapasów, salda klientów i zatwierdzenia finansowe.

Tradycyjny chatbot może udzielić nieprawidłowej odpowiedzi. Agent ERP z uprawnieniami wykonawczymi może przekształcić nieprawidłową odpowiedź w zaksięgowany zapis księgowy lub zatwierdzoną zmianę dostawcy.

Agentowa AI odnosi się do oprogramowania, które może interpretować cel, tworzyć plan, wybierać narzędzia i wykonywać kilka kroków przy ograniczonym nadzorze. Różni się to od automatyzacji o stałej logice, która podąża z góry określoną ścieżką.

Tradycyjny przepływ pracy może odrzucić fakturę zawsze wtedy, gdy brakuje zamówienia zakupu. Agent może zbadać rozbieżność, pobrać korespondencję, porównać dokumenty dostawy i zarekomendować wyjątek.

Ta elastyczność tworzy wartość, ponieważ rzeczywiste procesy biznesowe zawierają niejednoznaczności. Osłabia jednak przewidywalność, od której zależy wiele istniejących mechanizmów bezpieczeństwa.

Zespoły bezpieczeństwa mogą przeanalizować stały przepływ pracy przed wdrożeniem. Wiedzą, które pola odczytuje, jakie wywołania systemowe wykonuje i jakie warunki uruchamiają zatwierdzenie.

Agent może za każdym razem wybrać inną sekwencję. Jego zachowanie może zmieniać się wraz z promptem, dostępnymi narzędziami, pobranymi dokumentami, wersją modelu lub otaczającą rozmową.

Oznacza to, że autoryzacja nie może kończyć się na logowaniu. Bezpieczeństwo musi oceniać tożsamość agenta, delegowany cel, bieżący kontekst, wybrane narzędzie, żądane dane i zamierzony skutek.

Problem staje się trudniejszy, gdy agent przekracza granice aplikacji. Agent finansowy może konsultować pocztę e-mail, dokumentację zakupową, dane klientów i system płatności przed ukończeniem jednego zadania.

Każde połączenie rozszerza powierzchnię ataku. Utrudnia też przypisanie odpowiedzialności, gdy kilka komponentów przyczynia się do niebezpiecznego rezultatu.

Czytelnicy Google News mogą początkowo uznać tę historię za kolejne ostrzeżenie dotyczące dokładności generatywnej AI. Jej istota ma jednak poważniejsze konsekwencje.

Zespoły bezpieczeństwa ERP muszą zarządzać oprogramowaniem, które zachowuje się mniej jak pasywna aplikacja, a bardziej jak silnie połączony pracownik. Taki pracownik może działać nieprzerwanie, z szybkością maszyny i ponad granicami organizacyjnymi.

Zmiana wywiera presję na dyrektorów ds. bezpieczeństwa informacji, administratorów ERP, zespoły tożsamości, audytorów wewnętrznych i właścicieli procesów biznesowych. Żadna z tych grup nie może samodzielnie zarządzać tym ryzykiem.

Zespoły bezpieczeństwa rozumieją kontrolę dostępu, ale mogą nie mieć szczegółowego kontekstu procesowego. Liderzy finansowi rozumieją istotne konsekwencje, lecz mogą nie dostrzegać każdej zależności technicznej.

Administratorzy ERP rozumieją role i transakcje. Mogą jednak nie kontrolować zewnętrznych modeli, frameworków agentowych ani narzędzi zewnętrznych podłączonych do przepływu pracy.

Bezpośrednie wyzwanie ma więc charakter organizacyjny, a także techniczny. Firmy potrzebują jednego modelu kontroli, który śledzi agenta od początkowej instrukcji aż po każde wynikające z niej działanie.

Agenci AI w ERP przełamują model ludzkiej tożsamości

Prawidłowa tożsamość nie dowodzi już, że działanie jest właściwe, gdy oprogramowanie może reinterpretować cele i wybierać własną ścieżkę wykonania.

Kontrole ERP tradycyjnie koncentrowały się na nazwanych użytkownikach, przypisanych rolach i rozdzieleniu obowiązków. Rozdzielenie obowiązków zapobiega temu, by jedna osoba kontrolowała niezgodne ze sobą etapy wrażliwego procesu.

Na przykład pracownik, który tworzy dostawcę, nie powinien samodzielnie zatwierdzać płatności na rzecz tego dostawcy. Reguła ogranicza oszustwa i zmniejsza skutki przejętych poświadczeń.

Agenci komplikują ten model, ponieważ uprawnienia mogą przechodzić przez kilka warstw. Osoba instruuje agenta, agent wywołuje innego agenta, a ten uruchamia aplikację biznesową.

Końcowy system może widzieć jedynie uwierzytelnioną tożsamość usługi. Może nie otrzymać informacji o pierwotnym użytkowniku, celu, dowodach ani ograniczeniach związanych z żądaniem.

Tworzy to problem łańcucha delegacji. Każdy system rozpoznaje swojego bezpośredniego wywołującego, podczas gdy pełne źródło i intencja działania stają się trudniejsze do odtworzenia.

Współdzielone poświadczenia agentów pogarszają problem. Jeśli kilka przepływów pracy korzysta z jednego konta usługi, badaczom może być trudno odróżnić legalną automatyzację od nadużycia.

Trwałe poświadczenia pozwalają również, by uprawnienia przetrwały swój pierwotny cel. Agent utworzony na potrzeby tymczasowego projektu uzgadniania danych może zachować dostęp po zakończeniu tej pracy.

Przeglądy dostępu ludzi zwykle działają wokół zdarzeń związanych z zatrudnieniem i stałych ról. Agenci mogą pojawiać się, zmieniać, duplikować i znikać znacznie szybciej niż pracownicy.

Mogą też być tworzeni poza formalnymi procesami rozwoju. Zespół biznesowy może połączyć model z zatwierdzonym narzędziem, nie dostrzegając, że takie połączenie tworzy nową uprzywilejowaną tożsamość.

Framework bezpieczeństwa agentowego organizacji OWASP wskazuje nadużycia tożsamości i uprawnień jako jedno z głównych zagrożeń. Zwraca również uwagę na przejmowanie celów, niewłaściwe użycie narzędzi i słabości łańcucha dostaw systemów agentowych.

Przejęcie celu występuje wtedy, gdy złośliwa lub niezaufana treść zmienia to, co agent próbuje osiągnąć. Szkodliwa instrukcja może znajdować się w dokumencie, wiadomości, stronie internetowej lub odpowiedzi narzędzia.

W środowisku ERP jest to bardziej niebezpieczne niż w samodzielnym asystencie. Agent może już posiadać dostęp do poufnych rekordów i funkcji transakcyjnych.

Rozważmy agenta zakupowego, który czyta e-maile od dostawców. Przejęta wiadomość mogłaby polecić modelowi priorytetowe traktowanie kontrolowanego przez atakującego rachunku bankowego lub ujawnienie wewnętrznych danych zakupowych.

Żądanie mogłoby być sprzeczne z pierwotnym celem użytkownika. Mimo to agent może potraktować osadzony tekst jako istotny kontekst operacyjny, o ile zabezpieczenia nie oddzielają danych od instrukcji.

Zasada najmniejszych uprawnień pozostaje konieczna, ale jej wdrożenie musi stać się bardziej precyzyjne. Agent powinien otrzymywać jedynie uprawnienia wymagane do jednego celu i na ograniczony czas.

Wskazówki Oracle dotyczące bezpiecznych operacji jasno wyrażają to rozróżnienie. Agent analityczny nie potrzebuje uprawnień do zatwierdzania zakupów tylko dlatego, że oba elementy uczestniczą w jednym przepływie pracy.

Zasada brzmi znajomo, lecz agenci utrudniają jej egzekwowanie. Ich plany mogą ewoluować po rozpoczęciu zadania, a podczas wykonywania mogą żądać dodatkowych narzędzi.

Statyczne role nie mogą w pełni wyrazić warunków takich jak cel, wartość transakcji, wrażliwość danych, poziom pewności czy to, czy żądanie zainicjował inny agent.

Firmy potrzebują zatem kontroli zasad w momencie wykonywania działania. Kontrole te powinny oceniać zarówno żądaną operację, jak i otaczający ją kontekst.

Działania o dużym wpływie wymagają również silniejszego potwierdzenia ludzkiej intencji. Przycisk potwierdzenia nie wystarcza, jeśli osoba oceniająca widzi jedynie dopracowane podsumowanie stworzone przez tego samego agenta.

Osoba oceniająca potrzebuje oryginalnych dowodów, proponowanych zmian, wyjątków od zasad i oczekiwanego efektu biznesowego. W przeciwnym razie nadzór człowieka staje się czysto ceremonialny.

Rzeczywistym kompromisem jest autonomia kontra kontrola

Każde zwiększenie autonomii agenta podnosi wymagania dotyczące tożsamości, egzekwowania zasad, obserwowalności i odzyskiwania sprawności.

Agenci AI w ERP stają się użyteczni, gdy potrafią obsługiwać wyjątki. Jednak właśnie w przypadku wyjątków deterministyczne kontrole zapewniają najsłabsze pokrycie.

Stała automatyzacja podąża ścieżkami zdefiniowanymi wcześniej przez programistów. Agent interpretuje niepełne informacje i decyduje, która ścieżka wydaje się właściwa.

To rozróżnienie tworzy kompromis w zakresie bezpieczeństwa. Zbyt mocne ograniczenie agenta sprawia, że staje się on kosztownym interfejsem dla istniejących przepływów pracy. Przyznanie szerszych uprawnień powoduje natomiast, że jego błędy mają konsekwencje operacyjne.

Konflikt nie znika, gdy agent pozostaje w chmurze dostawcy. Kontrolowane środowisko może ograniczyć ekspozycję, ale to logika biznesowa nadal określa, czy działanie jest dopuszczalne.

Agent może mieć uprawnienie do aktualizowania rekordów dostawców. Nie oznacza to, że każda aktualizacja dostawcy służy uzasadnionemu celowi.

Agent może również połączyć funkcje niskiego ryzyka w sekwencję wysokiego ryzyka. Odczytywanie faktur, tworzenie dostawców i przygotowywanie płatności wydają się możliwe do opanowania, gdy ocenia się je osobno.

Łącznie te funkcje mogą odtworzyć całą ścieżkę oszustwa. Czasem określa się to jako ryzyko kompozycyjne, w którym pozornie bezpieczne komponenty tworzą niebezpieczny łączny rezultat.

Narzędzia bezpieczeństwa często sprawdzają pojedyncze wywołania API. Mogą zatwierdzać każdy krok, nie dostrzegając szerszego planu, który je łączy.

Pamięć agenta tworzy kolejną trudność. Pamięć pozwala oprogramowaniu zachowywać kontekst zadania, preferencje lub wcześniejsze obserwacje między interakcjami.

Ta ciągłość może poprawić wydajność. Może również zachować złośliwe instrukcje, wrażliwe dane lub nieprawidłowe założenia poza sesją, w której trafiły do systemu.

Generowanie wspomagane wyszukiwaniem, czyli RAG, dostarcza modelowi wybrane informacje przedsiębiorstwa podczas odpowiadania lub działania. Jego bezpieczeństwo zależy od źródła, uprawnień, jakości i aktualności pobranych materiałów.

Zatrute źródło wiedzy może zniekształcać późniejsze decyzje bez bezpośredniego naruszania bazowego modelu. Nieaktualny dokument dotyczący zasad może wywołać podobny efekt w wyniku zwykłej porażki operacyjnej.

To sprawia, że zarządzanie informacją staje się częścią bezpieczeństwa agentów AI. Zespoły muszą wiedzieć, z których źródeł korzysta agent, kto może je zmieniać i jak pobrane dowody wpływają na decyzje.

Pracownicy budujący wewnętrzne procesy również potrzebują rzetelnej dokumentacji. Przeszukiwalna baza wiedzy może pomóc zespołom zachować decyzje projektowe, modele zagrożeń i wymagania dotyczące zatwierdzania wdrożeń agentów.

Dokumentacja nie może zastąpić środków kontroli technicznej. Może jednak zmniejszyć ryzyko, że kluczowe założenia znikną, gdy agent zmieni właściciela lub przejdzie z fazy pilotażowej do produkcji.

Dostęp do narzędzi tworzy równoległe ryzyko. Narzędzia przekładają wyniki modelu na działania, takie jak odpytywanie bazy danych, wysyłanie wiadomości czy modyfikowanie rekordu biznesowego.

Model nie potrzebuje bezpośrednich poświadczeń do bazy danych, jeśli ma je już podłączone narzędzie. Narzędzie staje się więc częścią efektywnej granicy uprawnień agenta.

Przeglądy bezpieczeństwa muszą obejmować schematy narzędzi, walidację danych wejściowych, przechowywanie poświadczeń, filtrowanie wyników i zachowanie w przypadku awarii. Analiza wyłącznie modelu pomija większość ścieżki wykonawczej.

Systemy wieloagentowe dodatkowo zwiększają niepewność. Jeden agent może delegować badania, inny interpretować politykę, a trzeci realizować transakcję.

Przy każdym przekazaniu zadania może dojść do utraty kontekstu lub wprowadzenia niezaufanego wyniku. Może ono także zacierać informację o tym, który komponent podjął decyzję prowadzącą do szkody.

Opublikowana przez SAP architektura bezpieczeństwa śledzi żądania agentów poprzez weryfikację tożsamości, przetwarzanie AI, realizację operacji biznesowych i rejestrowanie danych do celów dochodzeniowych.

To właściwy kierunek spojrzenia całościowego. Diagramy architektury nie dowodzą jednak, że każde wdrożenie u klienta konsekwentnie stosuje te mechanizmy kontrolne.

Środowiska ERP obejmują niestandardowy kod, starsze integracje, systemy pozyskane w wyniku przejęć, partnerów zewnętrznych i długotrwałe wyjątki. Różnice te mogą osłabiać domyślny model bezpieczeństwa dostawcy.

Najtrudniejsze wdrożenia będą dotyczyć środowisk hybrydowych. Agent może zaczynać pracę w nowoczesnej usłudze chmurowej, lecz działać za pośrednictwem starszych aplikacji o szerokich uprawnieniach i ograniczonej telemetrii.

W takich środowiskach najnowszy komponent może odziedziczyć najsłabszy mechanizm kontrolny w łańcuchu. Autonomia agenta dodatkowo wzmacnia dług techniczny, z którym organizacje już wcześniej miały trudności.

Dzienniki audytowe nie potrafią wyjaśnić każdej decyzji agenta

Bezpieczeństwo ERP potrzebuje dowodów łączących intencję użytkownika z rozumowaniem agenta, wywołaniami narzędzi, zmianami danych i wynikami biznesowymi.

Tradycyjne dzienniki audytowe odpowiadają na znane pytania. Pokazują, które konto uzyskało dostęp do systemu, kiedy doszło do transakcji i które pole uległo zmianie.

Procesy agentowe wymagają dłuższego łańcucha dowodowego. Osoby prowadzące dochodzenie potrzebują informacji o użytkowniku inicjującym, delegowanym celu, wersji modelu, pobranym kontekście, decyzjach polityki, wywołaniach narzędzi i końcowym wyniku.

Mogą również potrzebować wiedzieć, czego agent odmówił wykonać. Powtarzające się odrzucone żądania mogą ujawniać próby sondowania, błędną konfigurację lub skompromitowane źródło.

Rejestrowanie każdego promptu i odpowiedzi nie jest prostym rozwiązaniem. Prompty mogą zawierać dane płacowe, umowy, dane osobowe, poświadczenia i inne informacje objęte ograniczeniami.

Pełny dziennik może więc tworzyć kolejne wrażliwe repozytorium. Zasady retencji, dostępu, szyfrowania i redakcji danych muszą odpowiadać charakterowi bazowych danych biznesowych.

Rozumowanie modelu wprowadza kolejną komplikację. Wygenerowane wyjaśnienie może brzmieć spójnie, nie odzwierciedlając dokładnie sposobu, w jaki system doszedł do wyniku.

Zespoły bezpieczeństwa nie powinny traktować opisowego wyjaśnienia jako dowodu. Potrzebują weryfikowalnych zapisów danych wejściowych, żądań narzędzi, ocen polityk i wynikających z nich zmian stanu.

To zmienia znaczenie obserwowalności. Monitorowanie musi obejmować zachowanie w całym procesie, a nie jedynie dostępność modelu czy błędy API.

Przydatne sygnały obejmują nieoczekiwany wybór narzędzi, nietypowy wolumen transakcji, dostęp wykraczający poza zwykły zakres działalności, powtarzające się odmowy wynikające z polityk oraz zmiany w wrażliwych rekordach.

Punkty odniesienia muszą także uwzględniać przypisane agentowi przeznaczenie. Agent uzgadniający listy płac i agent ds. zaopatrzenia nie powinni mieć tego samego profilu normalnego zachowania.

Limity częstotliwości mogą ograniczyć skalę skutków błędów. Nie są jednak w stanie stwierdzić, czy niewielka liczba działań o wysokiej wartości jest uzasadniona.

Progi transakcyjne zapewniają kolejną warstwę ochrony. Atakujący mogą jednak dzielić aktywność na mniejsze działania albo wykorzystywać procesy, w których jedna zmiana o niskiej wartości umożliwia późniejszą stratę.

Firmy potrzebują mechanizmów kontrolnych w kilku punktach. Środowisko uruchomieniowe agenta powinno ograniczać narzędzia, warstwa tożsamości — uprawnienia, a ERP — weryfikować reguły biznesowe.

Niezależne monitorowanie powinno następnie potwierdzać, co faktycznie się wydarzyło. Poleganie na tym samym agencie, by działał, oceniał i raportował własne zachowanie, koncentruje zbyt duże zaufanie.

Zatwierdzanie przez człowieka pozostaje wartościowe w przypadku działań nieodwracalnych lub istotnych. Osoby zatwierdzające potrzebują jednak wystarczającej ilości czasu i kontekstu, aby wykryć manipulację.

Zmęczenie zatwierdzaniem może zamienić zabezpieczenie w formalność. Agenci działający z prędkością maszyn mogą generować więcej próśb o przegląd, niż pracownicy są w stanie rzetelnie ocenić.

Autonomia stopniowana według ryzyka oferuje bardziej praktyczny model. Zadania o niewielkim wpływie i odwracalnych skutkach mogą przebiegać automatycznie, podczas gdy wrażliwe działania wymagają niezależnej walidacji.

Przykłady prac o niższym ryzyku obejmują przygotowywanie wyjaśnień, zbieranie dowodów i oznaczanie anomalii. Prace o wyższym ryzyku obejmują zmianę danych płatniczych, uwalnianie środków lub modyfikowanie dostępu.

Odwracalność powinna wpływać na poziom kontroli. Błędny raport można skorygować, podczas gdy płatność zewnętrzna lub usunięty rekord mogą spowodować trwałe szkody.

Profil ryzyka NIST porządkuje działania związane z ryzykiem AI wokół zarządzania, mapowania, pomiaru i zarządzania ryzykiem. Takie podejście oparte na cyklu życia lepiej pasuje do agentów ERP niż jednorazowe zatwierdzenie.

Ryzyko związane z agentem zmienia się, gdy zmieniają się jego narzędzia, model, źródła danych, uprawnienia lub cel biznesowy. Każda modyfikacja powinna uruchamiać ponowną ocenę i ukierunkowane testy.

Testy muszą obejmować dane wejściowe o charakterze adversarialnym oraz realistyczne wyjątki biznesowe. Demonstracja oparta na czystych danych nie ujawni, jak agent zachowuje się przy sprzecznych instrukcjach.

Zespoły powinny również testować częściowe awarie. System zależny może przekroczyć limit czasu po wykonaniu przez agenta jednego kroku, ale przed zarejestrowaniem kolejnego.

Bez idempotencji, która zapobiega temu, by ponowne wykonanie powodowało zduplikowane skutki, agent może ponownie wysłać tę samą transakcję podczas odzyskiwania po awarii.

Te zwykłe problemy z niezawodnością stają się kwestiami bezpieczeństwa, gdy wpływają na rejestry finansowe, prawa dostępu lub dane regulowane. Bezpieczeństwo agentów nie może pozostawać oddzielone od inżynierii systemów.

Mechanizmy ochronne dostawców zderzają się z rzeczywistością dostosowanego ERP

SAP i Oracle mogą zabezpieczać własne platformy agentowe, ale klienci nadal kontrolują integracje, role, dane i wyjątki, które określają praktyczne ryzyko.

Dostawcy ERP mają przewagę strukturalną. Rozumieją modele swoich aplikacji i mogą osadzać agentów obok istniejących usług tożsamości, przepływów pracy i audytu.

Natywni agenci mogą dziedziczyć metadane biznesowe, których brakuje zewnętrznemu modelowi. Mogą także korzystać z zatwierdzonych interfejsów zamiast naśladować działania użytkowników za pośrednictwem ekranu.

Oracle zaleca klientom rozdzielanie odpowiedzialności agentów i stosowanie zasady najmniejszych uprawnień wśród współpracujących agentów. SAP opisuje kontrole tożsamości, izolację tenantów, walidację wyników i ścieżki audytowe na potrzeby dochodzeń.

Mechanizmy te odpowiadają na realne obawy. Wspierają również argument dostawców, że osadzeni agenci są bezpieczniejsi niż luźno połączona automatyzacja firm trzecich.

Ten argument ma ograniczenia. Większość dużych organizacji nie prowadzi jednego, uporządkowanego środowiska ERP o standardowych konfiguracjach.

Prowadzą dostosowane procesy w kilku systemach. Część aplikacji pozostaje lokalnie, podczas gdy inne działają w chmurach publicznych lub usługach zarządzanych przez dostawców.

Partnerzy, wykonawcy, banki, dostawcy logistyki i jednostki biznesowe pozyskane w wyniku przejęć mogą łączyć się z tym samym procesem. Każda granica wprowadza inny model tożsamości i kontroli.

Natywny agent finansowy nadal może otrzymywać niezaufane treści z poczty e-mail. Może opierać się na parserze dokumentów firmy trzeciej lub przesyłać wynik do starszej aplikacji płatniczej.

Cały proces jest wiarygodny tylko w takim stopniu, w jakim wiarygodne są jego zależności. Dokumentacja bezpieczeństwa dostawcy nie może uwzględnić każdego rozszerzenia klienta.

Agenci zewnętrzni wiążą się z innym kompromisem. Mogą koordynować pracę między konkurencyjnymi platformami ERP, CRM, komunikacyjnymi i analitycznymi.

Ta niezależność może ograniczać uzależnienie od dostawcy i wspierać szersze procesy. Umieszcza jednak dodatkową tożsamość, warstwę orkiestracji i ekosystem narzędzi między użytkownikami a rekordami biznesowymi.

Praktyczny wybór nie sprowadza się więc do bezpiecznego oprogramowania natywnego kontra niebezpieczne oprogramowanie zewnętrzne. Oba podejścia tworzą ryzyka, lecz koncentrują je w różnych miejscach.

Natywni agenci koncentrują zaufanie w platformie, chmurze i modelu zarządzania dostawcy ERP. Agenci zewnętrzni rozpraszają zaufanie między konektorami, poświadczeniami, modelami i narzędziami orkiestracji.

Zespoły bezpieczeństwa powinny oceniać pełną ścieżkę działania, zamiast akceptować etykiety kategorii. Produkt natywny może stać się niebezpieczny wskutek zbyt szerokiej konfiguracji.

Produkt zewnętrzny może ograniczać ryzyko, jeśli otrzymuje wąsko określone, krótkotrwałe uprawnienia i nie może bezpośrednio realizować wrażliwych transakcji.

Przeglądy zakupowe muszą odzwierciedlać te różnice. Standardowe kwestionariusze dotyczące oprogramowania rzadko obejmują głębokość delegowania, zachowanie pamięci, obsługę promptów czy uprawnienia na poziomie narzędzi.

Kupujący powinni pytać, która tożsamość pojawia się w dzienniku ERP i czy identyfikuje ona pierwotnego użytkownika. Powinni także pytać, jak polityka podąża za zadaniem podczas przekazywania go między agentami.

Inne kluczowe pytania dotyczą aktualizacji modeli, zachowywanego kontekstu, lokalizacji danych, reagowania na incydenty i dostępu klienta do szczegółowej telemetrii.

Dostawca powinien wyjaśnić, jak administratorzy mogą natychmiast zawiesić agenta. Taka kontrola musi unieważniać aktywne poświadczenia i przerywać oczekujące działania, a nie jedynie ukrywać interfejs.

Klienci potrzebują także dowodów dotyczących zarządzania zmianą. Zachowanie agenta może się zmienić po zmianie modelu, system promptu, definicji narzędzia lub źródła pobierania danych.

Tradycyjna aktualizacja aplikacji zwykle zmienia deterministyczny kod. Aktualizacja modelu może zmienić decyzje nawet wtedy, gdy otaczający proces pozostaje niezmieniony.

Testy bezpieczeństwa muszą więc być kontynuowane po wdrożeniu. Zespoły powinny uruchamiać reprezentatywne zadania i przypadki nadużyć przy każdej istotnej zmianie komponentu.

Powinny porównywać wyniki między wersjami i zachowywać wystarczające dowody do badania regresji. Zaliczone testy sprzed sześciu miesięcy niewiele mówią o zmodyfikowanym agencie.

Presja konkurencyjna może osłabiać tę dyscyplinę. Dostawcy ERP chcą, by klienci wdrażali agentów, a liderzy biznesowi oczekują mierzalnej poprawy produktywności.

Zespoły bezpieczeństwa mogą być naciskane, by zatwierdziły szerokie pilotaże, zanim systemy tożsamości i monitorowania będą gotowe. Taka kolejność zamienia zarządzanie w projekt naprawczy.

Bezpieczniejsze wdrożenie zaczyna się od ograniczonych zadań i obserwowalnych wyników. Uprawnienia rozszerzają się dopiero wtedy, gdy organizacja potrafi wyjaśnić, wykryć i odwrócić zachowanie agenta.

Trzy sygnały pokażą, czy bezpieczeństwo ERP nadąża

O kolejnej fazie zdecydują tożsamości specyficzne dla agentów, egzekwowanie zasad na poziomie działań oraz dowody z rzeczywistych incydentów produkcyjnych.

Pierwszym sygnałem będzie to, czy platformy ERP przyjmą odrębne, krótkotrwałe tożsamości dla każdego agenta i delegowanego zadania. Współdzielone konta usługowe powinny stać się wyjątkiem.

Dojrzały projekt zachowa pierwotnego użytkownika, tożsamość agenta, cel i uprawnienia w całym procesie. Aplikacje podrzędne powinny otrzymać ten kontekst przed zezwoleniem na działanie.

Wzmocniłoby to argument, że agenci AI w ERP mogą działać w ramach ustalonych struktur odpowiedzialności. Dalsze poleganie na szerokich poświadczeniach osłabiłoby ten argument.

Drugim sygnałem jest to, czy dostawcy i klienci egzekwują zasady na poziomie transakcji. Uprawnienie do korzystania z narzędzia nie powinno oznaczać zgody na każdy możliwy rezultat jego działania.

Mechanizmy kontroli powinny uwzględniać typ transakcji, wartość, miejsce docelowe, dowody źródłowe oraz odwracalność. Operacje wrażliwe powinny wymagać niezależnej weryfikacji poza modelem wykonującym działanie.

Zespoły bezpieczeństwa powinny śledzić premiery produktów pod kątem konkretnych funkcji egzekwowania zasad. Marketingowe deklaracje dotyczące odpowiedzialnej AI są mniej użyteczne niż konfigurowalne mechanizmy kontroli i eksportowalne logi.

Powinny również sprawdzać, czy te mechanizmy działają we wszystkich połączonych aplikacjach. Ochrona ograniczona do interfejsu jednego dostawcy nie zabezpieczy workflow działającego na wielu platformach.

Trzecim sygnałem jest jakość publicznego raportowania incydentów. Awarie produkcyjne ujawnią, gdzie teoretyczne architektury zawodzą w rzeczywistych warunkach biznesowych.

Przydatne ujawnienia wskażą naruszoną tożsamość, zmanipulowane dane wejściowe, dotknięte narzędzia, nieautoryzowane działania i metodę ograniczenia skutków. Niejasne odniesienia do błędu AI nie pomogą obrońcom.

Incydenty powinny również wyjaśniać, czy istniała akceptacja człowieka i dlaczego zawiodła. Takie dowody pokażą, czy nadzór ogranicza ryzyko, czy jedynie przenosi odpowiedzialność.

Główna teza stojąca za ostrzeżeniem Google News będzie zyskiwać na sile, jeśli agenci będą rozwijać się szybciej niż te trzy mechanizmy kontroli. Osłabnie, jeśli tożsamość, egzekwowanie zasad i dowody będą dojrzewać równolegle.

Organizacje nie powinny czekać na poważną stratę, zanim zmapują własną ekspozycję na ryzyko. Mogą zacząć od wymienienia każdego agenta połączonego z procesem ERP.

Taki spis powinien obejmować właściciela, cel, model, narzędzia, źródła danych, poświadczenia, punkty zatwierdzania oraz procedurę wyłączenia. Nieznane pozycje zasługują na natychmiastowe zbadanie.

Następnie zespoły powinny prześledzić kilka workflow o dużym wpływie — od instrukcji do końcowej transakcji. Dobrymi punktami wyjścia są zmiany płatności, nadawanie dostępu, zapisy księgowe i aktualizacje danych pracowników.

To ćwiczenie ujawni brakujący kontekst między systemami. Pokaże również, gdzie jedno poświadczenie lub narzędzie ma większe uprawnienia, niż wymaga tego zadanie biznesowe.

Firmy powinny następnie klasyfikować działania według ich wpływu i odwracalności. Badania w trybie tylko do odczytu nie wymagają takich samych mechanizmów kontroli jak uwalnianie środków lub zmiana danych podstawowych.

Na koniec liderzy bezpieczeństwa powinni przetestować, jak organizacja reaguje, gdy agent zachowuje się nieprawidłowo. Wykrycie bez ograniczenia skutków pozostawia najważniejsze pytanie bez odpowiedzi.

Czy administratorzy mogą zatrzymać agenta, odebrać mu uprawnienia, zachować dowody, odwrócić działanie i zidentyfikować dotknięte rekordy, zanim szkody się rozprzestrzenią?

Bezpieczeństwo ERP nie musi eliminować autonomii. Musi zapewnić, że autonomia nigdy nie stanie się nieograniczoną władzą.

Praktyczny kolejny krok jest prosty: wybierz jeden działający lub planowany workflow agenta i prześledź każdą tożsamość, narzędzie, źródło danych oraz akceptację, których dotyka. Jeśli zespół nie potrafi wyjaśnić tego łańcucha, agent nie jest gotowy na szerszy dostęp.

Zapytaj, kto może go zatrzymać, jakie dowody przetrwają i które działania można odwrócić. Te odpowiedzi mają większe znaczenie niż kolejna dopracowana demonstracja.

Google News zwróciło uwagę na to ostrzeżenie. Zespoły przedsiębiorstw muszą teraz zdecydować, czy ich mechanizmy kontroli ERP nadzorują agentów równie starannie, jak nadzorują ludzi.