Od kopilota do kolegi: co oznacza autonomiczne działanie AI

Analiza oparta na badaniach dotycząca przejścia od silników sugestii do autonomicznych współpracowników. Dlaczego to dzieje się teraz, co się psuje w trakcie tej zmiany i jak wdrażać AI bez oddawania pełnej kontroli.

Era kopilotów osiąga szczyt

15 kwietnia 2026 Sam Altman ogłosił na X, że OpenAI wdraża „aktualizacje Codex w tym tygodniu, skupione na zespołach i dużych firmach”.

Odpowiedzi były wymowne. Na każdego dewelopera pytającego o roadmapę przypadał inny, zadający trudniejsze pytanie: dlaczego Codex nadal wymaga mojego nadzoru? Sześć miesięcy wcześniej badacze BeyondTrust opublikowali proof-of-concept pokazujący, że specjalnie spreparowana nazwa gałęzi Git może nakłonić Codex do wykradzenia tokena GitHub użytkownika. Kopilot, którego można oszukać, by wyciekł token przez nazwę gałęzi, nie jest kolegą. To naładowana broń z zabezpieczeniem.

To napięcie towarzyszy każdej rozmowie o AI w przedsiębiorstwach w 2026. Kopiloty osiągnęły swój sufit, a liczby to potwierdzają:

Inicjatywa NANDA MIT poinformowała w 2025, że 95% pilotaży generatywnego AI nie przynosi wymiernych korzyści biznesowych.
Badanie RAND wielokrotnie cytowane na Reddicie r/ArtificialIntelligence na początku 2026 wykazało, że 80 do 90% projektów agentów AI kończy się niepowodzeniem w środowiskach produkcyjnych.
Wskaźniki akceptacji GitHub Copilot przez deweloperów ustabilizowały się na poziomie 35 do 40%, podczas gdy Cursor osiąga 42 do 45%, a Claude Code zdobył ocenę 46% „najbardziej lubiany” w ankiecie 2026 AI coding. To zaskakująca zmiana dla narzędzia, które wystartowało dopiero w maju 2025.
Satya Nadella miał nazwać wewnętrzne wdrożenie Copilot w Microsoft „prawie nieużywalnym” pod koniec 2025, a firma ogłosiła tzw. „reset wysokiej stawki” produktu.
Badanie arXiv opublikowane pod koniec 2025 wykazało, że autouzupełnianie w stylu Copilot zwiększało frustrację wśród doświadczonych deweloperów, ponieważ przerywało ich pracę sugestiami, które były wiarygodne, ale subtelnie błędne.

Ten zastój nie wynika z błędów modeli. To porażka wzorca interakcji. Kopilot działa na poziomie pojedynczego naciśnięcia klawisza lub pytania. Kolega działa na poziomie całego workflow. Bits&Chips dobrze to ujęło w eseju z kwietnia 2026 „Od kopilota do kolegi”: „Kopilot działa na poziomie pojedynczej interakcji, podczas gdy agent działa na poziomie workflow. To ważne, bo w większości organizacji wąskim gardłem nie jest pojedyncze zadanie, lecz koordynacja między zadaniami.”

To właśnie tę zmianę próbują dziś wdrażać przedsiębiorstwa. Nierówno, nieidealnie, ale na znaczną skalę.

Spektrum autonomii

„Agent” stał się słowem marketingowym, więc przejdźmy do konkretów. Istnieją cztery wyraźne poziomy autonomii AI i większość rozczarowań w 2025 i 2026 wynikała z mylenia jednego z drugim.

Poziom 1: kopilot

Sugestie. Prosi o zgodę. Pozostaje na ekranie. Autouzupełnianie GitHub Copilot to archetyp. Wartość mierzona w zaoszczędzonych naciśnięciach klawiszy.

Poziom 2: asystent

Odpowiada na pytania i tworzy artefakty na żądanie. ChatGPT, Claude w przeglądarce, panel czatu Microsoft 365 Copilot. Wartość mierzona jakością szkicu i syntezą kontekstu.

Poziom 3: agent

