Perché usare un intero VPS come sandbox invece di un container?

Il raggio d'azione. Un container sulla tua macchina condivide il kernel e sta accanto ai tuoi file, chiavi e rete. Un VPS separato è vero isolamento — codice non fidato, generato dall'IA, gira su una macchina che non ha nulla di tuo, e quando il task è finito l'intera macchina viene distrutta. Per codice di cui non ti fidi, un server usa-e-getta è il confine più pulito.

Come crea e distrugge la macchina l'agente stesso?

Tramite il nostro server MCP l'agente chiama order_vps per fare provisioning di una macchina nuova (pagata da un saldo prepagato in crypto), legge il suo accesso SSH con get_vps_status, esegue il codice, poi cancel_service con modalità 'immediate' per distruggerla. Nessun umano clicca nulla. La cancellazione immediata cancella la VM e rimborsa il tempo pagato non usato sul saldo, così la prossima sandbox è finanziata.

Cosa succede al denaro quando una macchina di breve durata viene annullata?

La cancellazione immediata rimborsa la parte non usata del periodo pagato sul saldo del tuo account — non è persa. Quindi un agente che avvia una macchina per dieci minuti e la distrugge riottiene gran parte di quel periodo come saldo per finanziare la prossima. Combinato con il modello prepagato, è un tetto di spesa netto: l'agente può usare solo ciò che c'è sul saldo.

È davvero isolamento sicuro?

È molto più forte di un container locale, e onesto sui suoi limiti. Ogni sandbox è la propria VM con il proprio OS, IP e disco — nulla di tuo è su di essa, e distruggerla rimuove tutto. È isolamento VPS standard, non un'enclave rinforzata per la ricerca sulla sicurezza; non eseguire qualcosa che affideresti solo a una sandbox formalmente verificata. Per il caso comune — eseguire codice che un LLM ha appena scritto, senza rischiare la tua macchina — un VPS usa-e-getta è esattamente giusto.

No. Email per registrarti, USDC o USDT per pagare. Niente documenti, niente carta, niente KYC — il che conta quando è un agente autonomo a fare provisioning e a pagare.

Sandbox VPS effimere: lascia che un agente IA avvii, esegua codice non fidato e distrugga la macchina

Nel momento in cui un agente IA scrive codice che non hai revisionato, hai un problema: dove lo esegui? Non sul tuo laptop accanto alle tue chiavi SSH e ai tuoi file. La risposta abituale è un container — ma un container condivide il tuo kernel e vive sulla tua macchina. C'è un confine più pulito che quasi nessuno usa perché prima era troppo lento da configurare: un intero VPS usa-e-getta che l'agente crea, usa e distrugge da solo.

È di questo che si tratta — ed è uno schema per cui EQVPS è costruito in modo unico, perché l'agente può fare l'intero ciclo di vita da solo tramite MCP.

Perché un VPS usa-e-getta batte un container locale

Per eseguire codice di cui non ti fidi, la domanda è il raggio d'azione — cosa può toccare se si comporta male?

Un container locale condivide il tuo kernel, sta sulla tua rete, ed è a una configurazione sbagliata di distanza dal tuo host. Va bene per codice che hai scritto tu; rischioso per codice che un LLM ha appena generato.
Un VPS usa-e-getta è una macchina separata con il proprio OS, il proprio IP e nulla di tuo. Il codice non fidato gira lì. Quando è finito, la macchina viene distrutta e tutto ciò che c'era se ne va con essa.

Il motivo per cui prima non lo facevano è l'attrito: creare e smontare un server significava una dashboard, una carta, un umano. Rimuovilo e la sandbox VPS usa-e-getta diventa la scelta ovvia.

Il ciclo di vita, posseduto dall'agente

Questa è la parte che funziona solo qui. Tramite il nostro server MCP l'agente esegue l'intero ciclo senza umano:

order_vps({ product: "nano", os_id: 1 })      // macchina nuova, pagata dal saldo prepagato
get_vps_status({ service_id })                // → ip, ssh_port, password root una tantum
// l'agente fa SSH, esegue il codice non fidato, rilegge il risultato
cancel_service({ service_id, type: "immediate", confirm: "<hostname>" })
//    → VM distrutta; tempo pagato non usato rimborsato sul saldo

Quattro chiamate: crea, leggi l'accesso, esegui, distruggi. Nessuna dashboard, nessuno ad approvare un acquisto. L'agente ha comprato e gestito il proprio server; ora se ne disfa anche.

L'economia che lo rende pratico

Due scelte di design lo trasformano da "costoso" in "ovvio":

Saldo prepagato = tetto di spesa netto. L'agente paga da un saldo che hai finanziato una volta con crypto. Non può mai spendere più di ciò che c'è — quindi un loop impazzito che crea macchine è limitato dal saldo, non da tutto il tuo wallet.
La cancellazione immediata rimborsa il tempo non usato. Distruggere una macchina a metà periodo restituisce il tempo pagato non usato sul tuo saldo (refund_amount), che finanzia la prossima sandbox. Un agente che avvia una macchina per dieci minuti riottiene gran parte di quel periodo. Le macchine di breve durata restano economiche.

Insieme rendono economicamente sensata una sandbox usa-e-getta per task, non un pozzo di denaro.

Ambito onesto

Questo è isolamento VPS, non un'enclave per la ricerca sulla sicurezza. Ogni sandbox è una VM completa — molto più forte di un container locale, ma è virtualizzazione standard, non una sandbox formalmente rinforzata. Per eseguire codice che un LLM ha appena scritto senza rischiare la tua macchina, è esattamente giusto; per l'analisi di malware avversario, usa strumenti costruiti apposta.
Il provisioning richiede circa un minuto. Una VM nuova si avvia e l'SSH risponde in circa 60 secondi — rapido, ma non istantaneo come un container caldo. Per l'isolamento per-task va bene; per chiamate di funzione sub-secondo non è lo strumento.
La AUP si applica comunque. Una sandbox usa-e-getta per il tuo codice non fidato va bene; usare macchine usa-e-getta per abusi, attacchi o spam no, e porta alla terminazione dell'account.

Perché proprio qui

Nessun altro host lascia a un agente possedere questo ciclo dall'inizio alla fine: crea, paga, esegui, distruggi, rimborsa — senza umano, senza carta e senza KYC. Email per registrarsi, USDC o USDT per finanziare un saldo, e un agente può gestire una flotta di sandbox usa-e-getta da solo. Se stai costruendo un agente che scrive ed esegue codice, questo è il confine di isolamento che non mette in gioco la tua macchina. Puntalo sull'endpoint MCP e lascialo fare provisioning.