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