Przyjmuje cel, planuje sekwencję kroków, wykonuje je w różnych narzędziach, raportuje wyniki. Claude Code skanujący repozytorium i otwierający PR. Deep Research ChatGPT wykonujący 20 minut wyszukiwań i zwracający raport z cytowaniami. Anthropic udokumentował przypadek, gdy instancja Claude wykonała 7-godzinne autonomiczne zadanie inżynieryjne dla Rakuten. Wartość mierzona liczbą ukończonych workflow na godzinę pracy człowieka.

Poziom 4: kolega

Agent działający w ramach istniejącego modelu uprawnień, uczestniczący w kanałach komunikacji zespołu, utrzymujący kontekst przez dni i tygodnie, rozliczany według tego samego śladu audytu co pracownik. To jest granica możliwości.

Społeczność r/ChatGPT na Reddicie zaproponowała praktyczny test rozróżniający te poziomy, sparafrazowany: czy to coś wykazuje inicjatywę, czy czeka na każdą instrukcję? Czy radzi sobie z nieoczekiwanymi sytuacjami, czy się zawiesza i wymaga ponownego promptowania? Czy pamięta kontekst w zadaniu wieloetapowym, czy musisz się powtarzać? Większość produktów reklamowanych jako „agenci AI” w 2025 nie zdała żadnego z tych pytań. Te, które zdały, to właśnie to, co dziś rozumiemy przez „kolegę”.

Użycie komputera vs umiejętności: dlaczego architektura ma znaczenie

AI na poziomie kolegi musi działać w świecie. Są dwa podejścia architektoniczne, niosące zupełnie różne ryzyka.

Użycie komputera

AI steruje symulowaną myszą i klawiaturą. Dosłownie widzi ekran i klika przyciski. Anthropic wdrożył Computer Use pod koniec 2024, a OpenAI Operator poszedł w jego ślady. Zaletą jest uniwersalność: każde oprogramowanie z GUI staje się dostępne.

Kosztem jest zakres szkód. Agent używający komputera dziedziczy wszystkie uprawnienia zalogowanego użytkownika. W październiku 2025 zespół bezpieczeństwa BeyondTrust pokazał, że agent Codex OpenAI może zostać oszukany przez złośliwą nazwę gałęzi Git zawierającą polecenia powłoki, by odczytać i wyeksportować GITHUB_TOKEN użytkownika. Agent robił dokładnie to, co zrobiłby człowiek (checkout gałęzi), ale nie miał intuicji, że sama nazwa gałęzi to wrogie dane wejściowe. W tym incydencie model uprawnień był wszystko albo nic. To domyślny tryb awarii przy użyciu komputera.

Umiejętności

AI wywołuje dyskretne umiejętności. Każda umiejętność to jawna, typowana funkcja z wąskim kontraktem: „wyszukaj w Slacku wiadomości pasujące do q”, „utwórz zadanie w Linear z title i body”, „odczytaj ten plik GitHub”. W przeciwieństwie do użycia komputera, umiejętność ma z góry zatwierdzony kształt. Agent może ją wywołać tylko z parametrami zgodnymi z kontraktem, a platforma może zezwolić, odmówić lub poprosić o potwierdzenie przed opuszczeniem sandboxa.

Różnica, z punktu widzenia bezpieczeństwa, sprowadza się do Zasady Najmniejszych Uprawnień. To podstawowa zasada bezpieczeństwa informacji: proces powinien mieć dostęp tylko do zasobów niezbędnych do wykonania zadania, i nic więcej. Umiejętności pozwalają egzekwować najmniejsze uprawnienia dla każdego wywołania. Użycie komputera nie.

Wdrożenie AI na poziomie kolegi używa umiejętności do działań strukturalnych (np. zapis do CRM, otwarcie zgłoszenia), a użycie komputera rezerwuje dla wąskiej grupy aplikacji bez API. Proporcja ma znaczenie. Jeśli każda akcja agenta przechodzi przez symulowaną mysz, masz demo produktywności, nie system produkcyjny.

Architektura zaufania, której naprawdę potrzebują firmy

Przejście od kopilota do kolegi to nie aktualizacja modelu, lecz infrastruktury. Trzy elementy odróżniają wdrażalnego kolegę od potencjalnej odpowiedzialności.

1. Izolacja uprawnień

