Hvorfor en hel VPS som sandkasse i stedet for en container?

Skaderadiussen. En container på din maskine deler kernen og sidder ved siden af dine filer, nøgler og netværk. En separat VPS er ægte isolation — upålidelig, AI-genereret kode kører på en maskine, hvor intet af dit findes, og når opgaven er færdig, ødelægges hele maskinen. For kode, du ikke stoler på, er en engangsserver den renere grænse.

Hvordan opretter og ødelægger agenten maskinen selv?

Via vores MCP-server kalder agenten order_vps for at provisionere en frisk maskine (betalt fra en forudbetalt kryptosaldo), læser dens SSH-adgang med get_vps_status, kører koden og så cancel_service i tilstanden 'immediate' for at ødelægge den. Ingen klikker på noget. Den øjeblikkelige opsigelse sletter VM'en og krediterer ubrugt betalt tid tilbage til saldoen, så den næste sandkasse allerede er finansieret.

Hvad sker der med pengene, når en kortlivet maskine opsiges?

Den øjeblikkelige opsigelse krediterer den ubrugte del af den betalte periode tilbage til kontosaldoen — den går ikke tabt. Så en agent, der starter en maskine i ti minutter og ødelægger den, får det meste af den periode tilbage som saldo til at finansiere den næste. Med den forudbetalte model er det et hårdt forbrugsloft: agenten kan kun bruge det, der er på saldoen.

Er dette virkelig sikker isolation?

Langt stærkere end en lokal container, og ærlig om sine grænser. Hver sandkasse er sin egen VM med eget OS, IP og disk — intet af dit findes på den, og at ødelægge den fjerner alt. Det er standard VPS-isolation, ikke en hærdet enklave til sikkerhedsforskning; kør ikke det, du kun ville betro en formelt verificeret sandkasse. Til det almindelige tilfælde — at køre kode, en AI netop skrev, uden at risikere din egen maskine — er en engangs-VPS præcis det rigtige.

Spørger I om ID eller kort?

Nej. E-mail for at registrere, USDC eller USDT for at betale. Ingen dokumenter, intet kort, ingen KYC — hvilket tæller, når det er en autonom agent, der provisionerer og betaler.

Efemere VPS-sandkasser: lad en AI-agent starte op, køre upålidelig kode og så ødelægge maskinen

I det øjeblik en AI-agent skriver kode, du ikke har gennemgået, har du et problem: hvor kører du den? Ikke på din laptop, ved siden af dine SSH-nøgler og filer. Det sædvanlige svar er en container — men en container deler din kerne og lever på din maskine. Der findes en renere grænse, som næsten ingen bruger, fordi den før var for langsom at sætte op: en hel engangs-VPS, som agenten selv opretter, bruger og ødelægger.

Det er, hvad dette handler om — og det er et mønster, EQVPS er unikt bygget til, fordi agenten kan gennemgå hele livscyklussen selv via MCP.

Hvorfor en engangs-VPS slår en lokal container

For at køre kode, du ikke stoler på, er spørgsmålet skaderadiussen — hvad kan den røre, hvis den opfører sig dårligt?

En lokal container deler din kerne, sidder på dit netværk og er én fejlkonfiguration fra din vært. Fint til kode, du skrev; risikabelt til kode, en AI netop genererede.
En engangs-VPS er en separat maskine med eget OS, egen IP og intet af dit på den. Den upålidelige kode kører der. Når den er færdig, ødelægges maskinen, og alt på den forsvinder med den.

Grunden til, at man før ikke gjorde dette, er friktion: at oprette og rive en server ned betød et dashboard, et kort, et menneske. Fjern det, og engangs-VPS-sandkassen bliver det oplagte valg.

Livscyklussen, ejet af agenten

Dette er den del, der kun virker her. Via vores MCP-server gennemgår agenten hele cyklussen uden menneske:

order_vps({ product: "nano", os_id: 1 })      // frisk maskine, betalt fra forudbetalt saldo
get_vps_status({ service_id })                // → ip, ssh_port, engangs root-adgangskode
// agenten logger ind via SSH, kører den upålidelige kode, læser resultatet tilbage
cancel_service({ service_id, type: "immediate", confirm: "<hostname>" })
//    → VM ødelagt; ubrugt betalt tid krediteret tilbage til saldoen

Fire kald: opret, læs adgang, kør, ødelæg. Intet dashboard, ingen der godkender et køb. Agenten købte og kørte sin server; nu smider den den også væk.

Økonomien, der gør det praktisk

To designvalg forvandler det fra "dyrt" til "oplagt":

Forudbetalt saldo = hårdt forbrugsloft. Agenten betaler fra en saldo, du en gang fyldte op med krypto. Den kan aldrig bruge mere, end der er — så en løbsk løkke, der opretter maskiner, er begrænset af saldoen, ikke af hele din wallet.
Øjeblikkelig opsigelse krediterer ubrugt tid. At ødelægge en maskine midt i perioden fører ubrugt betalt tid tilbage til saldoen (refund_amount), hvilket finansierer den næste sandkasse. En agent, der starter en maskine i ti minutter, får det meste tilbage. Kortlivede maskiner forbliver billige.

Sammen gør de en engangs-per-opgave-sandkasse økonomisk fornuftig, ikke et pengehul.

Ærligt omfang

Dette er VPS-isolation, ikke en sikkerhedsforsknings-enklave. Hver sandkasse er en hel VM — langt stærkere end en lokal container, men det er standardvirtualisering, ikke en formelt hærdet sandkasse. Til at køre kode, en AI netop skrev, uden at risikere din maskine, er det præcis rigtigt; til fjendtlig malware-analyse, brug særlige værktøjer.
Provisionering tager omkring et minut. En frisk VM starter op, og SSH svarer på omkring 60 sekunder — hurtigt, men ikke øjeblikkeligt som en varm container. Til isolation per opgave er det fint; til funktionskald under et sekund er det ikke værktøjet.
AUP gælder stadig. En engangs-sandkasse til din egen upålidelige kode er okay; at bruge engangsmaskiner til misbrug, angreb eller spam er ikke, og fører til lukning af kontoen.

Hvorfor netop her

Ingen anden vært lader en agent eje denne cyklus fra start til slut: opret, betal, kør, ødelæg, refunder — uden menneske, uden kort og uden KYC. E-mail for at registrere, USDC eller USDT for at fylde en saldo, og en agent kan selv styre en flåde af engangs-sandkasser. Bygger du en agent, der skriver og kører kode, er dette isolationsgrænsen, der ikke sætter din maskine på spil. Peg den mod MCP-endpointet og lad den provisionere.