Віддалені виконавці

Дайте агенту справжній комп’ютер для роботи — під Linux, macOS або Windows.

Що таке віддалений виконавець

Агент у Nessie не має комп’ютера. Він може читати те, що є в Nessie, спілкуватися з людьми й викликати підключені інструменти через мережу, але не може відкрити файл на ноутбуці, виконати команду чи переглянути сторінку, яка існує лише за чиїмось логіном. Віддалений виконавець дає агенту машину, з якою він може працювати.

Виконавець — це невеликий демон, який ви встановлюєте на комп’ютер під своїм контролем. Він спарюється з вашим екземпляром Nessie назовні, доводить, яка це машина, за допомогою ключа, що ніколи не покидає хост, а потім пропонує фіксований набір іменованих операцій і нічого більше. Робота надходить окремими підписаними командами; результати повертаються як обмежені структуровані квитанції. Машина ніколи не приймає вхідного з’єднання від Nessie.

Варто точно розуміти, чим виконавець не є, адже більшість інструментів віддаленого доступу належить до одного з цих типів, а виконавець навмисно не є жодним із них. Тут немає SSH, немає загальної віддаленої оболонки, немає підключення до термінального мультиплексора, який у вас уже відкрито, немає стандартного вводу з боку хмари й немає загального проксі для локальної мережі. Виконавець не є MCP-сервером, не є контейнером чи хмарним середовищем виконання: Nessie вже має такі речі, і це інші речі. Виконавець — це кінцева точка з визначеними повноваженнями та закритим переліком операцій, і цей перелік і є всією поверхнею.

Кому належить виконавець

Кожен виконавець створюється з рівно однією областю дії, і згодом її змінити не можна. Вона визначає, хто може викликати виконавця і хто ним адмініструє.

Приватний виконавець завжди має мати принаймні одного активного адміністратора-людину. Видалити останнього напряму не вдасться; якщо транзакція, що відключає співробітника, залишила б жодного, виконавець перестає приймати нову роботу, завершує те, що вже має, і відкликає сам себе. Власник організації має аварійний шлях лише для відкликання, яким можна завершити виконавця, яким він не керує, не показуючи йому ні приватний список учасників, ні сесії, ні вміст. Приватний доступ ніколи мовчки не передається іншій особі.

Що агент справді може робити з виконавцем

Перелік операцій зафіксовано в коді, а не налаштовується для кожного розгортання. Він поділяється на дві частини, і саме цей поділ визначає, що вам треба встановити: деякі операції демон обслуговує з власного тимчасового каталогу без жодної віртуальної машини, а решта потребує гостьової ВМ на хості для кожного сеансу.

Операції, яким не потрібна гостьова система, становлять пакет робочого простору. Хост, який не може запустити гостьову систему, не є зламаним виконавцем: він спарюється звичайним чином, повідомляє про свій бекенд пісочниці як none і пропонує лише пакет робочого простору та нічого більше. Саме в такому стані опиняється видання Windows без Hyper-V або машина Linux, чий користувач не має доступу до /dev/kvm, і інтерфейс прямо про це повідомляє, а не відмовляє незрозуміло.

Агент ніколи не починає роботу з браузером за власною ініціативою. Звичайний маршрут прив’язки однієї операції прямо відхиляє browser.open і browser.observe. Запуск браузера виконує людина з каналу як один пакет із чотирьох операцій у новому запуску, і після цього до нього вже не можна додати жодну прив’язку. Керовані сесії кодування працюють так само.

Ще дві групи існують у коді, але навмисно недоступні. Операції для керування вкладкою Chrome, в яку ви вже увійшли, мають повну локальну реалізацію і розширення для native messaging, але площина керування відмовляється їх рекламувати, доки сервер не зможе довести, що розмова-джерело була приватною, і записати, хто що розкрив. Основа навмисно неактивна, а розширення не поставляється в жодному з інсталяторів. А кілька операцій кодування — attach, prompt, interrupt і close — названо в схемі, але їх не реалізовано, тож їх не можна надати.

Як це працює

Підключення завжди вихідне

Демон встановлює вихідні з’єднання HTTPS і WSS лише з вашим API Nessie і ні з чим іншим. Nessie ніколи не звертається до ноутбука, не зберігає його адреси й ніколи не розглядає жодну кінцеву точку каталогу як транспорт до машини. Тому виконавець працює з домашньої мережі, за NAT, у корпоративному VPN, без перенаправлення портів і без правила вхідного брандмауера. Саме тому зупинка демона є повним і миттєвим відключенням.

Джерело API має бути HTTPS. Єдиний виняток — локальна петльова адреса (loopback) для людей, які запускають Nessie на власному комп’ютері, через окрему змінну середовища. Жоден звичайний прапорець не перетворює продакшн-джерело на звичайний HTTP.

Спарювання підтверджує машину, а людина його підтверджує

Спарювання — це двосторонній доказ. Уповноважена особа створює виконавця у Nessie з його областю дії, і Nessie видає реєстрацію: 256-бітний випадковий виклик, від якого зберігається лише перевірочний SHA-256. Реєстрація чинна десять хвилин і придатна для використання один раз.

На машині демон створює пару ключів Ed25519, зберігає її в захищеному засобами ОС сховищі, доступному лише власнику, і записує точний підписаний запит на диск до будь-якого мережевого виклику. Так у разі втраченої відповіді можна повторити запит із тим самим підготовленим ключем, а не тихо спаритися двічі. Далі демон надсилає ідентифікатор реєстрації, виклик, свій публічний ключ і підпис доказу. Nessie зберігає публічний ключ і його відбиток. Приватний ключ Nessie ніколи не зберігає.

Потім Nessie показує цей відбиток людині, яка його підтверджує. Доки немає такого підтвердження та наступного доказу володіння, виконавець залишається офлайн. Спарювання ніколи не можна завершити з тексту чату чи з журналу терміналу: для цього потрібна свідома дія людини у веб- або настільному інтерфейсі.

Машина, яка втратила свій ключ, не може повернути собі запис виконавця. Його відкликають і реєструють знову як нового виконавця. Натомість ротація ключа — це одна транзакція, підписана одночасно старим і новим ключем.

Дескриптор — це підписана заява машини про себе

Спарений демон публікує дескриптор: підписану заяву з монотонно зростаючою версією, що містить лише структурні факти — які схеми операцій він підтримує, його ліміти ресурсів і мережі, платформу та дайджест його локальної політики. Він не містить шляхів на хості й не створює жодних повноважень у хмарі.

Нова версія ніколи не активується одразу після надходження. Її зберігають як таку, що очікує перевірки, і уповноважена особа має її побачити й підтвердити, перш ніж вона вплине на те, що доступно. Саме це не дає оновленню можливостей мовчки надати нову силу: нововиявлена операція спочатку відхиляється.

Зрозумійте, що саме доводить підпис. Дескриптор, підписаний ключем спареного виконавця, доводить, що цей ключ зробив заяву. Він не доводить, що хост не скомпрометовано, і інтерфейс зобов’язаний це прямо сказати.

Диспетчеризація: кандидат, прив’язка, команда, квитанція

Агент ніколи не називає виконавця. Перш ніж запуск зможе його використати, Nessie перетворює логічну операцію на непрозорий короткоживучий кандидат доступності. Відповідь не містить ідентифікатора виконавця, а база даних зберігає лише дайджест маркера разом із тим, для кого і для чого його видано. Моделі та клієнти отримують маркер, а не машину, яку можна вибрати.

Доступність визначає один розв’язувач, який однаково використовують API, воркер, інтерфейс і асистент:

available(operation, human, agent, immutableRunContext) =
  human may discover executor
  ∩ exact executor-agent-operation grant allows operation
  ∩ stable logical tool grant allows operation
  ∩ scope matches immutable run context
  ∩ executor is online and descriptor is approved
  ∩ local policy permits operation

