Czy pasywne wykrywanie pomija coś, co wychwyciłby serwer proxy?

Na w pełni współpracujących ścieżkach oba podejścia są zbieżne. Serwer proxy może zobaczyć każdy bajt przepływów, które terminuje, podczas gdy pasywne wykrywanie zależy od telemetrii i śladów audytu emitowanych przez agenta lub jego hosta. Luka pojawia się na niewspółpracujących ścieżkach, które emitują niewiele. Dokładnie do tego służy jądrowe zabezpieczenie eBPF: wywołanie systemowe dotykające gniazda lub pliku jest obserwowalne niezależnie od tego, co aplikacja postanowiła zalogować. Tam, gdzie dowodów jest mniej, mapa dostępu oznacza dane połączenie jako przybliżone, a nie przypisane, więc obserwacja o niższej pewności nigdy nie jest przedstawiana jako pewnik.

Jeśli kolektor zawiedzie, czy to zepsuje moich agentów?

Nie. Pasywny kolektor jest z założenia poza ścieżką żądań: odczytuje OpenTelemetry, natywne ślady audytu oraz sygnały jądra poza pasmem i nigdy nie terminuje ani nie przekazuje dalej ruchu agenta. Jeśli przestanie działać, agenci pracują dokładnie tak jak wcześniej; traci się aktualną widoczność do czasu jego powrotu, a nie produkcję. Ta asymetria — brak ryzyka po stronie ścieżki danych — jest istotą zbierania danych w modelu read-first.

Pasywne wykrywanie a serwery proxy: inwentaryzacja agentów AI bez umiejscawiania się na ścieżce danych

Większość zespołów odkrywa ten sam niewygodny fakt w tej samej kolejności. Najpierw uświadamiają sobie, że agenci AI już działają w całej ich infrastrukturze: wywołują modele, otwierają serwery MCP, sięgają do baz danych i magazynów obiektów. Następnie próbują ich zinwentaryzować i okazuje się, że nie istnieje żadna lista. Niezależne badania branżowe (CSA/Token, n=418) podają liczby opisujące tę lukę: około 82% organizacji ma działających agentów, o których nie wie, a tylko mniej więcej 21% prowadzi inwentarz w czasie rzeczywistym. Zanim cokolwiek z tego da się objąć nadzorem, trzeba to najpierw zobaczyć. Pytanie brzmi: jak uzyskać tę widoczność, nie pogarszając sytuacji.

Istnieją dwie uczciwe odpowiedzi i znajdują się one na przeciwnych krańcach spektrum ryzyka.

Dwa sposoby na zobaczenie agenta

Pierwszym jest wbudowany serwer proxy. Ruch agenta jest kierowany przez komponent, który Państwo kontrolują, a ponieważ każde żądanie i każda odpowiedź przez niego przechodzą, można je w czasie rzeczywistym widzieć, kształtować i blokować. To rozwiązanie uzasadnione i potężne. W ten właśnie sposób egzekwuje się dziś wiele mechanizmów filtrowania ruchu wychodzącego, pośredniczenia w dostępie do sekretów oraz polityk na poziomie żądań.

Drugim jest pasywne wykrywanie. Zamiast stać w przepływie, obserwuje się go z boku: OpenTelemetry, które agent już emituje, natywne ślady audytu systemów, których dotyka (PostgreSQL pgAudit, logi audytu chmury, takie jak AWS CloudTrail, audyt Kubernetes), oraz sygnały na poziomie jądra przez eBPF jako zabezpieczenie odzwierciedlające stan faktyczny. Połączenie nigdy nie jest terminowane. Obserwuje się to, co się wydarzyło, i odtwarza, kto czego dotknął.

Istotna różnica nie polega na tym, ile każde z podejść może zobaczyć w najlepszym przypadku. Polega na tym, co się dzieje, gdy zawodzi sama warstwa widoczności.

Zasięg rażenia jest prawdziwą osią