Każdy agent działa w swojej własnej granicy uprawnień, z poświadczeniami, których nie może wynieść poza sandbox. Wiralny eksperyment Andreja Karpathy’ego z marca 2026 autoresearch, gdzie pozwolił agentowi prowadzić 700 eksperymentów treningowych bez nadzoru przez dwa dni, jest pouczający przez to, czego nie zrobił. Repozytorium Karpathy’ego instruuje użytkowników, by „wyłączyć wszystkie uprawnienia” w trybie autonomicznym. To akceptowalne na prywatnym laptopie badawczym. W firmie regulowanej to powód do zwolnienia.

Przeciwnym przykładem jest Moltbook, sieć społecznościowa tylko dla AI, która na krótko stała się wiralem pod koniec stycznia 2026 z 1.5 milionami autonomicznych agentów. Karpathy chwalił ją jako „najbardziej niesamowitą rzecz z pogranicza sci-fi, jaką ostatnio widziałem”. Potem badacze bezpieczeństwa z Wiz odkryli na froncie ujawniony klucz API do bazy danych, dający pełny dostęp do produkcyjnej bazy, w tym tokenów uwierzytelniających wszystkich 1.5 milionów agentów. Karpathy zmienił zdanie w ciągu 24 godzin: „To katastrofa. Zdecydowanie nie polecam uruchamiać tego na własnych komputerach.” Wniosek nie brzmi „agenci są niebezpieczni”. Wniosek jest taki, że agenci wdrożeni bez izolacji uprawnień na poziomie tożsamości tworzą wspólną strefę ryzyka.

2. Ślady audytu

Każda akcja logowana, każda decyzja możliwa do prześledzenia. Singapurskie ramy IMDA, opublikowane w Davos w styczniu 2026, kodują to w macierzy ryzyka, która mapuje przestrzeń działań agenta (odczyt vs zapis, odwracalne vs nieodwracalne) na autonomię (jak samodzielnie decyduje). Im wyżej na którejkolwiek osi, tym bogatszy wymóg audytu. Ramy te są analizowane przez regulatorów w Europie i USA, bo jako jedne z pierwszych przekładają zarządzanie z zasad abstrakcyjnych na narzędzie operacyjne.

Simon Willison równolegle argumentował za ujednoliconym logowaniem, by agenci mogli monitorować własne operacje i odzyskiwać po błędach: „Agenci z pełnym dostępem do systemu są potężni i niebezpieczni.” Praktyczna uwaga: jeśli wdrożenie agenta nie ma ujednoliconego logu czytelnego dla compliance, jesteś o jeden incydent od utraty prawa do wdrażania.

3. Zakresowy dostęp do umiejętności

Nie „dostęp do e-maila”. Dostęp do search inbox where from:@customer.com AND within last 7 days. Nowoczesne platformy agentów zmierzają do zakresów parametryzowanych, gdzie uprawnienie agenta do wywołania umiejętności ogranicza się do argumentów zatwierdzonych przez administratora, a nie do szerokiego zakresu OAuth używanego przez człowieka.

Połącz te trzy elementy i masz odpowiedź na pytanie, które zadaje każdy CISO: co zrobi agent, gdy się pomyli, i jak się o tym dowiem? Badanie McKinsey State of AI z 2026 wykazało, że 72% respondentów z firm wskazało cyberbezpieczeństwo jako obawę przy generatywnym AI, a bezpieczeństwo nazwano barierą nr 1 w skalowaniu workflow agentów przez ok. dwie trzecie respondentów. Izolacja uprawnień, ślady audytu i zakresowy dostęp do umiejętności to nie teatr zgodności. To infrastruktura brzegowa.

Dlaczego to ważne teraz: trzy siły się zbiegają

Przejście od kopilota do kolegi w 2026 nie wynika z jednego przełomu. To efekt przecięcia się trzech trendów.

Siła 1: integracja przestała być szyta na miarę

W 2024 podłączenie agenta do firmowego stosu SaaS oznaczało pisanie własnego konektora do każdego narzędzia. Na początku 2026 typowane kontrakty umiejętności i gotowe konektory zredukowały tę pracę. Agent, który w 2024 wymagał sześciu tygodni integracji, w 2026 potrzebuje popołudnia. Powierzchnia typowej firmy średniej wielkości (Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, kalendarze) jest już pokryta dojrzałymi, otwartoźródłowymi bibliotekami konektorów z typowanymi uprawnieniami.

