Агенты работают под вашими учётными данными — в этом корень проблемы
Инженер отправляет агента в продакшен. Ему нужно обратиться к внутреннему API, поэтому он берёт ключ, который уже лежит в его рабочем окружении. Агент запускается и сразу получает все разрешения, какие есть у самого инженера.
Сегодня это состояние по умолчанию для большинства развёрнутых агентов. У агента нет собственной идентичности, поэтому он одалживает чужую — как правило, человеческую, через API-ключ. В первый день агент работает как надо, и именно поэтому проблема незаметно проникает в продакшен.
Чем на самом деле оборачивается наследование прав
Одно-единственное упрощение ведёт к четырём типам сбоев, которые наслаиваются друг на друга.
Происходит эскалация привилегий. У вас появляется нечеловеческий процесс с полным доступом, какой есть у человека. Он может дотянуться до любой системы, до которой дотягивается сотрудник, — независимо от того, нужна ли она для текущей задачи.
Отсутствует ограничение области действий. Агент должен взаимодействовать лишь с узким срезом ваших систем. Вместо этого он получает всё, потому что ключ никогда не предназначался для выражения логики «только вот это».
Нет атрибуции. Когда агент выполняет действие, в аудиторском журнале значится человек. Невозможно отделить поступки агента от поступков сотрудника. Разбор инцидентов затягивается до бесконечности, а заодно рушится любая история compliance, которую позже придётся предъявлять.
Нет чистой процедуры отзыва. Чтобы отключить агента, вы меняете человеческий ключ. Тем самым вы ломаете доступ самому сотруднику и всем остальным процессам, зависевшим от этого ключа. Отдельной кнопки «выключить только агента» не существует.
Опытный читатель сразу потянется за очевидными решениями. Менять ключ по расписанию. Выдать агенту сервисную учётную запись. И то и другое упускает настоящую проблему.
Паспорт — неподходящая ментальная модель
Инстинктивно хочется относиться к идентичности как к паспорту. Паспорт подтверждает, кто вы, и привязывает к вам фиксированный набор разрешений. Показываете на границе — получаете доступ, который с этим связан. Такая модель работает, когда поведение внутри этих разрешений предсказуемо. Человек с доступом на чтение датасета читает датасет. Сервисная учётная запись, которая постит в очередь, постит в очередь с одним и тем же ритмом каждый раз.
Агенты разрушают допущение, на котором держится паспорт. Правильный вопрос — не «кто этот субъект», а «что этому субъекту разрешено делать прямо сейчас, для этой конкретной задачи». Это полномочие, а не идентичность в паспортном смысле, и разница между ними — суть дела.
Вот почему это важно. Агент недетерминирован. Дайте двум агентам одинаковые разрешения и одинаковую цель — они могут предпринять разные действия, потому что каждый выбирает цепочку инструментов во время исполнения, опираясь на свой промт, контекст и результат того, кто его вызвал. Набор действий, которые агент в итоге совершит, невозможно знать заранее, в момент выдачи разрешений.
Это превращает принцип минимальных привилегий, закладываемый на этапе проектирования, в дизайн-тайм ответ на рантайм-проблему. Вы заранее решаете, что субъекту можно делать, а сам субъект решает, что он будет делать, только когда уже запущен. Статическое разрешение не поспевает за субъектом, чьё поведение меняется при каждом взаимодействии.
Почему ваш IAM-стек ведёт себя именно так
Это не ошибка конфигурации. Это структурное допущение, встроенное в системы управления идентичностью и доступом. Системы, с которыми вы работаете, исходят из того, что субъект — это либо человек, либо долгоживущая сервисная учётная запись со статичным набором разрешений. И то и другое стабильно. И то и другое делает примерно одно и то же изо дня в день. Ваши механизмы контроля, ваша модель аудита и процессы предоставления доступа — все построены на этой стабильности.
Агенты не относятся ни к тому, ни к другому. Они действуют от имени людей — значит, они не сервисные учётные записи. Они — софт, который запускается и завершается по собственному графику, — значит, они не люди. Они занимают промежуток, для которого в вашем IAM-стеке нет отдельной категории, и именно в этом промежутке учётные данные одалживаются.
Вывод
Если ваши агенты аутентифицируются как люди, которые их развернули, — у вас прямо сейчас в продакшене живёт проблема наследования привилегий. Найдите её прежде, чем это сделает аудитор или инцидент: ищите человеческие API-ключи, которые используют нечеловеческие процессы, и аудиторские журналы, где действия агентов неотличимы от человеческих.
Поверхностное решение — перестать делиться ключами. Настоящее решение значительно сложнее. Недетерминированным субъектом невозможно управлять с помощью статического разрешения, выданного на этапе проектирования, а это значит, что агенту нужна идентичность, построенная под полномочие, которое определяется во время исполнения, а не под паспорт, единожды проштампованный на границе.
Отсюда возникает очевидный вопрос. Если агенту нужна собственная идентичность, то из чего она на самом деле состоит и больше ли это, чем просто идентичность рабочей нагрузки, которая у вас уже работает? Об этом — в следующем материале.