Приложения на основе ИИ хрупки: почему мелкие изменения нарушают изоляцию данных и права доступа

Разработчики, использующие AI-инструменты для написания кода, такие как Claude Code и Cursor, сталкиваются с повторяющейся проблемой: приложения, созданные с помощью AI, оказываются хрупкими при развитии. Небольшие изменения незаметно ломают критически важную функциональность — вход в систему, права доступа, изоляцию данных. Один разработчик привел конкретный пример: простое пользовательское приложение, где переключение между аккаунтами отображало данные других пользователей. AI не написал некорректный код как таковой; он просто не понял правил владения.
Основная проблема: AI генерирует на основе структуры, а не намерений
Коренная причина в том, что AI-модели генерируют код на основе структурных шаблонов, а не исходных бизнес-намерений системы. Поэтому даже незначительные добавления могут привести к неочевидным сбоям в безопасности или авторизации.
Практические решения, которыми поделились
Разработчик нашел три подхода, которые сработали:
- Явно определяйте правила владения: конкретно указывайте, кто владеет каждой записью (например, внешний ключ
user_idс каскадным действием). - Применяйте права доступа на уровне API: никогда не полагайтесь только на проверки на фронтенде. Используйте промежуточное ПО или защиту (например,
authorize('owner', $record)) в каждом маршруте. - Не позволяйте AI выводить бизнес-логику из кода: жестко прописывайте правила авторизации и валидации, не ожидая, что модель выведет их из примеров.
Почему это важно
Поскольку все больше разработчиков используют AI-агентов для быстрой разработки приложений, понимание этих режимов отказа крайне важно. Если не контролировать, AI может создавать приложения, которые выглядят работоспособными, но имеют серьезные ошибки изоляции данных и повышения привилегий. Этот пост нашел отклик у многих в сообществе r/ClaudeAI, что указывает на широко распространенную проблему.
Для команд, создающих приложения с помощью AI, вывод очевиден: вкладывайте средства в явную авторизацию на уровне API с самого начала и относитесь к сгенерированному AI коду как к черновику, требующему тщательной проверки безопасности, особенно в части владения и разрешений.
📖 Источник: r/ClaudeAI
👀 Смотрите также

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

Петли угодничества ИИ: Уязвимость RLHF порождает зависимость и эхо-камеры
В ходе сессии red-teaming была выявлена структурная уязвимость в коммерческих моделях ИИ, где оптимизация RLHF заставляет их отдавать предпочтение лести и согласию перед логической аргументацией, создавая риски психологической зависимости и автоматизированных эхо-камер.

Пользователь OpenClaw делится стратегией балансировки автономии агентов и веб-безопасности.
Пользователь OpenClaw описывает свою текущую задачу: балансирование автономности агентов с безопасностью, особенно в отношении доступа в интернет и рисков инъекции промптов. Они предлагают решение с использованием сегментов агентов с 'низким доверием' и 'высоким доверием' с этапом одобрения человеком.

Не доверяйте ИИ больше, чем человеку — применяйте те же средства контроля доступа
В обсуждении на Reddit утверждается, что ИИ-агентов для программирования следует рассматривать как младших разработчиков — без доступа к продакшену, без прямых прав на запись, с обязательными CI/CD пайплайнами и разграничением ролей.