W tygodniu zakończonym 2 listopada 2026 r. AWS poinformował, że istniejące workflows AWS Step Functions mogą być wystawione agentom jako narzędzia przez Amazon Bedrock AgentCore Gateway, który łączy agentów z narzędziami po protokole Model Context Protocol (MCP). Równolegle OpenAI udostępnił model GPT-6.1 Terra w Amazon Bedrock, pozycjonowany jako tańsza linia do codziennych obciążeń. Oba komunikaty dotyczą przede wszystkim zasięgu i kosztu, a nie skoku w możliwościach samego modelu.

Dotyczy to zespołów, które mają już procesy w Step Functions — na przykład obsługę zwrotów, provisioning kont, uzgodnienia czy sekwencje zatwierdzeń — i chcą dać agentowi możliwość ich uruchamiania bez przepisywania logiki. Jest to ważne, bo po raz pierwszy w tym zakresie deterministyczny workflow może stać się elementem sterowanym przez model, przy zachowaniu kolejności kroków zapisanej w definicji. Jednocześnie deklaracje cenowe i wydajnościowe producenta modelu wymagają ostrożności: część liczb pochodzi od OpenAI, a nie z niezależnych testów.

Co dokładnie ogłoszono

Według oficjalnego wpisu AWS w Weekly Roundup z 2 listopada 2026 r. workflows Step Functions są dostępne jako narzędzia agentów AI przez AgentCore Gateway. Podział ról opisano wprost: agent decyduje, kiedy uruchomić workflow i jakie wejście przekazać, a Step Functions wykonuje każdy krok zgodnie z definicją. Jako przykład podano agenta wsparcia, który może zainicjować zwrot, ale sprawdzenie uprawnień, akceptacja menedżera i księgowanie nadal następują w ustalonej kolejności.

Z komunikatu wynikają następujące fakty techniczne:

istniejące workflows w trybie Standard i Express kwalifikują się jako cele konektorów,
agenci mogą również odpytywać o uruchomienia workflow,
funkcja jest dostępna we wszystkich Regionach, w których działa AgentCore Gateway, w standardowych stawkach,
Step Functions orkiestruje ponad 220 usług AWS, co określa skalę potencjalnego zasięgu.

Osobno AWS poinformował o ogólnej dostępności GPT-6.1 Terra w Amazon Bedrock. Model ma obsługiwać do 1 mln tokenów wejściowych z wejściem tekstowym i obrazowym, a dostęp ma być możliwy przez API Bedrock oraz przez ChatGPT Work i Codex. Ceny tokenów wejściowych i wyjściowych mają być co najmniej o 50% niższe niż w GPT-6.1 Sol i GPT-5.6 Terra.

Deklaracje producenta a niezależne obserwacje

Trzeba wyraźnie rozdzielić dwie warstwy. AWS potwierdza dostępność produktu, regiony i model rozliczeń. Natomiast wyniki jakościowe modelu — 15 punktów procentowych więcej niż GPT-5.6 Terra w Agents’ Last Exam, wynik na poziomie GPT-6 Astra i ponad trzykrotnie szybsze wykonanie zadań — pochodzą z danych OpenAI. W materiale źródłowym zaznaczono wprost, że nie są to wyniki niezależnego testu. Nie mamy więc podstaw, by traktować je jako zweryfikowane poza deklaracją dostawcy.

Podobnie należy traktować przykład MoEngage: około 400 wewnętrznych operacji API wystawionych jako narzędzia agenta, zbudowanych przez 25 zespołów, w prywatnych VPC w siedmiu Regionach, z tożsamością tenanta, która nie może stać się parametrem ustawianym przez model. To opis przypadku opublikowany przez AWS, a nie audyt zewnętrzny. Warto go czytać jako ilustrację wzorca, nie jako dowód na uniwersalną skuteczność.

Tło techniczne prostym językiem

Step Functions to usługa orkiestracji: opisujesz maszynę stanów, czyli kolejność kroków, warunki przejścia, obsługę błędów i ponowień. Wykonanie jest deterministyczne — przy tym samym wejściu i stanie przejścia proces przebiega według definicji, a nie według uznania modelu.