Siła 2: multi-agent staje się rzeczywistością

Gartner uznał Systemy Multi-Agent za kluczowy trend technologiczny na 2026. Wyróżniony VP Analyst Gene Alvarez użył metafory powtarzanej dziś na każdej prezentacji AI w firmach: „Pomyśl o ekipie pit-stopu Formuły 1. Każdy członek ma wyspecjalizowaną rolę (zmieniacz opon, tankujący, operator podnośnika), ale są skoordynowani wokół jednego celu. Tak wyglądają wdrożenia agentów w firmach w 2026.” Systemy jednoagentowe napotykają ograniczenia rozumowania przy zadaniach długoterminowych. Systemy multi-agent, z wyspecjalizowanymi rolami i jawnie przekazywanymi zadaniami, pozwalają zespołom je omijać.

Siła 3: budżety firm się odblokowują

G2 podało w swoim badaniu State of Software 2026, że 57% firm ma agentów AI w produkcji (wzrost z ok. 20% rok wcześniej).
McKinsey wykazał, że 23% firm aktywnie skaluje agentowe AI, a 62% eksperymentuje. Tylko ok. 15% dużych organizacji pozostaje z boku.
Deloitte w ankiecie 2026 na 3,235 liderach firm wskazał usługi finansowe jako lidera wdrożeń, z opisanym przypadkiem agenta AI przejmującego i realizującego wyniki spotkań w pipeline’ie transakcji, co wcześniej wymagało trzech analityków.
Stanford's Enterprise AI Playbook, opublikowany na początku 2026, skatalogował 51 wdrożeń produkcyjnych, z migracją ETL w fintech jako wzorcową implementacją dla zespołów z branż regulowanych.
Zgłoszone inwestycje w infrastrukturę AI w firmach przekroczyły $600 miliardów w cyklu 2025.
Dario Amodei z Anthropic, na konferencji Code with Claude, oszacował 70 do 80% prawdopodobieństwa, że pierwsza jednoosobowa firma warta miliard powstanie w 2026 dzięki agentom AI.

Pieniądze są, protokół jest, architektura jest. W każdej sali zarządu negocjuje się teraz ile autonomii, pod jakim nadzorem i dla jakich workflow.

Argument sceptyka: co mówią Reddit, arXiv i raporty o incydentach

Odpowiedzialne spojrzenie na tę zmianę musi poważnie potraktować głosy sceptyków.

Na Reddicie konsensus na r/LocalLLaMA, r/ClaudeCode i r/ChatGPT jest pragmatyczny: agenci do kodowania już są i są użyteczni. Większość innych „agentów” to workflow automatyzacji w przebraniu chatbota. Cytowane w dziesiątkach wątków 2026 zdanie: „Używaj Copilot, gdy chcesz sugestii. Używaj Claude Code lub Cursor, gdy chcesz, by coś faktycznie zrobił” dobrze oddaje podział. Te same społeczności są bezlitosne wobec benchmarków. Nawet najlepsi agenci osiągają ok. 60% ogólnie w Terminal-Bench i spadają do 16% w trudnych zadaniach. Claude Opus 4.5 prowadzi w SWE-bench z wynikiem 80.9%, co i tak oznacza, że jedno na pięć zadań kończy się niepowodzeniem.

Sceptycyzm akademicki trudniej zignorować. Vishal Sikka (były CTO SAP, uczeń Johna McCarthy’ego) i jego współpracownik opublikowali Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models, matematycznie dowodząc, że transformatory LLM są fundamentalnie ograniczone w wykonywaniu zadań obliczeniowych i agentowych powyżej pewnego poziomu złożoności. Wniosek Sikki, „Nie mogą być niezawodne” przy zadaniach krytycznych, krąży dziś po każdym Slacku CISO. Artykuł nie twierdzi, że agenci są bezużyteczni. Twierdzi, że istnieje klasa problemów, gdzie człowiek musi pozostać w pętli, niezależnie od jakości modelu.

