AI agent: odobrenje prije plaćanja i nastavak zadatka

Zaustavite AI agenta neposredno prije poziva alata koji može pokrenuti plaćanje, poslati poruku ili promijeniti zapis. Osobi prikažite stvarnu radnju i njezine parametre, a odluku vežite uz taj poziv. Zaustavljeno izvođenje spremite na poslužitelju kako bi se nakon odobrenja ili odbijanja mogao nastaviti isti zadatak.

OpenAI Agents SDK za taj tijek koristi pravilo needs_approval: poziv koji traži odobrenje pojavljuje se među interruptions, a RunState čuva stanje potrebno za nastavak. Odobrenje se primjenjuje na poziv koji je stao; ponovno pokretanje zadatka iz početnog upita ne čuva tu vezu.

Koji pozivi traže odobrenje

Pravilo odredite prema učinku alata i argumentima konkretnog poziva. OWASP-ov vodič za sigurnost AI agenata razlikuje čitanje i pretraživanje od slanja e-pošte, brisanja podataka i prijenosa sredstava te traži izričito odobrenje za radnje velikog učinka. Za aplikaciju koja upravlja porukama, zapisima i plaćanjima korisna je ova početna matrica:

Čitanje bez promjene: pretraživanje već dopuštenih podataka može teći bez nove ljudske odluke. Pristup podacima i dalje mora biti ograničen ovlastima korisnika.
Ograničena interna promjena: spremanje vlastitog nacrta može biti automatsko unutar zadanog opsega. Objavu ili promjenu tuđeg zapisa usmjerite na pregled.
Vanjska komunikacija: prije slanja prikažite stvarnog primatelja i konačan sadržaj poruke. Naknadno povlačenje možda neće ukloniti ono što je primatelj već dobio.
Financijska, administrativna ili nepovratna radnja: iniciranje plaćanja, brisanje ili promjena ovlasti traži zasebnu odluku za konkretan poziv. Nepoznat alat zadržite na čekanju dok mu ne odredite pravilo.

Ta je matrica predložena politika aplikacije, a ne ovlast koju agent dodjeljuje sam sebi. Izvršni dio sustava mora neovisno provjeriti smije li korisnik pokrenuti alat i pripada li odobrenje upravo radnji koja će se izvršiti.

Prekid mora biti prije izvršenja

Za pojedini alat odredite traži li pregled svaki poziv ili samo poziv s određenim argumentima. Pravilo može, primjerice, propustiti spremanje nacrta, a zaustaviti njegovo slanje. Ako se argumenti ne mogu pouzdano protumačiti, poziv treba čekati pregled; nejasan ulaz ne smije postati prečac oko pravila.

U pregled uključite naziv radnje, cilj, primatelja, iznos ako postoji te konačan sadržaj ili polja koja će se mijenjati. Sažetak koji izostavlja odlučujući parametar ne daje osnovu za odobrenje. Ako osoba promijeni iznos, cilj ili sadržaj, to je novi prijedlog koji ponovno prolazi pravilo.

Microsoftove upute za Foundry raspoređuju kontrole na korisnički ulaz, poziv alata, odgovor alata i završni izlaz; za radnje sa stvarnim posljedicama navode provjeru usklađenosti sa zadatkom i validaciju radnje. Opisano vođeno postavljanje koristi pakete u pretpregledu koje Microsoft ne preporučuje za produkcijska opterećenja. Ta raspodjela pokazuje gdje se provjere mogu odvijati, dok ljudsku odluku i dalje treba vezati uz poziv prije njegova izvršenja.

Sačuvajte stanje koje pripada zadatku

Po pauziranju pohranite serijalizirani RunState u zapis kojim upravlja poslužitelj. Uz njega spremite identitet korisnika, zadatak, identifikatore poziva na čekanju, rok za odluku i verziju konfiguracije agenta. Pregledniku pošaljite samo pojedinosti koje osoba smije vidjeti i neprozirni identifikator zahtjeva. Nazive alata i argumente pritom prikazujte kao nepouzdan sadržaj.

RunState može sadržavati argumente alata, kontekst i već donesene odluke. Zato klijentova kopija stanja, izmijenjen popis poziva ili polje „odobreno” ne mogu biti dokaz odobrenja. Kad odluka stigne, poslužitelj učitava vlastiti zapis i iz njega utvrđuje koji pozivi čekaju; pristup spremljenom stanju ograničite, a njegovo čuvanje uskladite s osjetljivošću sadržaja.

Ako se cijelo stanje ipak prenosi kroz klijent, prije obnove izvođenja treba provjeriti njegov cjelovit integritet, pripadnost korisniku i zadatku te zaštitu od ponovne uporabe. Sama provjera sheme ili otisak poziva nisu dovoljni za potvrdu vlasništva nad stanjem. Za dugotrajan prekid sačuvajte i oznaku verzije agenta ili SDK-a kako biste stanje mogli učitati odgovarajućom konfiguracijom.

Odluku vežite uz poziv i potrošite je jednom

Prije nastavka izvršni dio aplikacije provjerava odluku, ne samo pritisak na gumb. Kontrolna lista obuhvaća:

identitet osobe iz prijavljene sesije i njezinu ovlast za taj zadatak i poziv;
podudarnost identifikatora zahtjeva s pozivom na čekanju te istovjetnost alata, cilja i normaliziranih parametara;
važeći rok, neiskorišteno odobrenje i atomski prijelaz stanja koji sprječava da dva istodobna odgovora pokrenu isti poziv;
odbijanje izvršenja ako nedostaje pravilo, provjera ovlasti ne uspije ili je zahtjev istekao.

Za plaćanje provjeru i potrošnju odobrenja smjestite neposredno prije slanja naloga pružatelju usluge. Promijeni li se primatelj ili iznos, zatražite novu odluku. Kad vanjski sustav podržava identifikator operacije, zadržite isti identifikator pri sigurnom ponovnom pokušaju; ako je ishod prethodnog pokušaja nepoznat, prvo ga utvrdite u vanjskom sustavu.

Nastavite iz pauze, uključujući odbijanje

Nakon provjerenog odobrenja primijenite odluku na poziv na čekanju i nastavite izvorno izvođenje. Kod odbijanja vratite odbijanje u isti tijek: agent tada može završiti bez radnje ili predložiti drukčiju radnju koja će zasebno proći pravilo. Ako nastavak koristi pohranjenu sesiju razgovora, mora se povezati s istom poviješću sesije.

Istekom roka zatvorite zahtjev bez izvršenja. Ako je radnja još potrebna, agent može sastaviti novi prijedlog za novi pregled; stara potvrda ne prelazi na njega. U uvjetnom primjeru plaćanja ponovljeni klik, promjena iznosa, odbijanje i istek roka moraju ostaviti nalog neizvršenim, dok valjano odobrenje dopušta samo pregledanu radnju.

Pročitajte i: