Жёсткие контроли · Агенты · Черновик

Крошечный хост-агент: без модели, без входящего порта

Статус: это письменный замысел, черновик; он ещё не построен и не используется. Внедрение планируется сначала только с фактами и только на чтение, команды в последнюю очередь.

Большинство разговоров об ИИ-агентах — о том, что они могут. Эта статья — о детали, которая намеренно задумана делать очень мало: о небольшом агенте, который жил бы на хосте. В нём не было бы модели. Он сообщал бы факты о хосте, выполнял бы только команды из фиксированного списка, получал бы указания в виде подписанных сообщений через git и не слушал бы ни одного входящего порта.

Это самый маленький пример идеи, проходящей через всю серию: когда компонент нельзя сделать надёжным, просто вежливо попросив его, сделайте его настолько маленьким, чтобы доверять почти нечему.

Для чего он нужен

Некоторыми хостами ИИ-ассистент вообще не управляет. Их всё равно нужно знать и, в узких пределах, ими управлять: что на них работает, в каком они состоянии и горстка рутинных действий. Крошечный хост-агент задуман так, чтобы стоять на таком хосте и делать именно это и ничего больше.

Он делал бы три вещи. Сообщал бы факты о хосте. Получал бы указания как подписанные сообщения. Выполнял бы команду, только если она есть в его списке разрешённых.

Почему каждый выбор конструкции

Каждый выбор нужен ради того, что он отнимает у поверхности атаки.

Без модели. С моделью можно спорить: текст, который она читает, может направлять её действия. Небольшую фиксированную программу нельзя уговорить на действие, и она достаточно мала, чтобы человек прочитал и проверил её за один присест. Убрав модель, мы убираем с хоста целый класс манипуляций.

Список разрешённых. Агент отказывался бы от любой команды, которой нет в его списке. Тогда ошибка, плохое сообщение или поддельный запрос смогут достичь только того, что список допускает. Неизвестное значит отказ.

Подписанные сообщения. Хост действовал бы только по указаниям, подпись которых он может проверить. Возможности достучаться до канала недостаточно; указывать хосту может только владелец ключа подписи.

Git как канал. Хост сам спрашивал бы у git о новых сообщениях, а не ждал вызова. Каждое указание становится коммитом, так что история — запись того, что просили и кто, а для транспорта не нужно ничего особенного.

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

Одно сообщение, пять фиксированных шагов

Каждое сообщение проходило бы одни и те же шаги в одном и том же порядке: забрать его, проверить подпись, сверить команду со списком разрешённых, выполнить одну команду из списка, сообщить результат и факты о хосте. Если какой-то шаг не проходит, сообщение останавливается на нём. Без подписи, неизвестное или не из списка значит, что ничего не выполняется, и посередине нет рассуждения, на которое можно было бы надавить.

Чего это стоило бы

У малого и строгого есть цена.

• Гибкость. Новый вид задачи означает новую запись в списке разрешённых, которую нужно написать и проверить. В этом смысл, а ещё это трение.
• Управление ключами. Подпись требует ключей: кто-то должен их создавать, беречь, решать, кому подписывать, и менять при необходимости. Замысел требует, чтобы эта работа была сделана хорошо; как хранится ключ подписи — открытый вопрос замысла, и эта статья не описывает никакой конкретной настройки.
• Скорость. Хост, который опрашивает, узнаёт об указании при следующем опросе, а не мгновенно.
• Зависимость от git. Канал зависит от того, что сервис git доступен и ведёт себя как надо.
• Диагностика. Фиксированная программа с узким выводом мало что говорит, когда что-то идёт не так, поэтому отчётность и журналирование требуют внимания.

От чего этот замысел не защищает

Назвать пределы важнее, чем перечислить сильные стороны.

Ключ подписи. Тот, у кого ключ подписи, может отправлять действительные сообщения. Список разрешённых ограничивает, о чём можно просить, но вредное действие, которое есть в списке, было бы выполнено. Как хранится ключ и как его заменять — открытый вопрос замысла.

Повтор. Настоящее подписанное сообщение можно отправить снова позже. Замысел требует способа отличать свежие сообщения от старых, например срока действия или счётчика; без него повтор возможен.

Скомпрометированный сервис git. Сервис не может подделать подписи, но может удерживать сообщения, задерживать их или показывать старые. Это влияет на доступность и свежесть, а не на подлинность.

Плохой список разрешённых. Список разрешённых — настоящая граница прав. Он безопасен настолько, насколько безопасны его записи и принимаемые ими аргументы; широкая запись — это широкое разрешение.

Скомпрометированный хост. Захваченный хост может сообщать о себе ложные факты. Ущерб ограничен собственными путями этого хоста: по этому замыслу он не добрался бы до других хостов.

Эти риски сужались бы малыми списками разрешённых с фиксированными аргументами, свежими сообщениями, аккуратным обращением с ключами и мониторингом того, что сообщает хост. Они не устраняются.

Как это вписывается в остальную серию

Хост-агент был бы нижним слоем той же картины. Агенты выше предлагают, люди одобряют, а подписанные, записанные сообщения несут одобренное указание вниз. Внизу была бы деталь, которая следует своему списку и ведёт запись, и которой почти нечего атаковать.