Ghost будує безпечний каркас для агентів
Розробник Ghost описав native macOS AI workspace версії 2.1.0: застосунок викликається через ⌥Space і поєднує чат, RAG, автоматизацію Mac, coding-agent задачі, календар, повідомлення й таймери. У системі близько 78 інструментів, 4 рівні ризику — Low, Medium, High, Blocked — і 3 режими підтвердження: Ask, Safe та Auto-run.
Ключова ідея — не давати LLM напряму торкатися файлової системи. Модель лише просить інструмент, а Ghost нормалізує шлях, перевіряє дозволи, виконує дію Swift-кодом і повертає машинний receipt. Команди в терміналі розділяються детерміновано: ! — виконати команду, > — віддати агенту.
Де варто прибрати здогадки моделі
У Ghost критична розвилка в термінальному блоці не віддана LLM. Якщо користувач вводить команду, застосунок сам визначає, що це: виконання команди чи задача для агента. Для цього є префікси ! і >, а також детерміновані перевірки. Модель підключається вже після цього — для планування агентської задачі, а не для рішення, чи запускати команду.
Такий самий принцип корисний у будь-якому бізнес-інструменті, де помилка класифікації має побічний ефект: відправити повідомлення, змінити календар, відредагувати файл, запустити shell-команду. Автор прямо формулює проблему: LLM-класифікатор може спрацювати у більшості випадків, але небезпечні саме ті випадки, де він «тихо вгадав неправильно».
- Для виконання команди використовуйте явний сигнал:
! run this command - Для агентської задачі використовуйте інший явний сигнал:
> plan this task - Класифікатор намірів може існувати, але лише як підказка для маршрутизації, не як механізм безпеки.
Файли, записи й видалення: модель просить, застосунок виконує
Головне правило Ghost: модель ніколи напряму не торкається файлової системи. Вона формує запит до інструмента, після чого Ghost нормалізує шлях, перевіряє дозволи, виконує дію власним Swift-кодом і повертає машинозчитуваний receipt. Це зменшує поверхню атак на кшталт path traversal і prompt injection: модель може вигадати будь-який шлях, але не отримує прямого доступу до open().
Другий приклад із джерела — перевірка побічних ефектів. Агенти часто кажуть «done», хоча фактично нічого не зробили. Тому кожен запис перевіряється проти реальної файлової системи: чи існує файл, чи він не порожній, чи шлях правильний. Якщо запис заявлений, але не підтверджений, це показується як помилка, а не приймається за успіх.
Третій приклад — undo journal. Для редагування файлів, календарних подій, нагадувань і закриття застосунків Ghost зберігає знімки стану до і після дії, щоб її можна було відкотити одним натисканням. Є дві виняткові дії — uninstall і junk-clean: вони переміщують об’єкти в Trash, і картка прямо це пояснює, а не показує непрацюючу кнопку Undo.
- Перед записом: нормалізувати шлях і перевірити дозволи.
- Після запису: перевірити фактичне існування, непорожній вміст і правильний шлях.
- Для редагувань: зберігати стан до і після, якщо дію треба робити оборотною.
- Для необоротних або особливих дій: не імітувати Undo, а прямо показувати реальну поведінку.
Рівні ризику замість одного перемикача «дозволити»
У Ghost близько 78 інструментів розкладені за чотирма рівнями: Low — read-only, Medium — створення, High — патчі, видалення й shell, Blocked — fail closed. Поверх цього є три режими підтвердження: Ask, Safe та Auto-run. Ідея не в тому, щоб один раз «довірити ШІ все», а в тому, щоб різні типи дій проходили різні правила.
Для дій, яких немає серед готових інструментів, є computer-use fallback: Ghost пише AppleScript і запускає його тільки після того, як користувач затвердить точний скрипт. У формулі автора: модель пропонує, людина вирішує. Це особливо важливо для нетехнічних команд: бухгалтерії, HR, юристів, фінансистів. Їм не треба читати внутрішній ланцюжок міркувань моделі, але треба бачити конкретну дію, яка змінить файл, подію, нагадування або застосунок.
- Read-only дії можна віднести до нижчого ризику.
- Створення нових об’єктів потребує окремого рівня контролю.
- Патчі, видалення й shell-команди треба вважати високим ризиком.
- Невідомі або заборонені дії мають завершуватись за принципом
Blocked, а не виконуватись «якось».
Межі підходу й що перевіряти людині
Підхід не прибирає потребу в людському рішенні. Автор прямо називає незручний компроміс: він обрав режими підтвердження за рівнями ризику, а не матриці дозволів по папках чи застосунках. Причина — надмірна гранулярність, яку користувачі не налаштовують, може перетворитися на security theater. Але запит на права запису по папках уже з’явився, тож межа не остаточна.
Окрема межа — локальні моделі. Ghost не відкидає слабші локальні моделі з Ollama або LM Studio, але перевіряє їх під час першого запуску: якість чату, JSON mode, native tool-calling, точність аргументів. Якщо модель не вміє native function calls, вона отримує managed tool loop. Для локальних провайдерів цей цикл зафіксований: немає escape hatch в agent mode.
Ще одна зона контролю — вихідні мережеві запити. Ghost блокує localhost, private IPv4 та IPv6, link-local і multicast; перевіряє всі адреси після DNS resolution; відхиляє редиректи на приватні призначення. Інакше агент може стати SSRF-вектором не гіршим за вебзастосунок.
- Перед довірою до результату перевірте receipt або інший машинозчитуваний доказ дії.
- Для файлів звірте фактичний шлях, наявність файлу й непорожній вміст.
- Для скриптів перегляньте точний AppleScript до запуску.
- Для локальних моделей перевірте tool-calling, JSON mode і точність аргументів.
- Для мережевих дій перевірте, що приватні адреси й редиректи на них заблоковані.