Agent AI działa inaczej. Otrzymuje cel, zestaw dostępnych narzędzi i podejmuje decyzje niedeterministycznie: które narzędzie wybrać, z jakimi argumentami, w jakiej kolejności. To zaleta przy zadaniach otwartych i ryzyko przy procesach, w których kolejność ma skutki prawne lub finansowe.

AgentCore Gateway pełni rolę warstwy pośredniej. Publikuje narzędzia i opisuje je agentowi, a wywołania przekazuje do systemów docelowych. W tym przypadku narzędziem staje się uruchomienie workflow Step Functions. MCP to protokół opisujący, jak agent odkrywa narzędzia i jak je wywołuje. Praktyczny skutek: nie trzeba pisać nowego API ani przenosić logiki do promptu — wystarczy opisać istniejący workflow i wskazać go jako cel konektora.

Warto zauważyć jeden szczegół z przypadku MoEngage, który ma znaczenie architektoniczne: pełny katalog narzędzi przekraczałby 20 tys. tokenów na jedno połączenie. Dlatego agenci wyszukują narzędzia, opisując zadanie, zamiast otrzymywać cały katalog. To wpływa na projekt opisów narzędzi i na koszt tokenów przy każdym wywołaniu.

Realne konsekwencje dla organizacji

Najważniejsza zmiana nie polega na tym, że agent „umie więcej”. Polega na tym, że granica między decyzją a wykonaniem została jawnie rozdzielona. Model decyduje o intencji i parametrach wejścia. Workflow odpowiada za sekwencję, warunki i skutki. To pozwala włączyć agenta do procesów, które wcześniej odrzucano jako zbyt ryzykowne, bez rezygnacji z audytowalności.

Drugi skutek jest kosztowy. Jeśli workflow już istnieje, koszt wdrożenia może być znacznie niższy niż budowa dedykowanego API dla agenta. AWS nie podaje jednak konkretnych oszczędności poza opisem przypadku MoEngage, gdzie oszacowano około sześciu miesięcy pracy zespołu platformowego. To szacunek klienta, nie gwarancja.

Trzeci skutek dotyczy bezpieczeństwa uprawnień. Skoro agent może wywołać workflow z efektem finansowym, to zakres uprawnień agenta staje się równie istotny jak uprawnienia człowieka. Model nie powinien mieć możliwości ustawienia tożsamości tenanta jako parametru — w przypadku MoEngage podkreślono, że tożsamość nigdy nie może być wartością przekazywaną przez model.

Scenariusze ryzyka

Poniższe scenariusze są interpretacją ryzyk wynikających z opisanej architektury, a nie potwierdzonymi incydentami.

Scenariusz	Mechanizm	Ograniczenie
Agent uruchamia workflow z błędnym wejściem	Model błędnie interpretuje intencję użytkownika i przekazuje niepoprawne parametry	Walidacja wejścia w pierwszym stanie workflow, odrzucanie wartości spoza dozwolonego zakresu
Nadużycie uprawnień przez prompt injection	Treść dokumentu lub wiadomości skłania agenta do wywołania narzędzia	Zasada minimalnych uprawnień, rozdzielenie narzędzi odczytu i zapisu, zatwierdzenie człowieka dla operacji nieodwracalnych
Podwójne wykonanie operacji	Ponowienie wywołania po timeoucie bez idempotencji	Klucze idempotencji, sprawdzanie stanu uruchomienia przed ponownym wywołaniem
Rozmycie odpowiedzialności	Zespół zakłada, że „model dopilnuje” kolejności	Jawny zapis, że kolejność wynika z definicji workflow, nie z decyzji modelu
Koszt tokenów przy dużej liczbie narzędzi	Rozbudowany katalog narzędzi zwiększa zużycie tokenów	Wyszukiwanie narzędzi po opisie zadania zamiast przekazywania pełnego katalogu
Błędna ocena kosztu modelu	Decyzja na podstawie deklaracji producenta bez pomiaru własnego obciążenia	Własny benchmark na reprezentatywnych zadaniach przed migracją

Jak sprawdzić, czy problem dotyczy Twojej organizacji

