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. 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ął. Przechwytywanie na poziomie jądra pochodzi z czujnika Tetragon, który Państwo wdrażają; Olivares AI odczytuje eksport Tetragona i sam nie ładuje programów eBPF.

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.

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, którego źródło niesie tożsamość pojedynczego agenta, na przykład kooperatywne OpenTelemetry z identyfikatorem agenta albo ślad audytu, w którym agent ma własną rolę w bazie danych, oznaczane jest jako przypisane. Połączenie wywnioskowane z częściowej telemetrii oraz każde połączenie widziane wyłącznie przez jądro oznaczane jest jako przybliżone, ponieważ sygnały z jądra wskazują proces, cgroup lub kontener, a nie agenta. 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   approximate
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. Jądro potwierdza, że zapis nastąpił, ale wskazuje proces lub kontener, a nie agenta, dlatego to połączenie jest oznaczone jako approximate.

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. Olivares AI ocenia Cedar jako nakładkę forbid na rolach z domyślną odmową, więc reguła może jedynie odebrać dostęp; ta odrzuca każde żądanie dotykające tajnych poświadczeń, cokolwiek mówi rola.

permit(principal, action, resource);

forbid(principal, action, resource)
  when { resource.kind == "credential" && resource.sensitivity == "secret" };

Pisanie własnych reguł Cedar wymaga edycji Business. Community egzekwuje wbudowane role, natywną nakładkę odmowy i kill switch; role niestandardowe i uprawnienia o ograniczonym zakresie są w Business.

Pasywne wykrywanie znajduje niedozwolony zapis, a mapa dostępu oznacza go jako dryf. Olivares AI blokuje działanie tylko w czterech punktach egzekwowania: wewnątrz Claude Code, w proxy modelu, przy każdym wywołaniu narzędzia MCP i między agentami. Zapis, który przechodzi przez jeden z nich i którego rola agenta nie dopuszcza, jest odrzucany, zanim zostanie wykonany, i trafia do podpisanego, odpornego na manipulacje dziennika audytu; bezpośredni zapis do bazy danych jest obserwowany, a nie blokowany. 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.