Ваш coding agent стал точкой входа в инфраструктуру: что проверить после бэкдора в Claude Code/Cursor

Я Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и мой рабочий стек — Claude, Supabase, n8n, Doppler и self-hosted Postgres. Если ваш coding agent уже подключен к репозиторию, секретам, CI и базе, то после истории с бэкдором в Claude Code/Cursor надо считать его не IDE-ассистентом, а еще одним оператором инфраструктуры с широким периметром доступа.

Проблема не в самом факте уязвимости. Проблема в том, что многие команды до сих пор оценивают такие инструменты как “помощь разработчику”, а не как исполняемую сущность, которая читает конфиги, предлагает код, трогает migrations, может подсказать опасный shell-командный шаблон и часто видит больше, чем junior engineer в первый месяц работы.

1. Сначала зафиксируйте реальный blast radius

После любого инцидента с coding agent я сначала не ищу “вредоносную строку”. Я считаю радиус доступа. Какие репозитории агент видел? Какие ветки мог менять? Какие секреты были в среде IDE, локальном shell, .env, n8n credentials, Supabase service role keys, Postgres DSN, CI variables? Если вы не можете ответить за 15 минут, у вас уже не проблема разработки, а проблема инвентаризации доступа.

Что проверить в первую очередь

OWASP в LLM Top 10 2025 отдельно выделяет excessive agency как типовой риск: модельному компоненту часто дают доступ и полномочия шире, чем требуется задаче. Источник: OWASP GenAI Security Project, “LLM Top 10”, 2025, https://genai.owasp.org/. Для production-систем это очень точная формулировка: инцидент редко ограничивается одним ответом модели, обычно он раскрывает переизбыточный доступ вокруг нее.

2. Ротация секретов важнее поиска виноватого коммита

Если coding agent имел доступ к секретам, относитесь к ним как к потенциально скомпрометированным. Не “если увидим признаки”, а сразу по списку. Я обычно делю ротацию на 3 волны: мгновенно отзываемые токены, сервисные ключи с зависимостями и долгоживущие учетные данные инфраструктуры.

#!/usr/bin/env bash
set -euo pipefail

echo "Rotate high-risk secrets first"
echo "1) Revoke Git access tokens"
echo "2) Rotate Supabase service role key"
echo "3) Rotate Postgres application password"
echo "4) Rotate Doppler service token"
echo "5) Re-issue n8n credentials"

for item in git supabase postgres doppler n8n; do
  printf "queued: %s\n" "$item"
done

echo "After rotation, restart workers and invalidate cached sessions"

Здесь важен порядок. Сначала закрываете каналы дальнейшего доступа, потом меняете то, что может сломать прод, и только потом разбираете форензику. В regulated среде это особенно заметно: задержка в 6 часов между обнаружением и ротацией может быть опаснее самого первоначального вектора.

3. Перепроверьте код, который агент уже помог сгенерировать

Самый недооцененный участок — код, который был создан до публичного инцидента и уже попал в production. Особенно DB layer, shell wrappers, integration handlers и code, который работает с файлами. Я несколько раз ловил один и тот же паттерн: модель пишет удобную SQL-обертку через f-string или string interpolation, а дальше это проходит ревью, потому что выглядит “как обычно”.

OpenAI Cookbook в материалах по function calling и tool usage много раз подчеркивает необходимость валидации входов и ограничения действий инструмента на стороне приложения, а не на стороне модели. Источник: OpenAI Cookbook, 2024, https://cookbook.openai.com/. Это относится и к coding agents: доверять надо не тексту подсказки, а контролям вокруг исполнения.

import os
import psycopg
from psycopg.rows import dict_row

conn = psycopg.connect(os.environ["DATABASE_URL"], row_factory=dict_row)

def get_order(order_id: str):
    with conn.cursor() as cur:
        cur.execute(
            "select id, status from orders where id = %s",
            (order_id,)
        )
        return cur.fetchone()