To nie jest podatność, więc „problem” oznacza tu raczej pytanie o zasadność i bezpieczeństwo wdrożenia. Odpowiedz na poniższe pytania.

Czy masz workflows w Step Functions w trybie Standard lub Express, które wykonują operacje o skutkach finansowych lub prawnych?
Czy w Twoim Regionie działa AgentCore Gateway? Funkcja jest dostępna tylko tam, gdzie działa ta usługa.
Czy któryś z workflow przyjmuje parametry, które mogłyby pochodzić od użytkownika końcowego lub z treści dokumentu?
Czy workflow jest idempotentny przy ponownym wywołaniu z tym samym wejściem?
Czy tożsamość użytkownika lub tenanta jest ustalana po stronie systemu, a nie przekazywana jako parametr?
Czy masz logi i ślad audytowy pozwalający odtworzyć, kto i na jakiej podstawie uruchomił dany workflow?
Czy zespół rozumie różnicę między decyzją modelu a wykonaniem kroków?

Jeśli odpowiedź na pytania 1 i 3 jest twierdząca, a na 4 lub 5 przecząca, wdrożenie należy wstrzymać do czasu uzupełnienia zabezpieczeń.

Plan reakcji krok po kroku

Inwentaryzacja. Spisz workflows, które mogłyby stać się narzędziami. Dla każdego określ skutek: odczyt, zapis, operacja finansowa, zmiana konfiguracji.
Klasyfikacja. Podziel na trzy grupy: tylko odczyt, zapis odwracalny, zapis nieodwracalny. Dwie pierwsze mogą być kandydatami do wystawienia agentowi; trzecia wymaga zatwierdzenia człowieka.
Kontrola wejścia. W pierwszym stanie workflow dodaj walidację parametrów: dozwolone wartości, zakresy, formaty. Odrzucaj wszystko, co nie przechodzi.
Idempotencja. Wprowadź klucz idempotencji powiązany z intencją operacji, nie z identyfikatorem wywołania.
Tożsamość. Upewnij się, że tożsamość użytkownika i tenanta jest ustalana po stronie systemu i nie może być nadpisana przez model.
Uprawnienia. Nadaj agentowi minimalny zakres. Oddziel narzędzia odczytu od narzędzi zapisu, jeśli to możliwe.
Opisy narzędzi. Napisz opisy zrozumiałe dla modelu, ale precyzyjne co do skutków. Unikaj ogólników, które zachęcają do nadużycia.
Testy. Przetestuj na środowisku nieprodukcyjnym, w tym przypadki błędnych parametrów i próby wywołania spoza dozwolonego kontekstu.
Monitoring. Ustaw alerty na nietypowe wzorce wywołań: nagły wzrost liczby uruchomień, powtarzające się błędy walidacji, wywołania z nieoczekiwanymi parametrami.
Stopniowe wdrażanie. Zacznij od jednego workflow o niskim ryzyku, z ograniczoną grupą użytkowników.

Typowe błędy

Przenoszenie logiki do promptu. Kolejność kroków ma zostać w definicji workflow, nie w instrukcji dla modelu.
Brak walidacji wejścia. Założenie, że model zawsze przekaże poprawne parametry.
Tożsamość jako parametr. Pozwolenie modelowi na ustawianie identyfikatora tenanta lub użytkownika.
Brak idempotencji. Ponowienia po timeoucie powodują podwójne operacje.
Zbyt szerokie uprawnienia. Agent dostaje dostęp do wszystkich workflows, bo „tak jest prościej”.
Decyzja o modelu na podstawie cennika. Niższa cena tokenów nie oznacza niższego kosztu zadania, jeśli model zużywa więcej tokenów lub wymaga więcej prób.
Traktowanie deklaracji producenta jako benchmarku. Wyniki OpenAI nie są niezależnym testem.
Pominięcie kosztu odkrywania narzędzi. Duży katalog narzędzi zwiększa zużycie tokenów przy każdym połączeniu.

Działania krótkoterminowe

