Comments 2
Итак, агент что в наивной что в продвинутой реализации может читать репозиторий и читать писать тикеты. Злоумышленник контролирует тикетницу. Из принципа минимальных привелегий мы ограничили агента двумя внешними хостами - репозиторий и тикетница. Агент, прочитав зловредный промт в тикетнице, может как прочитать репозиторий и сложить все интересное в комментарий к зловредному тикету, так и прошерстить всю тикетницу (в том числе возможно недоступные злоумышленнику проекты) и сложить опять же в тикет, к которому у злоумышленника есть доступ.
Как нам помог принцип “Презумпция взлома” по сравнению с “Минимальные привилегии”?
Но вообще конечно я периодически упирался в непонимание в ответ на просьбы “а дайте мне пяток служебных учеток, которым я права настрою ниже, чем у меня”. ИБ в ответ твердо отвечало “операции должны быть авторизованы сотрудником, который за ними стоит, так что никаких служебных учеток в частные руки, отдавай своим агентам личные токены”.
Да, здесь замечание по делу. В описанной конфигурации одного ограничения egress до репозитория и тикетницы недостаточно. Если тикетница сама является разрешённым каналом записи, скомпрометированный агент вполне может использовать её для эксфильтрации данных.
То есть мой пример получился слабее самого принципа.
«Минимальные привилегии» и «презумпция взлома» я бы при этом не противопоставлял. Первое скорее один из механизмов реализации второго. Если мы действительно предполагаем, что агент рано или поздно проглотит prompt injection, надо проектировать права так, чтобы даже уже скомпрометированный агент не получил большой blast radius.
В вашем примере недостаточно разрешить ему только Git и тикетницу. Надо ещё ограничивать сами capabilities: конкретный репозиторий, конкретные paths, конкретный проект или тикет, отдельное право на запись и, в идеале, контроль того, какие данные вообще могут переходить из repo в ticket. Иначе две по отдельности легальные операции read repo и write ticket складываются в совершенно легальный с точки зрения ACL канал утечки.
С личными токенами сотрудников я бы, наоборот, не согласился.
Требование ИБ «операция должна быть связана с конкретным сотрудником» разумное. Но из него не следует, что агент должен работать под постоянным личным токеном этого сотрудника.
Мне кажется более здоровой схема:
user → конкретный run → короткоживущие downscoped credentials → agent
Тогда в аудите остаётся и инициатор, и агент, и конкретный запуск, но агент не получает весь объём постоянных прав человека и не выглядит в логах как сам человек.
Так что да: пример в статье я бы после вашего комментария уточнил. Default deny по сети сам по себе здесь не является достаточной реализацией «презумпции взлома». Нужен ещё контроль сочетания разрешённых возможностей и потоков данных между ними.
Zero Trust для ИИ-агентов: почему отдельной идентичности недостаточно