NIST vrea identitate separată pentru agenții AI, nu conturi partajate

La 29 septembrie 2026, Centrul Național de Excelență în Securitate Cibernetică (NCCoE) al NIST a publicat sinteza observațiilor primite de la peste 600 de comentatori din industrie, administrație și mediul academic. Pe baza lor, proiectul DevSecOps al centrului va fi primul caz de implementare menit să arate cum pot fi identificați, autentificați și autorizați agenții AI în dezvoltarea software. Demonstrația urmează să fie construită; anunțul privește direcția proiectului, nu rezultatele unui test încheiat.

Direcția susținută în consultare este ca agentul să aibă o identitate verificabilă, distinctă de persoana care îl însărcinează, și drepturi limitate la sarcina primită. În sinteza NCCoE, un participant cere aplicarea standardelor existente „rather than creating a parallel identity stack”. Majoritatea comentatorilor au preferat această abordare, iar identificarea distinctă a agenților a întrunit un acord aproape unanim. Mecanismul exact rămâne însă de stabilit pentru fiecare caz de utilizare.

Ce trebuie să identifice sistemul de acces

Identitatea proprie înseamnă mai mult decât un nume atribuit agentului. Comentatorii au descris-o prin identitatea serviciului sau a sarcinii software, instanța care rulează, persoana ori organizația care a autorizat-o și autoritatea pe care o deține atunci când cere acces. Aceste legături permit unui serviciu să distingă un agent autorizat de cineva care doar pretinde că acționează în numele unui utilizator.

Autentificarea este pasul prin care agentul dovedește acea identitate. Printre mecanismele discutate se află credențialele pentru sarcini software, semnăturile criptografice, autentificarea reciprocă și atestarea mediului de execuție. Consultarea nu a ales un mecanism universal: un agent intern, administrat de organizație, și unul controlat de un terț ridică probleme diferite privind emiterea credențialelor și verificarea celui care le folosește.

Participanții au susținut separarea unei baze de încredere stabile, legate de organizație și de componenta software care produce agentul, de credențialele folosite pentru o execuție. Acestea din urmă pot expira după sarcină, pot avea drepturi restrânse și pot fi revocate fără anularea identității de bază. Pentru agenții creați temporar, distincția păstrează proveniența verificabilă fără a le oferi chei permanente sau toate privilegiile unui cont uman.

De ce DevSecOps face vizibile limitele permisiunilor

Dezvoltarea software oferă proiectului un mediu în care acțiunile unui agent pot fi separate clar. În scenariile descrise de participanți, agenții pot scrie, verifica și distribui cod. Fiecare acțiune atinge alte resurse și poate avea altă consecință: permisiunea de a propune o modificare nu acordă automat dreptul de a publica o versiune.

Într-un exemplu ipotetic, un agent primește acces de scriere pe o ramură de lucru pentru a pregăti o modificare. Publicarea versiunii rezultate ar necesita o autorizare separată. Dacă agentul transmite verificarea codului unui subagent, drepturile acestuia ar trebui limitate la verificare, iar sistemul ar trebui să poată urmări de la cine a pornit delegarea. Exemplul arată cum se pot traduce observațiile consultării în permisiuni; nu reprezintă o configurație demonstrată deja de NCCoE.

Comentatorii au susținut evaluarea accesului în contextul sarcinii și al acțiunii cerute, inclusiv la apelarea unui instrument sau API. O autentificare reușită la începutul execuției nu spune dacă fiecare acțiune aleasă ulterior este permisă. Această distincție contează când agentul își împarte singur sarcina în pași sau folosește alte servicii: drepturile delegate mai departe trebuie să rămână în limitele autorității primite inițial.

În ghidul The Observability Layer, William Fisher descrie separat identitatea agentului, persoana care inițiază sarcina, identitatea subagentului și credențiala folosită pentru accesarea resursei. Modelul propus păstrează legătura dintre ele și limitează drepturile efective la ceea ce permit delegarea, sarcina și politica resursei. Este o propunere de implementare, nu un standard de certificare emis de NIST.

Ce trebuie să explice jurnalul unei acțiuni

O identitate distinctă arată cine a făcut un apel, dar nu și de ce apelul a fost permis. Observațiile din consultare cer o evidență care să lege cererea evaluată de identitatea agentului, autoritatea delegată, regula aplicată și decizia de acces. Într-un flux DevSecOps, astfel se poate reconstrui diferența dintre un instrument care a fost apelat și o modificare de cod care a primit autorizare.

Legătura devine mai importantă când sarcina trece prin mai mulți agenți, instrumente sau servicii. Fără păstrarea lanțului de delegare, ultimul apel poate părea legitim deși drepturile au fost extinse pe parcurs. Comentatorii au ridicat și problema datelor sensibile din instrucțiuni și jurnale: trasabilitatea cere context suficient pentru a explica decizia, dar colectarea excesivă poate expune informațiile utilizatorului.

Când vor exista exemple de implementare

Următoarea etapă anunțată este o descriere preliminară a proiectului, pentru care NCCoE intenționează să ceară din nou observații. Ea ar urma să precizeze domeniul, cazurile de utilizare, arhitectura și standardele propuse. Nu a fost comunicată o dată pentru demonstrația DevSecOps.

Primul caz va privi agenți folosiți într-un mediu organizațional de dezvoltare software. Descrierea proiectului va arăta ce mecanisme de identificare și autorizare intră efectiv în demonstrație și unde sunt plasate limitele delegării. Pentru echipele care dau agenților acces la cod și instrumente, acele detalii vor face diferența dintre principiile asupra cărora există acord și un model de permisiuni care poate fi pus în practică.

Citește și:

• UiPath și BDO mută auditul spre agenți AI, dar omul păstrează controlul
• Moldova caută 2–3 proiecte-pilot ServiceNow pentru servicii publice
• GigaHack a adunat peste 300 de participanți pentru zece probleme reale