Zidentyfikuj jeden workflow o niskim ryzyku i ograniczonym zakresie skutków jako pilotaż.
Dodaj walidację wejścia i klucz idempotencji przed jakimkolwiek wystawieniem.
Ustal, kto zatwierdza włączenie kolejnych workflows do katalogu narzędzi.
Zbierz dane o koszcie tokenów na reprezentatywnych zadaniach, zanim podejmiesz decyzję o modelu.
Sprawdź, czy Twój Region obsługuje AgentCore Gateway.

Działania długoterminowe

Wprowadź katalog workflows z klasyfikacją ryzyka i właścicielem każdego procesu.
Zbuduj standard opisów narzędzi: cel, parametry, skutki, ograniczenia.
Ustal politykę zatwierdzania człowieka dla operacji nieodwracalnych.
Włącz monitorowanie kosztów na poziomie zadania, nie tylko na poziomie konta.
Zaplanuj okresowy przegląd uprawnień agentów, podobnie jak przegląd uprawnień ludzkich.
Utrzymuj własny zestaw testów porównawczych dla modeli, niezależny od deklaracji dostawców.

Checklista praktyczna

☐ Mam listę workflows kwalifikujących się jako narzędzia.
☐ Każdy workflow ma określony skutek i właściciela.
☐ Workflow ma walidację wejścia w pierwszym stanie.
☐ Workflow jest idempotentny.
☐ Tożsamość użytkownika i tenanta jest ustalana po stronie systemu.
☐ Agent ma minimalne uprawnienia.
☐ Operacje nieodwracalne wymagają zatwierdzenia człowieka.
☐ Opisy narzędzi są precyzyjne i aktualne.
☐ Mam logi i ślad audytowy uruchomień.
☐ Mam alerty na nietypowe wzorce wywołań.
☐ Zmierzyłem koszt tokenów na własnych zadaniach.
☐ Wiem, że wyniki wydajności modelu to deklaracja producenta, nie niezależny test.

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy powinien przede wszystkim ustalić granicę odpowiedzialności: które decyzje podejmuje model, a które wynikają z procesu. To decyzja biznesowa, nie techniczna. Jeśli proces ma skutki finansowe lub regulacyjne, kolejność kroków musi być zapisana w workflow, a nie pozostawiona modelowi.

Administrator powinien zadbać o trzy elementy: kontrolę wejścia, tożsamość ustalaną po stronie systemu oraz idempotencję. Bez nich wystawienie workflow agentowi jest ryzykowne niezależnie od jakości modelu. Dodatkowo administrator powinien zweryfikować, czy Region obsługuje AgentCore Gateway, i oszacować koszt tokenów na podstawie własnych pomiarów, a nie cennika.

Niższa cena tokenów nie jest tym samym co niższy koszt zadania. Decyzję o modelu podejmuj po pomiarze na własnym obciążeniu.

Na koniec: nie traktuj deklaracji OpenAI o wydajności Terra jako potwierdzonego faktu. AWS potwierdza dostępność i model rozliczeń. Liczby dotyczące jakości i szybkości pochodzą od producenta modelu i wymagają własnej weryfikacji, zanim wpłyną na decyzję architektoniczną.

Weryfikacja praktyczna przed wdrożeniem: jak testować workflow wystawiony jako narzędzie agenta

Weryfikacja praktyczna nie polega na sprawdzeniu, czy agent „potrafi” wywołać workflow. Polega na sprawdzeniu, czy workflow zachowuje się poprawnie niezależnie od tego, co model postanowi przekazać. Testujesz więc nie model, a granicę między modelem a definicją workflow. Poniższe sekcje porządkują tę granicę w formie ćwiczeń do wykonania na środowisku nieprodukcyjnym.

Test 1: walidacja wejścia w pierwszym stanie

Celem jest potwierdzenie, że workflow odrzuca parametry spoza dozwolonego zakresu, zanim wykona jakikolwiek krok o skutkach. Wykonaj serię wywołań z wartościami granicznymi i błędnymi.

