Короткий ответ
#Сорок пунктов без порядка
После первого серьёзного разговора о безопасности агентов у команды появляется список. Я видел такие списки много раз, и они похожи друг на друга. В нём сорок пунктов: от «убрать общий ключ из конфигурации» до «внедрить мониторинг поведения агентов». У каждого пункта стоит приоритет «высокий», потому что низкий приоритет в таком списке выглядит безответственно.
Через квартал картина обычно такая. Сделано шесть пунктов, и это те шесть, которые было интереснее делать. Один инженер месяц выбирал шлюз для инструментов. Общий административный ключ всё ещё лежит в конфигурации, потому что его замена скучная и затрагивает всё. На вопрос руководителя «мы стали безопаснее?» честного ответа нет. Сделанное не складывается ни в какое состояние, которое можно назвать.
Дело не в лени и не в нехватке людей. У списка нет последовательности и нет критерия завершённости. Непонятно, что идёт первым, и непонятно, когда можно остановиться.
#Зачем здесь уровни
Модель зрелости отвечает ровно на эти два вопроса. Она раскладывает меры по ступеням так, что каждая ступень опирается на предыдущую. И она даёт каждой ступени название, по которому можно сказать «здесь мы стоим» и «сюда нам не надо».
Порядок важен, потому что меры верхних уровней не работают без нижних. Мониторинг поведения агента бесполезен, если агент ходит под общим ключом: в журнале видно, что «сервис что-то удалил», и не видно, какой из семи агентов это был. Общий шлюз с политиками мало что даёт, пока инструменты можно вызвать в обход шлюза старым токеном. Деньги, потраченные наверху при дырявом низе, покупают ощущение, а не защиту.
Отсутствие порядка стоит дорого, и счёт растёт. Каждый месяц добавляется новый агент или новый инструмент. Если базовый уровень не закрыт, каждый новый агент наследует общий ключ и отсутствие лимитов. Через год исправлять придётся не одного агента, а двенадцать, и у каждого уже будут пользователи, которые привыкли, что он «всё может».
#Пять уровней
- Уровень зрелости
- Состояние агентной системы, в котором определённый набор защитных мер действует в момент исполнения и может быть показан проверяющему на живой системе.
- Если проще Набор ограничений, которые уже работают сами, без надежды на аккуратность модели и людей.
-
Уровень 0. Эксперимент
Агент работает с ноутбука разработчика или с тестового сервера под широким ключом. Лимитов нет, журнала нет, правила записаны в инструкции для модели. Для прототипа на выдуманных данных это нормальное состояние.
Опасным его делает одно: настоящие данные. Уровень 0 с рабочей базой это уже не эксперимент, а инцидент, у которого пока нет даты.
-
Уровень 1. Базовый
У каждого агента свои учётные данные с правами только на свой сценарий. Секреты живут на сервере и не попадают в текст для модели. Есть лимиты на объём и сумму, журнал действий и подтверждение человеком для необратимого.
Это минимум для любой системы с настоящими пользователями. Он не требует покупок и закрывается за недели.
-
Уровень 2. Управляемый
У агента есть собственная идентичность, и каждое его действие можно отличить от действий людей и других агентов. Политики записаны явно, лежат вне промпта и проверяются там, где действие исполняется. Код и файлы извне исполняются в песочнице. Исходящие соединения разрешены по списку. Изменения инструментов и инструкций проходят ревью.
Сюда переходят, когда агент начинает писать в важные системы, исполнять чужой код или работать с чувствительными данными.
-
Уровень 3. Платформа
Общий слой для многих агентов и команд: реестр агентов, каталог одобренных инструментов, единый шлюз, который применяет политики, общая идентичность, централизованный контроль выхода наружу и аварийный выключатель.
Оправдан, когда агентов десятки, а команды начали переписывать одно и то же. Для одного агента это дорогая избыточность.
-
Уровень 4. Измеримая устойчивость
Защиту регулярно атакуют сами: тесты на обход, учения по инцидентам, наблюдение за поведением агентов. Есть числа, за которыми следят: время до обнаружения, время до остановки агента, доля действий, прошедших через шлюз. У агента есть формальный жизненный цикл от заявки до вывода из работы.
Нужен там, где агенты стали критической инфраструктурой. Большинству компаний он не нужен, и это нормально.
Каждая ступень стоит на предыдущей. Пунктирная дуга нарисована так, как на этом сайте рисуют всё неустановленное: прыжок через три уровня существует только на слайде.
#Чем подтверждается уровень
Уровень нельзя объявить. Его можно только показать. Главное правило оценки простое: считается то, что ограничение делает в момент исполнения. Написанное в регламенте не считается. Документ «агентам запрещено удалять данные» ничего не стоит, если у агента есть право на удаление.
| Уровень | Доказательство | Типичная дыра |
|---|---|---|
| 1. Базовый | Список ключей агентов с правами каждого. Запись в журнале о любом вчерашнем действии. Попытка превысить лимит, которая получила отказ. | Старый общий ключ не отозван и лежит в конфигурации «на всякий случай». |
| 2. Управляемый | Политики в репозитории с тестами. Записи об отказах в журнале. Попытка соединиться с адресом не из списка, которая не прошла. | Политика проверяется в одном сервисе, а тот же инструмент доступен из второго без проверки. |
| 3. Платформа | Реестр совпадает с реальностью: в сети нет агента, которого нет в реестре. Аварийный выключатель опробован, время остановки известно. | Команда, которая спешила, подключила агента в обход шлюза, и про это знают трое. |
| 4. Измеримый | Ряды чисел за полгода, отчёты об учениях, закрытые находки с датами. | Метрики собираются, но на них никто не смотрит и по ним ничего не решают. |
Обратите внимание на правый столбец. На каждом уровне типичная дыра одна и та же по природе: обходной путь, оставшийся с предыдущего уровня. Поэтому оценка начинается с вопроса «как это можно сделать мимо защиты», а не с вопроса «какая защита у нас есть».
#Что запускает переход
Переход на следующий уровень запускают три величины. Это число агентов, чувствительность данных и размер ущерба от одной ошибки. Календарь и мода его не запускают. Пока все три малы, подниматься выше базового уровня незачем.
Хороший пример даёт аналитический агент, который отвечает на вопросы по базе данных и сам пишет SQL. На базовом уровне у него отдельный пользователь базы с правом только на чтение, и этого хватает, пока он читает таблицу заказов небольшого магазина. Потом ему открывают таблицы с персональными данными. Чувствительность выросла, и простого «только чтение» стало мало: право читать не мешает выгрузить всю таблицу одним запросом. Это триггер перехода на второй уровень для этого агента. Ему дают отдельную реплику вместо рабочей базы, потолок на число строк и время запроса и подготовленные запросы с параметрами вместо склейки строк. Изменение структуры и запись запрещают на уровне прав базы. Фраза в инструкции для этого не годится.
Пора ли вам строить платформенный слой
Два ответа «да» это повод начать проектирование. Ни одного означает, что платформа пока будет стоить больше, чем беречь.
- Агентов больше десяти, и у них разные владельцы? До этого порога реестр помещается в одну таблицу, которую ведёт один человек.
- Работу с токенами и журналом уже написали в третий раз в третьей команде? Три копии расходятся. Общий слой дешевле их сопровождения.
- Можете ли вы за минуту остановить всех агентов сразу? Если нет и агентов много, аварийный выключатель окупается в первый же инцидент.
- Знаете ли вы полный список внешних адресов, куда агенты отправляют данные? Без центрального контроля выхода этот список собирают опросом, и он всегда неполон.
- Подключают ли команды сторонние серверы инструментов без общего согласования? Каталог одобренных инструментов нужен в тот момент, когда их перестал знать один человек.
#Уровень ставят агенту, а не компании
Самая частая ошибка в применении модели это одна цель для всех. «К концу года вся компания на третьем уровне» звучит как план и не является им. У агентов разный радиус ущерба, и цель у них должна быть разной.
Агент, который пишет черновики постов из открытых материалов, может годами жить на базовом уровне, и это правильное решение. Агент, который двигает деньги, должен быть на втором уровне с первого дня, даже если он в компании один. Для кодового агента с доступом к репозиторию и терминалу второй уровень тоже стартовый: отдельная среда, никаких рабочих секретов, запись только в отдельную ветку.
Практически это выглядит как таблица на одну страницу: агент, что он может испортить в худшем случае, текущий уровень, целевой уровень, следующий шаг. Строк с разрывом между текущим и целевым обычно три или четыре. Это и есть ваш настоящий список работ, и в нём уже есть порядок: сначала строки с самым дорогим худшим случаем.
#Стартап и корпоративный шлюз
В финтех-стартапе один внутренний агент. Он читает заявки клиентов и готовит черновики решений для сотрудника. Новый технический руководитель приходит из большой компании и приносит привычную схему: шлюз для инструментов, сервис политик, реестр агентов. По его оценке это полгода работы двух инженеров.
Оценка по уровням занимает один вечер и показывает другое. Агент стоит на нулевом уровне. Он работает под административным токеном, доставшимся от прототипа. Лимитов нет. Журнал пишется в тот же сервис, которым агент управляет. До первого уровня не хватает трёх вещей: узкого токена, лимитов и независимого журнала. Это три недели работы одного человека.
Шлюз за полгода решал бы задачу третьего уровня для компании, у которой открыт первый. Все эти полгода агент продолжал бы работать под административным токеном.
Обратная ситуация встречается реже, но тоже бывает. В компании пятнадцать агентов в четырёх командах, каждый честно доведён до первого уровня, и каждая команда написала своё хранение токенов и свой журнал. Здесь следующий шаг это именно общий слой. Продолжать полировать каждого агента отдельно значит платить четыре раза за одно и то же.
#Как модель зрелости портят
Галочки без исполнения: в таблице зрелости стоит «политики есть», потому что написан документ, а в момент вызова инструмента ничего не проверяется.
Вместо этого Засчитывайте только то, что можно показать отказом. Попросите выполнить запрещённое действие на тестовом стенде и посмотрите, что произойдёт. Если действие прошло, уровня нет, сколько бы документов ни лежало рядом.
Уровень ради статуса: цель «третий уровень к аудиту» превращает модель в гонку за строчкой в отчёте.
Вместо этого Формулируйте цель через ущерб: «ни один агент не может выгрузить больше тысячи записей за запрос». Уровень становится следствием, а не целью, и пропадает соблазн его нарисовать.
Одинаковая цель для всех агентов: безобидного агента тянут на третий уровень, а опасный ждёт своей очереди на нулевом.
Вместо этого Ставьте цель каждому агенту по его худшему сценарию. Общий список сортируйте по цене ошибки, а не по алфавиту и не по громкости команды-владельца.
#Скорость взросления и отдача
У каждого уровня есть цена, и она растёт быстрее пользы. Первый уровень стоит недель и снимает самый крупный ущерб. Второй стоит месяцев и добавляет трения: песочница замедляет работу агента, список разрешённых адресов ломается при каждой новой интеграции, ревью инструкций удлиняет выпуск. Третий уровень это постоянная команда, которая сопровождает платформу. Четвёртый это люди, чья работа состоит в том, чтобы ломать собственную защиту.
Поэтому взрослеть быстрее, чем растёт риск, невыгодно. Платформа, построенная на вырост, два года обслуживает трёх агентов и успевает устареть раньше, чем появится четвёртый. Но и отставание имеет цену. Компания с тридцатью агентами на первом уровне платит её каждый день: дублированием, несогласованными правилами и тем, что на вопрос «что у нас вообще работает» отвечают неделю.
Разумный темп такой: один шаг вверх, когда сработал триггер, и остановка там, где следующий шаг стоит больше, чем ущерб, который он снимает. Остановку стоит записать вместе с причиной, чтобы через год её можно было пересмотреть по той же логике.
#Где по этой шкале стоим мы
Будет честно приложить шкалу к себе. В 1ADK один тип агента: он читает систему клиента и возвращает структурированные сведения с доказательствами. Худший сценарий для нас это агент, который сделал на машине клиента что-то кроме чтения или принёс нам то, чего приносить не должен.
Поэтому базовый уровень закрыт полностью. Задание ограничено чтением, ничего не запускает, имеет срок жизни, секреты в результат не попадают. 1ADK не требует доступа к вашему репозиторию и не требует загружать исходный код в сервис. Со второго уровня мы взяли то, что отвечает нашему худшему сценарию. Правила задания записаны как контракт вне промпта. Его исполняют обе стороны, и он покрыт общими тестами. Текст репозитория считается данными, а не инструкцией. Присланный результат проходит независимую проверку до того, как попадёт в хранилище знаний.
Третьего уровня у нас нет, и мы его не строим. Реестр агентов и общий шлюз решают задачу многих агентов и многих команд, а у нас её пока нет. Это записанное решение с условием пересмотра, а не пробел, о котором забыли.
#Чего уровень не обещает
Чего это не делает
- Высокий уровень не означает отсутствия инцидентов. Он означает, что ущерб от инцидента ограничен и что его заметят. Прямой связи между номером уровня и числом происшествий никто не доказал.
- Модель не заменяет анализ конкретных угроз. Она говорит, в каком порядке строить защиту, и не говорит, от кого именно вы защищаетесь.
- Уровень не переносится между агентами. Платформа третьего уровня не поднимает агента, подключённого в обход неё.
- Границы между уровнями условны. Мера со второго уровня может понадобиться вам на первом, если этого требует ваш худший сценарий. Модель задаёт порядок по умолчанию, а не запрет.
- Оценка устаревает. Уровень, подтверждённый полгода назад, описывает систему, которой уже нет.
Выпишите своих агентов в столбик и поставьте каждому уровень по доказательствам, а не по ощущениям. У кого из них самый большой разрыв между тем, что он может испортить, и уровнем, на котором он стоит?