РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-21
Как дать LLM доступ к SQL только для чтения
Как построить помощника для аналитики, который получает ограниченный доступ к данным и не выполняет произвольные команды.
Доступ LLM к SQL ограничивают на уровне базы и приложения. Инструкция «выполняй только SELECT» не заменяет отдельную роль с минимальными правами, разрешённый набор данных и ограничения времени исполнения. Модель должна предлагать запрос, а сервер — проверять его и выполнять под контролируемой учётной записью. Начните с заранее подготовленных аналитических представлений. Для часто повторяющихся вопросов безопаснее дать инструмент с параметрами, чем разрешать свободную генерацию SQL по всей рабочей базе.
1. Определите доступную область данных
Выберите вопросы, на которые должен отвечать помощник, и подготовьте представления с нужными столбцами. Не отправляйте ему полную схему базы только ради удобства. Для пользователя из одной организации сервер должен определять её идентификатор из проверенной сессии, а не доверять значению, предложенному моделью. Продумайте доступ к строкам и агрегатам: даже итоговая сумма может раскрывать сведения, если выборка слишком мала. Зафиксируйте допустимые операции в контракте инструмента.
2. Ограничьте исполнителя в базе
Используйте отдельную роль без административных полномочий и без прав изменения рабочих таблиц. PostgreSQL поддерживает режим READ ONLY для транзакции и описывает, какие команды он запрещает. У режима есть конкретные границы, поэтому не считайте его единственной защитой и проверяйте права роли отдельно. Отдельно рассмотрите вызываемые функции, временные объекты и доступ к другим схемам. Не передавайте модели пароль базы: подключение и учётные данные остаются внутри серверного компонента.
3. Проверьте запрос и ресурсы
Перед исполнением разберите SQL библиотекой и проверьте разрешённые конструкции, объекты и функции. Сравнение первых букв с SELECT ненадёжно для сложного синтаксиса и нескольких команд. Ограничьте время исполнения, число возвращаемых строк и объём результата. Один LIMIT не гарантирует дешёвую обработку: соединение больших таблиц может потребовать значительных ресурсов до формирования ответа. Для непредвиденного запроса верните понятную ошибку и предложите уточнить вопрос вместо автоматического расширения полномочий.
4. Проверьте ответ на контрольных данных
Создайте небольшой набор таблиц, где правильный итог известен заранее. Включите разные организации, отсутствующие значения, повторяющиеся записи и неоднозначное название показателя. Сравните не только текст SQL, но и смысл результата: период, валюту, единицу измерения и фильтры. В интерфейсе покажите, к каким данным относится вывод. Не отдавайте пользователю большой сырой результат, если для ответа достаточно разрешённого агрегата. Испытание на учебной базе не подтверждает готовность доступа к production.
Частые вопросы
Достаточно ли написать запрет в системном сообщении?
Нет. Модель может ошибиться или неверно понять задачу. Запрет должен обеспечиваться реальными правами и серверными проверками до выполнения SQL.
READ ONLY защищает от утечки данных?
Сам по себе нет. Он ограничивает часть изменений, но не определяет, какие строки и поля пользователь имеет право читать.
Можно ли выполнять запрос без просмотра человеком?
Для заранее ограниченного аналитического инструмента это проектное решение. Свободный SQL требует отдельной оценки и проверок; автоматическое выполнение не должно расширять доступ.
Зачем лимит времени при небольшом ответе?
Несколько строк могут потребовать дорогого соединения или сортировки. Ограничение выдачи и ограничение ресурсов решают разные задачи.