NIST nada agentom AI własną tożsamość — DevSecOps będzie pierwszym testem

National Cybersecurity Center of Excellence (NCCoE) przy NIST opublikowało 29 września 2026 r. podsumowanie uwag ponad 600 komentujących z przemysłu, administracji i środowiska akademickiego na temat tożsamości oprogramowania i agentów AI. Jako pierwszy planowany przypadek wdrożeniowy wybrano projekt bezpiecznego wytwarzania oprogramowania, DevSecOps. Demonstracja ma pokazać identyfikację, uwierzytelnianie i autoryzację agentów w cyklu tworzenia oprogramowania.

Dla zespołu utrzymującego potok CI/CD oznacza to pytanie o to, kto działał, na czyje polecenie i z jakim prawem do repozytorium, narzędzia lub wdrożenia. W analizie Logana Daleya wspólne konto usługi i token programisty wskazano jako słabe substytuty tożsamości agenta. Zapowiedź wyznacza kierunek demonstracji; nie jest gotowym standardem ani wdrożoną usługą.

Własna tożsamość nie oznacza stałego tokenu

Podsumowanie konsultacji NCCoE opisuje tożsamość agenta jako połączenie tożsamości usługi, konkretnej uruchomionej instancji, podmiotu udzielającego upoważnienia oraz zakresu uprawnień w danej chwili. Jeden z komentujących ujął zasadę trwałości słowami „The identity anchor should be stable”. W odpowiedziach przeważało poparcie dla odrębnej, weryfikowalnej tożsamości agentów, ale nie uzgodniono jednej metody jej technicznej realizacji.

Większość uczestników wolała rozbudować istniejące standardy i protokoły niż tworzyć równoległą infrastrukturę od początku. Przyszły projekt ma sprawdzić, czy obecne mechanizmy, uzupełnione profilami i rozszerzeniami, wystarczą do powiązania instancji agenta z właścicielem i zakresem jej uprawnień.

Trwała podstawa zaufania pozwala powiązać kolejne uruchomienia z oprogramowaniem i organizacją, które za nimi stoją. Pojedyncza instancja może jednak działać tylko przez czas potrzebny do wykonania zadania. Dlatego poświadczenie używane w potoku może być krótkotrwałe, ograniczone do określonego zasobu i możliwe do unieważnienia bez likwidowania trwałej tożsamości usługi. Ten podział zapobiega sytuacji, w której raz wydany klucz pozostaje użyteczny długo po zakończeniu pracy agenta.

Potok musi znać właściciela i granice delegacji

W modelu zagrożeń dla CI/CD samo oznaczenie żądania jako „agent AI” mówi zbyt mało. Potrzebne są odpowiedzi na pytania, która instancja rozpoczęła operację, jaki użytkownik lub proces ją upoważnił, jakie zadanie było jej celem i na którym etapie potoku obowiązywało zezwolenie. Wspólne konto techniczne może poprawnie przejść uwierzytelnienie, a jednocześnie ukryć różnicę między agentem analizującym kod a agentem przygotowującym zmianę.

Warunkowy przykład pokazuje stawkę: agent przygotowujący poprawkę dostaje odczyt repozytorium i prawo do utworzenia propozycji zmiany. Prawo do zatwierdzenia wdrożenia produkcyjnego wymaga osobnej decyzji. Jeżeli agent uruchomi podagenta do analizy testów, przekazana mu delegacja powinna obejmować tylko narzędzia potrzebne do tej części pracy. W przeciwnym razie kolejne ogniwo łańcucha może odziedziczyć dostęp szerszy od własnego zadania, a ustalenie odpowiedzialności za jego działania staje się trudniejsze.

Czas życia tokenu jest częścią tej samej decyzji o dostępie. Po zakończeniu zadania, cofnięciu polecenia lub zmianie zakresu pracy poświadczenie nie powinno pozwalać na dalsze wywołania narzędzi. Szczególnie ważne jest rozróżnienie między odebraniem pojedynczej delegacji a wyłączeniem całego agenta: inne równoległe zadania mogą nadal mieć prawidłowe upoważnienie. Ograniczenie zakresu i możliwość unieważnienia konkretnego tokenu zmniejszają skutki jego przejęcia.

Autoryzacja przy działaniu, audyt po działaniu

Jednorazowa zgoda przy uruchomieniu agenta nie opisuje wszystkich operacji, które wykona on później. Odczyt kodu, wywołanie narzędzia, zapis w repozytorium i uruchomienie wdrożenia mają różne skutki, więc decyzja o uprawnieniu powinna być oceniana przy konkretnym żądaniu. Ma to znaczenie również wtedy, gdy agent napotka niezaufaną treść w pliku lub odpowiedzi narzędzia: taka treść może wpłynąć na jego następny krok, ale nie powinna samodzielnie rozszerzać prawa dostępu.

Ślad audytowy powinien połączyć czynność z tożsamością instancji, źródłem delegacji, obowiązującą regułą i decyzją o autoryzacji. Zapis „konto techniczne zmieniło plik” pokazuje skutek, lecz nie wyjaśnia, dlaczego operacja została dopuszczona. Przydatny ślad odtwarza także przejście przez podagentów i narzędzia, dzięki czemu zespół może przypisać zmianę do odpowiedzialnego podmiotu. Zakres zapisywanego kontekstu trzeba jednak ograniczać: polecenia, kod i odpowiedzi narzędzi mogą zawierać dane wrażliwe.

Co pokaże pierwszy przypadek wdrożeniowy

Plan zakłada wykorzystanie istniejących mechanizmów tożsamości i autoryzacji oraz sprawdzenie, gdzie potrzebne są rozszerzenia lub profile. Pierwszy przypadek ma dotyczyć agentów pracujących w środowisku wytwarzania oprogramowania; później projekt przewiduje przypadek agentów należących do konsumentów lub przez nich kontrolowanych. W tym drugim środowisku upoważnienie musi być zrozumiałe również dla usługi spoza organizacji, która uruchomiła agenta.

Najbliższy zapowiedziany rezultat to projekt opisu przedsięwzięcia z proponowanym zakresem, przypadkami użycia, architekturą i standardami do dalszych uwag. Dopiero ten dokument określi, które warianty identyfikacji i delegowania rzeczywiście znajdą się w demonstracji. Dla dostawców i administratorów tożsamości będzie to punkt odniesienia do porównania własnych decyzji o właścicielu agenta, zakresie tokenu, egzekwowaniu uprawnień i rozliczalności działań.

Przeczytaj także:

• Cloudflare oddaje agentom 2900 poleceń — logowanie nadal wymaga człowieka
• OpenAI oddaje agentom komputer — zgody stają się kluczową barierą
• Google Vids obiecuje darmowe 1080p, lecz pierwszy test wskazał 720p