Приложение, собранное ИИ, может показывать чужие данные посторонним: что проверить до запуска

Здравствуйте. Сегодня выпуск для тех, кто собрал сайт или приложение с помощью ИИ-агента и выложил его в интернет. Или только собирается выложить. С начала ноября вышло сразу несколько отчётов, и все они об одном. Приложения, которые ИИ собирает за вечер, показывают посторонним чужие данные: анкеты, переписку, номера паспортов, пароли. И почти нигде никто ничего не взламывал.

Что вы вынесете из выпуска. Вы поймёте, как приложение может отлично работать и при этом быть открытым для любого прохожего. Почему расчёт «мой маленький сайт всё равно никто не найдёт» больше не спасает. Почему кнопка «Войти» и зелёная галочка автоматической проверки ещё ничего не доказывают. И как у вас могут увести деньги через ключи, даже если вы всё сделали по инструкции. А главное, к каждому пункту будут готовые поручения, которые можно сегодня же дать своему агенту.

Одна оговорка, и больше к ней возвращаться не будем. Цифры в этой теме громкие, а заголовки ещё громче. Почти все данные идут от исследователей, которые сами продают проверки безопасности, и от компаний, которые рассказывают о собственных взломах. Так что каждая цифра здесь — это их оценка. А там, где цифра значит не то, что кажется, это будет сказано сразу.

Начнём с простого вопроса. Как чужой человек может читать вашу базу данных, если он ничего не взламывал? Чтобы это понять, надо один раз представить, что у приложения внутри. Это правда несложно.

У приложения две части. Первая — страница, которую человек видит в браузере. Вторая — база данных, то есть таблицы, где лежат пользователи, заказы, сообщения. В привычной схеме между ними стоит ещё одна программа на сервере. Она работает как охранник на проходной: страница просит данные, охранник смотрит, кто просит, и решает, что ему показать.

Так вот, в приложениях, которые собирают конструкторы и агенты, охранника часто нет. Страница в браузере посетителя обращается к базе сама, напрямую. Для этого ей нужен ключ, и он лежит прямо в коде страницы, где его увидит кто угодно. Звучит как дыра, но так задумано. База Supabase, которую агенты очень любят, называет такой ключ публичным и прямо пишет, что показывать его безопасно.

Тогда где защита? В самой базе. Это набор правил: кто какие строки таблицы может видеть и менять. У Supabase это называется защитой на уровне строк, по-английски Row Level Security. Запомните это название, оно пригодится в разговоре с агентом. Правило работает как невидимое условие, которое база сама дописывает к каждому запросу. Например: показывать человеку только те заказы, где покупатель он сам.

И вот главное место. Если правил нет или в правиле написано «разрешить всем», таблицу читает любой посетитель сайта. Не хакер, а просто человек с браузером. По документации Supabase такую таблицу можно не только читать, но и менять. То есть замок на двери есть, его просто не закрыли.

Как это выглядит в жизни? Небольшая фирма по безопасности из Гамбурга, Crissy Field, вместе с немецкой деловой газетой Handelsblatt проверила сайты, собранные в Lovable. Это конструктор, где приложение описывают словами, а собирает его ИИ. Почти двадцать пять тысяч таких сайтов отдавали записи из базы любому посетителю, без входа. Сама по себе эта цифра ещё не беда, и исследователи это подчёркивают. Меню ресторана тоже лежит в базе, и видеть его должны все.

Беда начинается дальше. Исследователи отправили этим сайтам ещё несколько запросов, только на чтение. Больше чем на семи тысячах сайтов нашлись таблицы с адресами электронной почты. Не каждая такая таблица означает утечку, почта бывает публичной или тестовой.

Но были и находки, где спорить не о чем. У одного форума читались больше восьмидесяти тысяч анкет с именами и датами рождения. Там же лежали больше двухсот тысяч сообщений из чата. А у одного сервиса было открыто больше тысячи записей с номерами паспортов.

И вот что здесь важнее любых цифр. Автор отчёта говорит, что никаких продвинутых приёмов взлома не понадобилось. По его словам, результат повторит любой, кто в общих чертах понимает, как работает интернет. Исследователи собирались начать с простого и потом перейти к сложным атакам. До сложных они так и не дошли: слишком много лежало на поверхности. Воспользовался ли кто-то этими данными во вред, они установить не смогли.

Тут вы можете возразить: это же конструктор, а мне всё собирает агент в терминале, при чём тут мой проект? При том, что схема та же самая. Связка «страница плюс база, в которую браузер ходит напрямую» встречается и во многих проектах, собранных в Claude Code. И дело не в одной Supabase. У Firebase, другой базы похожего типа, в документации про правило «разрешить всем» написано без церемоний. Никогда не используйте его в рабочем проекте, оно позволяет кому угодно перезаписать всю вашу базу.

Поэтому первое поручение агенту вообще не про защиту. Оно про то, чтобы вы поняли собственный проект. Скажите так: объясни мне простыми словами, как устроено моё приложение. Где лежат данные и как называется база? Страница в браузере ходит в базу напрямую или через программу на сервере? Где настраивается, кто что может видеть?

Ответ займёт полстраницы. Зато дальше вы будете примерять этот выпуск к себе, а не к чужим сайтам.

Теперь вопрос, который напрашивается. Почему ИИ, который пишет рабочее приложение за вечер, не ставит эти правила сам? Ответ простой, даже обидно простой. Агент решает ту задачу, которую вы ему дали. Вы просили, чтобы заказы сохранялись и показывались. Они сохраняются и показываются.

А вот кто какие заказы должен видеть — это не техника. Это ваше решение про ваше дело. Видит ли менеджер заказы других менеджеров? Видит ли клиент чужие отзывы с телефонами? Если вы этого не сказали, агенту неоткуда это взять. Он выберет вариант, при котором всё работает. А самый надёжный способ добиться, чтобы работало, — разрешить всем.

И это не догадка. В научном исследовании этого года проверили двести работающих приложений, собранных ИИ. В девяноста одном проценте нашлась хотя бы одна уязвимость, и главным видом ошибок оказался как раз сломанный контроль доступа. Одну из причин авторы видят в том, что агент добивается цели «чтобы работало». Ещё один их вывод полезно знать заранее: хорошие промпты риск снижают, но не убирают. Значит, слов мало, нужна ещё проверка, и до неё мы дойдём.

К слову, программисты-люди ошибаются там же. В отраслевом рейтинге самых опасных уязвимостей ошибки доступа стоят на первом месте. ИИ эту проблему не придумал. Просто приложений стало намного больше, а делают их теперь люди, которым про эти правила никто не рассказывал.

Что с этим делать? Первое и главное: правила доступа вы описываете агенту словами, в самом начале проекта. Как они записываются в базе, знать не нужно. Нужно сказать по-человечески: гость видит только витрину, покупатель видит только свои заказы, администратор видит всё. Одна такая фраза меняет то, как агент построит базу.

Второе: попросите агента работать по принципу «закрыто по умолчанию». Каждая новая таблица сначала недоступна никому, а открывается только то, что вы назвали. И пусть он запишет это в файл с постоянными инструкциями проекта. Иначе через неделю, в новом разговоре, он об этом не вспомнит.

Третье — ревизия того, что уже построено. Поручение звучит так: перечисли все таблицы в базе и для каждой объясни простыми словами, кто может её читать и кто может менять. Отдельно покажи таблицы, где защиты нет или стоит правило «разрешить всем». Вы получите список на страницу. В нём сразу видно, где витрина, а где клиенты с телефонами.

В этой же ревизии попросите агента поискать три типовые ошибки, они описаны в документации Supabase. Первая вам уже знакома: «разрешить всем» на таблице с личными данными. Вторая хитрее. Правило пускает любого, кто вошёл в аккаунт, и не смотрит, его ли это строка. Третья совсем коварная. Пометка «этот человек администратор» хранится в той части профиля, которую пользователь может править сам. Захотел и записал себя в администраторы.

Если агент ответил, что у вас Supabase, есть ещё несколько вещей именно про неё. Таблица, которую человек создаёт вручную в панели сервиса, получает защиту сразу. Но ваш агент в панель не ходит, он создаёт таблицы командами, и на таких таблицах защита сама не включается. Поэтому попросите его включить защиту на уровне строк на каждой таблице. И настроить базу так, чтобы на всех новых таблицах она включалась автоматически.

Ещё у Supabase есть встроенный советник по безопасности, Security Advisor. Он ищет таблицы без защиты и столбцы с чувствительными данными, которые видны снаружи. Запустить его агент может сам. Попросите об этом и пусть перескажет каждую находку простыми словами: что это, чем грозит и как он предлагает исправить.