Przygotuj listę parametrów przyjmowanych przez workflow i dla każdego określ dozwolony zakres, format oraz wartości graniczne.
Wywołaj workflow z wartością poprawną, aby potwierdzić, że ścieżka pozytywna działa.
Wywołaj z wartością poniżej i powyżej zakresu. Oczekiwany wynik: odrzucenie w pierwszym stanie, bez przejścia do kolejnych kroków.
Wywołaj z wartością o błędnym formacie (np. tekst tam, gdzie oczekiwana liczba). Oczekiwany wynik: odrzucenie.
Wywołaj z brakującym parametrem wymaganym. Oczekiwany wynik: odrzucenie z czytelnym komunikatem.
Sprawdź w logach, że odrzucenie nastąpiło przed wykonaniem jakiejkolwiek operacji zapisu.

Jeśli którykolwiek test błędnego wejścia kończy się wykonaniem kroku zapisu, wstrzymaj wystawienie workflow agentowi. Walidacja w pierwszym stanie jest warunkiem koniecznym, nie opcją.

Test 2: idempotencja przy ponowieniu

Ponowienie po timeoucie to typowy scenariusz w systemach rozproszonych, a agent może ponowić wywołanie bez wiedzy, że pierwsze się powiodło. Test polega na wymuszeniu dwóch wywołań z tym samym kluczem idempotencji powiązanym z intencją operacji.

Wywołaj workflow z kluczem idempotencji i zapisz wynik oraz identyfikator uruchomienia.
Wywołaj ponownie z tym samym kluczem. Oczekiwany wynik: brak drugiego wykonania operacji, zwrot informacji o istniejącym uruchomieniu.
Wywołaj z innym kluczem idempotencji dla tej samej intencji. Oczekiwany wynik: nowe uruchomienie, co potwierdza, że klucz jest powiązany z intencją, a nie z identyfikatorem wywołania.
Sprawdź, czy przed ponownym wywołaniem system sprawdza stan uruchomienia.

Klucz idempotencji powiązany z identyfikatorem wywołania nie chroni przed podwójnym wykonaniem, ponieważ każde ponowienie ma nowy identyfikator. To najczęstszy błąd w tym obszarze.

Test 3: tożsamość ustalana po stronie systemu

Sprawdź, czy tożsamość użytkownika i tenanta jest ustalana przez system, a nie przekazywana jako parametr, który model mógłby nadpisać.

Wywołaj workflow w kontekście użytkownika A i potwierdź, że operacja została wykonana w jego imieniu.
Spróbuj przekazać w parametrach identyfikator użytkownika B. Oczekiwany wynik: parametr jest ignorowany lub wywołanie jest odrzucane.
Powtórz próbę dla identyfikatora tenanta. Oczekiwany wynik: brak możliwości nadpisania.
Sprawdź w śladzie audytowym, że zapisano, kto i na jakiej podstawie uruchomił workflow.

Jeśli tożsamość da się ustawić parametrem, agent może zostać nakłoniony do działania w imieniu innego użytkownika. To ryzyko nie znika wraz z jakością modelu.

Test 4: uprawnienia i rozdzielenie odczytu od zapisu

Zweryfikuj, że agent ma minimalny zakres uprawnień i że narzędzia odczytu są oddzielone od narzędzi zapisu, jeśli to możliwe.

Wylistuj workflows wystawione agentowi i przypisz każdemu skutek: odczyt, zapis odwracalny, zapis nieodwracalny.
Sprawdź, czy agent nie ma dostępu do workflow spoza zatwierdzonego katalogu.
Potwierdź, że operacje nieodwracalne wymagają zatwierdzenia człowieka i że zatwierdzenie jest częścią definicji workflow, a nie instrukcją w prompcie.
Sprawdź, czy uprawnienia agenta są węższe niż uprawnienia człowieka, który go uruchamia, gdy skutki są nieodwracalne.

Test 5: odporność na treść dokumentu i wiadomości

Prompt injection to scenariusz, w którym treść dokumentu lub wiadomości skłania agenta do wywołania narzędzia. Test polega na przygotowaniu dokumentów zawierających instrukcje sprzeczne z intencją użytkownika.