Wbudowany serwer proxy z definicji znajduje się na ścieżce danych. To daje kontrolę w czasie rzeczywistym, ale kosztuje wspólny tryb awarii. Jeśli serwer proxy jest wolny, agenci są wolni. Jeśli się przewróci, bezpiecznym domyślnym zachowaniem jest zwykle fail closed, co oznacza, że agenci się zatrzymują, albo fail open, co oznacza, że kontrola po cichu znika w najgorszym możliwym momencie. Tak czy inaczej komponent widoczności dzieli teraz zasięg rażenia z produkcją. Dodaje też skok opóźnienia do każdego wywołania oraz powierzchnię wdrożeniową, którą ktoś musi obsługiwać, skalować i łatać na ścieżce krytycznej.

Pasywne wykrywanie ma odwrotny profil. Kolektor działa poza pasmem i w modelu read-first: odczytuje telemetrię, ślady audytu i zdarzenia jądra; nie przekazuje dalej ani nie przepisuje ruchu agenta. Jeśli ulegnie degradacji lub przestanie działać, nic na ścieżce żądań się nie zmienia. Traci się aktualną widoczność do czasu jego odzyskania — nie przepustowość, nie dostępność. Oto co w praktyce oznacza model read-first o niskim asymetrycznym ryzyku: rzecz, której jedynym zadaniem jest obserwowanie, nie wnosi żadnego ryzyka po stronie produkcji.

	Wbudowany serwer proxy	Pasywne wykrywanie
Pozycja	Na ścieżce danych	Poza pasmem, obok niej
Blokowanie w czasie rzeczywistym	Natywne	Wymaga egzekwowania w punkcie dostępu
Dodane opóźnienie	Tak, przy każdym wywołaniu	Brak
W razie awarii	Agenci się zacinają lub kontrola znika	Widoczność się dezaktualizuje; agenci nienaruszeni
Pokrycie cichych ścieżek	Wysokie (terminuje przepływ)	Zależy od emitowanych sygnałów + zabezpieczenia eBPF

Dlatego właśnie stanowisko produktowe brzmi brak obowiązkowego serwera proxy, a nie „serwery proxy są bezużyteczne”. Istnieją ścieżki, na których wbudowany komponent jest właściwym wyborem, i da się je komponować. Ale wykrywanie — część, której nigdy nie wolno pozwolić na unieruchomienie tego, co inwentaryzuje — to złe zadanie do przyspawania na ścieżce krytycznej.

Kompromis przedstawiony uczciwie

Pasywne wykrywanie ma autentyczną słabość, a udawanie, że jest inaczej, byłoby rodzajem chochoła, który po cichu podkopuje zaufanie do całego projektu. Serwer proxy, który terminuje przepływ, widzi każdy jego bajt. Pasywny kolektor widzi tylko to, co agent, jego środowisko uruchomieniowe lub zasób postanowiły wyemitować. Na w pełni niewspółpracującej ścieżce — takiej, która loguje niewiele i nie emituje użytecznej telemetrii — wykrywanie na poziomie aplikacji się przerzedza. Można wnioskować, że coś się wydarzyło, ale przypisanie staje się trudniejsze.

Dwie rzeczy sprawiają, że jest to uczciwe, a nie fatalne.

Pierwszą jest jądrowe zabezpieczenie eBPF. Logi aplikacji bywają niekompletne, opóźnione lub — w przypadku adwersaryjnym — celowo tłumione. Jądra nie da się grzecznie poprosić, by zapomniało o wywołaniu systemowym. Agent, który otwiera gniazdo do bazy danych lub zapisuje plik, pozostawia ślad na granicy wywołań systemowych niezależnie od tego, co jego mechanizm logowania postanowił zarejestrować. To czyni eBPF stanem faktycznym odpornym na obchodzenie zabezpieczeń: gdy sygnały wyższego poziomu są ze sobą sprzeczne lub milkną, widok z jądra stanowi warstwę potwierdzającą. To także powód, dla którego adnotacje narzędzi MCP, takie jak readOnlyHint i destructiveHint, choć użyteczne jako wskazówki, traktowane są zgodnie ze specyfikacją MCP jako niezaufane. Narzędzie, które deklaruje, że jest tylko do odczytu, a obserwuje się, jak zapisuje, to dokładnie ta rozbieżność, którą warto wydobyć na wierzch — i wychwyci się ją tylko wtedy, gdy zestawi się deklarację z tym, co rzeczywiście się wydarzyło.