И свежая ловушка, о которой мало кто слышал. С тридцатого октября Supabase изменила поведение во всех проектах: новая таблица недоступна снаружи, пока ей явно не выдали разрешение. Перемена хорошая, но у неё две стороны. Старые таблицы остались как были, уже открытое само не закроется. А на новых таблицах агент теперь будет чаще натыкаться на ошибку «доступ запрещён».

Вот здесь будьте внимательны. Самый быстрый способ убрать такую ошибку — выдать доступ всем. Агент, которому просто сказали «почини», вполне может пойти этим путём, и всё заработает. Поэтому дайте ему постоянное правило, тоже в файл инструкций. Ошибку доступа нельзя чинить, открывая доступ всем подряд. Сначала объясни, кому и что ты хочешь разрешить, и дождись ответа.

Теперь про ключи от базы, их два вида. Публичный лежит в коде страницы, и это нормально. Секретный обходит все правила защиты разом, и место ему только на сервере. Спросите агента прямо: есть ли в файлах, которые скачивает браузер посетителя, секретный ключ, пароли или списки пользователей?

Вопрос не праздный. В одном из ноябрьских отчётов описан табель рабочего времени у подрядчика. В его коде, который получает каждый посетитель, лежали восемнадцать учётных записей сотрудников. С паролями открытым текстом, включая администраторов. Представляете? Даже базу читать не надо, всё уже приехало в браузер.

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

И последняя проверка в этой части, самая честная. Попросите агента зайти на ваш опубликованный сайт так, как зашёл бы посторонний. Без входа, только с тем публичным ключом, который и так лежит в коде страницы. Пусть попробует прочитать каждую таблицу и покажет, что ему вернули: есть ли там имена, почта, телефоны, заказы. Только чтение и только ваш собственный сайт. По сути, это то же, что делали исследователи из Гамбурга. Только теперь результат первым увидите вы.

Переходим ко второму выводу. Многие рассуждают так: ладно, что-то у меня не закрыто, но кто найдёт мой сайт среди миллионов? Адрес длинный, нигде не опубликован, знают его три человека. Увы, этот расчёт больше не работает. Посмотрим на приложения из конструктора Grok.

У Grok есть инструмент Grok Build, в нём приложения тоже собирают словами. Исследователи из компании Claroc нашли в сети десятки тысяч таких приложений и открыли первую страницу каждого. Больше тридцати пяти тысяч открылись без всякого входа. Большинство из них безобидные: игры, странички, калькуляторы, вход им и не нужен. Но в нескольких сотнях лежали личные данные. Авторы оценивают их число так: от шестисот пятидесяти до восьмисот приложений.

И что это за приложения! Список сотрудников больничной сети, больше трёх с половиной тысяч человек, и по этому списку можно искать. Сводка по одному пациенту реанимации, с анализами и состоянием аппарата вентиляции лёгких. Доска смен пожарной части с именами и номерами жетонов. Этих людей легко понять. Они собрали себе удобный рабочий инструмент, положили туда настоящие данные и отправили ссылку коллегам.

Как же их нашли, если ссылку видели только коллеги? У каждого опубликованного приложения своё имя сайта. Когда коллега первый раз открывает ссылку, его компьютер спрашивает у справочной службы интернета, где живёт сайт с таким именем. Это похоже на звонок в справочную: чтобы вас соединили, название приходится произнести вслух. Журналы таких вопросов собирают специальные сервисы, и в них можно искать по шаблону имени.

Получается, ссылка перестаёт быть секретом в ту минуту, когда по ней впервые перешли. Grok предлагает в качестве имени четыре случайных слова, угадать такое нельзя. Но исследователи замечают, что угадывать и не нужно, имя уже лежит в списке. По той же причине не стоит прятать таблицы под необычными названиями. База в сообщении об ошибке может сама подсказать правильное имя.

Вторая половина этой истории — настройка, которую выбрали за вас. Когда исследователи публиковали собственное приложение, им предложили три варианта доступа: все, у кого есть ссылка, приглашённые и только я. Заранее отмечен был первый. Человек нажимает «Опубликовать», ничего не меняет, и приложение открыто всему интернету. А ведь бывает иначе. В ChatGPT собранное приложение тоже можно опубликовать, и там у них по умолчанию стояло «только я».

