Почему read-only SQL для LLM ещё может раскрывать данные
Запрет записи защищает от части изменений базы, но не ограничивает чтение чужих строк и чувствительных столбцов. Для аналитического агента нужны разрешённая область данных и контроль стоимости запроса.
Разберём рабочий случай
Помощнику разрешили выполнять только SELECT и дали доступ к общей базе клиентов. Он не сможет удалить таблицу, зато сможет выбрать адреса и телефоны всех организаций. Пользователь спрашивал средний чек своей компании, но соединение не ограничено её данными. Проверка первого слова SQL создаёт ощущение безопасности, не отвечая на главный вопрос: что именно агенту позволено узнать.
Что изменить
Используйте выделенную роль базы с минимальными правами, разрешённые представления или иной проверяемый слой доступа. Применяйте ограничения пользователя и организации там, где реально читаются данные. Значения параметризуйте; динамические имена таблиц и колонок выбирайте из разрешённого списка. Для произвольных аналитических запросов отдельно задайте лимит времени и объёма результата. Простое добавление WHERE моделью не заменяет обязательное серверное ограничение: оно может исчезнуть в следующем запросе.
Как проверить результат
| Проверка | Ожидаемое поведение |
|---|---|
| Средний чек доступной организации | Результат рассчитан только по разрешённым строкам и не возвращает лишние индивидуальные сведения. |
| Запрос чувствительного столбца вне задачи | Роль или слой доступа запрещает чтение независимо от текста, которым модель обосновывает необходимость. |
| Тяжёлое объединение больших таблиц | Ограничение ресурса прекращает запрос по согласованной политике и не блокирует базу бесконечно. |
Агрегат тоже может раскрывать закрытые сведения при слишком узком фильтре. Если пользователь не должен узнавать индивидуальные значения, отдельно оцените минимальный размер группы и допустимые комбинации вопросов.
Проверка SQL требует знания конкретной СУБД: функции, права, представления и ограничения различаются. Этот разбор задаёт модель контроля, а не предлагает универсальный безопасный парсер одной строкой.
Если LLM получает доступ к корпоративным данным, безопасность чтения так же важна, как запрет разрушительных команд. В платном курсе LLM Security PRO: Prompt Injection, утечки, tool-abuse можно продолжить изучение соответствующего инженерного направления. Перед покупкой сравните программу и открытые материалы со своей задачей.
Документация для проверки технических деталей: OWASP: предотвращение SQL injection, OWASP: авторизация.
Следующий шаг: Безопасность LLM-приложений: практические проверки. По смежным вопросам: LLM предлагает shell-команду: как ограничить исполнение, HTML из ответа LLM: как не превратить чат в XSS.
