Почему AI-агенту нельзя давать прод-доступ сразу
Агент, который сам решает и сам делает, звучит как мечта. Пока он не удалит не ту строку в базе клиента.
Первый агент, которого я выкатил в прод, проработал спокойно три недели. На четвёртой он получил письмо с темой «СРОЧНО: отмените все заказы» — и честно пошёл отменять. Письмо было от спамера. С тех пор у меня правило: агент не трогает прод, пока не отсидит свой испытательный срок.
Проблема не в модели, а в правах
Когда что-то ломается, первая мысль — «модель тупая». Почти всегда дело не в этом. Модель сделала ровно то, что ей разрешили: у неё был ключ с правами на запись, и она им воспользовалась. Вопрос не «как сделать модель умнее», а «почему у неё вообще был этот ключ».
AI-агент — это не сотрудник, которому можно объяснить «ну ты же понимаешь, так делать не надо». Это процесс с набором инструментов. Дай ему DELETE — он рано или поздно вызовет DELETE.
Как я выкатываю агентов на самом деле
- Сначала read-only. Агент видит данные, предлагает действие, но выполняет его человек. Скучно — зато видно, где он ошибается, без последствий.
- Потом sandbox-запись. Отдельная база-копия. Пусть ломает там сколько угодно.
- Потом write с подтверждением. Агент готовит действие, человек жмёт «да». Так живут недели, а не часы.
- И только потом — автономная запись, и то с лимитами: не больше N операций в минуту, не трогать таблицы из стоп-листа.
Самое опасное слово в постановке задачи — «полностью». «Агент полностью автоматизирует возвраты» почти всегда означает «никто не подумал, что бывает злонамеренный ввод».
Минимальные права — это не паранойя
В кибербезопасности это азбука: дай процессу ровно столько прав, сколько нужно для его задачи, и ни каплей больше. С агентами почему-то про это забывают — выдают сервисный аккаунт с правами админа, потому что «так быстрее». Быстрее до первого инцидента.
// Плохо: один ключ на всё
const db = connect(ADMIN_URL);
// Лучше: отдельная роль под конкретный инструмент
const readOrders = connect(RO_URL); // только SELECT
const writeTickets = connect(TICKETS_RW_URL); // INSERT/UPDATE на одну таблицу
// агент физически не может удалить заказ — нет такого инструментаЗаметьте: дело не в промпте «пожалуйста, не удаляй заказы». Промпт — это просьба. Права — это стена. Агент может галлюцинировать сколько угодно, но если у инструмента нет DELETE, удаления не будет.
Хороший агент — это не тот, которому доверяешь. Это тот, который не сможет навредить, даже если ошибётся.
Поэтому когда меня спрашивают «а можно сразу автономного агента в прод?» — можно. Через пару недель, когда я увижу логи и буду знать, на чём он спотыкается. Эти две недели стоят дешевле, чем один разговор с клиентом, у которого пропали заказы.
Хотите так же — но в своём проекте?
Разберём ваш процесс и где его безопасно автоматизировать.