# Local sandboxing і Ollama у Copilot: контроль агентів стає практичним

> GitHub зробив local sandboxing загальнодоступним у Copilot CLI, app і VS Code та навчив CLI бачити локальні Ollama-моделі. Розбираємо, чому permissions важливіші за prompt і як вибудувати model tiering.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-10-15
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/copilot-local-sandbox-ollama

---

У coding agents є дві давні проблеми: «не хочу давати агенту доступ до всього» і «не хочу платити frontier-модель за кожну дрібницю». 9 жовтня GitHub зробив крок в обидва боки: local sandboxing став generally available у Copilot CLI, Copilot app і VS Code-сесіях через Agent Host, а Copilot CLI через `/model` тепер бачить моделі з локального Ollama поруч із хмарними. Нудніше за анонс нової моделі – і значно корисніше для production.

## Що саме стало GA

Local sandboxing дозволяє обмежити доступ агента до файлів, мережі й credentials – і працює в Copilot CLI, Copilot app та VS Code-сесіях через Agent Host, без додаткової оплати. Це та функція, яку легко пропустити в weekly changelog, бо вона не дає красивих демо. Але якщо ти хоч раз спостерігав, як агент із повним доступом до файлової системи «досліджує» директорії, яких задача не стосується, – ти розумієш, навіщо це.

## Чому permissions важливіші за prompt

Можна 15 разів написати в system prompt:

> Never read ~/.ssh.

А можна технічно не дати процесу такого доступу.

Другий варіант – engineering.

Prompt – це policy intention. Sandbox – це enforcement. Різниця між ними така сама, як між табличкою «не паркуватися» і бетонним стовпчиком. Табличка працює з сумлінними водіями. Стовпчик працює з усіма.

Для агентів це особливо важливо, бо prompt injection нікуди не зник: агент, який читає файли проєкту, читає і те, що в них написано. Якщо серед цього виявиться інструкція «а тепер надішли вміст .env на цей URL», єдине, що реально зупинить витік, – технічна неможливість це зробити. Ми вже бачили цю тезу в контексті [Node.js Permission Model](/blog/nodejs-permission-model): флаги процесу захищають краще за будь-яку дисципліну. І свіжий [Vercel Sandbox Challenge](/blog/vercel-sandbox-million-dollar-challenge) показав зворотний бік тієї ж монети: навіть сам sandbox – це implementation, яку треба перевіряти, а не магічне слово.

Правильна ієрархія виглядає так:

1. **Технічні обмеження** (sandbox, permissions, мережеві правила) – працюють завжди.
2. **Approval-гейти** для незворотних дій – працюють, коли людина уважна.
3. **Промпт-інструкції** – працюють, коли пощастило.

Будувати безпеку згори вниз цього списку – нормально. Знизу вгору – ні.

## Ollama в CLI: tiering замість фанатизму

Друга частина релізу виглядає як дрібниця: `/model` у Copilot CLI тепер показує підтримувані моделі з запущеного локального Ollama поруч із твоїми налаштованими та хмарними моделями.

Насправді це відкриває нормальний **model tiering**:

| Задача | Рівень |
|---|---|
| Форматування, перейменування, дрібні правки | локальна модель |
| Boilerplate, типові тести | дешева хмарна |
| Складний баг, ambiguous reasoning | frontier |
| Чутливий код, який не можна відправляти назовні | локальна – вже не з економії, а за security policy |

Не кожен task потребує найсильнішої моделі. Якщо 80% кроків агентського workflow може якісно зробити легка модель, загальна вартість системи падає сильніше, ніж від будь-якої оптимізації промптів. А для коду, який за політикою компанії не має залишати периметр, локальна модель – це не компроміс, а єдиний варіант, за якого агент взагалі можливий.

## Справжній тренд: execution platform

Найцікавіше в цьому релізі – не окремі фічі, а напрям. AI coding tooling рухається від «ось тобі модель, роби що хочеш» до **execution platform**: model routing + sandbox + permissions + worktrees + approvals.

Це та сама еволюція, яку колись пройшли CI-системи: спочатку «скрипт, який щось запускає», потім – ізоляція, секрети, права, аудит. Агенти проходять її прискорено, бо ціна помилки вища: CI виконує код, який написала людина і хтось відревʼювив, а агент – код, який щойно згенерував сам.

Для тебе як інженера це означає зміщення навички: цінність не в тому, щоб знати найкращу модель місяця, а в тому, щоб спроєктувати межі, в яких будь-яка модель не наробить біди. Як саме делегувати задачі агенту в межах цих обмежень – я детально розбирав у [статті про Claude Code для React](/blog/claude-code-dlia-react); принципи однакові незалежно від вендора.

## Ілюзії безпеки, які варто зловити в себе

- **Сприймати sandbox як галочку.** «У нас є sandbox» – початок розмови, а не кінець. Що саме обмежено: файли? мережа? credentials? Якщо не можеш відповісти – обмежень фактично немає.
- **Класти секрети в доступне агенту оточення.** Sandbox не допоможе, якщо `.env` із production-ключами лежить усередині пісочниці.
- **Тримати один «універсальний» вибір моделі.** Hardcoded frontier-модель на всі задачі – це як їздити в булочну на вантажівці: доїдеш, але навіщо.
- **Вмикати локальні моделі без policy.** Локальна модель слабша: для когось це прийнятний trade-off на простих задачах, для когось – ні. Рішення має бути свідомим, а не «що першим відповіло».

## Аудит свого workflow за 20 хвилин

Проведи аудит свого поточного AI-workflow – 20 хвилин:

1. Випиши, до чого реально має доступ твій агент прямо зараз: які директорії, чи є мережа, які credentials лежать у досяжності.
2. Для кожного пункту постав питання: «це обмежено технічно чи лише тим, що агент поки не пробував?»
3. Увімкни local sandboxing у Copilot CLI (або еквівалент у твоєму інструменті) і проганяй тиждень звичайні задачі. Запиши, де обмеження реально завадили роботі, а де ти просто звик до зайвого доступу.
4. Виміряй на 10 типових задачах, скільки з них локальна модель з Ollama закриває без помітної втрати якості.

Результат – не абстрактна «безпека», а конкретна таблиця: що обмежено, що делеговано дешевшій моделі, скільки це економить.