MCP Postgres даёт агенту инструмент для чтения разрешённых данных PostgreSQL через MCP-сервер. Рабочая схема начинается с отдельной роли базы, ограниченного набора запросов и предела выдачи, а заканчивается тестом запрета записи от имени той же роли. Агент формулирует вопрос и объясняет результат; сервер и PostgreSQL решают, какие строки и действия доступны.
Граница доступа
Архивный пример PostgreSQL MCP-сервера показывает чтение схемы и запросов в транзакции READ ONLY. Репозиторий архивирован, поэтому для рабочего контура проверяют выбранную реализацию и её код отдельно.
Начните с вопроса пользователя, который можно решить узким чтением: «каковы статусы заказов моего отдела?». Приложение знает личность сотрудника и доступный ему набор данных, MCP-сервер принимает вызов инструмента, а PostgreSQL отвечает от имени выделенной роли. Между этими слоями проходят схема таблиц, параметры запроса и результат. Если модель видит весь каталог базы, она может выбрать лишнюю таблицу даже при корректной формулировке вопроса. Поэтому перечень объектов определяют до подключения.
Старый пример из архива полезен как иллюстрация интерфейса query и ресурса со схемой таблицы. Его описание допускает передачу SQL-строки; такую свободу нельзя автоматически переносить на корпоративную базу. Отдельно проверьте происхождение, обновления, зависимости и фактические ограничения любого пакета, который собираетесь запустить. Права определяются кодом выбранного сервера и учётной записью базы. Практический проект может использовать собственный небольшой MCP-сервер с заранее описанными запросами.
О настройке связи клиента с сервером есть отдельная статья про MCP-подключения. Здесь главный предмет — граница между текстом запроса агента и чтением PostgreSQL. Векторный поиск через pgvector решает другую задачу: сопоставляет представления текстов. Для ответа по операционным таблицам нужны схема, права и проверяемая выборка строк.
Роль и схема
Администратор базы создаёт для интеграции отдельную роль с доступом к согласованным объектам. В документации PostgreSQL по GRANT права SELECT, INSERT, UPDATE и DELETE заданы раздельно. Для чтения выбирайте разрешённые таблицы или представления и проверяйте все унаследованные права роли. Владелец данных определяет, какие столбцы допустимо выдавать агенту. Если набор меняется, ревью затрагивает и схему инструмента, и привилегии базы.
Схему показывайте модели дозированно: имя разрешённого представления, смысл полей, типы и допустимые фильтры. Служебные таблицы, персональные данные и поля с секретами скрывайте на уровне источника. Если пользователи разделены по отделам, простой общий логин чтения способен объединить их данные. Для такой ситуации сервер проверяет личность сотрудника и передаёт в запрос только его область данных. Если ограничения строк реализованы политикой PostgreSQL, она должна опираться на проверенный контекст пользователя; одна общая роль без такого контекста смешивает доступ сотрудников. Официальная документация по политикам строк описывает этот механизм и его исключения для владельцев таблиц и особых ролей.
| Слой | Разрешить | Проверить |
|---|---|---|
| Клиент MCP | Только нужный инструмент | Список доступных действий |
| MCP-сервер | Согласованные шаблоны запросов | Параметры и размер ответа |
| Роль PostgreSQL | Чтение выбранных объектов | Отказ записи и лишних таблиц |
| Пользователь | Строки своего контура | Отказ на чужой записи |
Транзакция READ ONLY добавляет ещё одну границу. PostgreSQL описывает её как режим текущей транзакции; приложение устанавливает его перед чтением и закрывает транзакцию после ответа. Проверяйте режим реальным тестом, сохраняя независимую защиту через привилегии роли. Пароль роли хранится в механизме секретов сервера, а агент и журнал получают только название операции и очищенный результат.
Разрешённые запросы
Вместо универсального инструмента с произвольной SQL-строкой предложите агенту несколько предметных функций: найти заказ по идентификатору, получить статусы по отделу, показать сводку по выбранному периоду. Каждая функция использует подготовленный запрос с параметрами, явным перечнем колонок и ограничением выдачи. Предел выдачи задаёт сервер независимо от формулировки пользователя и ответа модели. Запросы без фильтра по доступной области возвращают контролируемую ошибку.
Полный экспорт и расчёты по большой выборке выполняйте отдельным скриптом с утверждённой задачей и правами. Для обычного ответа агенту достаточно небольшой порции строк либо проверенной сводки. Языковая модель объясняет возвращённый результат и предлагает гипотезу о расхождении; аналитик сверяет исходную таблицу и формулу. Если пользователь спрашивает «выгрузи всё», приложение направляет запрос в предусмотренный ручной процесс с отдельным допуском.
Проверяйте параметры до обращения к базе: формат идентификатора, допустимый период, принадлежность отдела и известное имя фильтра. Строки из базы считайте данными, даже если в поле комментария содержится команда для агента. В журнале сохраняйте имя инструмента, шаблон, обезличенные параметры, роль базы и количество возвращённых строк. Такое описание помогает восстановить ответ без публикации содержимого секретной записи.
Если сервер показывает структуру таблиц как ресурс, включайте в выдачу только согласованную часть схемы. Полная схема способна раскрыть имена закрытых объектов и подсказать агенту запросы вне задачи. Перед пробным запуском согласуйте список функций с владельцем базы и запишите ожидаемые отказы. Проверка должна подтвердить ограничения сервера и базы фактическим отказом.
Какие таблицы вашему агенту действительно нужны для чтения?
Тест запрета
Предложите пробу на отдельной базе с вымышленными записями и той же схемой прав, которая задумана для рабочего контура. Подключите выбранную реализацию MCP после проверки её кода и конфигурации. Сохраните список ролей, выданных прав, шаблонов и тестовых данных. Оценивайте результат PostgreSQL и сервера: техническую преграду создают их правила.
- Запросите разрешённую строку через предметный инструмент и сравните ответ с записью в тестовой базе.
- Передайте идентификатор чужого отдела и проверьте отказ либо пустую выдачу согласно политике доступа.
- Попробуйте обратиться к таблице вне списка и к закрытому столбцу от имени роли интеграции.
- Проверьте попытку INSERT или UPDATE напрямую под той же ролью, затем через доступные инструменты MCP.
- Отправьте запрос без фильтра и с требованием полной выгрузки; сравните ограничение выдачи с настройкой сервера.
Отдельно проверьте обработку ошибок и повторов. Сервер должен вернуть понятный статус при неверном параметре, недоступной таблице или прерывании запроса, сохранив журнал без пароля подключения. Если ответ обрезан пределом строк, сообщите пользователю об этом явно и предложите уточнить фильтр. Модель сообщает пользователю об ограниченной выборке. После теста закройте доступ к пробной базе и сохраните протокол решений по правам.
Для многоарендной базы проверьте политику строк под фактической ролью подключения. PostgreSQL указывает, что владельцы таблиц и роли с особыми полномочиями могут обходить обычную политику строк. Поэтому тест выполняют той же учётной записью, которую будет использовать сервер. При изменении списка представлений или ролей повторяйте проверки отказа до допуска новой версии.
Эксплуатация и ревизия
После допуска закрепите владельца MCP-сервера и владельца данных. Первый отвечает за шаблоны, журнал, ошибки и обновления кода. Второй согласует таблицы, поля и круг пользователей. При изменении схемы базы проверяйте, сохранились ли фильтры и пределы выдачи. Новая колонка в представлении требует отдельного решения о доступности для агента. Плановый просмотр ролей включает прямые и унаследованные привилегии, а также фактические результаты тестовых запросов.
Если пользователю нужен анализ причин изменения показателя, отдайте модели проверенную выборку с указанием источника и периода. Полные расчёты выполняет скрипт, а специалист сверяет исходные данные. Такое разделение снижает риск, что модель сочинит отсутствующую строку или перепутает агрегат с транзакцией. В ответе агента должны быть видны ограничение выборки и место, где аналитик может повторить запрос по разрешённому пути.
Для команды, которая хочет подключить данные к агенту с контролем операций, можно обсудить внедрение ИИ-агента с проверкой инструментов и доступа. Объём работ зависит от схемы базы, числа ролей, состава разрешённых запросов и правил аудита; условия проекта определяют после ревью конкретного контура. Активную реализацию MCP выбирайте по проверенному репозиторию, документации и испытанию с ограниченной ролью.
Итоговая схема проста для проверки: вопрос сотрудника превращается в вызов разрешённой функции, сервер проверяет параметры и пользователя, PostgreSQL применяет права роли и возвращает ограниченный ответ. Журнал связывает этот ответ с вызовом, а человек сверяет вывод при споре. Архивный пример остаётся исторической иллюстрацией query и чтения схемы; рабочие гарантии создают права, код сервера и повторяемые тесты отказа.