Agent AI to, z operacyjnego punktu widzenia, proces dysponujący poświadczeniami. Ktoś nadaje mu konto usługowe, klucz API albo rolę IAM, aby mógł wykonywać swoje zadanie, i od tego momentu może osiągnąć wszystko to, co osiągają te poświadczenia. Opis zadania mówił: „eksportuj dane rozliczeniowe co noc”. Poświadczenie mówiło: „odczyt i zapis produkcyjnej bazy danych, a także magazynu obiektowego i kolejki”. Nikt nie uzgodnił tych dwóch rzeczy. Miesiące później nikt w zespole nie potrafi odpowiedzieć na pytanie, które powinno być banalne: co ten agent faktycznie może osiągnąć i czego faktycznie dotyka?
Ta luka nie jest hipotetyczna. Niezależne badania branżowe (CSA/Token) wykazały, że około 82% organizacji ma działające agenty AI, o których nie wie, podczas gdy tylko około 21% utrzymuje ich inwentaryzację w czasie rzeczywistym. Nie da się zarządzać tym, czego się nie widzi, a obecnie większość środowisk w ogóle nie widzi swoich agentów — nie mówiąc już o krawędziach łączących każdego agenta z zasobami, które może osiągnąć.
Trzy różne pytania, rutynowo mylone ze sobą
Powód, dla którego „co ten agent może osiągnąć” jest trudnym pytaniem, jest taki, że łączy ono trzy odrębne pytania w jedno. Utrzymanie ich rozdzielności to istota całej sprawy.
- Posiadane — poświadczenia, którymi dysponuje agent. Token, klucz, powiązanie roli. To fakt dotyczący tożsamości: do jakich drzwi agent ma klucze.
- Dozwolone — to, co te poświadczenia wolno robić, zgodnie z polityką: nadania IAM, role w bazie danych, reguły sieciowe. To fakt dotyczący polityki i jest on niemal zawsze szerszy, niż ktokolwiek pamięta, ponieważ nadania kumulują się, a nikt ich nie odbiera.
- Zaobserwowane — to, przy czym agent został faktycznie zauważony: które zasoby osiągnął i czy każdy dostęp był odczytem, czy zapisem. To fakt behawioralny i dopóki go nie zbierzesz, po prostu nigdzie nie istnieje.
Większość narzędzi bezpieczeństwa zatrzymuje się na dozwolonym. Odczytują Twój IAM i mówią, że agent mógłby zapisywać do kubełka z eksportami rozliczeniowymi. To konieczne, ale niewystarczające, ponieważ „mógłby” to zbiór tysięcy uśpionych możliwości, a człowiek nie jest w stanie triażować tysięcy „być może”. To, co zmienia tę rozmowę, to zestawienie zaobserwowanego obok dozwolonego i przyjrzenie się różnicy.
Mapa dostępu
Mapa dostępu to graf tych krawędzi: dla każdego wykrytego agenta krawędź do każdego zasobu, który może osiągnąć, opatrzona adnotacją o tym, co faktycznie zaobserwowano w jej obrębie. Jednostką, która ma znaczenie, jest krawędź, a najważniejszą adnotacją na krawędzi jest rozróżnienie odczyt/zapis.
R (read) oznacza, że agent pobrał dane bez ich zmiany: SELECT, GET, odczyt pliku. RW (read/write) oznacza, że zmienił stan: INSERT/UPDATE/DELETE, PUT do magazynu obiektowego, migracja schematu. Zasięg rażenia tych dwóch jest nieporównywalny. Krawędź odczytu na wrażliwej tabeli to kwestia ekspozycji. Krawędź zapisu — zwłaszcza niezamierzona — to kwestia integralności i incydentu. Traktowanie ich jako tego samego „dostępu” to sposób, w jaki zespoły przeoczają odkrycie, które miało znaczenie.
Tak wygląda pojedynczy wiersz agenta po zbudowaniu mapy:
| Agent | Zasób | Dozwolone | Zaobserwowane | Pewność |
|---|---|---|---|---|
| data-export-job | prod-postgres | RW | RW | przypisane |
| data-export-job | s3://billing-exports | RW | R | przypisane |
| data-export-job | internal-metrics-api | R | — | przybliżone |
Spójrz na pierwszy wiersz. Zadanie eksportu miało odczytywać z prod-postgres i zapisywać wynik do s3://billing-exports. Odczyt ze źródła, zapis do celu. Jednak poświadczenie, które mu nadano, przyznaje RW na bazie danych, a kolektor zaobserwował, jak zapisuje do prod-postgres — modyfikacja w produkcyjnym systemie ewidencji, której nikt nie zweryfikował, nie zamierzył ani nie potrafi obecnie wyjaśnić. Kolumna dozwolonego po cichu mówiła, że przez cały czas było to dozwolone. To zalążek incydentu, leżący na widoku, a bez kolumny zaobserwowanego nie ma nic, co można by oznaczyć.
Dozwolone minus zaobserwowane równa się dryf
Charakterystycznym produktem jest różnica. Dryf zasady least-privilege to to, co otrzymujesz, odejmując jedną kolumnę od drugiej, i działa to w obie strony:
- Dozwolone, lecz nigdy niezaobserwowane — agent może osiągnąć
internal-metrics-api, ale w całym oknie obserwacji nigdy tego nie zrobił. To martwy zakres: nadanie, którego odebranie możesz bezpiecznie zaproponować, zmniejszając powierzchnię ataku bez wpływu na zachowanie. - Zaobserwowane poza tym, co zweryfikowano — zapis do
prod-postgres, na który nikt nie wyraził zgody. To odkrycie o wysokim sygnale: działanie, które — gdyby ktoś zapytał o nie w chwili nadawania uprawnień — nie zostałoby zatwierdzone.
Druga kategoria to główne ryzyko, a uczciwa wersja produktu nigdy go nie wymyśla. Każda zaobserwowana krawędź niesie ze sobą poziom pewności — przypisane, gdy działanie jest powiązane z konkretną tożsamością agenta i potwierdzone dodatkowym sygnałem, przybliżone, gdy dowody są słabsze. Pokazujesz różnicę, zamiast prać domysł, by uchodził za pewnik. Odkrycie, za którym nie potrafisz stanąć, jest gorsze niż brak odkrycia.
Wykrywane pasywnie, przypisywane per agent
Dwie decyzje projektowe sprawiają, że jest to godne zaufania, a nie tylko kolejny pulpit.
Po pierwsze, wykrywanie jest pasywne. Kolektor obserwuje — logi, ślady OpenTelemetry, strumienie audytu baz danych takie jak pgAudit w PostgreSQL oraz eBPF na poziomie jądra jako zabezpieczenie dające stan faktyczny — i nie znajduje się w ścieżce danych agenta. Nie ma obowiązkowego proxy. Jeśli kolektor zawiedzie, agent dalej działa; degraduje się obserwowalność, nie produkcja. Dla systemu, którego cała istota polega na zarządzaniu krytyczną infrastrukturą, ta asymetria jest właśnie założeniem projektowym: niskie ryzyko, wysoki sygnał.
Po drugie, każde działanie jest przypisywane do konkretnej tożsamości agenta, a nie do współdzielonego konta usługowego. To różnica między dziennikiem audytu, który mówi „rola eksportu zapisała do prod-postgres o 02:14”, a takim, który mówi, który agent to zrobił, pod czyją odpowiedzialnością i wobec jakiego zamierzonego zakresu. Tożsamość per agent to warunek konieczny, by zasada least-privilege w ogóle cokolwiek znaczyła — bez niej działanie można zobaczyć, ale nigdy nie da się go cofnąć do odpowiedzialnego właściciela.
Przechowywane są wyłącznie krawędzie oraz fakty odczyt/zapis. Mapa zapisuje relacje — agent do zasobu, R lub RW — a nie ładunki, nie odczytane wiersze, nie sekrety. Dane wejściowe mogące zawierać sekrety lub dane osobowe są redagowane i skanowane pod kątem sekretów, zanim cokolwiek zostanie zapisane. Graf jest wrażliwy właśnie dlatego, że jest mapą dostępu, więc został zbudowany tak, by przechowywać minimum umożliwiające zarządzanie i nic ponadto.
Sygnały z własnego ekosystemu agenta pomagają, ale same w sobie nie są obdarzane zaufaniem. Serwer MCP może deklarować, że narzędzie jest tylko do odczytu, za pomocą adnotacji takich jak readOnlyHint; zgodnie ze specyfikacją MCP te wskazówki są niezaufane i muszą być potwierdzone, nigdy ślepo brane na wiarę. To widok na poziomie jądra wychwytuje narzędzie, które zadeklarowało tryb tylko do odczytu, a mimo to zapisało.
Gdy mapa już istnieje, następnym krokiem jest egzekwowanie: przypięcie zadania eksportu do trybu tylko do odczytu na bazie danych, odmowa zapisu oraz alertowanie zamiast samego logowania — polityka stosowana w momencie dostępu, a nie odtwarzana po incydencie.
agent "data-export-job" {
resource "prod-postgres" {
access = "read" # zamierzony zakres: wyłącznie odczyt ze źródła
deny = ["write", "ddl"]
}
resource "s3://billing-exports" {
access = "read-write" # zamierzony zakres: zapis do celu
}
on_violation {
action = "block"
alert = "secops"
}
}Mapa mówi Ci, jaką politykę powinieneś był napisać, ponieważ pokazuje ten jeden dostęp, którego agent faktycznie potrzebował, oraz tuzin, których nigdy nie użył. To różnica między zgadywaniem zasady least-privilege a wyprowadzaniem jej ze stanu faktycznego.
Jeśli to jest pytanie, na które Twoje środowisko nie potrafi dziś odpowiedzieć — co każdy agent może osiągnąć i czego faktycznie dotyka — to dokładnie do tego służy mapa dostępu. Przegląd produktu omawia wykrywanie oraz różnicę między dozwolonym a zaobserwowanym; architektura opisuje, jak pasywne zbieranie, tożsamość per agent i dziennik audytu współgrają ze sobą, nigdy nie znajdując się w ścieżce danych Twoich agentów.