# Supabase MCP и Cursor: агент с правами service_role выдал секреты через тикет

> Исследователи General Analysis показали, что сообщение в тикете поддержки может заставить AI-ассистента разработчика прочитать секретную таблицу базы данных и записать её содержимое обратно в тикет, видимый атакующему. Причина в том, что агент работал с ключом service_role, обходящим все правила доступа на уровне строк.

- Канонический HTML: [/incidents/supabase-mcp-cursor-sql-leak](https://ai-first.tech/incidents/supabase-mcp-cursor-sql-leak)
- Язык: русский
- Редакционный принцип: защитный контекст без вредоносных полезных нагрузок и инструкций обхода.

- Дата: 2025-07
- Категория: AI-агенты и MCP
- Затронуто: Разработчики, подключающие Supabase MCP-сервер к AI-ассистентам (в демонстрации — Cursor) с привилегированным ключом
- Критичность: Высокий

## Что произошло

В начале июля 2025 года General Analysis опубликовала демонстрацию на тестовом проекте Supabase с фиктивными данными. В условном SaaS-сервисе клиенты пишут в поддержку, а разработчик просматривает тикеты через Cursor с подключённым Supabase MCP-сервером. Атакующий оставил в тикете текст с указаниями для модели. Когда разработчик попросил ассистента показать последние обращения, модель выполнила эти указания: прочитала таблицу integration_tokens с токенами и записала её содержимое новым сообщением в тот же тикет. 6 июля случай разобрал Simon Willison как пример «смертельной триады». Реальная утечка у клиентов Supabase не сообщалась: это исследовательская демонстрация.

## Где нарушилась защита

Данные клиентов (текст тикета) и команды разработчика попадали в один контекст модели, и модель не отличала одно от другого. MCP-сервер выполнял SQL-запросы от имени роли service_role, которая по замыслу обходит защиту на уровне строк (RLS). Право записи в таблицу сообщений дало атакующему обратный канал. Ни один компонент не был взломан в классическом смысле: каждый работал по своим правилам, но вместе они создали путь утечки.

## Последствия

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

## Реакция

Supabase рекомендует подключать свой MCP-сервер в режиме только для чтения и с привязкой к конкретному проекту. General Analysis также советовала ограничивать набор доступных инструментов и проверять вызовы инструментов вручную.

## Уроки для бизнеса

- Нельзя выдавать AI-ассистенту ключи администратора базы данных
- Данные пользователей, попадающие в контекст агента, — потенциальный носитель чужих инструкций
- Режим только для чтения снижает риск, но не устраняет утечку через ответы модели
- Подключение MCP к рабочей базе требует такой же оценки, как выдача доступа новому сотруднику

## Меры защиты

- Подключать агентов к копиям или тестовым базам вместо рабочей
- Использовать роли с минимальными правами и режим только для чтения
- Ограничивать агенту набор таблиц и инструментов
- Включить ручное подтверждение SQL-запросов, сформированных моделью
- Хранить токены и секреты отдельно от таблиц, доступных агенту

Связанные карточки угроз: A33, A34, A35, A09, A52

## Первоисточники

- [Supabase MCP can leak your entire SQL database](https://generalanalysis.com/blog/supabase-mcp-blog) — General Analysis
- [Supabase MCP can leak your entire SQL database](https://simonwillison.net/2025/Jul/6/supabase-mcp-lethal-trifecta/) — Simon Willison's Weblog