Безопасность ИИ-агентов: от галлюцинаций до привилегированного доступа
Интеграция языковых моделей в корпоративные процессы обещает высокую автоматизацию, но вводит критические риски, связанные с надежностью агента и управлением его полномочиями. Решение задачи «не дать лишнего» кроется в сочетании классической информационной безопасности и новых протоколов, таких как DPoP и CIBA, адаптированных под архитектуру чат-ботов.
# Баланс автоматизации и безопасности: как контролировать ИИ-агентов с доступом к базе данных
Эра взаимодействия с искусственным интеллектом через чат-интерфейсы прочно вошла в практику. Пользователи привыкли формулировать сложные запросы в свободной речи, ожидая мгновенного выполнения: от списания средств до анализа документов. Однако за удобностью скрывается фундаментальная проблема доверия. ИИ-агент, несмотря на интеллектуальные способности, остается ненадежным исполнителем: он подвержен галлюцинациям и атакам типа prompt injection (вмешательство в промпт). Предоставление таким агентам полных прав доступа к пользовательским данным равносильно выдаче пароля от сервера стажеру с нестабильной психикой.
Эволюция принципа наименьших привилегий
Задача ограниченного доступа не нова. В 1975 году Saltzer и Schroeder сформулировали принцип наименьших привилегий, а в 1988 году Норм Харди описал модель «confused deputy» (запутанный заместитель), когда программа-попрошайка вынуждена использовать чужие полномочия для действий вне их назначения. ИИ-агент, читающий инструкции из пользовательского ввода, является прямым современным аналогом этой угрозы.
Сегодня подходы к управлению доступом (PAM) сместились от постоянной выдачи прав к модели just-in-time (Just-in-Time, JIT) и zero standing privileges (нулевым постоянным привилегиям). Администраторы больше не имеют root-прав постоянно, а запрашивают их на короткий срок для конкретной задачи. Эта же логика должна применяться к ИИ: агент должен действовать с урезанными полномочиями, которые подтверждаются или расширяются только в момент выполнения действия.
Ключевые технические механизмы защиты
Для реализации безопасного взаимодействия используются следующие стандарты:
* RFC 8693 (Token Exchange): Механизм обмена токенов, позволяющий аттенуировать (ослабить) полномочия. Токен пользователя может быть превращен в новый токен с ограниченной аудиторией (audience) и узким диапазоном доступа (scope). Агента невозможно заставить запросить больше прав, чем это позволяет исходный токен пользователя. * RFC 9449 (DPoP — Demonstration of Proof of Possession): Привязывает токен к ключу приложения, требуя доказательства владения ключом для каждого запроса. Это предотвращает использование украденных токенов, так как без секретного ключа сервер не сможет подтвердить личность агента. * OpenID CIBA (Client-Initiated Back-Channel Authentication): Протокол, обеспечивающий подтверждение действия человеком (human-in-the-loop). Если агенту требуются повышенные права (например, на возврат средств), он запрашивает их, а пользователь подтверждает действие непосредственно в интерфейсе чата. * Row-Level Security (RLS) в PostgreSQL: Проверка прав доступа осуществляется внутри базы данных на уровне строк. Даже если приложение или агент попытается получить доступ к чужим данным, база данных вернет пустой набор записей, если owner_sub (владелец данных) не совпадает с контекстом запроса.
Архитектура безопасного агента: от теории к практике
Рассмотрим сценарий чат-бота поддержки магазина с доступом к базам заказов. Система состоит из клиентского приложения, сервера идентификации (IdP) и сервера MCP (Model Context Protocol), управляющего доступом к PostgreSQL.
1. Защита на уровне хранилища База данных защищается политикой RLS. При подключении используется отдельная роль с правами только на чтение и обновление, без доступа к управлению. Контекст текущего пользователя устанавливается на уровне транзакции. Если приложение или агент забудут установить этот контекст, запрос вернет нуль строк, предотвращая утечку данных. Это последний рубеж обороны: безопасность обеспечивается не надежностью кода приложения, а надежностью самой СУБД.
2. Урезанные токены и DPoP
Вместо передачи полного авторизационного токена пользователя, агент использует механизм обмена. На каждый вызов инструмента создается новый токен с жестко ограниченным scope (например, orders:read или refunds:execute). Благодаря DPoP, этот токен привязан к ключу приложения. Если злоумышленник попытается переиграть запрос (replay attack), сервер отвергнет его, так как у него не будет валидного доказательства владения ключом для этого конкретного запроса.
3. Ступенчатое повышение привилегий (Step-up) Сценарий наиболее чувствительной операции — возврат средств. Агент не обладает правами на это по умолчанию. При попытке выполнить возврат агент инициирует запрос на повышение привилегий через CIBA. В чат-интерфейсе у пользователя появляются кнопки «Подтвердить» или «Отклонить». Только после подтверждения (или истечения времени ожидания) выдается временный токен с расширенными правами сроком на 120 секунд.
Этот подход трансформирует «ритуал» подтверждения в привычный интерфейс чата, не удлиняя путь пользователя, но обеспечивая высокий уровень безопасности.
Ограничения и перспективы
Представленная архитектура демонстрирует применимость проверенных временем стандартов к новым технологиям. Однако реализация в продакшене требует учета дополнительных факторов. Протокол CIBA в демо-версиях использует опрос (polling), тогда как в реальных системах эффективнее использовать push-уведомления. Также необходимо учитывать возможность делегирования цепочек запросов, хотя текущие реализации, такие как issuerd, могут еще не поддерживать сложные цепочки аттенуации.
Будущее агентных интерфейсов лежит не в создании новых сложных протоколов взаимодействия, а в грамотной интеграции существующих механизмов безопасности (минимальные привилегии, подтверждение человеком, защита на уровне базы данных) в привычные рабочие процессы. Это позволяет компаниям внедрять ИИ-агентов, не опасаясь за утечку критических данных или злоупотребление полномочиями.