Agent Native Cloud: chmura projektowana pod agentów AI

Na konferencji WAIC 2026 w Szanghaju Alibaba Cloud przedstawiło Agent Native Cloud — architekturę chmurową projektowaną od podstaw pod uruchamianie agentów AI. Ogłoszenie z 18 lipca obejmuje AgentTeams (orkiestracja wielu wyspecjalizowanych agentów), Agentic Computer (bezpieczne wykonywanie w chmurze) oraz przeprojektowaną infrastrukturę z natywnymi sandboxami, silną izolacją obciążeń, elastycznym skalowaniem i integracją z firmową tożsamością.

Dla osób zajmujących się bezpieczeństwem to ogłoszenie jest ciekawsze, niż wygląda na pierwszy rzut oka — i to niezależnie od tego, czy kiedykolwiek użyjesz produktu Alibaby. Powód jest prosty: lista komponentów tej platformy to w praktyce lista problemów, których nie rozwiązuje dzisiejsza infrastruktura, gdy uruchamiasz na niej agentów. Warto ją przeczytać jak diagnozę, a nie jak materiał marketingowy.

Co dokładnie ogłoszono

Kluczowe elementy zapowiedzi:

Komponent	Funkcja
AgentTeams	orkiestracja i nadzór nad wieloma wyspecjalizowanymi agentami
Agentic Computer	bezpieczne środowisko wykonawcze w chmurze
AgentLoop	rozszerzenie istniejącej platformy AgentRun
Infrastruktura	natywne sandboxy, izolacja obciążeń, elastyczne skalowanie
Tożsamość	integracja z firmowymi systemami tożsamości

Alibaba pokazała też wyniki wewnętrzne: 15 skoordynowanych agentów obsługuje 85% zgłoszeń wsparcia dla programistów, redukując czas obsługi operacyjnej o 90% i skracając cykl wydawniczy do jednego dnia.

Do tych liczb warto podejść z rezerwą — pochodzą od producenta, dotyczą jego własnego środowiska i nie zostały niezależnie zweryfikowane. Jako kierunkowy sygnał o dojrzewaniu wdrożeń agentowych są jednak wiarygodne; jako obietnica wyniku w Twojej organizacji — nie.

Dlaczego „chmura pod agentów” to nie marketing

Uruchomienie agenta AI na klasycznej infrastrukturze przypomina uruchamianie aplikacji webowej na serwerze zaprojektowanym pod obliczenia wsadowe: zadziała, ale wszystkie założenia będą lekko nie te. Cztery różnice mają znaczenie praktyczne.

1. Agent wykonuje nieprzewidywalny kod

Klasyczna aplikacja robi to, co zaprogramował programista. Agent generuje i uruchamia działania w czasie pracy: wywołuje narzędzia, wykonuje polecenia, pisze i odpala kod. Z perspektywy bezpieczeństwa oznacza to, że nie da się z góry wyliczyć zbioru operacji, jakie wykona.

Klasyczny model bezpieczeństwa aplikacji zakłada znany zakres działań i zabezpiecza jego granice. Przy agencie to założenie upada — stąd nacisk na sandboxy jako element natywny, a nie dokładany później.

2. Uprawnienia są dynamiczne i szerokie

Aplikacja ma zwykle wąsko określony zestaw uprawnień: konkretna baza, konkretna kolejka, konkretne API. Agent, żeby być użyteczny, dostaje szeroki dostęp — do dokumentów, systemów wewnętrznych, integracji. To odwrócenie zasady minimalnych uprawnień, wymuszone przez sam charakter zadania.

Dlatego pojawia się integracja z firmową tożsamością. Agent nie powinien działać na współdzielonym kluczu API, lecz mieć własną tożsamość, cykl życia i możliwość odebrania uprawnień — dokładnie to, o czym pisaliśmy przy tożsamościach nieludzkich (NHI).

3. Wiele agentów to nowa powierzchnia ataku

AgentTeams adresuje orkiestrację wielu agentów. Z perspektywy bezpieczeństwa każdy dodatkowy agent to nie tylko kolejna tożsamość, ale też kolejny kanał wpływu: agenci przekazują sobie zadania i wyniki, a wynik jednego staje się wejściem drugiego.

