База данных — самая чувствительная система для подключения AI-агента. Аналитика, поддержка, автозаполнение — сценарии, где агенту хочется дать SELECT, но рядом лежит возможность сделать DROP, UPDATE без WHERE или выгрузить PII. Прямой доступ агента к БД с токеном подключения — самый короткий путь к инциденту.
Безопасный доступ — это прослойка с read-only по умолчанию, узкими представлениями, маскированием и аудитом.
Почему БД — особый случай для агента
В отличие от Jira или Notion, БД не прощает ошибок инструментов:
- деструктивные операции необратимы;
- выборки могут вернуть миллионы строк и раздуть контекст;
- PII и секреты лежат рядом с обычными полями.
Агент, который «просто читает», может случайно прочитать лишнее и утащить это в контекст, а оттуда — куда угодно. Поэтому к БД нельзя применять общие права «читать всё».
Read-only по умолчанию и узкие представления
Правило первое — агент не пишет в прод-базу по умолчанию. Любая запись — через явное подтверждение и отдельный scope.
Правило второе — агент видит не таблицы целиком, а узкие представления (views) под задачу:
- поддержка видит только свои тикеты, а не всю таблицу пользователей;
- аналитика — агрегаты, а не сырые строки с PII;
- автозаполнение — один столбец, а не
SELECT *.
Так вы делаете least privilege исполнимым: агент физически не может запросить то, чего нет в его представлении. Инструмент «query DB» должен быть не универсальным SQL-консолью, а набором точечных инструментов под задачу с ограниченными параметрами.
Маскирование PII до контекста
Даже read-only выборка может вернуть персональные данные, которым не место в контексте LLM. Маскирование должно происходить до того, как данные попадут в окно агента:
- email, телефон, адрес — маскируются или хешируются;
- секреты и ключи — не возвращаются вовсе;
- избыточные поля — отбрасываются (токен-эффективность и меньше поверхности).
Если данных нет в контексте, они не могут утечь — ни через ответ, ни через tool description. Это прямое применение принципа «минимум высокосигнальных токенов».
Защита от деструктивных запросов
Даже с read-only нужны дополнительные барьеры:
- запрет деструктивных ключевых слов (DROP, DELETE, UPDATE без WHERE, ALTER) на уровне шлюза, а не в промпте;
- лимиты на число строк и размер ответа — чтобы агент не раздул контекст выборкой на миллионы строк;
- таймауты и cost limits для тяжелых запросов;
- dry-run для любых пишущих операций — показать, что будет затронуто, до выполнения.
Полагаться на «агент поймет, что не надо удалять» — не защита. Защита — когда инструмент не может выполнить опасное действие даже если агент попросит.
Аудит запросов
Каждый запрос агента к БД должен оставлять неизменяемый след:
- какой агент, под чьими правами;
- какой инструмент/представление, с какими параметрами;
- сколько строк вернулось, какие поля маскированы;
- успех/ошибка и время.
Так инцидент «агент выгрузил лишнее» раскладывается на цепочку: кто инициировал, какие данные затронуты, какие права были применены. Без аудита вы не отличите «агент ошибся» от «агенту выдали слишком много».
Где Codenik: шлюз к данным без прямого доступа
Codenik работает как шлюз к БД: выдает агенту только разрешенные представления и инструменты, хранит секрет подключения на своей стороне, маскирует PII до попадания в контекст и пишет аудит каждого запроса.
Агент вызывает «база: выбери по представлению поддержки», не зная строки подключения и не видя лишних столбцов. Команда настраивает доступ один раз через политики, а не в каждом конфиге агента. Подробнее про классификацию данных — в статье «Какие данные отдавать AI-агенту».
Короткий вывод
Доступ агента к БД должен быть read-only по умолчанию, через узкие представления, с маскированием PII до контекста и аудитом каждого запроса. Деструктивные операции — под запретом на уровне шлюза, а не в промпте.
Так БД перестает быть самой опасной интеграцией и становится управляемой — с видимостью того, какие данные агент реально увидел.