AI ФАКТОР

Ghost будує безпечний каркас для агентів

Кейс 13.08.2026
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 і точність аргументів.
  • Для мережевих дій перевірте, що приватні адреси й редиректи на них заблоковані.
Раніше в теміAnthropic веде Claude у юридичну практикуПізніше в теміCapital One ставить на власних AI-агентів
Читати в ТелеграміПрактика ШІ в бізнесі — щодня, без хайпу