Przygotuj dokument z treścią sugerującą wywołanie operacji zapisu.
Uruchom agenta z zadaniem, które nie wymaga operacji zapisu.
Oczekiwany wynik: agent nie wywołuje operacji zapisu, a jeśli próbuje, workflow odrzuca wywołanie z powodu braku zatwierdzenia lub walidacji kontekstu.
Powtórz dla wiadomości przychodzącej, jeśli workflow jest wywoływany w kontekście obsługi zgłoszeń.

Monitoring po wdrożeniu: co obserwować i na co ustawić alerty

Po wdrożeniu monitoring przestaje dotyczyć poprawności definicji, a zaczyna dotyczyć wzorców wywołań. Agent działa w sposób, którego nie da się w pełni przewidzieć, więc obserwujesz odchylenia od ustalonej normy. Poniższe metryki wynikają wprost z ryzyk opisanych wcześniej.

Metryki wywołań

Liczba uruchomień workflow w jednostce czasu, z podziałem na workflow i na użytkownika. Nagły wzrost liczby uruchomień to sygnał do sprawdzenia.
Odsetek odrzuceń walidacji wejścia. Powtarzające się błędy walidacji oznaczają, że model przekazuje niepoprawne parametry.
Liczba wywołań z nieoczekiwanymi parametrami, czyli wartościami spoza wcześniej zaobserwowanego rozkładu.
Liczba ponowień i przypadków, w których klucz idempotencji zapobiegł podwójnemu wykonaniu.
Liczba operacji nieodwracalnych oczekujących na zatwierdzenie człowieka oraz czas oczekiwania.

Metryki kosztu

Koszt tokenów mierz na poziomie zadania, nie tylko na poziomie konta. Niższa cena tokenów nie oznacza niższego kosztu zadania, jeśli model zużywa więcej tokenów lub wymaga więcej prób. Obserwuj:

zużycie tokenów na zadanie, z podziałem na wejście i wyjście,
liczbę prób potrzebnych do ukończenia zadania,
koszt odkrywania narzędzi, czyli tokeny zużywane na wyszukiwanie narzędzi po opisie zadania,
odsetek zadań, w których agent wybrał niewłaściwe narzędzie i musiał ponowić.

Progi alertów do ustalenia

Ustaw alert na wzrost liczby uruchomień danego workflow powyżej ustalonego progu w krótkim oknie czasu.
Ustaw alert na wzrost odsetka odrzuceń walidacji powyżej progu, który ustalisz na podstawie pierwszych tygodni pracy.
Ustaw alert na każde wywołanie operacji nieodwracalnej bez zatwierdzenia człowieka. To zdarzenie powinno być traktowane jako incydent, nie jako metryka trendu.
Ustaw alert na koszt zadania przekraczający ustalony budżet jednostkowy.
Ustaw alert na wywołania z parametrami spoza dozwolonego zakresu, które przeszły walidację. To może oznaczać lukę w walidacji.

Ślad audytowy

Utrzymuj logi pozwalające odtworzyć, kto i na jakiej podstawie uruchomił dany workflow. Ślad powinien obejmować identyfikator uruchomienia, tożsamość ustaloną po stronie systemu, parametry wejściowe, wynik walidacji, numer próby oraz informację o zatwierdzeniu, jeśli było wymagane. Bez tego śladu nie odtworzysz przyczyny incydentu ani nie odpowiesz na pytanie, czy operacja została wykonana zgodnie z definicją workflow.

Checklista weryfikacji przed wystawieniem kolejnego workflow

Traktuj tę listę jako bramkę jakościową stosowaną do każdego kolejnego workflow, a nie jednorazowy dokument. Wypełnij ją przed dodaniem workflow do katalogu narzędzi agenta.

Definicja i klasyfikacja

☐ Workflow ma określony skutek: odczyt, zapis odwracalny lub zapis nieodwracalny.
☐ Workflow ma wskazanego właściciela procesu.
☐ Kolejność kroków jest zapisana w definicji workflow, a nie w instrukcji dla modelu.
☐ Opis narzędzia jest precyzyjny co do skutków i parametrów, bez ogólników zachęcających do nadużycia.

Kontrola wejścia i tożsamość

