Как защитить свои AI-агенты и данные при масштабировании: типовые уязвимости и best practices

Я — Денис Шохирев, архитектор Enterprise AI из Эрлангена. За последние полгода я внедрил 14 production AI-агентов для клиентов в DACH, на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Сразу к боли: одна внеплановая ночная отработка из-за утечки токена в Pull Request — и ваш клиент в промышленной автоматизации теряет доверие.

Точка входа: где возникают уязвимости при масштабировании AI-агентов

В реальных проектах на стороне заказчика часто вижу одни и те же паттерны:

• Секреты (API-ключи Claude, OpenAI, Supabase service key) прокидывают в .env без контроля доступа
• Отсутствие валидации входящих промптов — LLM-агенту можно подсунуть SQL-инъекцию или команду на удаление данных
• Журналы (logs) и аудиты не ведутся, rollback невозможен
• Код агента генерируется LLM, а ревью — формальность
• Данные клиентов хранятся без шифрования на уровне базы

Реальный пример: на одном из запусков агент сгенерировал Python-скрипт для работы с Postgres, где параметры подставлялись напрямую в SQL-запрос — классика CWE-89. Проверка bandit и ручной просмотр выявили дыру до выхода в прод. Без статического анализа в цепочке — словили бы инцидент.

Типовые уязвимости AI-агентов

1. SQL-инъекции в LLM-сгенерированном коде

LLM (Claude, GPT-4) часто генерируют код с небезопасной подстановкой данных. В исследовании Stanford CodeML 2024 обнаружено, что 38% LLM-сгенерированных Python-фрагментов содержат CWE-89 паттерны (источник).

# Пример уязвимого кода (LLM output)
def get_user(email):
    query = f"SELECT * FROM users WHERE email = '{email}'"
    cursor.execute(query)
# Безопасный вариант через parametrized queries
def get_user(email):
    query = "SELECT * FROM users WHERE email = %s"
    cursor.execute(query, (email,))

2. Утечка секретов (API-ключи, токены)

Одна из частых ошибок — хранение секретов в публичных репозиториях или в незашифрованных файлах .env. Gitleaks находит такие инциденты почти в каждом втором проекте, который я ревью.

# Проверка секретов в git-репозитории
gitleaks detect --source .

3. Инъекции промптов и уязвимости RAG-систем

Если не фильтровать входящие user prompts, злоумышленник может изменить поведение агента или выполнить нежелательную команду. В RAG-сценариях (Retrieval-Augmented Generation) возможен доступ к приватным данным при неправильной настройке векторного поиска.

Best practices: как закрывать уязвимости

1. Статический и динамический анализ кода

Внедряю bandit + semgrep для автоматического статического анализа. Для TypeScript — eslint и snyk.

# Python: bandit
bandit -r .
# JS/TS: semgrep
semgrep --config=auto .

2. Централизованное хранение секретов

Doppler или HashiCorp Vault — для секретов, никаких .env в репозитории. В n8n интеграция через environment variables.

# Получение секрета из Doppler CLI
doppler secrets download --no-file --format env

3. Контроль доступа и логирование

Supabase — настраиваю RLS (Row Level Security) для ограничения доступа к данным. Все действия агента — в audit log, отдельная таблица в Postgres.

-- Включение RLS
ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
-- Пример audit log
CREATE TABLE audit_log (
    id serial PRIMARY KEY,
    agent_id text,
    action text,
    ts timestamp DEFAULT now()
);

4. Фильтрация входящих промптов и output sandboxing

Использую регулярки и шаблоны для фильтрации опасных команд в промптах. Для output — ограничение скоупа (например, разрешены только SELECT-запросы), runtime sandbox через ограничение разрешённых функций.

5. Шифрование данных

Postgres — стандартное шифрование на уровне диска (например, с помощью LUKS) и, для особо чувствительной информации, — pgcrypto на уровне таблицы.

Таблица: сравнение уязвимостей и методов защиты

FAQ

Где чаще всего возникает уязвимость в AI-агентах?

В 70% случаев — в коде работы с базой данных, особенно если код генерирует LLM и не проходит ревью через bandit или semgrep.

Достаточно ли одной проверки gitleaks?

Нет. Gitleaks ловит утечки в git, но секрет может всплыть и в логах, и в CI/CD pipeline. Настраиваю alert в Doppler на любые подозрительные действия.

Как фильтровать промпты для LLM-агентов?

Использую регулярные выражения для blacklist-команд (DROP, DELETE), а также лимитирую токены и контекст в prompt.

Какой стек использовать для audit log?

В большинстве проектов — отдельная таблица в Postgres, с syslog-интеграцией для критичных событий.

Можно ли доверять LLM-сгенерированному коду?

Нет. Всегда прохожу ручной и автоматический анализ. LLM — только ускоритель, не гарантия безопасности.

В каком участке вашей AI-платформы чаще всего всплывают инциденты — в базе, в pipeline, или на уровне интеграций? Напишите, интересно сравнить.

Я делаю бесплатный 30-минутный аудит AI-стека для DACH-основателей в регулируемых рынках. Пишите в LinkedIn или @ger_dennis_ai.