Режим «только чтение» — это недостаточно: защитные механизмы для ИИ-агентов
Опытные инженеры часто говорят одно и то же, чтобы обеспечить безопасность ИИ-агентов: предоставьте им доступ только для чтения.
Это звучит безопасно. Агент может исследовать медленные запросы или обобщать схемы, ничего не ломая.
Но режим «только чтение» — это не модель безопасности. Это ограничение.
Как только агенту требуется выполнить полезную работу, режим «только чтение» его останавливает. Если агент обнаружит плохой индекс или поврежденную строку, он не сможет это исправить. В итоге вы получаете помощника, который указывает на пожар, но не может взять в руки шланг.
Команды часто сдаются и предоставляют агенту доступ на запись. Именно тогда начинается настоящая опасность.
Настоящий вопрос не в том, «должен ли агент писать». Настоящий вопрос в том, «как вы управляете этими записями».
Не пытайтесь управлять записями с помощью инструкций. Не вставляйте правила в системный промпт вроде «никогда не удаляй таблицу».
Промпт-инъекции делают эти правила бесполезными. Злоумышленник может использовать строку данных или комментарий, чтобы обманом заставить агента игнорировать ваши правила. Если защитный механизм находится в том же окне, что и агент, агент сможет «переспорить» его.
Вам нужно разграничение между неуправляемыми записями и контролируемыми (mediated) записями.
• Неуправляемые записи: агент решает выполнить команду, и база данных её исполняет. Единственный контроль — это собственное суждение агента. • Контролируемые записи: команда проходит через контрольную точку вне агента. Эта точка находится на пути передачи данных между агентом и базой данных.
Контролируемая запись работает следующим образом:
- Агент предлагает выражение (statement).
- Прокси-сервер или уровень управления (control plane) анализирует выражение.
- Прокси классифицирует риск.
- Прокси решает, разрешить ли выполнение или запросить одобрение у человека.
Этот подход защищает вас от промпт-инъекций. Вредоносная инструкция может обманом заставить агента отправить команду DROP TABLE, но она не сможет обмануть прокси. Прокси не читает намерения агента; он смотрит только на фактическую SQL-команду.
Используйте следующую структуру, чтобы оставаться в безопасности:
- Автоматически разрешайте безопасное чтение. Позвольте агентам свободно выполнять SELECT-запросы, чтобы не замедлять работу.
- Ограничивайте рискованные записи. Требуйте одобрения человека для DELETE, UPDATE или изменений схемы.
- Логируйте всё. Ведите неизменяемый журнал того, кто предложил изменение и кто его одобрил.
Не полагайтесь на реплики для чтения (read replicas) в целях безопасности. Реплики помогают при расследовании, но они не могут применять исправления. Чтобы исправить проблему в рабочей среде (production), необходимо вносить изменения в основную базу данных.
Контроль (mediation) позволяет агенту быть полезным, сохраняя при этом ваши данные в безопасности.
Optional learning community: https://t.me/GyaanSetuAi