Споживання кандидата створює прив’язку під блокуванням у базі даних. Це блокування ще раз перевіряє кожен із цих шлюзів і просуває монотонний лічильник fence. Диспетчеризація перевіряє їх знову. Наслідок такий: якщо доступ відкликано, політику звужено або виконавця відключено між двома кроками, робота зупиняється, а не виявляється пізніше. Повторна спроба ніколи не потрапить на іншу машину, ніж та, до якої прив’язано запуск.

Сама команда йде через звичайну чергу завдань Nessie і життєвий цикл викликів інструментів, а не через власну другу чергу. Демон опитує роботу через свій автентифікований канал керування, до нього ніколи не надсилають push. Команда проходить через чотири квитанції і жодних інших:

leased → accepted → started → result-acknowledged

Кожен кадр прив’язує ідентифікатор команди, походження запуску, fence прив’язки, версію можливостей, термін дії, ключ ідемпотентності та дайджести аргументів і корисного навантаження. Демон відхиляє невідповідність, застарілу політику, повтор або другий результат для команди, яку вже завершив. Аргументи та термінальні результати шифруються AES-256-GCM у стані спокою. База даних зберігає обмежений шифротекст і канонічні дайджести, а не вміст.

Якщо підтвердження загубилося, Nessie не вважає, що операція вдалася. Команду записують як результат із невідомим статусом, і запуск іде звичайним шляхом відновлення. Демон, який записує кожну доставлену команду у свій локальний журнал до початку роботи, не повторить побічний ефект. Запізніла квитанція все ще може чесно зняти невизначеність.

Межа довіри

Встановлення та спарювання виконавця

Встановіть CLI для Mac через Homebrew, застосунки для Mac через cask-пакети Homebrew, CLI для Linux через APT або DNF, а виконавця для Windows через WinGet. Кожна команда зі спарюванням має окремі дозволи, що зберігаються на комп’ютері. Nessie керує доступом у межах команди, але не може змінювати локальні ресурси.

У посібнику з встановлення та спарювання є точні команди, двосторонній процес із восьмизначним кодом, локальні налаштування, запуск, оновлення та видалення.

Наскільки добре кожну платформу справді перевірено

Стан трьох гостьових пісочниць відрізняється, і ця різниця суттєва. macOS — це бекенд із працюючим, перевіреним гостьовим шляхом. Бекенд Firecracker на Linux і бекенд Hyper-V на Windows реалізовано й покрито тестами на боці хоста: послідовність запуску, образи дисків, транспорти керування й виходу в мережу, протокол чернеток. Але жодна гостьова система ще не запускалася на реальному апаратному забезпеченні в безперервній інтеграції цього проєкту, бо для цього потрібна машина з KVM або Hyper-V, а завдання, яке мало б це довести, ніколи такої машини не мало. Пакет робочого простору, якому гостьова система не потрібна, перевірено від початку до кінця на Windows на реальному циклі керування. Вважайте операції з гостьовою системою на Linux і Windows недоведеними, доки не перевірите їх на власному обладнанні. Екран спарювання в Nessie каже те саме своїми словами.

Безпека і ізоляція

Єдиний корінь робочого простору, а його шлях залишається на машині

Спарювання вибирає рівно один канонічний корінь робочого простору: один каталог, а не набір папок і ніколи не їхнього найближчого спільного батьківського каталогу. Nessie повідомляють базову назву кореня, щоб людина могла впізнати межу в інтерфейсі. Повний шлях зберігається в стані машини, доступному лише власнику, і ніколи не вивантажується. Змінити корінь можна, але лише після видалення всіх локальних чернеток і пісочниць. Зміна створює нову версію дескриптора, яка проходить той самий людський перегляд, що й будь-яка інша зміна політики. Корінь ніколи мовчки не розширюється до батьківського каталогу.