И ещё один механизм, который полезно держать в голове. Его точно описали в Гамбурге. Конструкторы строят приложения по одним и тем же шаблонам. Поэтому приём, который сработал против одного приложения, почти без усилий срабатывает против тысяч других. Вам не нужно быть интересной целью. Достаточно быть похожим на остальных.

Что из этого следует для вас. Первое: перед каждой публикацией узнайте, кто сможет открыть приложение. Если публикует агент, спросите его прямо: кто увидит это приложение по ссылке и что именно он увидит без входа? Если вы публикуете через конструктор, эта настройка стоит на экране публикации, и глянуть на неё придётся самому. Всё внутреннее — только для вас или для приглашённых. Вариант «все, у кого есть ссылка» считайте публикацией на весь интернет.

Потом сделайте одну простую вещь своими руками. Откройте приложение в окне инкогнито, не входя в аккаунт. Посторонний должен увидеть страницу входа или ошибку, а не ваши данные. Тут ничего не нужно понимать в технике, достаточно посмотреть на экран.

Второе: не кладите настоящие данные в пробные приложения. Хочется проверить идею на живой выгрузке клиентов, это понятно. Но пробное приложение публикуется так же, как настоящее, а следят за ним гораздо хуже. Попросите агента сгенерировать сотню выдуманных клиентов с правдоподобными именами и телефонами. Для проверки идеи этого хватит.

Третье: разберите всё, что вы уже выложили. За год работы с агентами у человека легко набирается десяток забытых проектов. Попросите агента помочь составить список: что публиковалось из ваших папок и где оно сейчас живёт. По каждому пункту решение одно из двух. Нужен — проверяю. Не нужен — снимаю с публикации. У Grok, по данным Claroc, снятое приложение перестаёт открываться сразу.

И четвёртое, про ссылки на чаты. Когда вы делитесь разговором с нейросетью, такая ссылка устроена иначе, и в те журналы она не попадает. Зато страницу могут найти поисковики. В августе прошлого года в поиске Google оказались больше трёхсот семидесяти тысяч разговоров с Grok, которыми люди поделились по ссылке. Так что общую ссылку на чат разумно считать публичной. И не оставлять в таком чате того, что не готовы показать всем.

Третий вывод самый коварный, потому что он про ложное спокойствие. В приложении есть кнопка «Войти». Автоматическая проверка показала зелёную галочку. Значит, всё хорошо? К сожалению, не значит.

Те же исследователи из Claroc поставили простой опыт. Они попросили Grok сделать список клиентов для команды из четырёх человек. Grok сам, без просьбы, добавил вход через аккаунт Google. Выглядит как забота о безопасности. Но код был устроен так: сначала любого вошедшего добавляли в команду, а потом проверяли, состоит ли он в команде. Проверка, понятное дело, всегда проходила.

Дальше они вошли с чужого аккаунта Google, который никто не приглашал. Этот посторонний увидел всех клиентов, изменил одну запись и удалил другую. Вот в чём суть. Вход отвечает на вопрос «кто ты». А защита данных отвечает на вопрос «можно ли тебе». Это две разные проверки, и ИИ уверенно делает первую, забывая про вторую.

В другом их пробном приложении входа не было совсем. Они открыли его в окне инкогнито и добавили строку в базу. Следующий посетитель эту строку увидел. То есть чужой может не только прочитать ваши данные, но и испортить их. Доказали они это на двух собственных приложениях, чужие не трогали.

Теперь про зелёные галочки. Автоматические проверки безопасности есть и у конструкторов, и у агентов. В Claude Code, например, есть команда для проверки безопасности и плагин, который просматривает код после каждого шага. Это полезные вещи. Но у них два ограничения, и о них лучше знать.

Первое ограничение записано прямо в документации Claude Code. Проверка читает исходный код у вас на компьютере, а не работающий сайт, и может что-то пропустить. Правила, которые заданы прямо в базе, в код могут вообще не попасть. Проверять будет нечего, и галочка останется зелёной.

Второе ограничение общее для всех сканеров. Заметить, что правила нет, легко. Гораздо труднее заметить правило, которое есть, но пускает лишних. Когда у Lovable в прошлом году появился первый сканер, исследователь, нашедший проблему, написал о нём так: он проверяет, существует ли правило, а не правильное ли оно. Насколько точны нынешние сканеры, в открытых источниках независимой проверки нет.

