Ваш AI-агент может быть взломан через плагины: как защитить прод от уязвимостей в Claude Code и Codex

Я Денис Шохирев, архитектор агентных AI-систем из Фрайбурга и основатель DennisCraft AI Studio. Мой стек — Claude, Supabase, n8n, Doppler, self-hosted Postgres. В одном из недавних проектов для B2B-клиентов я поймал SQL-инъекцию в автогенерируемом плагине — уязвимость возникла прямо в Claude Code, и была бы совершенно незаметна на демо.

Где ломают: реальные векторы атаки через плагины

Автономные AI-агенты в проде часто расширяются плагинами или кастомными "скиллами" — небольшими модулями на Python или JS, которые подключаются через API или прямую интеграцию. Проблема: 80% кода таких плагинов сгенерировано LLM (источник: внутренний аудит 2024, 11 проектов). Если разработчик не проводит отдельную ревизию, ошибки типа CWE-89 (SQL-инъекции), SSRF, или RCE попадают в прод.

Паттерны уязвимостей в Claude Code и Codex

• SQL-инъекции: когда LLM "собирает" SQL-запрос из строк без параметризации.
• Insecure deserialization: плагины обрабатывают входные данные без валидации.
• Неочевидные SSRF: LLM пишет код, который позволяет agent'у делать HTTP-запросы к внутренним сервисам.
• OS-команды через unsafe eval или subprocess — особенно если агенту дали "расширенные права".

В одном из недавних случаев Claude сгенерировал Python-плагин, который напрямую вставлял user input в SQL-запрос:

def get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    cursor.execute(query)
    return cursor.fetchall()

Этот код прошёл ревью, потому что был частью auto-generated блока, но в итоге стал прямой точкой входа для SQL-инъекции.

Как ловить такие баги ДО продакшна: pipeline в деталях

В моих агентных системах я строю pipeline из трёх основных этапов:

1. Статический анализ кода (semgrep, bandit, gitleaks)
2. Sandbox-тесты с реальными payload'ами
3. Человеческое ревью — только для "критических" плагинов

Статический анализ: semgrep + bandit

semgrep отлично ловит паттерны типа f"SELECT ..." и небезопасные вызовы. bandit даёт специфическую проверку под Python. Пример правила semgrep для SQL-инъекций:

rules:
  - id: possible-sql-injection
    pattern: cursor.execute(f"...")
    message: "Возможная SQL-инъекция через f-string"
    severity: ERROR

bandit интегрируется CI/CD:

bandit -r ./plugins/

gitleaks — для поиска случайно закоммиченных токенов и секретов в плагинах.

Sandbox-тесты: эмулируем злоумышленника

Любой новый плагин я сначала гоняю в изолированной среде с payload'ами — например, ' OR '1'='1 для SQL, file:///etc/passwd для SSRF. Полезно использовать тестовые эндпоинты и фейковые базы.

# Пример unit-теста для проверки SQL-инъекции
def test_sql_injection():
    result = get_user_data("' OR '1'='1")
    assert "admin" not in result

Ошибки в проде: как реагировать и патчить

Если уязвимость уходит в прод, важно иметь процесс roll-back и мгновенного патчинга. В моей практике быстрее всего работает отдельная ветка для "критических" плагинов: они могут деплоиться вне release-цикла, с отдельным audit-log.

Плюс — логирование всех входных payload'ов и их ассоциация с версией плагина. Это позволяет быстро понять, какой код сработал при атаке.

Что с LLM sandbox: ограничения Claude Code и Codex

Claude Code и Codex в production-режиме часто работают с урезанными правами (restricted execution). Однако, по умолчанию многие фреймворки разрешают агенту генерировать любой Python-код и даже выполнять shell-команды. Не рассчитывайте на "sandbox по умолчанию" — например, в Anthropic SDK официально рекомендуют явно ограничивать список разрешённых функций и проверять output до исполнения.

# Пример ограничения функций в Claude Code
allowed_functions = {"get_user_data", "send_email"}
if requested_function not in allowed_functions:
    raise Exception("Запрещённая функция")

Если вы строите агента через n8n, помните: каждый custom node — это потенциальная точка риска, если он генерируется автоматически.

FAQ

Какой инструмент лучше всего ловит SQL-инъекции в автогенерируемом коде?

semgrep наиболее универсален: позволяет писать кастомные правила, легко интегрируется в любые пайплайны.

Реально ли полностью доверять bandit или semgrep?

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

Есть ли смысл делать ручной аудит всех плагинов?

Нет, если их >10 в неделю. Я делаю ручную проверку только для тех, что имеют доступ к критическим данным или внешним API.

Как защитить self-hosted Postgres от LLM-агентов?

Вынесите все запросы в параметризованные процедуры, не давайте агенту прямой доступ к raw SQL. В Supabase используйте Row Level Security (RLS).

Что делать, если уязвимость ушла в прод?

Выделяйте отдельную ветку для срочных патчей, ведите audit-log payload'ов, чтобы быстро понять масштаб атаки.

На каком этапе ваш пайплайн чаще всего ловит реальные баги — статический анализ, sandbox-тесты или ручной аудит? Мне реально интересно.

Я бесплатно провожу 30-мин аудит AI-стека для фаундеров и CTO из DACH, которые строят AI в регулируемых рынках. Напишите в LinkedIn или в телегу: @ger_dennis_ai.