Файлові операції приймають лише відносні шляхи. Вони відхиляють обхід каталогів і кожен компонент, що є символічним посиланням. Вони повторно перевіряють, що налаштований корінь досі є звичайним каталогом, і повертають обмежені структуровані результати без шляхів на хості.

Записи йдуть у копію, а застосовує їх лише людина

Агент ніколи не пише у ваші файли. file.write створює обмежене дерево copy-on-write у власному каталозі стану демона, прив’язане до запуску, і подальші читання та переліки для цього запуску бачать чернетку. Робота в гостьовій системі, зокрема сесії кодування, використовує той самий тимчасовий простір copy-on-write.

Застосування чернетки до справжнього робочого простору — це одна операція, workspace.promote, і це єдиний запис на хості в системі. Для моделей у неї взагалі немає схеми: жоден агент, жоден асистент і жоден шлях, переданий викликачем, не може перетворити чернетку на запис на хості. Натомість людина відкриває Ваші перевірені чернетки, натискає Перевірити застосування і підтверджує поточним паролем. Сервер тоді повторно перевіряє підтверджений дайджест перегляду, дайджест маніфесту, запуск, користувача й агента, якими його створено, версію авторизації, грант на операцію та активну локальну політику, перш ніж створити команду. На машині демон сам перебудовує маніфест і відмовляє в дайджесті, який змінився. Тож правка, зроблена після перегляду, не може проскочити разом із його схваленням.

Саме застосування базується на дескрипторах файлів і веде журнал. Нативний помічник отримує корінь робочого простору та чернетку як уже відкриті дескриптори каталогів, а не як шляхи. Він перевіряє кожен компонент операціями без переходу за посиланнями, відмовляє в символічних і жорстких посиланнях, спеціальних файлах і перетинах точок монтування, і веде журнал «усе або відновлення». Тому збій або завершує перевірений маніфест, або відновлює початковий стан до того, як запуститься щось інше.

У гостьовій системі немає мережі, а вихід назовні примусово проходить через шлюз

Коли операції справді потрібна гостьова система, це мікро-ВМ Linux на кожен сеанс: без домашнього каталогу хоста, без сокета Docker, без агента SSH, без успадкованого середовища і без монтування хоста, крім спільного доступу до робочого простору. Виконуване монтування середовища виконання доступне лише для читання, а монтування записуваного робочого простору забороняє виконання. Тож усе, що запускається, походить із перевіреного корисного навантаження середовища виконання, а не з того, що написав агент. Гість переходить до непривілейованої ідентичності, перш ніж відкрити будь-який сокет, а спільний ресурс, що належить root, спричиняє збій завантаження, а не залишає привілейоване навантаження працювати.

Найважливіше: у гостьовій системі немає мережевого інтерфейсу. У Linux послідовність запуску навмисно ніколи його не налаштовує, і пристрій TAP не створюється. У Windows віртуальний мережевий адаптер, який Hyper-V додає за замовчуванням, видаляють під час встановлення. Єдиний маршрут гостя назовні — це проксі loopback усередині нього, який тунелюється через віртуальний сокет до моста на хості й передає байти власному шлюзу демона. Цей шлюз — слухач локального сокета з доступом лише для власника, без слухача TCP і без режиму загального переспрямування. Саме там застосовується політика HTTP, CONNECT, WebSocket, перенаправлень, походження, завантажень і вивантажень, через наявний механізм закріпленого отримання Nessie, а не через другу реалізацію тих самих правил. NAT-моста немає, як і прямого розв’язувача DNS: альтернативний DNS, сирий TCP, QUIC і обхід проксі заборонені.

Список джерел, який застосовує шлюз, налаштовує на машині її власник, і цей список навмисно ніколи не вивантажується. Інтерфейс прямо називає цю відсутність, а не вдає, що Nessie — це редактор політики джерел. Щоб дізнатися, до чого може дістатися браузерний виконавець, запитайте людину, яка володіє машиною.

Облікові дані