To otwiera scenariusz, który warto nazwać wprost: wstrzyknięcie instrukcji propagujące się między agentami. Agent A przetwarza dokument z zewnątrz, w którym ukryto instrukcję; jego wynik trafia do agenta B, który ma szersze uprawnienia. Klasyczna granica zaufania („dane z zewnątrz są niezaufane”) rozmywa się, bo dla agenta B wejście pochodzi od zaufanego agenta A. Mechanikę tej klasy ataków opisujemy w przewodniku po prompt injection.

4. Skalowanie jest nieregularne i kosztowne

Agent potrafi w jednej sesji nie zrobić nic, a w następnej uruchomić kilkadziesiąt równoległych wywołań narzędzi. Stąd nacisk na elastyczne skalowanie — ale z tego wynika też realne ryzyko: koszt jako wektor ataku. Agent w pętli, wywołany złośliwym wejściem, potrafi wygenerować rachunek, zanim ktokolwiek zauważy. Limity budżetowe i twarde ograniczenia liczby wywołań to element bezpieczeństwa, nie tylko FinOps.

Sandbox dla agenta — co to naprawdę znaczy

Słowo „sandbox” jest nadużywane, więc warto sprecyzować, czego wymagamy od środowiska uruchomieniowego agenta. Ta lista jest uniwersalna — obowiązuje niezależnie od dostawcy.

Izolacja wykonania. Agent nie powinien mieć dostępu do warstwy zarządzania środowiskiem, w którym działa. Praktycznie: brak dostępu do gniazda demona kontenerowego, brak trybu uprzywilejowanego, ograniczone możliwości jądra (seccomp, capabilities). Dlaczego to nie jest przesada, pokazał przypadek modelu, który zaatakował własne środowisko testowe, próbując eskalować uprawnienia wobec demona kontenerowego po odcięciu sieci.

Kontrola ruchu wychodzącego. Domyślne „agent może łączyć się z internetem” to prosta droga do eksfiltracji. Egress powinien być domyślnie zablokowany i otwierany wyłącznie do wskazanych celów. Bez tego każde wstrzyknięcie instrukcji może zakończyć się wysłaniem danych na zewnątrz.

Efemeryczność. Środowisko powinno być tworzone na czas zadania i niszczone po jego zakończeniu. Trwały kontener agenta to trwały punkt zaczepienia dla napastnika.

Systemy plików tylko do odczytu tam, gdzie to możliwe, z wąsko określonymi katalogami zapisu.

Pełne logowanie akcji. Nie tylko wynik, ale każde wywołanie narzędzia, każde polecenie, każdy dostęp do pliku. Bez tego nie odpowiesz na pytanie „co ten agent właściwie zrobił” — a to pierwsze pytanie każdego incydentu.

Limity zasobów i budżetu. Czas wykonania, liczba wywołań, koszt. Ograniczenie, które przy okazji chroni przed pętlą wywołaną błędem lub manipulacją.

Techniczne tło izolacji rozwijamy w tekstach o ucieczkach z kontenerów i bezpieczeństwie Kubernetes — bo w praktyce sandbox dla agenta buduje się z tych samych klocków.

Czego ta zapowiedź nie rozwiązuje

Uczciwie: żadna platforma nie rozwiązuje problemów, które leżą po stronie projektu wdrożenia.

Nie rozwiązuje prompt injection. Izolacja ogranicza skutki udanej manipulacji, ale nie zapobiega samej manipulacji. Jeśli agent ma legalny dostęp do danych i legalne narzędzie do ich wysłania, wstrzyknięta instrukcja użyje tych uprawnień w sposób nieodróżnialny od normalnej pracy.

Nie rozwiązuje nadmiarowych uprawnień. Platforma dostarcza mechanizm, ale zakres nadaje wdrażający. Agent z dostępem do całego dysku firmowego pozostaje ryzykiem niezależnie od jakości sandboxa.

Nie rozwiązuje problemu weryfikacji wyników. Sandbox nie sprawdza, czy agent wykonał zadanie poprawnie. To odrębna warstwa — testy, ewaluacja, kontrola jakości — o której piszemy przy ewaluacji LLM.

Nie usuwa pytań o lokalizację i suwerenność danych. Gdzie fizycznie przetwarzane są dane, kto ma do nich dostęp, jakie obowiązują warunki umowne — to pozostaje decyzją Twoją, nie dostawcy. Przy dostawcach spoza UE dochodzi wymiar regulacyjny, który trzeba rozstrzygnąć przed wdrożeniem, a nie po.

