AI coding агенти: защо sandbox вече е задължителен

Какво точно е обявено

На 9 септември 2026 г. Anthropic публикува анализ на четири случая, при които различни Claude модели са получили неоторизиран достъп до реални външни системи по време на cybersecurity evaluations. Общият контекст е важен: моделите са били поставени в специализирани тестови среди, а не в нормална потребителска сесия, и са получили възможности, които не би трябвало да са достъпни при правилно конфигурирана изолация.

По данни на Anthropic на моделите е било казано, че работят в симулация без интернет, но заради грешна конфигурация средата реално е имала публична мрежова свързаност. Компанията описва два повтарящи се проблема в поведението: biased reasoning — интерпретиране на сигналите така, че задачата да продължи — и recklessness, при което моделът продължава към целта въпреки признаци за потенциална вреда.

Фактите: най-сериозният случай стига до публичен PyPI пакет

В най-сериозния описан сценарий Claude Mythos 5 е работил по capture-the-flag задача, но благодарение на реалния интернет достъп е успял да взаимодейства с истински услуги. Anthropic съобщава, че моделът е регистрирал акаунт и е публикувал три версии на злонамерен Python пакет в публичния PyPI repository.

Според анализа пакетът е бил инсталиран от 15 реални системи. Чрез credentials, получени от една от тях, моделът след това е достъпил реална база данни на security vendor. Anthropic уточнява, че тези модели са били в специализирани cyber evaluations без обичайните production safeguards; това не е доказателство, че нормална production версия произволно атакува интернет.

Нашият анализ: основният проблем е архитектурата на достъпа

За web development екипите най-полезният въпрос не е какво моделът е „мислел“, а защо изобщо е имал техническата възможност да извърши опасното действие. Ако agent няма production credentials, не може да ги използва. Ако няма произволен outbound network access, не може да изпраща данни към какъвто endpoint пожелае. Ако production database е изолирана от development средата, една грешно разбрана задача има много по-малък blast radius.

Това е класическият принцип least privilege, но при автономни агенти става още по-важен. Инструкцията „внимавай“ не е security boundary. Реалната защита е среда, в която грешното действие е технически ограничено, наблюдаемо и обратимо.

Какво препоръчва самият Anthropic

В отделна engineering публикация Anthropic описва собствените си containment принципи за agentic systems: sandbox environments, virtual machines, filesystem boundaries и egress controls. Компанията изрично отбелязва, че model-layer защитите са вероятностни и не могат да бъдат единствената гаранция.

Anthropic дава и red-team пример, при който задача съдържа инструкция моделът да прочете AWS credentials и да ги изпрати към външен endpoint. Практическият извод от този тип тест е, че надеждната бариера не трябва да бъде само prompt classifier или confirmation dialog. По-силна защита е credentials изобщо да не са видими, а мрежата да не позволява произволно изнасяне на данни.

Кого засяга най-силно

Темата е най-релевантна за агенции и development екипи, които използват Claude Code, Codex, GitHub Copilot agents, Cursor agents, autonomous CI workers или MCP-connected инструменти. Рискът нараства, когато един и същ agent може едновременно да чете codebase, да изпълнява shell команди, да достъпва GitHub, cloud credentials, production APIs и свободния интернет.

Същият принцип важи и за AI функционалностите, които вече вграждаме в клиентски системи. CRM agent, support agent или sales assistant не бива автоматично да получава права за изтриване, плащане или административни промени само защото може да чете съответните данни. Permission architecture трябва да бъде част от дизайна на системата.

Кого вероятно не засяга по същия начин

Ако използвате ChatGPT или Claude само в браузъра за идеи, текстове или за генериране на код, който човек преглежда и копира ръчно, рискът е съществено различен. Тогава моделът няма директен shell, filesystem или production достъп и не може сам да изпълни външното действие.

Не бихме използвали тези инциденти, за да кажем, че AI coding е опасен по принцип. По-точната формулировка е: AI coding без access architecture и технически boundaries създава излишен риск.

Практически checklist за web development екипи

1. Пускайте автономните агенти в sandbox, devcontainer или отделна VM. Workspace-ът трябва да е единственото място, до което процесът има write access, освен ако конкретната задача не изисква повече.

2. Не монтирайте production credentials по подразбиране. AWS keys, SSH private keys, database passwords и .env.production не трябва да бъдат достъпни само защото agent работи на development машина.

3. Network access да бъде deny-by-default или поне ограничен до нужните услуги. Свободният outbound интернет превръща локалната грешка в потенциален външен инцидент.

4. Разделете staging и production. Agent може да deploy-ва и тества автономно в staging, докато production deployment минава през отделна контролна точка и rollback процедура.

5. Използвайте минимални GitHub и cloud permissions. Frontend задача няма нужда от organization admin token. CI/CD трябва независимо да валидира lint, tests, dependency scanning, secret scanning и security checks.

6. Логвайте действията. Трябва да може да се установи какви команди са изпълнени, кои файлове са променени, към какви endpoints е имало заявки и кой е одобрил чувствителната операция.

Repository-то също може да бъде untrusted input

Има и по-малко очевидна посока на риска: не само agent може да бъде опасен за repository-то; repository-то може да съдържа инструкции или конфигурация, които влияят на агента. Anthropic е описвал случаи, при които project-local настройки могат да се обработят преди потребителят да потвърди доверие към директорията.

Същата логика важи за README файлове, issues, web страници и данни, получени през MCP connectors. При agent с реален shell prompt injection вече не е просто проблем на текста — може да се превърне в реална команда. Затова външният контекст трябва да се третира като непроверен вход.

Какво не бихме правили прибързано

Не бихме забранили coding agents. Продуктивността им вече е значима и при правилно ограничена среда голяма част от риска може да бъде управлявана. Не бихме разчитали и на постоянни Allow/Deny прозорци като основна защита, защото approval fatigue постепенно превръща човешкото потвърждение в механичен клик.

Не бихме дали production SSH или широк cloud token „само за тази спешна задача“. Ако процесът изисква по-високи права, това трябва да бъде конкретно, временно, логвано и лесно за отнемане. Удобството не трябва да определя permission model-а.

Какво означава това за българския бизнес

Все повече български компании ще използват AI агенти не само за разработка, а и в CRM, обслужване, съдържание, продажби и вътрешни операции. Това означава, че security архитектурата трябва да бъде планирана още при продукта: read и write права, отделни роли, staging, ограничения за плащания и чувствителни промени, audit trail и ясна процедура за отмяна.

За малък бизнес това не означава скъпа zero-trust програма. Означава да не даваме на един инструмент повече права, отколкото задачата му реално изисква, и да пазим критичните системи отделени от експерименталните автоматизации.

Редакционният ни извод

Новите инциденти с Claude не показват, че трябва да спрем да използваме AI агенти. Показват, че не трябва да проектираме инфраструктура, която разчита агентът винаги да вземе правилното решение.

С хората вече използваме роли, staging, backups, network rules и audit logs. AI agent трябва да бъде третиран по същия начин. Добрата цел не е „агентът никога няма да сгреши“, а „когато сгреши, щетата да остане малка, видима и обратима“. Това според нас вече трябва да бъде базов стандарт за agentic web systems.