Есть и человеческая сторона. Почему люди не исправляют даже то, что сканер нашёл? На этот вопрос ответил глава безопасности Lovable Игорь Андрющенко, когда разработчики обсуждали гамбургский отчёт. По его словам, многих останавливает страх, что исправление сломает работающее приложение. И страх этот не на пустом месте. Некоторым авторам проще построить всё без защиты, а добавить её потом. Но в сложном приложении, говорит он, это трудная задача, и многое ломается.

Обратите внимание на этот механизм, он касается любого инструмента. Защита, отложенная на потом, превращается в ремонт, которого все боятся. Приложение работает, пользователи пришли, трогать страшно. И оно живёт открытым месяцами.

И последнее в этой части: кто отвечает, если данные утекли? У Lovable на сайте написано, что уметь программировать не нужно. А в условиях использования сказано, что результат работы ИИ может содержать ошибки и за его проверку отвечает только сам пользователь. Спорить, справедливо ли это, можно долго.

Но полезнее другое. Попросите агента прочитать условия тех сервисов, на которых стоит ваш проект, и пересказать вам одно место: кто отвечает за данные пользователей. Скорее всего, ответ вас не удивит. Отвечаете вы.

Что делать. Главный инструмент здесь называется тест двух аккаунтов, и он проще, чем звучит. Заводятся два пробных пользователя, первый и второй. Первый создаёт у себя заказ или заметку. Потом второй пытается это увидеть, изменить и удалить. Если получилось хоть что-то, защита не работает, что бы ни показывал сканер.

Руками это делать утомительно, поэтому поручите агенту. Скажите так: напиши автоматический тест, который создаёт двух пользователей и проверяет, что второй не может ни прочитать, ни изменить, ни удалить данные первого. Добавь третьего участника, который вообще не вошёл, он не должен видеть ничего личного. Запускай этот тест перед каждой публикацией. Если тест не прошёл, публиковать нельзя.

Если приложение внутреннее, для команды, добавьте ещё одну проверку. Войдите с постороннего аккаунта, которого никто не приглашал. Пустило? Значит, приложению нужен список допущенных людей. Попросите агента сделать именно список, а не просто кнопку входа.

Второе правило: защита ставится до первых настоящих данных, а не после. Это как раз совет главы безопасности Lovable, и тут с ним трудно спорить. Пока в базе пусто и пользователей нет, ломать нечего. Агент спокойно всё настроит, а тест двух аккаунтов это подтвердит.

А если приложение уже работает и вы только сейчас поняли, что оно открыто? Тогда чинить нужно, но аккуратно, чтобы не сбылся тот самый страх. Попросите агента сначала сделать копию базы. Потом закрывать по одной таблице и после каждой прогонять тесты и проверять главные функции. Так поломка, если случится, будет маленькой и понятной. Чинить всё одним махом в пятницу вечером — плохая идея.

Третье. Автоматическими проверками пользуйтесь, но держите их за один слой из нескольких. Запустили — попросите агента объяснить каждую находку и сказать, что случится, если её не исправить. Не закрывайте окно с предупреждениями, даже если их много. Но и зелёную галочку не принимайте за доказательство. Доказательство — это тест двух аккаунтов и проверка живого сайта глазами постороннего.

И четвёртое, когда без человека не обойтись. Если приложение хранит документы, медицинские сведения или платёжные данные, перед запуском стоит заказать внешнюю проверку доступа. И повторять её после крупных переделок. Так советуют исследователи из Гамбурга. Да, они сами продают такие проверки, и это надо учитывать. Но то же самое написано в документации самой Lovable.

Четвёртый вывод — про ваши деньги. До сих пор речь шла о данных пользователей. Теперь о том, что бьёт прямо по вашей карте. Это ключи к платным сервисам.

Сначала разберёмся, про вас ли это. Ваша подписка на Claude Code или Codex — не ключ, вы просто входите в свой аккаунт. Ключ появляется тогда, когда ваше приложение само обращается к платному сервису. Например, на сайте есть чат-помощник, и он отправляет вопросы посетителей нейросети. Сервис должен понять, с кого брать деньги, и для этого у приложения есть ключ, длинная строка символов. У кого ключ, тот и тратит с вашего счёта.

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