def update_status(order_id: str, status: str):
    with conn.cursor() as cur:
        cur.execute(
            "update orders set status = %s where id = %s",
            (status, order_id)
        )
    conn.commit()

Минимальный набор после инцидента: прогон semgrep, bandit, gitleaks по активным репозиториям и выборочный ручной аудит модулей, к которым агент чаще всего прикасался. semgrep хорошо ловит опасные паттерны в application code, bandit — типовые проблемы в Python, gitleaks — случайно закоммиченные секреты.

semgrep --config auto .
bandit -r app/
gitleaks detect --source . --verbose
git log --since="90 days ago" --stat -- '*.py' '*.ts' '*.sql'

4. Ограничьте агенту среду исполнения, а не только prompt

Очень многие команды после подобных историй переписывают system prompt и считают задачу закрытой. Это почти ничего не меняет, если у агента все еще есть shell, сеть, секреты и право писать в доверенную ветку. Исполнение должно быть ограничено независимо от качества модели.

Практический baseline

Я рекомендую 4 слоя. Первый — отдельный low-privilege runtime для агентных задач. Второй — раздельные ключи для read и write операций. Третий — запрет прямого доступа к production-базе из среды, где работает coding agent. Четвертый — human approval на migrations, credential changes и любые действия с инфраструктурой.

agent_runtime:
  git_access: read_only
  network_egress: allowlist
  database:
    prod_direct_access: false
    staging_role: read_write
  secrets:
    mount_env_files: false
    use_doppler_service_token: true
  approvals:
    require_human_for:
      - migrations
      - credential_rotation
      - infra_changes

Если у вас Supabase, разделите service role и обычные application keys по контексту исполнения. Если у вас self-hosted Postgres, создайте отдельного пользователя только для staging и запретите reuse паролей между средами. Если у вас n8n, перепроверьте все credentials и webhook nodes: именно автоматизация часто превращает локальный инцидент в системный.

5. Логи и история подсказок — это тоже активы, а не мусор

Еще одна типичная ошибка: команды проверяют репозиторий и секреты, но забывают prompt history, IDE extension logs, CI artifacts и traces. А там нередко лежат фрагменты SQL, DSN, customer payloads и внутренние URL. Для европейского B2B это уже не просто инженерная небрежность, а риск инцидента с персональными данными и контрактными обязательствами.

После такого события я делаю короткий data-flow review: какие данные агент видел на входе, какие мог передать внешнему API, где они логировались, сколько времени хранятся и кто имеет к ним доступ. Этот шаг скучный, но он часто показывает больше, чем анализ самого suspicious commit.

FAQ

Нужно ли полностью отключать coding agent после такого инцидента?

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

Достаточно ли read-only доступа к Git?

Это хороший старт, но не полный ответ. Даже read-only доступ к коду, конфигам и истории коммитов может раскрыть чувствительные детали архитектуры, internal endpoints и паттерны ротации секретов.

Нужно ли проводить аудит всех старых PR, где участвовал агент?

Все подряд — обычно слишком дорого. Я бы начал с 60–90 дней, затем приоритизировал PR, затрагивавшие SQL, shell, auth, CI, secrets handling и инфраструктурные скрипты.

Какие инструменты дают практический минимум?

Для быстрого прохода мне хватает semgrep, bandit, gitleaks и ручного просмотра критичных модулей. Дальше уже зависит от стека и требований вашей компании.

Это проблема только Claude Code и Cursor?

Нет. Это класс проблем для любого coding agent или IDE-интеграции, которая имеет доступ к вашему коду, среде выполнения и инструментам. Название продукта меняет детали, но не меняет модель риска.

Где в вашем LLM pipeline сейчас реально ловятся самые опасные ошибки — на этапе статического анализа, в runtime-ограничениях или только на человеческом ревью перед merge? Мне правда интересно сравнить это с тем, что я вижу в production у B2B-команд.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.