Najbezpieczniejszą granicą jest ta, której agent nie może przekroczyć

Jeśli agent AI zarządza infrastrukturą dla wielu organizacji, bezpieczeństwo staje się koszmarem.

Zagrożeniem nie jest to, że agent popełni błyskotliwy błąd. Zagrożeniem jest to, że agent wykona jakąś zwyczajną czynność dla niewłaściwej osoby.

Wystawienie ticketu lub rotacja sekretu dla Klienta B zamiast dla Klienta A to naruszenie bezpieczeństwa. Naruszenia nie da się „załatać”. Musisz je ujawnić.

Większość ludzi próbuje rozwiązać ten problem za pomocą uprawnień. Tworzą listę rzeczy, których agent może dotknąć. Sprawdzają każdą czynność pod kątem tej listy.

To zawodzi. Uprawnienia zakładają, że zasób istnieje, a ty po prostu mówisz „nie”. Jeśli w twojej regule jest błąd lub brakuje określonego przypadku, agent uzyska dostęp do niewłaściwych danych.

Stosuję inny model. Sprawiam, że niewłaściwe dane są strukturalnie nieobecne.

W sesji dla Klienta A zasoby dla Klienta B nie istnieją. Dane uwierzytelniające nie są ładowane. Punkty końcowe (endpoints) nie znajdują się w mapie. Nie ma o co prosić, więc nie ma czego odmawiać.

Reguły mają błędy. Fizyczna struktura systemu – nie.

Nauczyłem się tego w trudny sposób. Myślałem, że menedżer sekretów (secrets manager) wystarczy. Myślałem, że izolowanie sekretów izoluje również najemców (tenants). Myliłem się.

Menedżer sekretów izoluje sekrety, ale nie izoluje punktów końcowych. Agent może posiadać właściwy token dla Klienta A, a mimo to wysłać żądanie pod adres Klienta B, jeśli ten adres znajduje się w konfiguracji.

Wyciek nie leży w sekrecie. Wyciek leży w routingu.

Naprawiłem to, wiążąc każdy zasób w jeden rekord: • Zasób (Resource) • Punkt końcowy (Endpoint) • Dane uwierzytelniające (Credential) • Właściciel (Owning tenant)

Nie można uzyskać adresu bez uzyskania właściciela. Biblioteka wysyłająca dane odmawia działania, jeśli najemca nie zgadza się z sesją. Nie da się tego obejść poprzez hardkodowanie, ponieważ adres istnieje tylko wtedy, gdy jest nierozerwalnie połączony ze swoim właścicielem.

Stosuję trzy warstwy obrony:

  • Izolacja strukturalna, dzięki której niewłaściwe dane nie istnieją.
  • Blokada obejść (bypass block), aby agent nie mógł używać surowych narzędzi do pomijania kontroli.
  • Ograniczenie ruchu wychodzącego (egress scoping), dzięki czemu sesja może komunikować się tylko z dozwolonymi adresami.

Tworzy to system, który domyślnie blokuje dostęp (fails closed).

W mojej poprzedniej pracy opowiadałem się za modelem „fail open”. Jeśli agent nie ma pewności, czy dana czynność jest bezpieczna, powinien kontynuować. Agent, który zamiera przy każdym wątpliwości, jest bezużyteczny.

Ale granice między najemcami (tenants) są inne. Jeśli agent nie ma pewności, czyich danych dotyka, musi się zatrzymać.

Niepewność w działaniu prowadzi do ruchu. Niepewność w posiadaniu musi prowadzić do bezruchu.

Nie buduj mechanizmów sprawdzających, które mówią „nie”. Usuń kształty, które wymagają sprawdzania.

Źródło: https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi