Как обеспечить безопасность AI-агентов с доступом к базе данных

Подробности изложены в материале первоисточника. Если вы задумывались, как дать AI-агенту доступ к рабочим данным и не пожалеть об этом через неделю — у меня для вас хорошие новости. Задача старая, инструменты для нее существуют давно, и ниже я продемонстрирую рабочий пример, разворачиваемый одной командой.

Интерфейс текстового чата прочно закрепился в качестве основного способа взаимодействия пользователей с программным обеспечением. Когда клиент просит службу поддержки отменить денежный перевод или вернуть средства за конкретную покупку, интеллектуальный помощник распознает намерение и задействует профильный инструмент для проведения операции. Это крайне удобно, однако сам агент представляет собой потенциально уязвимый элемент внутри защищенного периметра. Модели склонны к галлюцинациям и легко поддаются на атаки типа prompt injection, когда злоумышленники пытаются заставить систему проигнорировать исходные инструкции. Если предоставить боту полноценные полномочия пользователя без дополнительных ограничений, это создает серьезные риски для безопасности.

Эволюция принципов безопасности и проблема ненадежного актора

Проблема взаимодействия с ненадежным исполнителем существует уже несколько десятилетий, изменился лишь сам субъект: на смену стороннему программному коду или привилегированному администратору пришли вероятностные языковые модели. Базовый принцип наименьших привилегий был заложен исследователями еще в 1975 году, а концепция capability-моделей ввела понятие аттенуации, позволяющей передавать ограниченный набор прав. Классическая уязвимость confused deputy, описанная в конце восьмидесятых, идеально описывает поведение современного LLM-агента, который под влиянием пользовательского ввода выполняет несанкционированные действия.

В сфере управления привилегированным доступом (PAM) индустрия давно пришла к моделям just-in-time и нулевым постоянным привилегиям, когда учетная запись получает расширенные права лишь на короткое время под конкретную задачу. Для современных чат-интерфейсов этот подход подходит наилучшим образом, позволяя запрашивать подтверждение непосредственно в диалоговом окне без использования громоздких внешних консолей.

Стандартизированные протоколы и архитектурные решения

Для реализации безопасного взаимодействия не требуется изобретать собственные велосипеды, поскольку необходимые стандарты уже давно утверждены:

• RFC 8693 (Token Exchange) отвечает за аттенуацию и позволяет обменивать исходный токен на более ограниченный по аудитории и областям видимости.
• RFC 9449 (DPoP) привязывает токен безопасности к криптографическому ключу конкретного клиентского приложения, делая украденные данные бесполезными без соответствующего ключа.
• OpenID CIBA реализует сценарий human-in-the-loop, позволяя инициировать операцию на стороне клиента и получать подтверждение от человека в асинхронном режиме.
• Row-Level Security в СУБД PostgreSQL переносит проверку полномочий на уровень самого хранилища данных, защищая систему от логических ошибок в коде приложений.

Среди инструментов, поддерживающих полный набор необходимых технологий из коробки, можно выделить современные версии Keycloak, библиотеку oidc-provider, а также решения issuerd на Rust и Attesto на Elixir. Для детального разбора я выбрал сервер issuerd, содержащий готовый демонстрационный сценарий.

Развертывание демонстрационного стенда

Типовой сценарий рассматривает работу службы поддержки магазина, использующей функции чтения заказов и проведения возвратов средств. Архитектура включает клиентское чат-приложение, сервер авторизации OIDC, изолированный сервер Model Context Protocol и реляционную базу данных под управлением PostgreSQL.

Для быстрого запуска инфраструктуры достаточно утилиты Docker Compose. После клонирования репозитория и выполнения команды инициализации можно открыть веб-интерфейс в браузере или запустить автоматические скрипты проверки, которые последовательно прогоняют сценарии авторизации, имитации атак и подтверждения операций.

По умолчанию агент функционирует в скриптовом режиме на основе регулярных выражений, что обеспечивает необходимую детерминированность при тестировании. Подключение полноценной языковой модели осуществляется через стандартные переменные окружения, при этом общая протокольная логика работы системы остается неизменной.

Управление доступом на уровне хранилища данных

Любая архитектурная защита в конечном итоге упирается в уровень хранения информации. В конфигурационном файле инициализации базы данных таблица заказов защищена встроенными механизмами разграничения доступа.

Приложение подключается к СУБД не от имени владельца таблиц, а через специальную учетную запись с минимально необходимым набором прав. Контекст безопасности устанавливается в рамках конкретной транзакции с использованием идентификатора пользователя из токена аутентификации. Если контекст по какой-то причине не был передан, механизм возвращает пустой набор данных вместо генерации критической ошибки.

Даже если злоумышленник успешно применит технику инъекции промпта и попытается запросить информацию обо всех клиентах магазина, политика безопасности базы данных отфильтрует результат, вернув исключительно записи текущего пользователя. Полномочия контролируются на уровне СУБД, а не кодом самого агента.

Ограничение прав и использование урезанных токенов

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

В результате формируется маркер с жестко ограниченной аудиторией, единственным разрешенным инструментом и криптографической привязкой к ключу приложения. Принимающая сторона на сервере MCP полностью отказывается от использования незащищенных Bearer-токенов, проверяя цифровую подпись, криптографический отпечаток и специфические области видимости для каждого входящего JSON-RPC запроса.

Подтверждение критических операций человеком

Для выполнения потенциально опасных действий, таких как возврат денежных средств, у агента изначально отсутствуют соответствующие разрешения. При попытке инициировать возврат система задействует протокол CIBA, отправляя запрос на подтверждение владельцу учетной записи.

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

Ограничения текущей реализации и дальнейшее развитие

Представленная демонстрационная схема намеренно упрощена: протокол CIBA функционирует в режиме опроса, механизмы привязки ключей требуют внимательной проверки на стороне серверных компонентов, а конфигурация использует статические параметры для учебных целей. Тем не менее, данная архитектура задает правильный вектор развития систем безопасности для автономных ИИ-агентов.

Дальнейшее масштабирование подхода предполагает интеграцию ролевой модели корпоративного каталога пользователей с динамическим назначением прав в базе данных, разделение доступа к разным типам сущностей, а также внедрение полноценных цепочек делегирования полномочий и аппаратных методов подтверждения действий через WebAuthn.