ИИ-инструменты ошибаются в изоляции данных клиентов: почему и что делать
ИИ-инструменты ошибаются в изоляции данных клиентов: почему и что делать Автор разбирает, почему код, который генерируют ИИ-инструменты для облачных сервисов по подписке (SaaS), часто не защищает данные клиентов друг от друга. Модель безопасности известна больше десяти лет: каждый запрос ограничивается одним клиентом-организацией, и это проверяется на уровне базы данных, а не только кода. Проблема — в разрыве между «модель понятна» и «сгенерированный код ей следует». Изоляция означает: пользователь одной организации не может прочитать, изменить или даже узнать о существовании данных другой — ни через интерфейс, ни через выгрузки, фоновые задачи или логи. Правило звучит просто, но в приложении десятки мест, где данные проходят через код, и пропустить его достаточно в одном. Есть три стандартных подхода. Общая схема с колонкой tenant_id (метка принадлежности записи конкретному клиенту) — самый дешёвый вариант, если фильтр дополнительно принуждает сама база данных: механизм Row-Level Security в PostgreSQL — построчная защита на уровне базы — не даст запросу без фильтра вернуть чужие строки. Отдельная схема на клиента даёт более чистую историю для аудита, но дороже в обслуживании. Отдельная база на клиента — максимальная изоляция, её ждут корпоративные и регулируемые заказчики, но это медленно и дорого, поэтому туда обычно переводят только конкретных клиентов. Автор советует начинать с общей схемы плюс Row-Level Security и наращивать изоляцию по требованию. Почему именно ИИ-код уязвим: агент оптимизирует под задачу «код работает и проходит тест». Если тест проверяет работу с позиции одного разработчика, код без фильтра по клиенту выглядит исправным — в среде разработки с одним клиентом ошибка невидима. Она проявляется в продакшене, когда данные второго клиента попадают в ту же таблицу — то есть когда исправление дороже всего. Автор приводит распространённую оценку, что около 45% ИИ-сгенерированного кода содержит эксплуатируемые уязвимости, и уточняет: цифра ориентировочная, определения «уязвимости» в исследованиях различаются. Реальный случай, как это ломается: в августе 2026 года исследователь опубликовал отчёт об ИИ-платформе заметок со встреч, где один контейнер базы данных вообще не имел разграничения доступа между клиентами. По данным отчёта, любой зарегистрированный пользователь мог читать записи о встречах других организаций: более 180 000 записей и около 84 000 пользователей, включая госорганы больше чем двадцати стран, университеты и компании. Исследователь подтвердил тяжесть на практике: присоединился к двум живым встречам, куда его не приглашали, используя ID из утёкших данных. Причина — не экзотическая ошибка архитектуры, а одна граница, которая предполагалась, но не была закреплена принудительно. Практический вывод автора: изоляция не может быть пунктом в чек-листе код-ревью, который легко пропустить. Её надо закрепить на уровне, который процесс генерации кода не сможет случайно обойти, — то есть в самой базе данных. Причём защиту нужно принудительно распространить и на владельцев таблиц (FORCE ROW LEVEL SECURITY), потому что в PostgreSQL они по умолчанию её обходят. А идентификатор клиента надо брать из проверенного JWT — подписанного токена входа, — а не из параметра, который прислал клиент: непроверенную метку доверять нельзя. Источник: https://dev.to/8080_ai/why-ai-coding-tools-get-multi-tenant-isolation-wrong-4jec