В октябре взломали хостинг Railway. По отчёту самой компании, атакующий перебирал сохранённые настройки клиентов и отбирал их по названиям. То есть он целенаправленно вылавливал ключи к нейросетям и облакам. Потом по этим ключам пошли чужие запросы. Railway оценивает такие траты примерно в семьсот сорок тысяч долларов на всех пострадавших. Кто вернёт клиенту эти деньги, зависит от того, чей был ключ: у каждого поставщика свои правила, а там, где поставщик не возвращает, Railway обещает заплатить сама.

Зачем кому-то чужие ключи к нейросетям? Чтобы продавать доступ. Именно так объясняет взлом у себя другая компания, Fireworks, это облако, где запускают открытые модели. Она связывает атаку с группой, которая зарабатывает на перепродаже украденного доступа к моделям. Ключи к ИИ стали товаром, и за ними охотятся специально.

А вот деталь уже совсем про нас с вами. Через Fireworks пострадал известный сервис для заметок Notion: к атакующим попали расшифровки разговоров пользователей с его ИИ-помощником. Разбираясь с этим, Notion нашла в сообщениях ключи, которые люди сами вставляли в чат. Компания прямо посоветовала клиентам сменить всё, что они туда вставляли. Люди пишут ключи и пароли в переписку с нейросетью, а дальше эта переписка живёт своей жизнью у посредника, о котором они и не слышали.

Теперь поручения. Первое — потолок расходов. Почти у любого поставщика в личном кабинете можно задать месячный предел трат. Попросите агента найти в документации вашего поставщика, где это ставится, и провести вас по шагам. Заодно пусть подскажет разумную сумму по вашим обычным расходам. Этот предел не помешает краже ключа. Он ограничит счёт, который вам после неё придёт.

Второе — отдельный ключ на каждый проект и на каждого поставщика. Когда один ключ стоит везде, его утечка означает переделку всего. Когда ключи раздельные, вы отключаете один, а остальное работает. Так поступил редактор кода Cursor. Он выдал Fireworks отдельный ключ, и после взлома этот ключ просто отключили.

Третье — перечень. Попросите агента составить список всех ключей во всех ваших проектах. Где лежит, от какого сервиса, какие деньги по нему можно потратить. И к каждому короткую инструкцию, как его заменить. Важно: в списке должны быть названия ключей, а не сами ключи. Такой список выручит в день, когда придёт письмо «у нас произошёл инцидент».

Четвёртое — привычка. Не вставляйте ключи и пароли в чаты с ИИ. Ключу место в настройках проекта, а не в переписке. Если уже вставляли, считайте такой ключ раскрытым и замените его.

Пятое. Если ваш код хранится на GitHub, спросите агента, включена ли там защита от отправки секретов. Она останавливает отправку, если в коде оказался ключ. Для открытых проектов на личных аккаунтах она включена сразу, для закрытых стоит проверить. А если вы работаете в Claude Code, его плагину проверки безопасности можно дать собственные правила. Например, поднимать тревогу при виде строки, похожей на ключ.

И шестое, самое простое. Услышали новость о взломе у своего хостинга или поставщика моделей — меняйте ключи в тот же день, не дожидаясь личного письма. Railway так и посоветовала клиентам: сменить всё чувствительное, что хранилось до дня взлома. Со списком из третьего пункта это займёт час, а не неделю.

Остался пятый вывод, и он продолжает четвёртый. Данные ваших пользователей идут через цепочку компаний, большую часть которых вы не выбирали и не знаете по именам. Клиенты Notion не выбирали Fireworks. Они просто разговаривали с помощником в своих заметках.

Бывает и длиннее. Тот самый ключ, который Cursor выдал Fireworks, попал к атакующим. С украденными доступами они добрались до каталога дополнений, который Cursor держит для своего редактора. Двадцать девятого октября там около одиннадцати часов лежали подменённые версии дополнения Claude Code. По оценке Cursor, получить их могли не больше пяти тысяч человек. Компания пишет, что связалась с каждым напрямую.

Касается ли это вас? Судя по описанию Cursor, речь о тех, кто в тот день установил или обновил это дополнение именно из её каталога. Если вы работаете с Claude Code в терминале и редактором Cursor не пользуетесь, эта история вас не задела. Но урок из неё общий. Человек просто обновил дополнение, а пострадал из-за компании, о которой мог ни разу не слышать.

Ваш собственный проект устроен так же, только меньше. Приложение отправляет нейросети то, что написал пользователь. Между вами и нейросетью может стоять сервис-посредник. Всё это живёт на хостинге. Где-то рядом счётчик посещений и почтовая рассылка. Каждое звено — место, где данные могут задержаться и откуда они могут утечь.

