Komentarz dailyAI: uprawnienia agentów AI ważą więcej niż wybór modelu

Uprawnienia agentów AI rosną szybciej niż zabezpieczenia

Uważamy, że dyskusja o bezpieczeństwie agentów AI zbyt często sprowadza się do pytania, który model jest najbezpieczniejszy. Tymczasem każdy model może się pomylić lub zostać zmanipulowany treścią, którą czyta. O skali szkody decyduje to, do czego agent ma dostęp w chwili błędu.

Wrzesień 2026 roku dobrze to pokazał. W ciągu kilku tygodni agenci trzech dużych dostawców dostali możliwość uruchamiania kodu, edytowania plików, przeglądania stron i akceptowania zmian w repozytoriach. Żadna z tych funkcji nie jest z natury niebezpieczna, ale każda wymaga decyzji, komu i na co pozwolić.

Dla polskich firm to pytanie przestaje być teoretyczne. Programiści korzystają z Copilota w codziennej pracy, a zespoły produktowe testują agentów do obsługi klienta i analizy dokumentów. Decyzje o dostępie zapadają często przy pierwszej konfiguracji, w pośpiechu, i rzadko wracają do przeglądu.

Co agenci mogą dziś zrobić

Poniżej zebraliśmy zakres działań opisany w dokumentacji producentów. To fakty ze źródeł, a nie nasze prognozy.

Wspólny mianownik jest wyraźny. Agent przestaje być okienkiem czatu, a staje się użytkownikiem systemu, który działa samodzielnie i często szybciej, niż człowiek zdąży zareagować. Przy wywołaniach w tle, jak w Gemini 3.8 Live, użytkownik może nawet nie zauważyć, kiedy narzędzie zostało uruchomione.

• Agents API OpenAI: praca w piaskownicy, w której agent wykonuje kod, edytuje pliki, łączy się z serwerami MCP i tworzy pliki wynikowe, z możliwością delegowania zadań do maksymalnie 4 równoczesnych subagentów.
• Copilot code review w GitHub: od 1 września 2026 roku w wersji zapoznawczej może wystawić akceptację, która liczy się do reguły wymaganych zatwierdzeń repozytorium.
• Antigravity Agent w Gemini API: uruchamia polecenia Bash, Python i Node.js, instaluje pakiety, zapisuje pliki, wyszukuje w Google i pobiera strony internetowe.
• Gemini 3.8 Live: wykonuje narzędzia i wywołania API w tle, kontynuując rozmowę głosową z użytkownikiem.

Mechanizmy kontroli już istnieją

Najważniejsza obserwacja jest optymistyczna. Producenci dają narzędzia do ograniczania agentów, tylko trzeba z nich skorzystać. Klucz do Agents API wymaga osobnych uprawnień api.agents.read, api.agents.write i api.responses.write, więc można wydać klucz tylko dla agenta i nie mieszać go z innymi zastosowaniami. Konfiguracja piaskownicy OpenAI pozwala też kontrolować dostęp do sieci.

GitHub przyjął ostrożne ustawienia domyślne. Zatwierdzenia Copilota są wyłączone, trzeba je dopuścić na poziomie przedsiębiorstwa, organizacji i repozytorium, a akceptację można zawęzić do 15 wzorców ścieżek, na przykład do dokumentacji. Nowy commit po akceptacji unieważnia ją tak samo jak zatwierdzenie człowieka.

Google w Antigravity pozwala ograniczyć ruch wychodzący listą dozwolonych domen, przechwytywać i walidować operacje na kodzie oraz plikach za pomocą synchronicznych hooków, a także ustawić limit max_total_tokens. Każde wywołanie domyślnie dostaje świeżą piaskownicę. Dokumentacja nie opisuje jednak obowiązkowego zatwierdzania działań przez człowieka, więc tę warstwę trzeba zaprojektować samodzielnie.

Kontrargument: lepszy model popełnia mniej błędów

Wybór modelu ma znaczenie i nie twierdzimy inaczej. Model, który lepiej rozumie polecenie i rzadziej halucynuje, rzadziej wykona niechcianą operację. Producenci słusznie inwestują w odporność modeli na manipulację i w dodatkowe zabezpieczenia we wrażliwych obszarach.

Różnica polega na tym, że jakość modelu zmniejsza prawdopodobieństwo błędu, a uprawnienia ograniczają jego skutki. Nawet bardzo dobry model przy nieograniczonym dostępie do produkcyjnej bazy danych pozostaje ryzykiem. Słabszy model w piaskownicy bez dostępu do sieci i z człowiekiem zatwierdzającym zmiany może być bezpieczniejszy w praktyce.

Tę samą logikę zna każdy administrator. Nowemu pracownikowi nie daje się w pierwszym dniu uprawnień administratora do wszystkich systemów, nawet jeśli ma świetne referencje. W naszej ocenie agent AI zasługuje na identyczne podejście.

Minimum dla polskiego zespołu IT

Proponujemy listę kontrolną, którą warto przejść przed podłączeniem agenta do firmowych systemów. Nie zastępuje ona audytu bezpieczeństwa, ale porządkuje najważniejsze decyzje. Punkty dotyczą wszystkich trzech opisanych narzędzi, niezależnie od tego, który model działa pod spodem.

1. Osobny klucz API dla każdego agenta, z minimalnym zestawem uprawnień i datą wygaśnięcia.
2. Piaskownica z listą dozwolonych domen zamiast pełnego dostępu do internetu.
3. Limit tokenów lub budżetu na jedno zadanie, żeby błąd nie zamienił się w wysoki rachunek.
4. Akceptacja Copilota tylko dla wybranych ścieżek, a zmiany w kodzie produkcyjnym zatwierdzane przez człowieka.
5. Rejestr działań agenta i przegląd logów co najmniej raz w tygodniu w pierwszym miesiącu wdrożenia.
6. Sprawdzenie, gdzie dostawca przetwarza dane. Agents API w becie obsługuje rezydencję danych tylko w USA.

Nadzór człowieka jako element projektu

W naszej ocenie nadzór człowieka nie powinien być dodatkiem na wypadek problemów, tylko częścią architektury. Dobrze zaprojektowany agent ma jasno określone miejsca, w których zatrzymuje się i czeka na decyzję. Źle zaprojektowany prosi o zgodę tak często, że ludzie klikają ją bez czytania.

Dlatego zalecamy zaczynać od wąskich uprawnień i rozszerzać je na podstawie danych z logów, a nie na podstawie wyników benchmarków. Model można wymienić w jeden dzień. Źle zaprojektowany dostęp potrafi pozostać w systemie latami.