Prawdziwe incydenty potwierdzają sceptycyzm. Lider CX w retail cytowany w ankiecie Yellow.ai 2026: „Musieliśmy wycofać nasze AI wsparcie po dwóch tygodniach, bo zaczęło cytować błędne zasady zwrotów i wymyślać rabaty w ok. 1.35% zgłoszeń. Koszt honorowania tych błędów był większy niż planowane oszczędności.” Na dużą skalę nawet błąd poniżej 2% szybko staje się kosztowny.

Podsumowanie: AI na poziomie kolegi jest realne w kodowaniu, researchu, operacjach strukturalnych i wąskich workflow wsparcia. Nie jest jeszcze realne w otwartych interakcjach z klientem bez recenzji człowieka. Firmy czerpiące wartość w 2026 to te, które uczciwie określają, do której kategorii należy workflow.

Praktyczne konsekwencje: pięć pytań przed wdrożeniem

Jeśli Twój zespół rozważa AI jako kolegę (własny lub zewnętrzny), te pytania oddzielają wdrożenie produkcyjne od prawie-udanych prób.

Jaki jest zakres szkód najgorszej pojedynczej akcji, jaką agent może wykonać? Opisz to dosłownie. Jeśli najgorszy przypadek to „wysłanie szkicowego maila do złej osoby”, próg nadzoru jest niski. Jeśli to „modyfikacja danych produkcyjnych” lub „wysłanie instrukcji przelewu”, próg jest o rząd wielkości wyższy. Określ to przed wdrożeniem, nie po pierwszym incydencie.
Jak agent uzyskuje poświadczenia i czy może kiedykolwiek odczytać surowy token? Są trzy odpowiedzi i tylko jedna jest bezpieczna. Jeśli agent ma kopię tokena OAuth użytkownika w swoim środowisku, de facto przekazujesz LLM swój portfel. Jeśli agent ma „własną” tożsamość przez osobny OAuth konta serwisowego, musisz ją śledzić i cofać jak prawdziwego użytkownika. Trzecia odpowiedź, której naprawdę chcesz: token nigdy nie trafia do agenta. Pozostaje na platformie, zaszyfrowany, i jest wstrzykiwany na warstwie proxy sieciowej tylko na czas wywołania, które przeszło kontrolę polityki, tylko do czasu zwrotu odpowiedzi.
Czy każda akcja jest logowana w miejscu czytelnym dla compliance? Ujednolicone, przeszukiwalne, odporne na manipulacje. Jeśli odpowiedź brzmi „mamy jakieś logi w CloudWatch”, nie jesteś gotowy.
Czy możesz ograniczyć dostęp do umiejętności do konkretnych parametrów potrzebnych workflow? Dla każdego wywołania, nie dla całej integracji. Odczyt vs zapis. Po ID zasobu. Po oknie czasowym. Uprawnienia agenta powinny być prostokątem ściśle otaczającym zadanie, nie całą hurtownią.
Jaka jest procedura cofania, jeśli coś pójdzie nie tak? Jak cofnąć akcję? Jak szybko? Kto dostaje powiadomienie? Akcje nieodwracalne (przelewy, maile do klientów, wdrożenia produkcyjne) wymagają potwierdzenia lub okna opóźnienia. Odwracalne mogą działać autonomicznie.

Przeanalizuj te pięć pytań. Jeśli na wszystkie odpowiesz twierdząco, jesteś już poza erą kopilota i wchodzisz w etap, który naprawdę zmienia sposób pracy zespołu. Jeśli na dwa-trzy – tam skup się w następnej kolejności, to nie powód do zwlekania. AI na poziomie kolegi, do którego dąży Twój roadmap, już gdzieś działa w produkcji. Dzieli Cię od niego luka infrastrukturalna, nie luka w AI. A luki infrastrukturalne zamyka się szybko.

Nie musisz czekać na nowy model. Wybierz platformę, która już odpowiada na te pięć pytań i zacznij dawać agentowi prawdziwą pracę.

Najczęściej zadawane pytania

Jaka jest prawdziwa różnica między kopilotem a AI kolegą?

Kopilot sugeruje, prosi o zgodę i działa w jednym narzędziu. Kolega przyjmuje cele, planuje między systemami, działa z ograniczonymi uprawnieniami i jest rozliczany jak człowiek. Bits&Chips ujęło to jasno: kopiloty działają na poziomie interakcji, koledzy na poziomie workflow.

