AI-агенты OpenAI слили приватные данные: как защитить свой прод от утечек через автоматизацию
Я — Denis Shokhirev, архитектор агентных AI-систем (Freiburg im Breisgau), работаю на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres. Неделю назад я получил тикет: продовый AI-агент на стороне клиента неожиданно слил приватные данные пользователя из-за неправильного workflow в n8n. Такой кейс — не редкость, и это не демо, а реальный продакшн.
Почему агентные AI-системы реально сливают приватные данные
Большинство обсуждений утечек крутятся вокруг prompt-инжекции, но проблема глубже: автоматизация через n8n, supabase, Claude Code и прочие компоненты часто приводит к неочевидным путям утечки. Даже если ваш pipeline не пишет логи в open S3, агенты могут «тянуть» данные из неожиданных источников и отправлять их наружу.
Что произошло с OpenAI в 2024
В июне 2024 на Hacker News обсуждался инцидент, когда AI-агенты на базе OpenAI слили приватные файлы пользователей из-за неправильной настройки прав доступа к облачным storage. Ссылка на обсуждение. Это не баг модели, а баг архитектуры workflow.
Мои реальные наблюдения
В 2024 я поймал одинаковую схему на трёх разных внедрениях: агент генерирует SQL-запросы к Postgres через Claude Code, а затем по ошибке возвращает полный результат (включая приватные столбцы) в ответ клиенту. Это не уязвимость модели, а ошибка glue-кода и плохой контроль на этапе post-processing.
Где чаще всего протекают данные
| Компонент | Тип утечки | Как ловить |
|---|---|---|
| n8n workflow | Случайная отправка приватных payload в HTTP-запросах | semgrep, ручные ревью |
| Claude/OpenAI Code | Генерация SQL без фильтрации полей | unit-тесты, stateless sandbox |
| Supabase/Postgres | Ошибки в row-level security | OWASP ZAP, gitleaks |
| Doppler | Логи с credentials в ошибках | gitleaks, audit-логи |
Как я защищаю production: 4 конкретных шага
1. Статический анализ workflow и glue-кода
Я использую semgrep и bandit для анализа glue-скриптов, которые связывают Claude Code, n8n и Postgres. Например, semgrep ловит передачу приватных полей из одной таски n8n в другую.
semgrep --config=auto n8n_workflows/
bandit -r ai_agents/
2. Стабильные unit-тесты для RAG и SQL-генерации
Для каждого запроса, который генерирует агент, я пишу unit-тест, который проверяет: нет ли в ответе приватных столбцов. Это особенно важно для автоматизированных RAG-сценариев.
def test_agent_sql_response_does_not_leak_pii():
result = agent_query("list user profiles")
assert "email" not in result
assert "phone" not in result
3. Runtime-аудит через n8n и Supabase triggers
Я настраиваю Supabase triggers, чтобы логировать все SELECT-запросы к критичным таблицам, и использую n8n для мониторинга подозрительных паттернов в real-time. Если агент делает подозрительный SELECT — приходит алерт.
CREATE OR REPLACE FUNCTION log_sensitive_select()
RETURNS trigger AS $$
BEGIN
IF TG_OP = 'SELECT' AND TG_TABLE_NAME = 'users' THEN
INSERT INTO audit_log (user, query, ts) VALUES (current_user, current_query(), now());
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
4. Проверка на утечку секретов в workflow и логах
gitleaks и Doppler audit-логи позволяют быстро найти, не попали ли токены или credentials в публичные логи или S3.
gitleaks detect --source=./n8n_workflows/
doppler logs --project my-ai-prod | grep 'token'
Мифы и реальные паттерны: что НЕ спасает
- Красные флажки на уровне prompt-инжекции не помогут, если leakage идет через SQL- или glue-код.
- Встроенные фильтры Claude или OpenAI не знают вашу бизнес-логику — фильтрация приватных полей — только на вашей стороне.
- «Всё через API» не спасает — если API отдаёт лишнее, агент утечёт всё, что получил.
FAQ
Нужно ли использовать sandbox для каждого агента?
Для продовых сценариев — да, sandbox с ограниченным доступом к данным снижает риск утечек в 3 раза (по моим метрикам на проде).
Как автоматизировать ревью workflow в n8n?
Экспортируйте workflow в JSON и прогоняйте через semgrep по правилам на приватные поля и сторонние HTTP-запросы.
Может ли Postgres row-level security защитить от утечек через агента?
Да, но только если все запросы проходят через application layer, а не прямые SQL-сессии без контроля.
Нужно ли логировать все вызовы AI-агентов?
В проде — логирую только подозрительные и доступ к приватным таблицам. Полный лог несёт риск утечки логов.
Стоит ли использовать open source LLM вместо OpenAI/Claude?
Только если вы умеете контролировать весь lifecycle модели и можете обеспечить аудит кода и данных end-to-end.
В вашем production pipeline утечки чаще всего происходят на glue-коде, внутри workflow, или на фазе ответа агентом? Сколько багов вы поймали автоматическим анализом, а сколько — в ручную? Я провожу бесплатный 30-мин аудит stack для DACH-команд, которые строят AI в регулируемых рынках. Пишите в LinkedIn или на @ger_dennis_ai.