Жодне сховище облікових даних хоста ніколи не монтується в гостьову систему. Ні зв’язка ключів, ні ~/.codex чи ~/.claude, ні глобальний токен CLI, ні змінна середовища з ключем API. Єдиний підтримуваний вхід для керованої сесії кодування — це файл автентифікації, доступний лише власнику. Його вміст читає виключно побудовник initrd, яким керує власник, — ніколи Nessie, ніколи дескриптор, ніколи журнал чи аргумент команди. Потім файл один раз переноситься в приватний домашній каталог усередині гостя, який знищується разом із ВМ. Цей гість може дістатися рівно до одного джерела.

Браузерний виконавець суворіший: кожен сеанс отримує новий приватний профіль браузера і відмовляється від профілю, підготовленого робочим простором. Тож він починає без cookies, без розширень і без успадкованого стану входу в облікові записи.

Сирі локальні дані можуть потрапити до постачальника моделі лише всередині явного, обмеженого запуску. Nessie зберігає знеособлені маніфести, дайджести аргументів і політик, дайджести результатів і структурований статус. Вміст файлів, термінальний вивід, DOM браузера, облікові дані та фактори автентифікації заборонено записувати в записи бази даних, журнали аудиту, логи, події реального часу й звіти про помилки.

Що надає оператор і як він це відкликає

Право використовувати виконавця — це не один перемикач. Агент може викликати операцію, лише якщо має грант на саме того виконавця і саме цю операцію, і звичайна логічна політика інструментів це дозволяє, і область запуску збігається, і власна локальна політика машини це дозволяє. Тому надання одному виконавцю операції нічого не дає на іншому. Оновлення можливостей також нічого не розширює, бо нові операції спочатку відхиляються.

Доступ агентів і спільний доступ набувають чинності одразу на самій сторінці, без продовження схвалення, запиту пароля чи кроку повторної автентифікації. На вкладці Агенти виконавця керівник вмикає або вимикає доступ агента до машини напряму. На вкладці Спільний доступ він надає особі право «Може використовувати» або «Адміністратор» чи поширює використання на проєкт або на всіх у поточній команді так само. У вашій власній розмові з асистентом — лише там, ніколи в спільному каналі, у запланованому завданні чи запуску іншого агента — асистент може натомість підготувати зміну доступу агента або призначення, і така підготовка публікує картку підтвердження в цій розмові. Нічого не зміниться, доки ви не натиснете «Дозволити доступ» на ній, а текст чату ніколи не є підтвердженням.

Три зміни досі потребують повторного введення поточного пароля в момент підтвердження: активація версії дескриптора; призначення, підготовлене асистентом, яке дає машину особі, а не агенту; та постійна політика, що дозволяє колегам запускати на ній команди від імені її власника, — політика роботи із завданнями без нагляду. Вимкнення або видалення машини навмисно не вимагають ні того, ні іншого, бо аварійний вимикач ніколи не повинен бути важчим для доступу, ніж те, що він зупиняє. Застосування перевіреної чернетки завжди вимагає пароля. Журнал аудиту окремо фіксує, яка людина діяла і яку участь мав асистент.

Виконавець переходить через невеликий, явний набір станів:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

У меню Комп’ютер у заголовку керівник готує кожну зміну життєвого циклу: призупинити, відновити після призупинення, відключити або видалити. Призупинення залишає виконавця в мережі, але зупиняє прийом команд. Відключення анулює його клієнтські сертифікати та всі незавершені маркери кандидатів і не може бути скасоване: відключений виконавець реєструється знову як новий. Видалення робить те саме і додатково прибирає виконавця зі списку. На відміну від відключення, його пропонують незалежно від стану виконавця, зокрема для очікуваних спарювань і вже відключених, бо це єдиний спосіб вийти зі списку. Осушення — завершення вже наявної роботи до того, як виконавець перестане приймати нову, — є справжнім третім станом у протоколі. Інтерфейс може показати комп’ютер у цьому стані, але нічого тут його не запускає: лише прямий виклик API. Кожна підтверджена зміна доступу, перегляд дескриптора та перехід життєвого циклу, включно з осушенням, також просуває епоху з’єднання демона. Тож його наступне опитування керування, щонайбільше за секунду, завершується відмовою і зупиняє кожну живу гостьову систему, перш ніж вона зможе перепідключитися. Відкликання — це запит, який машина не може ігнорувати.

