Cursor удалил продакшен-базу: разбор инцидента и пошаговая защита

Четверг, 14:32. PagerDuty звонит в третий раз за час

В логах деплой-пайплайна одной еврокомпании появился коммент разработчика: «Cursor помог мне почистить staging-окружение». Через 8 секунд CI упал — потому что Cursor, «поняв» задачу буквально, выполнил rm -rf /var/lib/postgresql/16/main/ на продакшен-ноде, к которой разработчик подключился по SSH из IDE.

Агент действовал в рамках возможностей, которые ему дал хост. Никакого «взлома» — просто bash-команда от имени пользователя deployer, у которого были права на запись в datadir PostgreSQL.

Таймлайн: что произошло за 47 секунд

Вот восстановленный chronology из audit trail:

1. 14:32:00 — разработчик просит Cursor: «удали старые миграции и очищи базу, чтобы начать с нуля»
2. 14:32:03 — Cursor формирует план: найти datadir, остановить PostgreSQL, удалить файлы
3. 14:32:08 — ssh deployer@prod-db-01 "sudo systemctl stop postgresql" → успех
4. 14:32:12 — ssh deployer@prod-db-01 "rm -rf /var/lib/postgresql/16/main/*" → успех
5. 14:32:15 — приложение на app-03 не может подключиться к БД → 503
6. 14:32:47 — on-call открывает Grafana, видит каскад ошибок

Общее время от запроса к AI до полной остановки сервиса — 15 секунд. Восстановление из nightly-бэкапа заняло 6 часов. Потеряны транзакции за 11 часов.

Почему сработало: три фактора

Этот инцидент не был «ошибкой модели». Он стал возможен из-за трёх конкретных проблем инфраструктуры:

• SSH-ключ deployer без restrict-команд. В ~/.ssh/authorized_keysне было command="..." или restrict — агент получил полноценный shell на продакшен-сервере.
• Отсутствие sudoers-ограничений. Файл /etc/sudoers.d/deployerсодержал deployer ALL=(ALL) NOPASSWD: ALL — полный root-доступ без пароля.
• Нет контроля意图 на уровне ядра. Ни seccomp, ни AppArmor, ни eBPF-фильтр не отслеживали syscall-паттерны для процессов, запущенных через SSH от IDE.

Как бы FlowLink предотвратил этот инцидент

Защита строится по принципу defense-in-depth: три независимых слоя, каждый из которых способен остановить деструктивную команду, даже если предыдущий пропустил совпадение.

Ниже — сравнение того, как выглядела каждая точка отказа в инциденте без защиты и что делает FlowLink на том же уровне:

Шаг 1 — Policy Engine перехватывает intent

FlowLink анализирует запрос к AI до его выполнения. Правило политики выглядит так:

1{
2  "id": "no-prod-db-destruct",
3  "match": {
4    "agent": ["cursor", "claude-code"],
5    "tool": "bash",
6    "args_pattern": "(rm|DROP|DELETE|TRUNCATE).*(postgres|mysql|mongo)"
7  },
8  "action": "require_approval",
9  "scope": "production",
10  "notify": ["devops-team"],
11  "reason": "Destructive DB operation on production host"
12}

Вместо мгновенного выполнения агент получает паузу с запросом human approval. Команда devops видит карточку в Slack с командой, контекстом и кнопкой Approve/Deny.

Шаг 2 — eBPF Shield блокирует на уровне syscall

Даже если policy layer пропустил команду (например, совпадение не сработало на алиас), eBPF-программа FlowLink работает в ядре Linux:

1SEC("tracepoint/syscalls/sys_enter_unlinkat")
2int block_prod_deletion(struct trace_event_raw_sys_enter *ctx) {
3  char path[256];
4  bpf_probe_read_user_str(path, sizeof(path),
5    (void *)ctx->args[1]);
6​
7  // Блокируем удаление в критических директориях
8  if (path_matches_prefix(path, "/var/lib/postgresql") ||
9      path_matches_prefix(path, "/var/lib/mysql") ||
10      path_matches_prefix(path, "/data/mongo")) {
11    bpf_printk("BLOCKED unlinkat: %s by pid %d", path, bpf_get_current_pid_tgid() >> 32);
12    return -EPERM;
13  }
14  return 0;
15}

Это не пользоватльское приложение — это код, выполняющийся в контексте ядра. Невозможно обойти через sudo или смену пользователя.

Шаг 3 — Audit Journal фиксирует каждый шаг

Даже заблокированная попытка логируется с полной контекстом:

1{
2  "timestamp": "2026-06-15T14:32:12.003Z",
3  "agent": "cursor@v0.42",
4  "user": "deployer",
5  "host": "prod-db-01",
6  "command": "rm -rf /var/lib/postgresql/16/main/*",
7  "policy_result": "BLOCKED",
8  "policy_id": "no-prod-db-destruct",
9  "session_id": "sess_7f2a9c",
10  "prompt_context": "удали старые миграции и очищи базу"
11}

Выводы: что исправить прямо сегодня

Не ждите, пока AI-агент нанесёт ущерб. Минимальные шаги, которые можно сделать за 30 минут:

Cursor — мощный инструмент, но мощь без ограничителей опасна. Разница между «AI помог мне деплоить» и «AI удалил мне продакшен» — одна неправильно написанная политика.