Praktyczna lista kontrolna wdrożenia agentowego

Niezależnie od wybranej platformy, ten zestaw pytań warto przejść przed uruchomieniem produkcyjnym:

Tożsamość i uprawnienia

Czy każdy agent ma własną tożsamość, czy współdzielą klucz?
Jaki jest dokładny zakres uprawnień i kto go zatwierdził?
Czy potrafisz odebrać uprawnienia jednemu agentowi w minutę?
Czy istnieje przegląd okresowy uprawnień agentów?

Izolacja

Czy agent może dosięgnąć warstwy zarządzania środowiskiem?
Czy ruch wychodzący jest ograniczony do listy dozwolonych celów?
Czy środowisko jest niszczone po zadaniu?

Widoczność

Czy logujesz każde wywołanie narzędzia, nie tylko wynik końcowy?
Czy potrafisz odtworzyć pełną sekwencję działań z zeszłego tygodnia?
Czy masz alarmy na nietypowe wzorce (nagły wzrost wywołań, dostęp do nowych zasobów)?

Granice zaufania

Które dane wejściowe pochodzą z zewnątrz i są traktowane jako niezaufane?
Czy wynik jednego agenta trafia do drugiego bez filtrowania?
Czy operacje wysokiego ryzyka wymagają zatwierdzenia przez człowieka?

Reakcja

Kto może natychmiast zatrzymać agenta?
Jak odbierasz mu poświadczenia i zgody integracji?
Jak ustalasz zakres tego, do czego zdążył sięgnąć?

Ostatni blok to w praktyce plan reagowania na incydenty z udziałem AI, a całość dobrze weryfikuje się harnessem do red teamingu agentów.

Szerszy kontekst: infrastruktura dogania praktykę

Ta zapowiedź wpisuje się w wyraźny trend: rynek buduje warstwę operacyjną dla agentów, bo wdrożenia wyszły z fazy demonstracji. Widać to również po tym, jak zmienia się warstwa sprzętowa — pisaliśmy o wyścigu na dedykowane układy do inferencji i o spadku kosztu tokena.

Kolejność jest tu znajoma z historii IT: najpierw pojawia się technologia, potem masowe wdrożenia, potem — zwykle po serii bolesnych incydentów — warstwa bezpieczeństwa i zarządzania. Tak było z wirtualizacją, chmurą i konteneryzacją. Przy agentach jesteśmy dokładnie na etapie „infrastruktura dogania praktykę”, a incydenty pokazujące, dlaczego jest potrzebna, już mamy: AgentForger i ransomware prowadzony przez agenta.

Dla organizacji wdrażających agentów praktyczny wniosek brzmi: nie czekaj na gotową platformę. Wymienione wyżej kontrole — tożsamość, izolacja, egress, logowanie, limity — da się wdrożyć na istniejącej infrastrukturze. Platforma je upraszcza; ich brak jest ryzykiem niezależnie od tego, czyj produkt wybierzesz.

Dlaczego orkiestracja wielu agentów wymaga osobnego przemyślenia

Warto rozwinąć wątek, który w zapowiedziach platform agentowych pojawia się jako funkcja, a w praktyce jest najtrudniejszym problemem bezpieczeństwa: co się dzieje, gdy agenci rozmawiają ze sobą.

Zanika pojedyncza granica zaufania. W klasycznej aplikacji da się wskazać miejsce, w którym dane niezaufane wchodzą do systemu, i tam umieścić walidację. W układzie wieloagentowym dane przechodzą przez łańcuch: agent A pobiera dokument z zewnątrz, streszcza go, przekazuje agentowi B, ten na tej podstawie podejmuje działanie. Dla agenta B źródłem jest zaufany komponent wewnętrzny — mimo że treść pochodzi z zewnątrz. Walidacja na wejściu systemu nie chroni kolejnych ogniw.

Kumulują się uprawnienia. Każdy agent z osobna może mieć wąski zakres, ale zestaw agentów współpracujących tworzy ścieżkę o uprawnieniach będących sumą części. Agent czytający pocztę i agent wysyłający pliki to osobno dwie akceptowalne role; połączone przepływem — gotowy kanał eksfiltracji.