Експлуатація виконавця

Перевірка, що він працює справно

Власна відповідь Nessie — це перевірка живості. Демон підписує сигнал активності (heartbeat), і виконавець, чия остання автентифікована активність старша за шістдесят секунд, стійко позначається як офлайн. Це відбувається раніше, ніж його можна буде перелічити, обрати або надіслати йому роботу. Виконавець, що показується онлайн, підтвердив себе протягом останньої хвилини.

На машині немає кінцевої точки перевірки стану: демон з задуму не слухає жодного порту для оператора. У macOS і Linux запитуйте CLI напряму:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

У macOS статус показує launchd-агент кожної команди. Команда systemctl працює лише в Linux. У Windows відповідь видно на піктограмі в системному лотку, її меню називає причину, а журнал служби містить деталі. На обох платформах вкладка Огляд у Nessie показує затверджені профілі виконавця, його межу даних, час останньої активності та будь-яку локальну пропозицію політики, що очікує на перегляд.

Журнали

Туди потрапляє кожна відмова, на яку людина може відреагувати: непідписане або підроблене середовище виконання, каталог стану, який не вдалося захистити, виконавець, що не запустився під час завантаження. Туди ніколи не потрапляють виклик спарювання, ключі чи вивід дочірнього процесу. Немає налаштування рівня журналювання, який можна підвищити, бо більш детального режиму просто не існує.

CLI для Mac записує журнал служби кожної команди до ~/Library/Logs/NessieExecutor/<executorId>.log.

Оновлення

Оновіть CLI через Homebrew, APT або DNF, а потім перезапустіть службу кожної команди, спершу виконавши disable, а потім enable. WinGet оновлює виконавця для Windows. Прямі інсталятори Nessie Desktop пропонують підписані оновлення всередині застосунку, а інсталяції MSI і Debian використовують власний менеджер пакетів. Спарювання та локальні дозволи переживають оновлення.

Зупинка і видалення

Зупинка — це коректний шлях, яким керує сам демон, а не примусове завершення. Він отримує сигнал завершення, зупиняє кожен гостьовий сеанс, звільняє свою оренду й завершується. У Linux юніт чекає п’ятнадцять секунд за бюджету на завершення в десять секунд і навмисно ніколи не переходить до неперехопного kill. Причина проста: демон, убитий посеред завершення, залишає мікро-ВМ і оверлей робочого простору без жодного процесу, який би їх прибрав. Зупинка, що зависла, тому видима в systemctl --user status, а не непомітна. Переходити до примусового завершення може лише людина, і це її явне рішення.

Щоб видалити пакет у Linux:

nessie-executor disable <executorId>   # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger                # only if your user manager should stop running at boot too

У Windows msiexec /x зупиняє й видаляє службу, її записи реєстру та запис автозапуску лотка. На обох платформах спарений стан навмисно залишається: ~/.local/state/nessie-executor/ у Linux і %ProgramData%\Nessie Executor у Windows. Спарювання — це ключ машини та підписана версія політики, а видалення програми не є запитом знищити їх. Після перевстановлення все знову знайдеться там, де було. Щоб забути спарювання, видаліть каталог вручну, а щоб завершити його з іншого боку, відкличте виконавця у Nessie.

Пункт системного лотка у Windows і настільний супутній застосунок пропонують Забути спарювання на цьому комп’ютері як окрему дію. Вона зупиняє локальний демон, видаляє ключ машини й вибір папки та безповоротно видаляє локальні копії чернеток після одного підтвердження засобами системи. Серверний виконавець і його історія аудиту при цьому залишаються, щоб власник міг їх зберегти або відкликати.

Типові помилки