Ефемерни VPS sandbox-ове: остави AI агент да вдигне машина, да пусне недоверен код и да я унищожи

В мига, в който AI агент напише код, който не си прегледал, имаш проблем: къде да го пуснеш? Не на лаптопа си до SSH ключовете и файловете ти. Обичайният отговор е контейнер — но контейнер споделя ядрото ти и живее на машината ти. Има по-чиста граница, която почти никой не използва, защото преди беше твърде бавна за настройка: цял еднократен VPS, който агентът създава, използва и унищожава сам.

За това става дума — и това е модел, за който EQVPS е уникално построен, защото агентът може да върши целия жизнен цикъл сам през MCP.

Защо еднократен VPS бие локален контейнер

За пускане на код, на който не вярваш, въпросът е радиусът на взрива — какво може да докосне, ако се държи зле?

• Локален контейнер споделя ядрото ти, седи на мрежата ти и е на една неправилна конфигурация от хоста ти. Наред за код, който си написал; рисково за код, който LLM току-що е генерирал.
• Еднократен VPS е отделна машина със собствен OS, собствен IP и нищо твое на нея. Недоверения код работи там. Когато е готов, машината се унищожава и всичко на нея си отива с нея.

Причината хората да не правеха това преди е триене: създаването и разграждането на сървър значеше табло, карта, човек. Премахни това и sandbox-ът с еднократен VPS става очевидният избор.

Жизненият цикъл, притежаван от агента

Това е частта, която работи само тук. През нашия MCP сървър агентът пуска целия цикъл без човек:

order_vps({ product: "nano", os_id: 1 })      // свежа машина, платена от предплатен баланс
get_vps_status({ service_id })                // → ip, ssh_port, еднократна root парола
// агентът влиза по SSH, пуска недоверения код, чете резултата обратно
cancel_service({ service_id, type: "immediate", confirm: "<hostname>" })
//    → VM унищожен; неизползвано платено време върнато към баланса

Четири извиквания: създай, прочети достъп, пусни, унищожи. Без табло, никой не одобрява покупка. Агентът купи и пусна собствен сървър; сега го и изхвърля.

Икономиката, която го прави практично

Две дизайнерски решения превръщат това от „скъпо“ в „очевидно“:

• Предплатен баланс = твърд таван на харчене. Агентът плаща от баланс, който си захранил веднъж с crypto. Никога не може да похарчи повече от това, което е там — така че цикъл извън контрол, създаващ машини, е ограничен от баланса, не от целия ти портфейл.
• Незабавният отказ връща неизползвано време. Унищожаването на машина по средата на период връща неизползваното платено време към баланса ти (refund_amount), което захранва следващия sandbox. Агент, който вдига машина за десет минути, връща по-голямата част от този период. Краткотрайните машини остават евтини.

Заедно те правят sandbox за изхвърляне на задача икономически разумен, не яма за пари.

Честен обхват

• Това е VPS изолация, не enclave за security research. Всеки sandbox е пълен VM — много по-силен от локален контейнер, но е стандартна виртуализация, не формално втвърден sandbox. За пускане на код, който LLM току-що е написал, без да рискуваш машината си, е точно правилен; за анализ на adversarial malware използвай специализиран инструментариум.
• Провизирането отнема около минута. Свеж VM се стартира и SSH отговаря за грубо 60 секунди — бързо, но не мигновено като топъл контейнер. За изолация на задача това е наред; за sub-second извиквания на функции не е инструментът.
• AUP все пак важи. Sandbox за изхвърляне за твой собствен недоверен код е наред; използването на машини за изхвърляне за злоупотреба, атаки или спам не е и води до прекратяване на акаунта.

Защо точно тук

Никой друг хост не позволява на агент да притежава този цикъл от начало до край: създай, плати, пусни, унищожи, върни — без човек, без карта и без KYC. Имейл за регистрация, USDC или USDT за захранване на баланс, и агент може да управлява флот от еднократни sandbox-ове сам. Ако строиш агент, който пише и пуска код, това е границата на изолация, която не поставя машината ти на карта. Насочи го към MCP endpoint-а и го остави да провизира.