Agent potrzebuje własnej tożsamości.

Najciekawsza rzecz, jaką przeczytałem w tym tygodniu o agentach AI, nie dotyczyła modeli. Dotyczyła tożsamości.

Google Cloud zaktualizował właśnie dokumentację dotyczącą Agent Identity. W największym skrócie Google stwierdził, że agent może mieć własną, kryptograficznie potwierdzoną tożsamość, czyli działać we własnym imieniu albo w imieniu konkretnego użytkownika, dostać precyzyjnie określone uprawnienia i pozostawić po sobie jednoznaczny ślad audytowy. Chociaż może brzmi to trochę technicznie, to według mnie to przede wszystkim temat organizacyjny.

Dopóki AI odpowiadało głównie na pytania, koncentrowaliśmy się na jakości odpowiedzi, ale kiedy agent zaczyna wykonywać pracę, sytuacja się zmienia. Może pobrać dane z CRM, sprawdzić dokument, uruchomić workflow, wysłać wiadomość, zmienić status, utworzyć zadanie albo wykonać kolejną operację w innym systemie. I wtedy samo określenie uprawnień agenta oparte na stwierdzeniu, że agent ma token do API przestaje być wystarczającą odpowiedzią.

Dlaczego? bo trzeba wiedzieć kim jest ten agent, w czyim imieniu działa, do jakich danych i narzędzi ma dostęp, co wolno mu zrobić samodzielnie, kto odpowiada za jego uprawnienia, jak odebrać mu dostęp, kiedy jego zadanie albo rola się zmieni. Sam token odpowiada głównie na pytanie czy można się uwierzytelnić, ale nie odpowiada na znacznie ważniejsze pytanie czy właśnie ten agent powinien mieć prawo wykonać właśnie tę czynność, w tym kontekście i w imieniu tej osoby?

Z pracownikiem robimy to od lat. Wiemy, kim jest – nadajemy mu rolę, przydzielamy dostęp do konkretnych systemów, a jeżeli jest potrzeba to zmieniamy uprawnienia, kiedy zmienia stanowisk, a jak odchodzi to je odbieramy je. Z agentami będziemy musieli nauczyć się robić coś bardzo podobnego, tyle że jeszcze precyzyjniej.

To o tyle ważne, że agent może działać 24/7, wykonywać wiele operacji w krótkim czasie i łączyć działania pomiędzy kilkoma systemami. I właśnie dlatego coraz bardziej uważam, że zasada least privilege, która opiera się na zasadzie – agent nie powinien dostawać wszystkiego, co może się kiedyś przydać. Powinien dostać dokładnie taki zakres dostępu, jaki jest potrzebny do wykonania konkretnego procesu. Zresztą właśnie taką zasadą kierujemy się tworząc askee | Organisational Intelligence System.