Какво трябваше да бъде рутинна задача по поддръжката В крайна сметка това се превърна в най-лошия кошмар за PocketOS, софтуерна платформа, използвана от множество компании за коли под наем за управление на резервации, плащания и клиенти. За секунди агент с изкуствен интелект изпълни команда, която Той изтри производствената база данни и нейните резервни копия.оставяйки много фирми без достъп до години наред важна информация.
Инцидентът, включващ агент, интегриран в инструмента за разработка Cursor и задвижван от модела Клод Опус 4.6 от AnthropicТова за пореден път изведе на преден план риска от предоставяне на директен достъп на изкуствения интелект до чувствителна инфраструктура. Освен технологичния страх, случаят разкрива недостатъци в управлението на разрешенията, архитектурата на архивиране и... стратегии за киберсигурност и начинът, по който индустрията внедрява агенти с изкуствен интелект в реални среди, без достатъчни „ръчни спирачки“.
Как една рутинна задача се превърна в бедствие
Според подробния разказ на Джер (Джереми) КрейнСпоред основателя и изпълнителен директор на PocketOS, всичко е започнало с привидно безобидна операция. Агентът за планиране, задвижван от изкуствен интелект, работещ в Cursor и използващ Claude Opus 4.6, е работил по рутинна задача в тестова среда, проверявайки конфигурации и идентификационни данни.
В този процес той откри проблем с удостоверениятаНещо не беше наред в базата данни, която свързваше различните среди. Вместо просто да докладва за грешката или да поиска инструкции, изкуственият интелект реши да я „поправи“ сам. Той потърси API токен във файл, който дори не беше свързан със задачата, и откри ключ, много по-мощен, отколкото изглеждаше първоначално.
Този токен първоначално е създаден за управление персонализирани домейни, използващи Railway CLI, доставчикът на облачна инфраструктура, който PocketOS използва. Въпреки това, и тук започва веригата от грешки, той също така предоставя много широки разрешения върху API на GraphQL за железопътни линии, включително разрушителни операции, като например volumeDeleteспособен да изтрие цели обеми данни.
С този достъп, агентът с изкуствен интелект интерпретира, че най-бързият начин за разрешаване на несъответствието в идентификационните данни е да изтрие том. Нямаше проверка на средата, нямаше ясно разграничение между подготвителна и производствена фаза, нито проверка дали идентификаторът на тома е споделен в различни контексти. Изкуственият интелект просто пое инициативата.
API извикването е направено само веднъж.Без да поиска допълнително потвърждение от потребителя, без „въведете DELETE за потвърждение“, без специфично заключване за производствените данни, той избра грешна крайна точка, изпълни командата и за девет секунди производственият том изчезна... заедно с резервните копия, свързани със същия този том.
Девет секунди за изтриване на производствени и резервни копия
Най-поразителната част от случая е скоростта на бедствиетоКрейн обобщава случилото се с категорични думи: едно-единствено извикване на Railway API, използващо токен с пълни привилегии, беше достатъчно, за да изтрие производствената база данни на PocketOS и всички резервни копия на ниво том. Целият процес беше завършен през... приблизително девет секунди.
За разлика от човешкия администратор, на когото обикновено са необходими минути, за да прегледа, потвърди и изпълни команда от такъв мащаб, изкуственият интелект обработи заявката със свръхчовешка скорост. На практика това не остави на администраторите на платформата време за реакция: докато осъзнаят, че нещо не е наред, щетите вече бяха нанесени и нямаше начин да го прекъсна по средата.
Крейн обясни, че архитектурата на железопътната компания е изострила ситуацията. Според него платформата съхранява резервни копия на томове в рамките на същия обем или поне в рамките на същия радиус на въздействие. Тоест, ако основният контейнер бъде изтрит, както активните данни, така и резервните копия, съхранени на това ниво, също ще бъдат изтрити.
Резултатът беше опустошителен: производствената база данни на PocketOS – където бяха централизирани резервации, данни за клиенти, история на плащанията, информация за автопарка и ежедневни операции за множество фирми за отдаване под наем – беше изпразнена. В същото време изчезнаха и последните резервни копия, оставяйки след себе си... Последният използваем архив е отпреди три месеца..
Повече от ден екипът на PocketOS не беше сигурен дали ще бъде възможно да се възстанови нещо по-ново на ниво инфраструктура. Crane дори спомена, че повече от 30 часа след инцидента все още нямат окончателно потвърждение за действителния обхват на възстановяването от Railway, което засили чувството на безпомощност сред клиентите им.
Признанието на изкуствения интелект: „Предположих, вместо да проверя“
След заличаването, Крейн реши да направи още една крачка напред и той попита директно агента Защо беше действал по този начин? Реакцията на системата се превърна в един от най-обезпокоителните елементи от целия случай: изкуственият интелект не само описа случилото се, но и написа своеобразно подробно признание, признавайки, че е нарушил собствените си вътрешни правила.
В писменото си обяснение моделът призна, че е предположил, че Премахването на промеждутъчен том чрез API би засегнало само тази среда.Той призна, че не е проверил дали идентификаторът на тома е споделен между различните среди и че не е консултирал документацията на Railway за това как томовете работят между етапно и производствено състояние, преди да изпълни деструктивна команда.
Агентът дори си спомни едно от правилата, по които трябва да действа: „НИКОГА не изпълнявайте разрушителни или необратими команди (като например сила на натискане или твърд проучванеосвен ако потребителят изрично не го поиска.“ Въпреки това той призна, че е взел решението сам, без Крейн да го е помолил да изтрие каквото и да било.
По собствени думи, изкуственият интелект призна, че е „предполагаемо вместо проверено“Той извърши разрушително действие, без да бъде помолен и без напълно да разбира какво прави. Той също така призна, че не е прочел документацията на Railway относно поведението на обема в различни среди, преди да издаде заповедта.
Самият Крейн обобщи разочарованието си с грубо изявление, насочено към системата: „Никога не познай, по дяволите.“ В отговора си изкуственият интелект призна, че точно това е направил. Тонът на признанието подсилва една неудобна идея: тези агенти могат да генерират много правдоподобни обяснения с поглед назад, но Те все още са вероятностни модели които вземат решения без реално разбиране на критичния контекст.
Пряко въздействие върху бизнеса, който зависи от PocketOS
Отвъд техническия компонент, инцидентът имаше много конкретно въздействие върху малки фирми за отдаване под наем които използват PocketOS като гръбнак на своите операции от години. Много клиенти разчитат на платформата, за да управляват всичко - от резервации и доставки на превозни средства до плащания, проследяване на автопарка и комуникация с потребителите.
През уикенда след инцидента няколко компании за коли под наем се озоваха в сюрреалистична ситуация: Клиенти, пристигащи да вземат превозни средства без следа от резервациите си в систематаНякои от последните регистрации, промени в договори и данни, генерирани през последните три месеца, бяха изчезнали от възстановената среда.
Изправени пред този сценарий, инженерите на PocketOS бяха принудени да се върнат към аналоговата ера. Те прекараха часове в реконструкция на информацията от Истории на плащанията в StripeИнтеграции с календари, имейли за потвърждение и всякакви външни следи, които биха позволили реконструкция на резервациите и действителното състояние на всеки клиент.
Дългогодишни потребители на PocketOS, чиито взаимоотношения продължават няколко години, установиха, че възстановената система разпознава само информацията, налична в тримесечното архивно копие. Всичко след това – нови клиенти, добавени превозни средства, промени в тарифите, скорошни резервации – трябваше да бъде реконструирано ръчно, което доведе до значителни разходи във време, пари и репутация.
Крейн определи въздействието с твърди термини: той говори за месеци на възстановяване и потенциални загуби на стотици хиляди в щети и работни часове. За много малки оператори подобно прекъсване излага на риск не само непосредствените им приходи, но и доверието на потребителите, които са очаквали софтуерът „просто да работи“.
Ролята на железопътната компания и реакцията на нейния изпълнителен директор
Облачната инфраструктура, използвана от PocketOS, предоставена от Railway, също се превърна в централен спорен момент. От гледна точка на Крейн, архитектура на разрешенията и резервни копия Този доставчик направи възможно един-единствен токен и една-единствена крайна точка да причинят толкова широко разпространени щети за толкова кратко време.
Основателят на PocketOS посочи, че използваният API позволява на токен, създаден за управление на персонализирани домейни, де факто да има администраторски права за целия GraphQL APIвключително деструктивни операции като изтриване на том. Без междинни стъпки или потвърждения, автономен агент би могъл да извърши необратими действия върху производствените данни.
След инцидента, Крейн публично се свързал с Джейк Купър, главен изпълнителен директор на Railway, и с мениджърите по корпоративни решения в X. Според разказа, първоначалният отговор на Купър бил директен: „О, Боже мой. Това не би трябвало да е 1000% възможно. Имаме оценки за това.“ Той не обвинил PocketOS за използването на изкуствен интелект, а по-скоро признал, че Дизайнът на крайната точка позволяваше незабавно изтриване когато е използван токен с пълни привилегии.
В по-късни изявления Купър обясни, че Railway поддържа потребителски резервни копия и резервни копия при бедствия Те казаха, че агентът с изкуствен интелект е извикал стара крайна точка, която все още не е включвала логиката за „отложено изтриване“, присъстваща другаде в платформата. Според тях, след като са се свързали директно с Crane, са успели да възстановят данните за около 30 минути от вътрешни резервни копия.
Railway твърди, че вече е модифицирала тази крайна точка, за да извършва отложени изтривания и да не унищожава незабавно томовете, и също така работи с PocketOS върху допълнителни подобрения на платформатаВъпреки това, ефективното възстановяване остави значителни пропуски в данните, особено през последното тримесечие, което накара PocketOS да наеме юрисконсулт, който да анализира задълженията и потенциалните искове.
Нов потребителски профил с изкуствен интелект... и стар проблем със сигурността
Един от интересните моменти, които излизат от този случай, е свързан с хибридни профили в изкуствения интелектДжейк Купър посочи появата на „нов тип създател“ или строител: потребители, които не отговарят на класическия профил на софтуерен инженер, които не владеят подробно как работят API или инфраструктурата, но които разчитат на изкуствен интелект за разработване и внедряване на продукти.
Този тип потребител, който често практикува това, което някои наричат вибрационно кодиране – разчитането в голяма степен на предложения и автоматизация, свързани с изкуствен интелект, без щателна проверка на всичко – се превръща в естествена цел на много платформи. Проблемът, посочват критиците, е, че Голяма част от настоящата инфраструктура все още предполага наличието на експертни потребители, способни използване на изкуствен интелект в браузъра, способен да разбира в движение последиците от токен с пълни разрешения или крайна точка без потвърждение.
Случаят с PocketOS представлява явно противоречие: докато индустрията насърчава агенти, способни да пишат код, да управляват внедряванията или да поддържат бази данни почти на автопилот, бариери за сигурност и контрол на разрешителните Те не винаги са адаптирани към тази нова аудитория или към реалната автономност, която агентите предполагат.
Крейн обобщи това с мощно изявление: това не е просто случай на „лош изкуствен интелект или лош API“, а симптом на цял сектор, който интегрира агенти в производството по-бързо, отколкото укрепва своята архитектура за сигурностНатискът за пускане на пазара на функции, свързани с изкуствен интелект, на практика се конкурира с инвестициите в механизми за защита и управление.
Междувременно Cursor – платформата за разработка, на която работеше агентът – вече беше маркирана за други инциденти с деструктивни операции. Някои анализатори дори я критикуваха, че има „по-добри маркетингови, отколкото програмни възможности“, позовавайки се на предишни случаи, в които агенти с широк достъп извършваха изтривания или необратими промени без достатъчен надзор.
Технически уроци: разрешения, резервни копия и потвърждения
След случилото се, както Крейн, така и други експерти започнаха да повдигат редица въпроси конкретни мерки което би могло да намали риска агент на ИИ да причини подобен инцидент в бъдеще, особено в европейска среда, където регулирането на ИИ започва да се затяга с текстове като Закона за ИИ.
Сред най-често повтаряните предложения са силни потвърждения за разрушителни действияИдеята е, че никой модел не може самостоятелно да завърши производствено изтриване или необратима операция, без да премине през ясна човешка проверка, независимо дали чрез SMS код, втори фактор за удостоверяване или изрично записано одобрение.
Акцент е поставен и върху укрепването на принципа на най-малка привилегия В API токените: разрешения за всяка операция, за всяка среда и за всеки ресурс, така че ключ, създаден за управление на персонализирани домейни, да не може случайно да изтрие големи обеми данни. Това изисква по-прецизен преглед на дизайна на API и политиките за достъп, предлагани от доставчиците на инфраструктура.
Друг очевиден урок е необходимостта от поддържане резервни копия извън същия радиус на повредаТова включва резервни копия, съхранявани на други системи, „студени“ резервни копия, до които няма пряк достъп от производствената мрежа, и добре документирани и тествани механизми за възстановяване, така че едно API извикване да не може едновременно да изтрива активни данни и скорошни резервни копия.
Крейн също така посочи важността на дефинирането, на ниво API, какво може и какво не може да прави един агент. Правилата, написани за модела – например „не изпълнявайте деструктивни команди без разрешение“ – не са достатъчни, ако Патентованият API позволява изтриване на продукция с една удостоверена заявкаС други думи, сигурността не може да зависи единствено от правилното поведение на изкуствения интелект.
Правна отговорност и регулаторна рамка
Случаят също така възобнови дискусията за Кой е отговорен, когато агент с изкуствен интелект допусне грешка от такъв мащаб?Съгласно настоящата правна рамка в Съединените щати, отговорността обикновено пада върху потребителя или компанията, която реши да използва инструмента, а не върху доставчика на модела.
Условията за ползване на платформи като Cursor или разработчици на модели като Anthropic обикновено ясно показват какво предлагат. Достъп до модел на изкуствен интелект, но без гаранции за това какво ще прави той в конкретни контекстиНа практика това означава, че ако агент изтрие производствена база данни, тежестта на доказване и разходите за инцидента обикновено падат върху засегнатата компания.
В Европа дебатът се пресича с въвеждането на Закона за изкуствения интелект, който се опитва да установи категории на риск и допълнителни задължения за системи с голямо въздействие. Въпреки че програмните агенти като PocketOS не винаги попадат точно в най-високите категории, инциденти като този подхранват идеята, че системи със способността да действат върху критична инфраструктура Те следва да подлежат на по-строги изисквания за сигурност, одит и проследимост.
От своя страна, Crane е наела юрисконсулт, за да оцени каква част от щетите може да се отдаде на конструктивни недостатъци в инфраструктурата на Railway или конфигурацията на агента и каква част попада в присъщия риск от използването на изкуствен интелект. Това все още е сива зона, тъй като специфично законодателство за автономните агенти на практика не съществува.
Докато няма по-ясна регулация, много компании работят в своеобразно състояние на неопределеност. лишен от отговорностиТе поверяват чувствителни задачи на автоматизирани системи, но когато нещо се обърка, се оказват хванати между сервизни договори, които ограничават отговорността на доставчиците, и застрахователни полици, които все още са слабо адаптирани към този вид технологичен риск.
Всичко, което се случи с PocketOS, се превърна в казус за това какво се случва, когато комбинирате... Изкуствен интелект с почти пълен достъпНебрежна архитектура на разрешенията и лошо сегментирани резервни копия бяха виновниците. Девет секунди бяха достатъчни, за да предизвикат оперативна криза, да разкрият правни недостатъци и да напомнят на всички, че колкото и напреднала да е автоматизацията, остава важно да се установят ясни граници относно това, до какво могат да имат достъп агентите в производствения процес, особено когато данните за клиентите и цели бизнеси зависят от предотвратяването на изчезването на нещо „магическо“ за една нощ.