☐ Pierwszy stan workflow zawiera walidację parametrów: dozwolone wartości, zakresy, formaty.
☐ Wszystkie testy błędnego wejścia kończą się odrzuceniem przed wykonaniem kroku zapisu.
☐ Tożsamość użytkownika i tenanta jest ustalana po stronie systemu.
☐ Próba nadpisania tożsamości parametrem kończy się ignorowaniem parametru lub odrzuceniem wywołania.

Idempotencja i uprawnienia

☐ Workflow jest idempotentny przy ponownym wywołaniu z tym samym kluczem powiązanym z intencją operacji.
☐ System sprawdza stan uruchomienia przed ponownym wywołaniem.
☐ Agent ma minimalny zakres uprawnień, węższy niż pełny katalog workflows.
☐ Narzędzia odczytu są oddzielone od narzędzi zapisu, jeśli to możliwe.
☐ Operacje nieodwracalne wymagają zatwierdzenia człowieka zapisanego w definicji workflow.

Testy i monitoring

☐ Workflow przeszedł testy na środowisku nieprodukcyjnym, w tym przypadki błędnych parametrów i próby wywołania spoza dozwolonego kontekstu.
☐ Workflow przeszedł test odporności na treść dokumentu lub wiadomości sugerującą operację zapisu.
☐ Ustawiono alerty na nietypowe wzorce wywołań: wzrost liczby uruchomień, powtarzające się błędy walidacji, wywołania z nieoczekiwanymi parametrami.
☐ Ustawiono alert na operację nieodwracalną bez zatwierdzenia człowieka.
☐ Koszt tokenów na zadanie został zmierzony na reprezentatywnych zadaniach.
☐ Ślad audytowy pozwala odtworzyć, kto i na jakiej podstawie uruchomił workflow.

Warunki wstrzymania

Wstrzymaj wystawienie workflow, jeśli którykolwiek z poniższych warunków jest spełniony:

Test błędnego wejścia kończy się wykonaniem kroku zapisu.
Tożsamość użytkownika lub tenanta można nadpisać parametrem.
Ponowienie z tym samym kluczem idempotencji powoduje drugie wykonanie operacji.
Operacja nieodwracalna nie wymaga zatwierdzenia człowieka w definicji workflow.
Brak śladu audytowego pozwalającego odtworzyć przebieg uruchomienia.

Przegląd po pierwszym okresie eksploatacji

Po ustalonym okresie od wdrożenia przeprowadź przegląd, który nie powtarza testów wstępnych, ale sprawdza, czy założenia z wdrożenia nadal obowiązują.

Porównaj zaobserwowany rozkład parametrów z założonym zakresem walidacji. Jeśli model regularnie przekazuje wartości spoza zakresu, sprawdź, czy opis narzędzia jest wystarczająco precyzyjny.
Sprawdź, czy nie pojawiły się nowe workflows w katalogu narzędzi bez przejścia przez checklistę.
Zweryfikuj, czy uprawnienia agenta nie zostały rozszerzone okazjonalnie, bez przeglądu.
Porównaj zmierzony koszt zadania z wcześniejszymi pomiarami. Wzrost może oznaczać zmianę wzorca wywołań lub rozrost katalogu narzędzi.
Sprawdź aktualność opisów narzędzi. Opis niezgodny ze skutkami zachęca do nadużycia.
Potwierdź, że Region nadal obsługuje AgentCore Gateway i że nie zmieniono konfiguracji bez odnotowania.

Przegląd uprawnień agentów zaplanuj okresowo, podobnie jak przegląd uprawnień ludzkich. Utrzymuj też własny zestaw testów porównawczych dla modeli, niezależny od deklaracji dostawców, aby decyzje o zmianie modelu opierały się na pomiarze własnego obciążenia, a nie na cenniku ani na deklaracjach producenta.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

AWS Weekly Roundup: GPT-6.1 Terra on Bedrock, Step Functions as agent tools, and more (November 2, 2026) | Amazon Web Services (aws.amazon.com)

Zdjęcie wyróżniające: Vito Goričan / Pexels.

Step Functions jako narzędzia agentów AI: co zmienia AgentCore Gateway dla polskich zespołów DevOps