Zero Trust для ИИ‑агентов: почему отдельной идентичности недостаточно

[Ndochp]

Итак, агент что в наивной что в продвинутой реализации может читать репозиторий и читать писать тикеты. Злоумышленник контролирует тикетницу. Из принципа минимальных привелегий мы ограничили агента двумя внешними хостами - репозиторий и тикетница. Агент, прочитав зловредный промт в тикетнице, может как прочитать репозиторий и сложить все интересное в комментарий к зловредному тикету, так и прошерстить всю тикетницу (в том числе возможно недоступные злоумышленнику проекты) и сложить опять же в тикет, к которому у злоумышленника есть доступ.

Как нам помог принцип “Презумпция взлома” по сравнению с “Минимальные привилегии”?

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

[Smart_Soft]

Да, здесь замечание по делу. В описанной конфигурации одного ограничения egress до репозитория и тикетницы недостаточно. Если тикетница сама является разрешённым каналом записи, скомпрометированный агент вполне может использовать её для эксфильтрации данных.

То есть мой пример получился слабее самого принципа.

«Минимальные привилегии» и «презумпция взлома» я бы при этом не противопоставлял. Первое скорее один из механизмов реализации второго. Если мы действительно предполагаем, что агент рано или поздно проглотит prompt injection, надо проектировать права так, чтобы даже уже скомпрометированный агент не получил большой blast radius.

В вашем примере недостаточно разрешить ему только Git и тикетницу. Надо ещё ограничивать сами capabilities: конкретный репозиторий, конкретные paths, конкретный проект или тикет, отдельное право на запись и, в идеале, контроль того, какие данные вообще могут переходить из repo в ticket. Иначе две по отдельности легальные операции read repo и write ticket складываются в совершенно легальный с точки зрения ACL канал утечки.

С личными токенами сотрудников я бы, наоборот, не согласился.

Требование ИБ «операция должна быть связана с конкретным сотрудником» разумное. Но из него не следует, что агент должен работать под постоянным личным токеном этого сотрудника.

Мне кажется более здоровой схема:

user → конкретный run → короткоживущие downscoped credentials → agent

Тогда в аудите остаётся и инициатор, и агент, и конкретный запуск, но агент не получает весь объём постоянных прав человека и не выглядит в логах как сам человек.

Так что да: пример в статье я бы после вашего комментария уточнил. Default deny по сети сам по себе здесь не является достаточной реализацией «презумпции взлома». Нужен ещё контроль сочетания разрешённых возможностей и потоков данных между ними.

[Ndochp]

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

[Smart_Soft]

Да, с персональным токеном Maintainer вы правы. В GitLab нельзя считать PAT полноценным способом понизить права пользователя. Токен в существенной части наследует полномочия самой identity. Если Maintainer имеет право пушить в protected branch, передача агенту его личного PAT эту проблему не решает.

Но для меня это как раз аргумент против передачи агенту личного токена, а не против отдельной identity агента.

Если задача агента только читать репозиторий для разбора тикета, права на push у него вообще не должно быть. Это обычный least privilege.

Если агенту действительно нужно создавать изменения, я бы разделял две identity:

"человек = Maintainer"

"агент = отдельный bot/service account с Developer или более узкими правами"

Дальше protected branch можно настроить так, чтобы прямой push туда был запрещен, а изменения шли через отдельную ветку и merge request. Тогда агент не наследует Maintainer-права человека, который его запустил.

И здесь есть важная разница между двумя формулировками:

«операция должна быть связана с конкретным сотрудником»

и

«операция должна выполняться от имени этого сотрудника».

Первое обязательно. Второе, на мой взгляд, для агента опасно.

В audit trail вполне можно сохранить:

"initiated_by = employee"
"executed_by = agent/service account"
"task/run = конкретный запуск"

Мы знаем, какой сотрудник инициировал действие, но агент при этом не изображает этого сотрудника и не получает автоматически весь его набор прав.

Идеальная схема еще уже: агент получает полномочия под конкретную задачу и на ограниченное время. GitLab сам по себе не всегда позволяет сделать такой downscope для каждого Git-действия, поэтому в чувствительных сценариях понадобится дополнительный authorization broker или gateway.

Так что ваше замечание про Maintainer PAT я бы принял полностью. Более того, это хороший пример того, почему отдельная идентичность агента нужна не для красоты в логах, а как реальная граница безопасности.

[Ndochp]

Вот и я примерно об этом. Запись о том, что данные сервисных учеток выданы сотруднику - у ИБ остается. Тут конечно надо делить сервисные учетки выданные для того, чтобы они работали “как роли” (и не превращались в тыкву обмены между системами после увольнения настроевшего их сотрудника) и “для игр” конкретному сотруднику (агенты под его контролем и прочие личные эксперименты и автоматизации) - эти как раз должны сгореть синхронно с блокировкой учетки сотрудника.