IAMagenci AItożsamośćSPIFFEbezpieczeństwo AIzero trust

Kto to jest ten agent? IAM w świecie autonomicznych systemów AI

Active Directory, LDAP, OAuth, SAML — cały stos zarządzania tożsamością i dostępem przez ostatnie 30 lat był projektowany z jednym założeniem: człowiek się loguje, wykonuje określone działania, wylogowuje. Sesja jest ograniczona czasowo. Uprawnienia są przypisane do roli ludzkiego użytkownika. Audit trail pokazuje kto co zrobił.

Agent AI niszczy każde z tych założeń.

Co robi agent inaczej niż człowiek

Człowiek loguje się do systemu HR żeby zaktualizować adres. Zajmuje mu to 3 minuty. IAM obsługuje to dobrze.

Agent AI powołany do “obsługi onboardingu nowego pracownika” może przez 45 minut:

  • Tworzyć konto w Active Directory
  • Konfigurować e-mail w Exchange
  • Przypisywać licencje w Azure AD
  • Dodawać do grup Slack
  • Tworzyć ticket w Jira
  • Wpisywać dane do systemu HR
  • Wysyłać powitalnego e-maila przez korporacyjne konto
  • Zamawiać sprzęt przez system procurement
  • Provisjonować VPN access

Każda z tych operacji wymaga dostępu do innego systemu. Agent robi to wszystko w jednej sesji, działając “jako użytkownik” (zazwyczaj jako serwisowe konto z szerokimi uprawnieniami) lub z delegowanymi uprawnieniami HR managera, który go uruchomił.

Tradycyjne uwierzytelnianieUżytkownikCredentialsJeden systemjeden podmiot → jedna autentykacja → jeden systemUwierzytelnianie agentyczneAgent AIAD / EmailHR / SlackJira / VPNkolejny agentjeden agent → wiele systemów → wiele akcji → może spawować kolejne agenty

Gdzie się psuje tradycyjny IAM

Problem 1: Shared service accounts

Najczęstsze rozwiązanie: agent dostaje serwisowe konto z szerokimi uprawnieniami. Wszyscy agenci w organizacji używają tego samego lub podobnych kont. Audit trail pokazuje “[email protected]” wykonał 3847 operacji dzisiaj. Ale który agent? Na czyj wniosek? W jakim kontekście? Nie wiadomo.

Gdy coś pójdzie nie tak (pomyłka lub kompromitacja), nie możesz odtworzyć co się stało, kto był odpowiedzialny i jak daleko sięgają skutki.

Problem 2: Delegowane uprawnienia bez granicy

Alternatywne podejście: agent działa z delegowanymi uprawnieniami użytkownika, który go uruchomił. HR manager uruchamia onboarding agenta ze swoim tokenem. Agent działa “jako” HR manager.

Problem: HR manager ma dostęp do systemu HR. Nie ma dostępu do procurement, VPN provisioning i Azure AD. Jeśli agent potrzebuje tych dostępów do wykonania zadania, albo eskaluje uprawnienia (zły pomysł), albo dostaje dodatkowe credentials (które teraz agent ma, nie tylko manager), albo zadanie się nie wykonuje.

Problem 3: Łańcuchy agentów

W systemach multi-agent jeden agent może spawować kolejne sub-agenty. Sub-agent może spawować kolejne. Każdy z nich działa z jakimiś uprawnieniami, możliwe że delegowanymi od poprzedniego w łańcuchu.

Gdzie jest granica zaufania? Jeśli oryginalny użytkownik autoryzował “agenta onboardingowego”, czy autoryzował też wszystkie sub-agenty które ten agent stworzy?

SPIFFE/SPIRE: tożsamość dla workloadów

SPIFFE (Secure Production Identity Framework for Everyone) to standard CNCF (Cloud Native Computing Foundation), stworzony pierwotnie do problemu “jak serwisy w Kubernetes wiedzą że rozmawiają z właściwym serwisem”.

Podstawy:

  • Każdy workload (serwis, kontener, agent) dostaje SPIFFE ID — unikalna, kryptograficznie weryfikowalna tożsamość
  • Tożsamość jest enkodowana w SVID (SPIFFE Verifiable Identity Document) — certyfikat X.509 lub JWT
  • Krótki czas życia (godziny, nie lata) — automatyczna rotacja
  • SPIRE to implementacja referencyjna do zarządzania tymi tożsamościami

Zastosowanie do agentów AI: każdy agent dostaje własny SPIFFE ID. Każda akcja agenta jest atrybuowana do jego tożsamości, nie do serwisowego konta. Łańcuchy agentów mają weryfikowalny łańcuch tożsamości. Można określić “agent z ID X ma prawo do operacji Y na systemie Z”.

Kilka startupów (Aembit, Britive) i większe platformy (HashiCorp Vault, Azure Managed Identity) rozwijają podobne podejścia.

Least privilege dla agenta — jak to wygląda w praktyce

Least privilege dla człowieka: HR manager ma dostęp tylko do systemów HR, tylko do pracowników swojego działu.

Least privilege dla agenta onboardingowego:

  • Uprawnienia scoped do konkretnego zadania onboardingu (“nowy pracownik ID 1234”)
  • Uprawnienia ważne przez czas wykonania zadania (nie trwałe)
  • Każdy dostęp wymaga kontekstu uzasadnienia (“twoję akcji dla task-5678”)
  • Możliwość escalacji do ludzkiej weryfikacji przy nieoczekiwanych potrzebach dostępu

To wymaga zmiany w infrastrukturze. Większość systemów IAM nie obsługuje “contextual, time-limited, task-scoped permissions”. Są zoptymalizowane dla trwałych ról użytkowników.

Co robić teraz

Organizacje wdrażające agentów AI powinny:

  • Nie dawać agentom shared serwisowych kont z szerokimi uprawnieniami — to jest droga do niemożliwego do audytowania bałaganu
  • Oddzielne tożsamości dla każdego agenta lub przynajmniej każdej klasy agentów z różnymi funkcjami
  • Just-in-time access — zamiast trwałych uprawnień, agent żąda dostępu do konkretnego systemu na czas konkretnego zadania
  • Audit log na poziomie agenta — każda akcja agenta musi być loggowana z identyfikatorem agenta, identyfikatorem zadania i użytkownikiem który je autoryzował
  • Regularny przegląd co agenci faktycznie robią z uprawnieniami które mają

Dobre zarządzanie tożsamością agentów AI nie jest opcją dla zaawansowanych — to podstawa. Im więcej agentów działa w produkcji, tym ważniejsze jest żebyś wiedział kto co robi i mógł to szybko zatrzymać gdy coś pójdzie nie tak.

← wszystkie posty