Drugą są uczciwe poziomy pewności. Nie każda obserwacja zasługuje na tę samą wagę, więc mapa dostępu nie udaje, że tak jest. Połączenie poparte sygnałem z jądra oraz pasującym wpisem audytu oznaczane jest jako przypisane; połączenie wywnioskowane z częściowej telemetrii oznaczane jest jako przybliżone. Produkt nigdy nie przepuszcza domysłu za fakt. Recenzent powinien móc na pierwszy rzut oka ocenić, na ile zaufać każdej linii.

Od obserwacji do różnicy, która ma znaczenie

Wykrywanie jest jedynie danymi wejściowymi. Danymi wyjściowymi jest porównanie między PERMITTED, czyli tym, na co pozwala polityka, a OBSERVED, czyli tym, co kolektor faktycznie zobaczył. Ta różnica to dryf względem zasady najmniejszych uprawnień (least-privilege), a sztandarowym przypadkiem jest zaobserwowany zapis, którego polityka nigdy nie przyznała i którego nikt nie zweryfikował.

Kilka linii ze strumienia dostępu czyni to konkretnym. Odczyty są rutynowe; historia tkwi w oznaczonym zapisie:

agent             action  resource                outcome   confidence
data-export-job   READ    s3://billing-exports    allowed   attributed
data-export-job   READ    prod-postgres           allowed   attributed
data-export-job   WRITE   prod-postgres           flagged   attributed
support-rag       READ    internal-wiki-mcp       allowed   approximate

Zadanie eksportu odczytujące produkcyjną bazę danych jest niczym niezwykłym. To samo zadanie zapisujące do niej — gdy polityka przyznała wyłącznie odczyt — to taki rodzaj połączenia, które nigdy nie powinno przejść bez weryfikacji. Ponieważ zapis jest potwierdzony na granicy jądra, zostaje oznaczony jako attributed, a nie obwarowany zastrzeżeniem.

Dostrzeżenie dryfu to połowa zadania; jego zamknięcie to druga połowa. Egzekwowanie należy do punktu dostępu, wyrażone jako polityka jako kod (policy-as-code), tak aby reguła była weryfikowalna, a wobec naruszenia podjęto działanie, a nie jedynie je zalogowano:

policy "data-export-readonly" {
  agent        = "data-export-job"
  resource     = "prod-postgres"
  allow        = ["read"]
  deny         = ["write"]
  on_violation = "block + alert"
}

Pasywne wykrywanie znajduje niedozwolony zapis; polityka przypina agenta z powrotem do zasady najmniejszych uprawnień i blokuje kolejny. Widoczność i kontrola pozostają odrębnymi kwestiami — i właśnie dlatego warstwa wykrywania może sobie pozwolić na działanie w modelu read-first.

Wniosek

Widoczność agentów AI jest decyzją dotyczącą ryzyka, zanim stanie się decyzją dotyczącą funkcjonalności. Wbudowany serwer proxy daje kontrolę w czasie rzeczywistym kosztem dzielenia zasięgu rażenia z produkcją. Pasywne wykrywanie rezygnuje z części zasięgu na cichych ścieżkach w zamian za to, że nigdy nie jest w stanie unieruchomić produkcji, a następnie odzyskuje większość tego zasięgu dzięki zabezpieczeniu eBPF odzwierciedlającemu stan faktyczny oraz poziomom pewności, które pozostają uczciwe co do tego, co faktycznie zobaczono. Dla inwentarza — warstwy, której całym zadaniem jest obserwowanie — ta asymetria jest właściwym domyślnym wyborem.

Jeśli chcą Państwo uzyskać pełny obraz tego, jak kolektory, mapa dostępu i dziennik audytu układają się w całość, przegląd architektury przeprowadza przez to od początku do końca.