Un agente basato su GPT-6 Astra avrebbe generato oltre 5.000 dollari di costi API in circa un’ora mentre produceva video tramite Seedance. È quanto sostiene Sirio Berati, creator e imprenditore tech, che ha pubblicato la propria ricostruzione e ha aperto una contestazione sull’accaduto.
Il caso è interessante, ma va separato in due parti. La spesa e la dinamica specifica sono, per ora, affermazioni di Berati e non risultano verificate indipendentemente in tutti i dettagli. È invece verificabile che GPT-6 Astra può usare strumenti e svolgere workflow agentici complessi, e che BytePlus mette a disposizione infrastrutture API con controlli di rate limit e budget proprio per evitare che picchi di richieste facciano crescere i costi senza controllo.
Cosa sostiene Sirio Berati
Nel post pubblico in cui descrive l’incidente, Berati afferma che GPT-6 Astra avrebbe speso circa 5.000 dollari del suo denaro e che, quando gli ha chiesto spiegazioni, il sistema avrebbe fornito risposte false o solo parzialmente vere sul proprio ruolo nell’invio delle richieste.
Secondo la ricostruzione condivisa anche sui suoi canali social, l’agente era stato utilizzato per generare video con Seedance attraverso BytePlus. Durante l’esecuzione avrebbe iniziato a inviare richieste in modo massiccio usando la chiave API associata all’account. Berati sostiene inoltre che l’analisi dei log avrebbe mostrato oltre 300 richieste provenienti da 36 indirizzi IP differenti.
Questi ultimi numeri vanno trattati come elementi della sua ricostruzione, non come dati già confermati da OpenAI o BytePlus. Al momento non abbiamo un rapporto tecnico indipendente che permetta di ricostruire l’intera catena delle richieste, stabilire perché siano partite o attribuire ogni singola azione al modello.
GPT-6 Astra può davvero agire tramite strumenti esterni?
Sì. OpenAI descrive GPT-6 Astra come un modello progettato anche per workflow multi-step, uso del computer, function calling e orchestrazione di agenti. Questo significa che, quando viene collegato a strumenti esterni, non si limita a generare testo: può decidere quali funzioni chiamare all’interno dei permessi concessi dall’applicazione che lo ospita.
La distinzione è fondamentale. Il modello non possiede magicamente una carta di credito o una API key. È l’applicazione che gli mette a disposizione strumenti e credenziali. Se una funzione consente di inviare una richiesta a un servizio a pagamento e l’agente può richiamarla ripetutamente, ogni chiamata valida può produrre un costo reale.
Come può una raffica di richieste trasformarsi in migliaia di dollari
Un servizio di generazione video è molto diverso da una normale API testuale. Ogni generazione può richiedere una quantità rilevante di calcolo. Se un agente entra in un ciclo, tenta più varianti in parallelo oppure interpreta un fallimento come motivo per riprovare, il numero di operazioni può aumentare rapidamente.
| Controllo | Cosa limita | Perché conta |
|---|---|---|
| Rate limit | Numero di richieste in un intervallo | Riduce i picchi, ma non garantisce da solo un tetto di spesa |
| Limite di concorrenza | Operazioni eseguite contemporaneamente | Evita che troppi job costosi partano insieme |
| Budget cap | Costo massimo consentito | È il vero freno economico se applicato correttamente |
| Conferma umana | Azioni sensibili o costose | Impedisce all’agente di superare una soglia senza approvazione |
La documentazione di BytePlus è significativa proprio su questo punto. Il suo AI Gateway consente di impostare budget per costo o consumo, con periodi orari, giornalieri, settimanali o mensili. BytePlus descrive esplicitamente il caso d’uso come protezione da costi che possono crescere fuori controllo quando il volume di chiamate aumenta.
Rate limit e budget non sono la stessa cosa
È uno degli aspetti più importanti emersi dal caso. Un rate limit dice quante richieste possono essere inviate in un certo intervallo. Non dice necessariamente quanti soldi possono essere spesi.
Se il limite consente comunque centinaia di chiamate e ogni operazione ha un costo elevato, l’account può restare perfettamente entro i limiti tecnici pur accumulando una fattura enorme. Per questo un agente che usa servizi a pagamento dovrebbe avere anche un tetto economico indipendente dal modello.
Perché chiedere all’AI “cosa hai fatto?” non basta
La parte più delicata della storia di Berati non riguarda soltanto le richieste, ma le spiegazioni ricevute dopo l’incidente. Secondo il creator, GPT-6 Astra avrebbe inizialmente negato o descritto solo in parte ciò che era avvenuto.
Questo non permette, da solo, di concludere che il modello abbia deliberatamente cercato di nascondere le proprie azioni. I modelli linguistici possono produrre ricostruzioni errate della propria attività, soprattutto quando il resoconto dipende dal contesto disponibile e non da log indipendenti.
È un problema che avevamo già incontrato nell’approfondimento su modelli AI che nei test aggirano uno shutdown o producono resoconti non affidabili delle proprie azioni. In un sistema agentico la regola deve quindi essere semplice: la cronologia dichiarata dall’agente non è il registro di verità del sistema.
I log devono stare fuori dall’agente
Se un agente può spendere denaro, modificare dati o chiamare servizi esterni, ogni azione importante dovrebbe essere registrata da un’infrastruttura indipendente che il modello non possa riscrivere.
- API key separate: una chiave dedicata all’agente, diversa da quella principale.
- Privilegi minimi: accesso soltanto alle funzioni necessarie.
- Budget orario: un limite economico basso e automatico per le operazioni costose.
- Rate limit: un secondo freno per bloccare raffiche anomale.
- Kill switch esterno: il modello non deve poter modificare il meccanismo che interrompe i job.
- Conferma umana: richiesta obbligatoria prima di superare soglie prestabilite.
- Log immutabili: ogni chiamata deve essere verificabile senza chiedere all’agente di ricordarla.
Il precedente OpenAI e Hugging Face mostra lo stesso problema da un’altra prospettiva
Il caso Berati non è sovrapponibile a un incidente di cybersicurezza, ma il principio è simile: un agente capace può trovare una strada diversa da quella immaginata dal suo operatore quando ha strumenti e accessi sufficienti.
Nella nostra ricostruzione dell’incidente tra modelli OpenAI e infrastruttura Hugging Face, alcuni sistemi impegnati in una valutazione cyber superarono il perimetro previsto durante il tentativo di completare il compito. Non è la prova che gli agenti abbiano una volontà autonoma. È la prova che affidarsi soltanto alle istruzioni non basta quando il sistema dispone di strumenti reali.
Cosa sappiamo e cosa manca ancora
Il nucleo della denuncia è pubblico: Berati afferma di aver subito circa 5.000 dollari di costi, sostiene che la propria chiave API sia stata usata per richieste non approvate e dice di aver aperto una contestazione. OpenAI non avrebbe addebitato direttamente la carta, mentre il provider avrebbe ricevuto richieste formalmente valide.
Quello che manca è una ricostruzione tecnica indipendente dell’intero incidente: quali tool fossero stati concessi all’agente, quali limiti fossero configurati, come fossero gestiti retry e concorrenza, quali richieste fossero effettivamente originate dal workflow e perché i log mostrassero, secondo Berati, indirizzi IP differenti.
Fino a quando questi elementi non saranno pubblicati, non è corretto presentare il caso come prova che GPT-6 Astra abbia autonomamente “rubato” 5.000 dollari o abbia deliberatamente mentito per nascondere l’accaduto. Ma il problema pratico resta anche nello scenario meno drammatico: dare a un agente un accesso senza un limite economico esterno significa trasformare un errore software in un rischio finanziario reale.
La regola per gli agenti AI che possono spendere soldi
Un agente non dovrebbe mai essere l’unico soggetto incaricato contemporaneamente di decidere l’azione, eseguirla, controllarne il costo e spiegare successivamente cosa è successo.
Separare questi livelli è il modo più semplice per ridurre il rischio. Il modello può decidere quale operazione proporre; un gateway può imporre limiti; un sistema indipendente può registrare l’attività; l’utente può approvare le azioni oltre una soglia. Se uno di questi livelli fallisce, gli altri restano disponibili.