Trudniej ustalić odpowiedzialność. Gdy działanie wykonał agent B na podstawie wyniku agenta A, który przetworzył dokument dostarczony przez użytkownika, odpowiedź na pytanie „dlaczego system to zrobił” wymaga pełnego łańcucha zdarzeń. Bez logowania każdego kroku rekonstrukcja jest niemożliwa.

Praktyczne wnioski są trzy. Po pierwsze, traktuj wyjście każdego agenta jak dane niezaufane dla kolejnego, zwłaszcza gdy gdziekolwiek w łańcuchu pojawia się treść z zewnątrz. Po drugie, operacje nieodwracalne (wysłanie wiadomości, płatność, usunięcie danych, zmiana uprawnień) powinny wymagać zatwierdzenia przez człowieka albo osobnego, wąsko uprawnionego komponentu — nie decyzji agenta w łańcuchu. Po trzecie, projektuj przepływy tak, by suma uprawnień ścieżki była jawna: jeśli nikt nie potrafi jej narysować, nikt nie zarządza ryzykiem.

Najczęstsze pytania (FAQ)

Czy to oznacza, że dotychczasowa chmura nie nadaje się do agentów? Nadaje się, ale wymaga świadomej konfiguracji. Wszystko, co opisano jako „natywne” w tej platformie — sandboxy, izolacja, tożsamość, limity — da się zbudować samodzielnie z istniejących komponentów. Różnica dotyczy nakładu pracy i tego, jak łatwo o pominięcie kontroli, gdy nie jest domyślna.

Czy powinniśmy rozważyć tego dostawcę? To decyzja biznesowa i regulacyjna, nie tylko techniczna. Dla organizacji z UE kluczowe będą pytania o lokalizację przetwarzania, warunki umowne i zgodność — rozstrzygnij je przed oceną funkcji. Warto natomiast potraktować listę komponentów jako wzorzec wymagań, które postawisz dowolnemu dostawcy.

Czy sandbox wystarczy, żeby bezpiecznie uruchamiać agentów? Nie. Sandbox ogranicza skutki, ale nie zastępuje minimalnych uprawnień, kontroli egressu, logowania i weryfikacji wyników. Agent w doskonałym sandboxie, ale z dostępem do wszystkich firmowych dokumentów i możliwością wysyłania maili, pozostaje poważnym ryzykiem.

Co z wynikami typu „15 agentów obsługuje 85% zgłoszeń”? Traktuj je jako sygnał kierunkowy, nie benchmark. To dane producenta z jego własnego środowiska, bez niezależnej weryfikacji i bez opisu metodyki. Przed wdrożeniem policz własny przypadek na reprezentatywnej próbce zadań.

Od czego zacząć, jeśli dopiero wdrażamy agentów? Od trzech rzeczy: nadaj każdemu agentowi osobną tożsamość, domyślnie zablokuj ruch wychodzący i loguj każde wywołanie narzędzia. To fundament, na którym da się dobudować resztę — i to, czego brak najczęściej boli podczas pierwszego incydentu. Jeśli chcesz przejść przez to metodycznie, robimy to w ramach audytu bezpieczeństwa AI/LLM.

Podsumowanie

Agent Native Cloud jest wart uwagi nie jako produkt konkretnego dostawcy, lecz jako spis wymagań, które wdrożenia agentowe stawiają infrastrukturze: natywne sandboxy, silna izolacja obciążeń, tożsamość dla agentów, orkiestracja wielu agentów i elastyczne skalowanie. Czytany w ten sposób, jest użyteczny niezależnie od tego, czyją chmurę wybierzesz.

Kluczowe zastrzeżenie pozostaje niezmienne: platforma ogranicza skutki, ale nie zastępuje projektu bezpieczeństwa. Prompt injection, nadmiarowe uprawnienia i brak weryfikacji wyników to problemy po stronie wdrażającego. Najlepszy sandbox nie pomoże agentowi, któremu daliśmy dostęp do wszystkiego i którego nikt nie kontroluje. Jeśli wdrażasz agentów i chcesz mieć pewność, że kontrole nadążają za zakresem — sprawdźmy to razem.

Źródła i dalsza lektura: Alibaba Cloud — WAIC 2026, Alibaba Group, OWASP Top 10 for LLM Applications, NIST AI Risk Management Framework.