Jak agenci powinni obsługiwać poświadczenia użytkownika?

Żadne z oczywistych rozwiązań nie jest właściwe. Kopiowanie tokena OAuth użytkownika do środowiska agenta umieszcza żywe poświadczenie w kontekście LLM. Tworzenie osobnej tożsamości dla każdego agenta zamienia każdego agenta w podmiot, który trzeba śledzić, cofać i audytować jak człowieka. Wzorzec, który działa w praktyce, to dostęp pośredniczony: token pozostaje na platformie, zaszyfrowany; proxy sieciowe sandboxa odwołuje się do platformy w czasie żądania; platforma odszyfrowuje token i zwraca tylko nagłówki autoryzacji dla wywołań, które przeszły kontrolę polityki; agent nigdy nie widzi, nie loguje ani nie promptuje surowego tokena.

Użycie komputera czy umiejętności – co wybrać?

Domyślnie umiejętności, dla wszystkiego co ma API. Użycie komputera tylko, gdy system docelowy nie ma interfejsu programistycznego. Incydent BeyondTrust z Codex to przestroga: użycie komputera dziedziczy pełne uprawnienia użytkownika, a złośliwe dane wejściowe w polu widzenia agenta mogą stać się exploitem.

Jak bardzo autonomicznie powinniśmy pozwolić agentom działać?

Użyj dwuwymiarowego podejścia IMDA z Singapuru: przestrzeń działań × autonomia. Wąska przestrzeń działań (tylko odczyt, odwracalne) toleruje wysoką autonomię. Szeroka (zapisy, nieodwracalne, kontakt z klientem) wymaga potwierdzenia człowieka lub okna opóźnienia. Najgorsza konfiguracja to wysoka autonomia przy działaniach wysokiego ryzyka bez śladu audytu.

Jak mierzyć ROI?

Przestań liczyć zaoszczędzone naciśnięcia klawiszy. Mierz ukończone workflow na godzinę pracy człowieka, czas rozwiązania incydentu operacyjnego i wskaźnik przekazania zadania człowiekowi. Wyniki Deloitte 2026 sugerują, że liderzy śledzą trzy metryki: wskaźnik ukończenia workflow, wskaźnik błędów i wskaźnik interwencji człowieka, optymalizując ich proporcje.

Co zrobić z 95% wskaźnikiem niepowodzeń pilotaży?

Przeczytaj uważnie analizę MIT NANDA. Pilotaże, które się nie powiodły, opierały się głównie na „Dumb RAG” (wrzucanie wszystkiego do kontekstu), „Brittle Connectors” (niesprawne integracje API) i braku architektury zdarzeniowej. Udane pilotaże miały warstwę operacyjną wokół LLM: pamięć, I/O i uprawnienia. Jądro LLM nie jest wąskim gardłem. Jest nim infrastruktura wokół.

Gdzie pasuje VM0

Zero zbudowaliśmy wokół jednej architektonicznej zasady: agent nigdy nie powinien posiadać poświadczenia. Nie w środowisku, nie w promptcie, nie w pamięci. Token zostaje na platformie. Każde wywołanie wychodzące agenta przechodzi przez proxy sieciowe, które decyduje, czy wstrzyknąć nagłówek autoryzacji, czy zablokować żądanie.

To nietypowy wybór. Typowe wzorce w 2026 to albo nadanie agentowi własnej tożsamości OAuth (teraz masz drugiego użytkownika do audytu i cofania), albo przekazanie mu kopii tokena użytkownika w zmiennej środowiskowej (teraz LLM może odczytać Twój portfel). My nie robimy żadnego z tych rzeczy. Oto jak to działa w praktyce.

Token nigdy nie trafia do agenta. Gdy podłączasz konektor do Zero (GitHub, Slack, Gmail, Linear, Notion, HubSpot itd.), token OAuth jest przechowywany zaszyfrowany na platformie. Tokeny odświeżania zostają w bazie i nigdy jej nie opuszczają. W sandboxie nie ma zmiennej środowiskowej GITHUB_TOKEN do odczytu, pliku z sekretami do otwarcia ani narzędzia zwracającego token.

