Під час роботи з програмним забезпеченням, агентами штучного інтелекту або файлами, завантаженими з Інтернету, одним із найпоширеніших страхів є Зламання системи, зараження шкідливим програмним забезпеченням або витік конфіденційних даних Майже не усвідомлюючи цього. Вам не потрібно бути параноїком: одне невдале виконання може видалити базу даних, порушити розгортання або заразити вашу систему шкідливим програмним забезпеченням.
Гарна новина полягає в тому, що сьогодні у вас є кілька способів створити його. ізольоване середовище, де можна спробувати щось, не ризикуючиІ багато з них інтегровані в саму операційну систему або в платформи, розроблені для агентів коду. Ми називаємо це «пісочницею»: запуск коду всередині своєрідної контрольованої бульбашки, щоб навіть якщо щось піде не так або буде зловмисним, шкода була локалізована.
Що таке ручна пісочниця без додаткового програмного забезпечення?
У сфері безпеки та розробки, розмова про пісочниці означає розмову про... чітко визначити, до чого може торкатися програма або агент під час роботиЙдеться не лише про «запуск деінде», а про визначення чітких меж: які файли воно може бачити, які процеси воно може запускати, чи має воно мережу, які облікові дані воно може використовувати, як довго існує це середовище та що відбувається з його станом після завершення роботи.
Різниця між «вручну» та «без додаткового програмного забезпечення» є оманливою. У багатьох випадках ви можете покластися на функції, які вже включені до вашої операційної системи або вашої власної платформи розробкитакі як Windows Sandbox, примітиви Linux (Landlock, seccomp) або механізми macOS. Вам не потрібно встановлювати повний пакет віртуалізації, але вам потрібно навчитися, як це робити. активувати та керувати цими інтегрованими механізмами діяти як бар'єр між кодом, який ви хочете протестувати, та вашою фактичною машиною.
Чому агентам коду потрібні ізольовані середовища?
Сучасні агенти кодування вже не є простими помічниками, схожими на чат, які пропонують фрагменти коду: вони... середовища виконання, пов'язані з мовною моделлюВони можуть читати ваш репозиторій, редагувати файли, виконувати команди терміналу, встановлення пакетів, створювати контейнери, взаємодіяти із зовнішніми API та навіть відкривати сеанси браузера.
Такі платформи, як Claude Code, деякі "глибокі агенти" LangChain або спеціальні пісочниці, що розповсюджуються Docker та іншими інструментами, чітко описують, що ці агенти Вони працюють на реальних файлових системах, запускають потоки та делегують завдання спеціалізованим субагентам.Іншими словами, вони досить схожі на молодшого розробника з доступом до ваших інструментів... тільки автоматизовані та дуже швидкі.
У цьому контексті головне питання безпеки перестає бути «Чи добре він реагує на запит?» і стає таким: "Який приціл, коли він неправильний, зміщений або ним маніпулювали?"Якщо модель може, наприклад, запускати pytest, встановлювати npm-пакети, керувати гілками або перевіряти помилки компіляції, вона знаходиться лише за кілька кроків від дотику до скриптів розгортання, зміни перехоплювачів Git або вилучення секретів до віддаленого сервісу.
Проста відповідь зазвичай полягає в тому, щоб вимагати схвалення людини для кожної команди. Це допомагає, але має повторювану проблему: втома від схваленняУ середовищах, де інженери запускають багато агентів або робочих процесів паралельно, величезна кількість запитів часто призводить до того, що майже все схвалюється без ретельного розгляду. Коли понад 90% запитів на дозволи приймаються автоматично, цей механізм перестає бути справжнім засобом контролю безпеки та стає просто формальністю.
Ось чому пісочниці такі важливі: Вони не роблять модель безпомилковою, а також не виправляють введення інструкцій.Але вони зменшують «радіус вибуху» його помилок. Якщо ШІ дасть збій або комусь вдасться перехопити його інструкції, шкода залишиться в ізольованому середовищі, а не пошириться безпосередньо на вашу виробничу систему чи ноутбук.
Основні обмеження пісочниці кодового агента
Серйозна пісочниця для агентів кодування спирається на кілька типів меж, а не лише на «інший каталог» чи «інший контейнер». Кожна з них охоплює різний аспект ризику, і їх розуміння є важливим для ефективної ручної пісочниці з вашими існуючими ресурсами.
Межі файлової системи
Перше, що потрібно зробити, це визначитися. яке дерево каталогів може бачити та змінювати агентУ правильно налаштованому пісочному середовищі агент повинен мати можливість лише читати та записувати дані в робочу область або томи, які ви явно для нього створюєте. Решта системи (домашній каталог користувача, системні шляхи, інші проекти) повинні бути для нього недоступні.
Агентні фреймворки та платформи «пісочниці» чітко дають зрозуміти: «пісочниця» — це бар'єр, який запобігає доступу до файлів хоста поза межами спільного доступуУ моделях на основі microVM правило ще суворіше: лише каталог, який ви монтуєте (часто з правами читання та запису), перетинає межу між віртуальною машиною та хостом. Все інше залишається недоступним, якщо ви його не відкриєте.
Межі процесу та ядро
Друга ключова межа — це те, що агент бачить на рівні процесу та ядра. Якщо в ізольованому середовищі встановлює служби, запускає контейнери або потокиУсі ці дії мають залишатися інкапсульованими, без спільного використання процесів або голого ядра з хостом.
Багато надійних реалізацій пісочниці покладаються на мікровіртуальні машини або легкі віртуальні машини з власним ядром Linux, посиленим seccomp, cgroups, просторами імен та методами jail. Інші використовують такі шари, як gVisor або Kata Containers, щоб розмістити шар віртуалізації або емуляції між ізольованим процесом та ядром вузла. Основна ідея: якщо хтось щось експлуатує всередині, перехід до хоста набагато складніший, ніж у простому контейнері зі спільним ядром.
Межа мережі
Агенти коду часто дуже "вибагливі до мережі": вони хочуть встановлювати залежності, звертатися до документації, викликати API LLM, отримувати доступ до віддалених репозиторіїв або навіть переглядати веб-сторінки. Без чіткої політики "ізольоване" середовище може зрештою стати... фантастичний тунель для вилучення даних.
Ось чому все більше платформ займають позицію заборона вихідного трафіку за замовчуваннямHTTP/HTTPS блокується, окрім певних випадків, TCP/UDP/ICMP обмежено, і, що дуже важливо, доступ до приватних діапазонів і локальних адрес заборонено. Зв'язок дозволено лише з хостами або доменами, явно включеними до білого списку, і часто через проксі-сервер, контрольований хостом.
Обмеження облікових даних
Немає сенсу блокувати агента, якщо всередині своєї клітки він може зчитувати ваші ключі API, токени розгортання або секрети бази даних. Сучасний дизайн багатьох пісочниць складається з... Ніколи не впроваджуйте нерозголошені секрети в ізольоване середовищеНатомість, нехай проксі-сервер на хості додає облікові дані до заголовків HTTP-запитів, які має надіслати пісочниця.
За такого підходу процес у пісочниці Він використовує облікові дані, але ніколи їх не бачить.Це значно зменшує вплив потенційного захоплення агента. Однак, щойно ви зберігаєте ключ у файлі або змінній середовища всередині пісочниці, ця перевага зникає: модель може зчитувати його безпосередньо, і будь-яке впровадження інструкцій може наказати їй фільтрувати його.
Межа та стан життєвого циклу
Зрештою, є обмеження в часі: Що зберігається, а що руйнується, коли середовище зупиняєтьсяАгенти не є одноразовими процесами: вони читають, компілюють, налагоджують, відкривають кілька гіпотез, відмовляються від деяких, відновлюють інші… Це вимагає середовища виконання, яке інтелектуально керує станом: швидкий запуск, призупинення, знімки, розгалуження та безпечне видалення.
Деякі платформи пропонують знімки пам'яті, пули попередньо нагрітих середовищ та функції розгалуження з певного стану (наприклад, вже автентифікованого браузера або частково вирішеного графа залежностей). Це відрізняє придатного для використання агента — такого, що може інтерактивно виконувати ітерації — від агента, якому потрібно багато часу, щоб повторити одне й те саме налаштування знову і знову.
Реалізації пісочниці на macOS, Linux та Windows
Окрім комерційних продуктів, багато команд обрали скористатися перевагами примітивів ізоляції, які вже присутні в операційних системах створювати власні «пісочниці» для агентів коду без додавання важчих шарів. Головне — розуміти, що пропонує кожна платформа.
Пісочниця на macOS: профілі ременів безпеки та динамічні профілі
На macOS було оцінено кілька моделей: App Sandbox, контейнери, віртуальні машини та Seatbelt. Перші варіанти мають суттєві недоліки для середовища розробки: Пісочниця додатків вимагає підписання кожного бінарного файлу, який агент може виконати і успадковує довіру фірми, що відкриває вектори зловживань, якщо сам агент генерує або змінює бінарні файли; контейнери обмежені екосистемою Linux; традиційні віртуальні машини додають багато затримки завантаження та споживання пам'яті.
Практичною альтернативою було покладатися на Ремінь безпеки, доступний через sandbox-execХоча Apple роками позначив його як застарілий, він все ще використовується критично важливими програмами, такими як ChromeЦе дозволяє виконувати команди в профілі "пісочниці", який обмежує поведінку всього дерева процесів-нащадків.
Цей профіль визначає дозволи з великою деталізацією: Він може фільтрувати певні системні виклики та читати або записувати дані в певні файли та каталоги.використовуючи своєрідну мову політик. Існують реалізації, які генерують цю політику динамічно під час виконання, поєднуючи конфігурацію робочої області, політики адміністратора та файли ігнорування користувачів, щоб агент мав простір для маневру, не торкаючись небезпечних областей.
Пісочниця в Linux: Landlock та seccomp
Linux пропонує як більшу гнучкість, так і більше роботи: ядро надає доступ до таких примітивів, як Вихід до суші та секкомплексАле саме простір користувача відповідає за їх об'єднання в цілісну та керовану пісочницю.
Замість того, щоб покладатися виключно на зовнішні проекти, деякі команди вирішують Використовуйте seccomp безпосередньо для блокування системних викликів, які вважаються небезпечними. та Landlock для обмеження доступу до файлової системи. Поширена схема включає монтування робочого простору користувача поверх накладання файлової системи та Замініть файли, позначені як ігноровані, спеціальними копіями, захищеними Landlockщоб ізольований процес не міг прочитати або змінити те, що ви насправді хочете приховати.
Найповільнішою частиною цього підходу зазвичай є пошук та повторне збирання всіх цих файлів, оскільки Linux не пропонує простого способу знайти повний шлях до файлу всередині фільтра seccomp-bpf.Навіть так, результатом є досить тонка пісочниця: агент може працювати зі своїм деревом проєктів, тоді як заборонені шляхи, де-факто, знаходяться поза його всесвітом.
Пісочниця у Windows: використання WSL2
У Windows історія інша. Створення універсальної нативної пісочниці набагато складніше, оскільки Більшість існуючих примітивів ізоляції розроблені для браузерів або іншого дуже специфічного програмного забезпечення.і вони погано поєднуються з універсальними інструментами розробки.
Практичним рішенням є запустити пісочницю Linux у WSL2Таким чином, ви переробляєте інструменти ізоляції Linux (Landlock, seccomp, простори імен тощо) на основі віртуалізації, яка ізолює сеанс розробки від хоста Windows. Одночасно ведеться скоординована робота з Microsoft для викриття нових примітивів, які зрештою дозволять створити більш нативну "пісочницю" для інструментів розробки.
Пісочниця Windows: ізольований простір, інтегрований у систему
Для тих, хто використовує Windows 10 або 11 у версіях Pro, Enterprise або Education, є особливо цікавий інструмент: Пісочниця WindowsЦе легка віртуальна машина, інтегрована в саму систему, яка дозволяє запускати ненадійні програми або підозрілі файли в одноразовому середовищі.
Ідея проста: коли ви відкриваєте Windows Sandbox, вона запускається тимчасовий, чистий робочий стіл Windows, ніби щойно встановленийВсе, що ви копіюєте або встановлюєте всередині нього — програми, документи, скрипти — існує лише в цьому екземплярі. Якщо ви закриєте вікно, середовище знищується: програмне забезпечення, файли та стан відкидаються, і наступного разу ви почнете все з нуля.
Основні характеристики Windows Sandbox
Ця функція має кілька дуже корисних властивостей для ручного створення пісочниці без використання сторонніх інструментів:
- Частина WindowsВсе необхідне вже включено до сумісних видань (Pro, Enterprise, Education). Вам не потрібно завантажувати образи чи обслуговувати зовнішні віртуальні машини.
- Одноразові та бездоганніКожен запуск такий же чистий, як і нова інсталяція Windows. Ніщо з того, що ви робите всередині, не зберігається на вашому пристрої після закриття середовища.
- Безпечний за конструкцієюВін спирається на апаратно-підтримувану віртуалізацію (Hyper-V) для ізоляції ядра "пісочниці" від ядра хоста. Він використовує гіпервізор Microsoft для розділення цих двох світів.
- Ефективний: запуск відбувається швидко, за лічені секунди, завдяки інтелектуальному управлінню пам'яттю та підтримці віртуальних графічних процесорів, використовуючи менше ресурсів, ніж традиційна віртуальна машина.
Технічно, це поводиться так невелика одноразова віртуальна машина Windows, що цілком підходить для тестування інсталяторів, відвідування сумнівних веб-сайтів або відкриття вкладень електронної пошти, яким ви не довіряєте працювати у вашій реальній системі.
Практичні сценарії використання Windows Sandbox
Існує кілька типових сценаріїв, коли Windows Sandbox є простим ручним рішенням для створення пісочниці:
- Спробуйте невідоме програмне забезпеченняКоли ви завантажуєте програму або виконуваний файл з Інтернету і не впевнені в його походженні, ви можете спочатку встановити його в «пісочниці» Windows і подивитися, як він поводиться без ризику для вашого комп’ютера.
- Безпечніший перегляд веб-сторінок: для Відвідування потенційно небезпечних веб-сайтів, сайтів зі шкідливим програмним забезпеченням або фішингових сайтівВи можете відкрити браузер усередині пісочниці. Якщо щось піде не так, просте закриття вікна видалить будь-які сліди.
- Відкриття ненадійних вкладень та файлівЯкщо ви отримуєте підозріле вкладення або ZIP-файл, який не викликає довіри, ви копіюєте його в пісочницю, відкриваєте там і після перевірки вирішуєте, чи варто щось витягувати у вашу справжню систему.
- Демонстрації та випробування конкретних інструментівВін ідеально підходить для створення демонстрацій програмного забезпечення, тестування попередніх версій, розширень або доповнень, не захаращуючи основну інсталяцію.
- Підтримуйте кілька окремих середовищ розробкиВи можете створити окремі, ізольовані простори для кожного мовного стеку або версії, наприклад пісочниця для кожної версії Python та її залежностейщоб експерименти не порушували ваше стабільне середовище.
Вимоги та ліцензії для використання Windows Sandbox
Не кожен може використовувати Windows Sandbox, але він вже доступний у багатьох професійних середовищах. Щоб увімкнути його на своєму комп’ютері, вам потрібно:
- Сумісний випуск WindowsWindows 10/11 Pro, Enterprise, Pro Education/SE або Education. Видання Home не підтримується.
- Підтримка віртуалізаціїВажливо мати функції віртуалізації в BIOS/UEFI (Intel VT-x, AMD-V або еквівалент).
- Мінімум ресурсівщонайменше 4 ГБ оперативної пам’яті (хоча рекомендується 8 ГБ), 1 ГБ вільного місця на диску — бажано SSD — та щонайменше 2 ядра процесора (в ідеалі 4 з гіперпоточністю).
- оновлена операційна системаПочинаючи з певних збірок (наприклад, збірка Windows 10 18305 і пізніших версій, а також сучасні збірки Windows 11). На ARM64 сумісність з'явилася з новішими збірками.
Щодо ліцензій, Видання Pro, Enterprise та Education включають право використовувати Windows Sandbox. Немає потреби платити за додаткові ліцензії на програмне забезпечення для віртуалізації. Просто активуйте його, і все готово.
Як активувати Windows Sandbox без додаткових інструментів
Щоб запустити його та запустити, вам не потрібно нічого, крім самої системи:
- Відкрийте меню «Пуск» і знайдіть потрібний пункт «Увімкнення та вимкнення функцій Windows».
- У списку функцій позначте Пісочниця Windows і підтвердити.
- Перезавантажте комп’ютер, коли буде запропоновано.
- Після перезавантаження знайдіть у меню «Пуск» «Пісочниця Windows» та запустіть її.
Якщо ви віддаєте перевагу більш технічному підходу, ви також можете ввімкнути його за допомогою PowerShell за допомогою команди Enable-WindowsOptionalFeature -FeatureName “Containers-DisposableClientVM” -All -Onlineза умови, що у вас є права адміністратора. Після активації пісочниця завжди буде доступна, коли вам знадобиться ця безпечна «друга машина».
Файли конфігурації та налаштування
Підтримка Windows Sandbox прості файли конфігурації, які дозволяють налаштовувати певні параметри середовищаНаприклад, монтування папок хоста в режимі читання або читання-запису, відключення мережі, запуск скриптів під час запуску тощо. Ці файли доступні, починаючи з певних збірок Windows 10 та 11.
На практиці ця можливість допомагає створювати «рецепти» пісочниці: конфігурація з вимкненим доступом до мережі для відкриття шкідливого програмного забезпеченняІнший варіант із папкою проекту, змонтованою в режимі лише для читання для перегляду файлів, або конфігурація, орієнтована на тестування програмного забезпечення, з певними інструментами, попередньо встановленими в базовому образі.
Як навчити агентів ШІ правильно використовувати пісочницю
Пісочниця справді ефективна лише тоді, коли Сам кодовий агент розуміє середовище, в якому він працює. і знає, коли може вільно працювати, а коли потребує додаткового дозволу або допомоги людини.
Щоб досягти цього, багатьом платформам довелося ретельно переглянути інфраструктуру, яка описує інструменти моделі. Наприклад, оновити описи інструментів оболонки, щоб чітко пояснити:
- Які обмеження накладає пісочниця? (доступ до файлової системи, git, мережі).
- Як може агент запит на оновлення дозволів коли щось не вдається через брак привілеїв.
- Які типи команд найімовірніше блокуватимуться?
Ці зміни не завжди виходять ідеальними з першого разу: зазвичай це вимагає Розширене ручне тестування реальних процесів розгортанняАналіз того, де очікування моделі руйнуються, та коригування підказок та інструкцій. Вимірюючи поведінку з використанням пісочниці та без неї у внутрішніх бенчмарках, виявляються моделі збоїв, такі як агенти, які Вони повторюють ту саму команду в циклі, який блокує пісочниця. замість того, щоб зрозуміти, що їм потрібно запитувати інші дозволи або змінювати свою стратегію.
Практичне покращення відобразиться в результатах роботи інструменту конкретна причина блокування, накладеного пісочницею і навіть явно пропонувати агенту запитувати підвищені дозволи, коли це доречно. Ця невелика підказка значно зменшує кількість сліпих повторних спроб і покращує відновлення після помилок, пов'язаних з ізоляцією, як в автономному тестуванні, так і в робочому середовищі.
Щоб пісочниця не погіршувала взаємодію з користувачем, багато компаній обрали розгортати його поступовоЗбір внутрішніх та зовнішніх відгуків перед активацією за замовчуванням. Дані зазвичай чіткі: значна частина запитів (наприклад, близько третини) зрештою обробляється в «пісочниці» на сумісних платформах, зі значним скороченням як часу очікування на схвалення, так і часу ручної перевірки.
Моделі ізоляції та уроки безпеки з реального світу
На практиці не існує єдиної «ідеальної пісочниці». Існують важливі відмінності між спільний контейнер ядра, пісочниця типу gVisor, мікровіртуальна машина та повноцінна віртуальна машинаЦей нюанс має значення, коли ми говоримо про те, щоб дозволити агенту запускати Docker, встановлювати довільні пакети або навіть запускати складні браузери та потоки.
Історичні інциденти безпеки підкреслюють важливість мудрого вибору: такі вразливості, як CVE-2019-5736 або CVE-2024-21626, що дозволяло переходити з контейнера на хост або маніпулювати системними бінарними файлами, демонструють, що коли межею довіри є середовище виконання контейнера на ядрі хоста, серйозна помилка може зруйнувати весь бар'єр.
Це стає більш делікатним з агентами кодування, оскільки вони часто виконують ненадійний код компіляції, збірка образів, встановлення залежностей без аудиту і загалом обробляють дуже різнорідні вхідні дані. Крім того, тиск «надати їм більше влади» є сильним: якщо вони не можуть використовувати певні інструменти, вони часто не виконують свої завдання.
Ось чому багато сучасних дизайнів пісочниць агентів, як правило, зміцнити межі за допомогою мікровіртуальних машин або легких віртуальних машинЦе відбувається за рахунок дещо підвищеної складності. Пряма залежність від ядра хоста зменшується, а також досягається додатковий рівень ізоляції від витоків контейнерів. У багатокористувацьких середовищах або при великомасштабному виконанні ненадійного коду gVisor або Kata Container займають золоту середину, жертвуючи сумісністю заради більшої ізоляції.
Людські схвалення, політичні схвалення та пісочниці: як все це поєднати
Одна закономірність, яка повторюється всюди, полягає в тому, що Заявки на багаторічні дозволи не масштабуються добреУ демонстраційному режимі агент може запитувати дозвіл, перш ніж торкатися файлу. У робочому режимі, з напівавтономними робочими процесами та багатьма дрібними діями, модель «натисніть OK для всього» перетворюється на сито.
Більш зрілий підхід поєднує кілька рівнів:
- Міцна пісочниця для захисту хоста та обмеження середовища виконання.
- Обмежувальна мережева політика контролювати, з якими кінцевими точками може спілкуватися агент.
- Керування обліковими даними через проксі-серверщоб модель використовувала їх, не бачачи.
- Версійні конфігурації на рівні проекту (дозволи, перехоплення, зовнішні сервери), щоб команди мали єдине джерело достовірної інформації в репозиторії.
- Субагенти лише для читання для дослідження та планування, залишаючи дії з письма більш контрольованим випадкам.
- Людське схвалення зарезервовано для справді делікатних дій: публікація пакетів, зміни інфраструктури, ротація секретів або надсилання до критичних гілок.
Крім того, варто врахувати, поверхня керування які ви надаєте агенту разом із власними файлами конфігурації, плагінами та навичками. Посібники від таких постачальників, як OpenAI, чітко попереджають, що розкриття відкритих каталогів можливостей або дозвіл будь-кому визначати потужні інструкції в репозиторії може призвести до витоку даних або руйнівних дій, якщо зловмиснику вдасться впровадити шкідливі інструкції у файли README, файли задач, документацію або файли зразків.
У продуманому дизайні пісочниця не розглядається як чарівний трюк, який виправляє безпеку одним махом, а як ще одна межа в архітектурі, яка включає політики, незалежну перевірку, ретельне управління секретами та перевірку конфігураціїТаким чином, навіть якщо припустити, що одного дня агент прочитає шкідливі інструкції та виконає їх, система розроблена таким чином, щоб обмежити вплив: немає прямого доступу до ключів, немає відкритої мережі та немає можливості таємно змінювати скрипти, які ви потім запускаєте на своїй реальній машині.
Зрештою, налаштування гарної ручної пісочниці без використання додаткового програмного забезпечення передбачає... Скористайтеся всіма перевагами того, що вам вже пропонують macOS та Linux. —Профілі Seatbelt, Landlock та seccomp, Windows Sandbox та WSL2 — у поєднанні з чіткими мережевими правилами, обліковими даними та керуванням життєвим циклом середовища. Додайте до цього агентів, навчених розуміти ці обмеження, розумні політики та певну дисципліну щодо того, до чого їм дозволено доступ у вашому робочому просторі, і ви зможете тестувати ризикований код, інструменти та файли з набагато більшим спокоєм, знаючи, що якщо щось піде не так, проблема залишиться в пісочниці та не виведе з ладу вашу систему чи критично важливі дані. Поділіться інформацією, щоб більше користувачів могли дізнатися про тему.