Agenci programistyczni AI potrzebują własnej warstwy bezpieczeństwa
Publikacja Uber ADR pokazuje, dlaczego firmy potrzebują obserwowalności, zasad i detekcji na poziomie sesji, gdy Claude Code, Cursor, Codex i MCP wchodzą do codziennej pracy.
Agenci programistyczni z AI przestali być prywatnym eksperymentem. Wchodzą do środowisk firmowych, dlatego otwarte repozytorium Uber ADR jest ważnym sygnałem. Nie traktuje Claude Code, Cursor, OpenAI Codex CLI, Cline, Claude Desktop, Warp Terminal ani opencode jak zwykłych edytorów z podpowiedziami. To systemy, które czytają prompty, widzą repozytoria, wybierają narzędzia, uruchamiają shell, zmieniają pliki, używają MCP servers i czasem natrafiają na dane podobne do credentials. Tego łańcucha nie widać dobrze, gdy bezpieczeństwo obserwuje tylko procesy i pliki.

Co udostępnił Uber
ADR oznacza tutaj Agentic Detection and Response, nie typowe architecture decision records. Repozytorium opisuje system bezpieczeństwa enterprise dla agentów AI i informuje o wdrożeniu w Uberze. W chwili publikacji projekt był na licencji Apache-2.0, głównie w Pythonie, miał około 1 334 stars i 112 forks oraz aktualizację z 10 sierpnia 2026. Liczby nie są dowodem jakości, ale pokazują moment zainteresowania.
To nie jest magiczny skaner. Architektura obejmuje observability, benchmark, detection i prevention. W open source są Sensor, ADR-Bench i Detector. Warstwa prevention oraz część wewnętrznych narzędzi explorer nie zostały udostępnione. To ważne: można uczyć się z architektury, ale nie należy udawać, że samo sklonowanie repozytorium daje gotową kontrolę produkcyjną.
Paper przyjęty na MLSys 2026 Industry Track podaje szerszy kontekst. Wskazuje trzy trwałe problemy: ograniczoną obserwowalność, niewystarczającą odporność i wysoki koszt wykrywania. Według autorów system działał w Uberze ponad dziesięć miesięcy, obejmował ponad 7 200 unikalnych hostów i przetwarzał ponad 10 000 sesji agentów dziennie. To dane raportowane przez Uber, nie gwarancja dla każdej firmy.
Dlaczego EDR i SIEM widzą za mało
Klasyczny EDR odpowiada na pytania systemowe: który proces zapisał plik, jaki program otworzył połączenie, jaki host dotknął podejrzanej domeny. To nadal potrzebne. Agent dodaje jednak warstwę między intencją człowieka a zdarzeniem technicznym. Komenda shell może wyglądać normalnie, lecz być ryzykowna, jeśli pochodzi z prompt injection w issue, dokumencie albo odpowiedzi MCP.
W pracy z agentami trzeba pytać szerzej: czego chciał użytkownik, jaki kontekst przeczytał model, jaki plan pokazał, które tool calls zaproponował, które wykonał, jaka policy obowiązywała i jaki był wynik. Bez łańcucha sesji SOC widzi objaw, ale nie przyczynę.
Sensor README opisuje parsery logów dla Claude Code, Cursor IDE, Cline, Claude Desktop, OpenAI Codex CLI, Warp Terminal i opencode, z różnicami dla macOS, Linux i Windows. Zdarzenia są normalizowane przez session ID, timestamp, chat history, tools, model, project path i session context. To słownik, którego zwykle brakuje EDR.
Narzędzia i MCP jako granica ryzyka
Największa moc agenta nie jest w oknie czatu, lecz na granicy narzędzi. Coding agent staje się operacyjny, gdy może czytać repozytorium, wywołać git, uruchomić testy, otworzyć dokumentację wewnętrzną, dotknąć ticketu, użyć helpera wdrożeniowego albo połączyć się z MCP server. Każdy connector może mieć sens, ale razem tworzą trudny do zobaczenia graf uprawnień.
ADR-Bench traktuje ten graf jako powierzchnię wykrywania. Dokumentacja mówi o około trzystu scenariuszach; Detection README podaje 303 scenarios, 261 benign i 42 malicious, 17 attack techniques oraz 133 MCP servers. Ważniejszy od dokładnej liczby jest model: agent pracuje w realistycznym przepływie z wrogimi instrukcjami, syntetycznymi sekretami i podatnymi usługami.
Open Source Review ostrzega, że benchmark zawiera synthetic attack material oraz pinned dependencies with known CVEs dla powtarzalności. To należy uruchamiać w isolated environment, nie w production.
Co powinna zrobić firma
Dla CTO, CISO i platform teams wniosek nie brzmi „zakazać agentów” ani „zainstalować jeden projekt”. Najpierw trzeba zinwentaryzować zatwierdzone narzędzia, ich logi, wspierane systemy, dostępne repozytoria i działania wykonywane bez stałej recenzji człowieka.
Potem przychodzi least privilege. Agent nie powinien domyślnie dziedziczyć wszystkich credentials, uprawnień shell i sesji przeglądarki dewelopera. Credential gateways, krótkie tokeny, uprawnienia ograniczone do repozytorium, osobne konta dev i zasady dla MCP to podstawowa higiena.
Trzecia część to auditability. Logi powinny łączyć prompt, tool call i outcome. Jednocześnie pełne nagrywanie jest ryzykowne: telemetry może zawierać kod, wewnętrzne tickety, dane klientów i przypadkowo wklejone sekrety. Program podobny do ADR wymaga redaction, szyfrowania, kontroli dostępu, ograniczonej retencji i ostrożnego eksportu do SIEM.
Co zmienia się dla security
Podejrzana sesja agenta nie musi wyglądać jak malware. Może to być zwykła maszyna deweloperska, zwykły edytor i legalny terminal. Anomalia może tkwić w sekwencji narzędzi, wzorcu promptu, nagłym czytaniu lokalizacji sekretów, wygenerowanym skrypcie z nieoczekiwanym ruchem sieciowym albo MCP server, który zmienia dokumentację w akcję.
Reguły muszą łączyć kontekst. Telemetria procesów jest płytka, skanowanie promptów kruche, a sama odpowiedź modelu nie mówi, co wykonano. Użyteczną jednostką jest sesja: wejścia, kontekst, narzędzia, skutki w plikach i sieci oraz decyzje policy. Dojrzałe zespoły będą wymagać detekcji, która wyjaśnia ryzyko.
Dostawcy też poczują presję. IDE, cloud workspaces, terminale, agent frameworks i MCP platforms będą musiały dostarczać strukturalne logi i eksport. Prywatne formaty utrudnią enterprise adoption oraz incident response.
Szerszy sygnał
Bezpośredni wątek Hacker News o Uber ADR był mały, ale pobliskie dyskusje o cloud coding agents, credential gateways i sandboxes były znacznie żywsze. Wszędzie wraca pytanie: gdzie działa agent, jakie sekrety widzi, jak izolowany jest workspace i kto odpowiada, gdy automatyzacja przekracza granicę.
ADR wpisuje się w przejście do zarządzanej infrastruktury agentów. Podobnie jak z cloud, użycie zaczyna się oddolnie, a później potrzebuje identity, logging, cost controls, policy i incident response. Agent startuje w terminalu dewelopera, ale ryzyko należy do firmy.
Praktyczny start jest możliwy już teraz: mapa zatwierdzonych narzędzi, ograniczenie ambient credentials, korelacja logów z edytora, shell, MCP gateway, Git, pull requests i CI, a potem testy w izolowanym repozytorium z synthetic secrets. Jeśli zespół nie widzi, że agent przeczytał wrażliwy plik, wykonał wrogą instrukcję albo zmienił kod poza zakresem, backlog bezpieczeństwa jest oczywisty.
Najważniejsze: agenci kodujący nie są zwykłymi edytorami ani pracownikami. Są delegowanymi systemami, które zamieniają prompts i context na działania narzędzi. Kolejna faza AI w firmach zależy od tego, czy ta praca stanie się observable, bounded, reviewable i recoverable.
Comments
Sign in to comment.
No comments yet.