Proxy sieciowe pośredniczy w każdym wywołaniu. Każde żądanie HTTP wychodzące z sandboxa przechodzi przez dodatek oparty na mitmproxy. Proxy identyfikuje konektor po nazwie hosta, sprawdza politykę firewall dla agenta i sprawdza, czy metoda i ścieżka są dozwolone. Jeśli tak, proxy odwołuje się do webhooka platformy. Platforma odszyfrowuje token, odświeża go w razie potrzeby, rozwiązuje szablony nagłówków (${{ secrets.GITHUB_TOKEN }} staje się wartością rzeczywistą) i zwraca tylko gotowe nagłówki autoryzacji do proxy. Proxy wstrzykuje je do żądania wychodzącego. Po zakończeniu wywołania nagłówki znikają z pamięci proxy. Agent nigdy ich nie widział.

Uprawnienia są per-agent, per-konektor i typowane na poziomie endpointu. Każdy agent ma obiekt polityki mapujący każdy konektor na zestaw nazwanych grup uprawnień. github:repo-read to nie ogólny zakres. To pakiet konkretnych reguł metoda-ścieżka, np. GET /repos/{owner}/{repo}/pulls. Przyznanie dostępu do GitHub nie daje dostępu do całego GitHub. Daje określony kształt intencji w GitHub.

Trzy stany polityki, nie dwa. Każde uprawnienie rozstrzyga się na allow, deny lub ask. Ostatni wymaga potwierdzenia człowieka przed wykonaniem akcji. Wszystko, czego firewall nie dopasuje, trafia do domyślnego unknownPolicy per-konektor, który domyślnie jest deny. Najmniejsze uprawnienia są domyślne, nie opcjonalne.

Jeden sandbox na każde uruchomienie. Każde wykonanie agenta działa w osobnym mikroVM Firecracker z izolowaną przestrzenią sieciową. Po zakończeniu uruchomienia przestrzeń jest niszczona. Dwa uruchomienia tego samego agenta to dwa oddzielne sandboxy z dwoma oddzielnymi śladami audytu.

Ślad audytu dla każdego żądania. To samo proxy, które decyduje o allow/deny, zapisuje log JSONL dla każdego uruchomienia z metadanymi firewall do każdego żądania: konektor, grupa uprawnień, dopasowana reguła, decyzja, znacznik czasu. Logi wracają na platformę. Jeśli CISO chce wiedzieć, co agent zrobił 14 kwietnia między 15:00 a 17:00 CST, to jedno zapytanie.

CLI wyjaśniające blokady. Gdy uprawnienie blokuje wywołanie, agent (lub człowiek obok) może uruchomić zero doctor permission-deny <connector> --method <M> --path <P> i otrzymać dokładną grupę uprawnień, która zablokowała żądanie, plus link do rozwiązania. zero doctor permission-change pozwala adminom przełączyć uprawnienie bezpośrednio lub członkowi złożyć pisemną prośbę (do 500 znaków, by uzasadnienie było czytelne), która trafia do admina. Uprawnienia wysokiego ryzyka jak slack:chat:write czy gmail.send wywołują dodatkowe ostrzeżenie wskazujące bezpieczniejszą alternatywę dla bota.

Dwie role, jeden proces zatwierdzania. Właściciele i admini zmieniają uprawnienia bezpośrednio. Członkowie składają prośbę z uzasadnieniem, która trafia do admina. Nie ma trzeciego poziomu „pół-admina”. Proces jest na tyle prosty, że ludzie faktycznie go używają – o to chodzi.

Użycie komputera rezerwujemy dla wąskiej grupy systemów legacy bez API. Wszystko inne przechodzi przez umiejętności. Każda akcja jest sprawdzana polityką. Każde poświadczenie zostaje na platformie. Każda decyzja jest logowana.

Jeśli masz już dość „kolejnego AI autouzupełniania” i chcesz spróbować AI kolegi, którego zaakceptuje Twój dział bezpieczeństwa, zobacz jak Zero obsługuje workflow zaplanowane, triarzuje incydenty produkcyjne lub prowadzi poranny briefing produktowy.

Era kopilotów nie kończy się. Zostaje wchłonięta w coś większego. Zespoły, które wygrają kolejną rundę, to te, które rozumieją różnicę.