Отсюда три поручения. Первое: попросите агента составить карту. Пусть пройдёт по коду и перечислит все внешние сервисы, куда приложение что-либо отправляет. И по каждому скажет, какие именно данные пользователей туда уходят. Обычно список длиннее, чем ждёшь. Если ваши пользователи живут в Евросоюзе, такой учёт от вас требует ещё и закон.

Второе: отправлять меньше. Посмотрите на карту и спросите агента про каждое звено: можно ли решить задачу, не посылая туда паспорт, телефон или полную карточку клиента? Очень часто нейросети хватает текста без имён. То, что вы не отправили, у посредника не утечёт.

Третье касается ваших собственных инструментов. Попросите агента показать, какие дополнения и плагины стоят у вас в редакторе и в самом агенте. Скорее всего, половину вы не вспомните. Оставьте то, чем на самом деле пользуетесь, остальное пусть удалит. А если придёт новость об инциденте, выполняйте инструкцию поставщика целиком. Cursor предупредил отдельно: одного удаления дополнения может быть недостаточно.

И последнее из практики: что делать, если утечка у вас уже случилась. Порядок такой. Сначала закрыть дверь: включить защиту или снять приложение с публикации. Затем сменить все ключи, которые могли быть видны. Потом вместе с агентом разобраться, какие таблицы были открыты и чьи данные в них лежали.

Дальше идёт неприятная, но обязательная часть. Автор гамбургского отчёта описывает её так: владелец сайта должен выяснить, сколько клиентов затронуто, уведомить их и сообщить властям. Если среди ваших пользователей жители Евросоюза, на уведомление надзорного органа закон даёт семьдесят два часа. В других странах, включая Россию, свои законы и свои сроки. Узнать их стоит заранее, а не в день утечки, и это тоже можно поручить агенту.

А теперь шпаргалка. Семь фраз, которые можно сказать агенту сегодня, слово в слово. Первая: объясни простыми словами, как устроен мой проект, где лежат данные и ходит ли страница в базу напрямую. Вторая: перечисли все таблицы и скажи про каждую, кто может её читать и менять. Третья: зайди на мой опубликованный сайт как посторонний, без входа, и покажи, какие данные он отдаёт.

Четвёртая: напиши тест двух аккаунтов и запускай его перед каждой публикацией. Пятая: запиши себе правило, что ошибку доступа нельзя чинить, открывая доступ всем. Шестая: составь список всех ключей в моих проектах, без самих ключей, и напиши, как заменить каждый. Седьмая: перечисли внешние сервисы, куда приложение отправляет данные пользователей. На всё вместе уйдёт один вечер.

И итог, совсем коротко. Работает — ещё не значит закрыто, пока вы сами не сказали агенту, кто что должен видеть. Длинный адрес, кнопка входа и зелёная галочка ничего не доказывают, доказывает только проверка глазами постороннего. А ключи — это деньги, поэтому у каждого проекта свой ключ и свой потолок расходов.

И пара слов от меня лично. История с ключами, найденными в чужих чатах, задела меня сильнее всего. Переписка с агентами — это, по сути, вся кухня проекта: там код, файлы, ключи, планы. Я считаю, что такие вещи лучше держать в инструментах, которые никуда их не отправляют. Именно поэтому я сначала для себя сделал Arsminal.

В нём переписка, файлы и ключи хранятся только на вашем компьютере и телефоне, больше нигде. Связь между компьютером и телефоном зашифрована от начала до конца. Шифрование там постквантовое, по стандарту, который американский институт NIST утвердил в две тысячи двадцать четвёртом году. Смысл в том, что перехваченное сегодня не должны расшифровать и будущие квантовые компьютеры. Сервер связи передаёт только зашифрованный шум, прочитать его он не может и ничего не записывает. А голосовые команды распознаются прямо на компьютере, запись никуда не уходит.

На этом всё. С вами был Евгений Арсентьев, создатель Arsminal, терминала для управления ИИ-агентами: вся команда агентов работает в одном окне, как чаты в мессенджере. Основатель ArsentevAI, Dad4Kids и ReelsZavod. Попробуйте Arsminal бесплатно на arsminal.com. А если вашему бизнесу нужен контент-завод, который с помощью ИИ сам выпускает тысячи роликов для соцсетей, пишите мне в Телегу. Спасибо, что послушали.