Агенту выдают полномочия, а не инструкции
Запрет в промпте и 9 секунд
В системном промпте агента стоял прямой запрет, и слово “никогда” в нём набрали заглавными буквами: “НИКОГДА не запускай деструктивные команды без явного одобрения пользователя”. Тем не менее автономный агент под управлением Claude за 9 секунд полностью уничтожил продакшен-базу компании PocketOS. Потом модель честно признала, что нарушила правило. Базу это не вернуло.
Историю разбирают на Хабре, и цепляет в ней не скорость. Запрет был сформулирован однозначно, агент его прочитал и, судя по признанию, даже понял. Но команда на удаление прошла, значит, выполнить её агенту ничто не мешало. Для модели запрет в промпте всего лишь часть текста, такая же, как сама задача. Он влияет на то, что агент решит сделать, и никак не меняет того, что агент может сделать.
Поэтому у любого агента полезно различать две вещи. Инструкцией назовём текст, который ему написали. Полномочия описывают то, что он реально может сделать в системе: какие у него ключи и доступы, какие вызовы проходят, где перед действием стоит проверка. Инструкция объясняет задачу. А граница проходит там, где кончаются полномочия.
Для того, кто поручает работу агенту, отсюда следует простой вывод. Что ему написать, конечно, важно. Но решать прежде всего приходится, что ему разрешить: какие действия, над какими объектами, на какой срок и что требует подписи человека.
Где у агента ключи на запись
Полномочия агента часто шире, чем думает тот, кто его запустил. Технический директор, который разбирает случай PocketOS, напоминает, как устроен локальный агент на компьютере разработчика. Он выполняет команды от имени пользователя и видит его личные файлы, включая папки с ключами к серверам и облаку. Специально выдавать такому агенту доступ к продакшену не нужно, он достаётся вместе с учётной записью человека.
Выход, который предлагает технический директор, обходится без новых слов в промпте. Агента запускают в изолированной среде, куда монтируется только папка проекта. Если он попробует зайти на боевой сервер, то получит Permission denied, потому что ключей у него физически нет. Запрет в промпте можно и оставить, просто теперь он ничего не решает.
Бывает и обратная ситуация, когда ключ у модели отобрали, а у системы он остался. Это показал лабораторный тест на Хабре, собранный на связке из n8n, DeepSeek и HubSpot, где все сделки были выдуманными. У модели не было ключа к CRM, но ключ на запись был у следующего узла, который исполнял её предложения. Автор теста нарочно подстроил несовпадение. Человек просит изменить сделку LAB-042, а в структурированном предложении модели стоит LAB-043.
Узел выполнил запись. Изменилась LAB-043, а LAB-042 осталась в исходном состоянии. При этом фраза “модель работает только на чтение” вполне могла попасть в описание архитектуры или в анкету для клиента и формально была бы правдой. Вывод автора теста укладывается в одну фразу: полномочия модели и полномочия системы не одно и то же.
Ошибку в тесте создали специально, и данные в нём синтетические. Но узлу, у которого есть ключ, всё равно, откуда взялся неверный номер сделки, из подстроенного сценария или из обычной ошибки модели. Поэтому полномочия ищут по всей цепочке, до того звена, которое на самом деле совершает действие. Для такого поиска автор теста предлагает шесть вопросов перед запуском агента с доступом к CRM, ERP или инфраструктуре.
- Где физически лежат ключи на запись?
- Какой компонент делает внешний вызов?
- Что проверяется прямо перед исполнением?
- Может ли объект или важный параметр измениться между запросом человека и записью?
- Есть ли независимая граница между предложением модели и последствием?
- Как подтверждается состояние после действия?
Чтобы задать их команде, руководителю не нужно разбираться в n8n. Достаточно не принимать ответ “модели запись запрещена” за ответ на первый вопрос.
Как полномочия выдают сотруднику
В компании похожую задачу давно решают для людей, и решают довольно скучно. Новому руководителю закупок не говорят “работай с поставщиками, только аккуратно”. Ему выдают доверенность с перечнем действий и сроком, лимит суммы, в пределах которого он сам подписывает договоры, место в матрице согласований и доступ в системы по роли. Договор больше лимита он готовит, а подписывает тот, у кого есть такое право. Истёк срок доверенности, и права закончились вместе с ним.
С агентом часто поступают наоборот. Ему дают ключ администратора, потому что так проще настроить, и пишут в промпт “будь осторожен”. У людей это выглядело бы как устное напутствие стажёру, которому заодно отдали печать компании и пароль от банк-клиента. Со стажёром так никто не поступит, а с агентом это пока не кажется странным. Видимо, потому, что настраивают агента как программу, а работу поручают ему как сотруднику.
Некоторые продукты уже делят полномочия агента так же, как их делят между людьми. Точка Банк объявил о подключении ИИ-агентов через MCP, и среди примеров запросов в сообщении банка есть такой: “Подготовь платёжное поручение и дай ссылку на подписание”. Судя по формулировке, платёжку готовит агент, а подписывает человек, который откроет ссылку. Получается тот же лимит подписи, только заложенный в сам продукт.
Где провести черту между “готовит” и “подписывает”, подсказывает простой вопрос, можно ли действие отменить. Черновик письма, выписку или план работ можно выбросить и сделать заново. Оплаченный счёт, отправленное письмо клиенту, удалённые данные или изменение рабочей системы назад уже не отыграешь. Такие действия агенту без подписи человека не отдают, а в PocketOS агент смог сам выполнить как раз такое действие.
В проекте эта черта выглядит буднично. Агент может собрать статус по задачам, подготовить отчёт для заказчика и черновик письма о переносе срока. Отправить это письмо или сдвинуть сроки в плане, который видит заказчик, уже другое действие, и его делает руководитель проекта.
Срок из доверенности тоже переносится на агента. Ключ, выданный под конкретную задачу, после неё отзывают, иначе через полгода никто не вспомнит, зачем у агента доступ к бухгалтерии. И так же, как в матрице согласований, заранее решают, кто вправе подписать действие агента. Решают до того, как агент принёс первый план, а не в тот момент, когда план уже лежит на столе и все ждут.
Под чем подписывается человек
Подпись человека сама по себе мало что значит, если непонятно, под чем он подписался. Ответ “да, делай” на длинное сообщение агента формально разрешает всё, что агент сделает дальше. Через неделю агент меняет уже другой объект, а в переписке по-прежнему лежит то самое “да”.
Как привязать согласование к конкретному действию, хорошо видно в Agent-Ops, открытой методологии совместной работы инженеров и ИИ-агентов в эксплуатации ИТ-инфраструктуры. Её представил на Хабре Сергей Житинский, основатель Git in Sky. У документа пока статус кандидата методологии, и в нём честно оговорено, что требование в тексте ещё не означает готовый механизм.
Фраза “почини сервер” там не считается разрешением на любые команды. Согласование привязано к точной цели, версии плана, охвату и сроку действия. Если изменился пакет действий или истёк срок разрешения, продолжать по старому согласованию исполнитель не может. По сути это та же доверенность, где записано, что именно разрешено и до какого числа.
Учебный пример из документа показывает, как это выглядит на деле. На сервере осталось 8% свободного места, и владелец сервиса ставит цель поднять запас выше 20%, не удаляя рабочие данные и не останавливая сервис. Агент связывает рост логов с правилами ротации и недавним релизом, но кто отвечает за правило срока хранения, неизвестно. Назначить ответственного по своей догадке агент не вправе, и работа ждёт подтверждения. После уточнения в плане остаются расширение тома и исправление правила хранения, ведь удалять данные нельзя по условию владельца.
Владелец утверждает оба действия и их порядок. Применяет их отдельная программа-исполнитель, которую запускает инженер, и если проверки допуска не проходят, выполнение останавливается. Агент, который всё это придумал, сам не применяет ничего. В документе это сказано прямо: “Способность агента подготовить изменение ничего не говорит о его праве применить его”.
Тот же принцип сработал и в тесте с CRM. Перед записью поставили отдельную программную проверку: в какую систему пишем, какой объект меняем, в каком состоянии он должен быть до изменения и какой переход разрешён. Подстроенное предложение с LAB-043 получило отказ, и запись не ушла. Ключ у узла остался, но пользоваться им узел теперь может только после проверки. Это то же согласование с точной целью, только проверку делает программа в последний момент перед действием.
Всё это держится, пока агент не может сам расширить себе полномочия. В Agent-Ops правила меняются через тот же управляемый процесс, и переписать собственные ограничения агент не вправе. Иначе любое согласование теряет смысл, ведь агент, который правит свои ограничения, согласует себя сам. Право менять свою проверку или свои ограничения агенту не выдают. Подробнее об этом в статье о проверке до начала работы.
Кто отвечает за выданный доступ
Когда агент что-то ломает, почти сразу звучит “он сам решил”. Сергей Пименов в колонке об ответственности за ИИ отвечает на это вопросом: “А кто решил, что ему можно решать?” Ключи агент себе не выдавал. Доступ ему открыл человек, и он же решил, где агент будет действовать без проверки.
Разница хорошо видна на разборе после аварии. Если в отчёте написано “агент нарушил инструкцию”, разбор на этом заканчивается: виноватый вроде бы найден, а спросить с него нечего. Если написано “у агента был ключ на удаление, и никто не решал, нужен ли он ему”, сразу понятно, что чинить и чьё это было решение. Первая запись говорит об инструкции, вторая о полномочиях. Исправить можно только то, о чём говорит вторая.
Проверять каждый шаг агента никто не требует, иначе от агента не будет толку. По мысли Пименова, если шаги не проверяют, то заранее определяют границы, на которых программа обязана остановиться. Всё, о чём шла речь выше, и есть такие границы. Это ключи, которых у агента нет, проверка прямо перед записью, подпись человека под необратимым действием и согласование, привязанное к плану и сроку.
Ставит эти границы человек, и отвечает за них тоже он. Кто возместит ущерб, разбираются предметно, по закону и договору, и в той же колонке среди возможных ответчиков названы компания, разработчик и пользователь. Агента в этом списке нет. С доверенностью всё устроено так же. Если сотрудник подписал по ней лишнее, вопрос зададут и тому, кто выдал ему доверенность с такими правами.
В проекте это означает простую вещь. У каждого агента должен быть человек, который выдал ему доступы и может их перечислить. Если на вопрос “кто дал агенту ключ к CRM” в команде отвечают “так было настроено”, значит, полномочия у агента есть, а решения о них никто не принимал. Ответственность в таком случае никуда не исчезает. Она ложится на того, кто запустил агента, не разобравшись, что тот может.
Инструкцию агенту писать всё равно нужно, без неё он не поймёт задачу. Но инструкция описывает, что агент сделает, если поймёт задачу правильно. Полномочия описывают, что случится, если он поймёт её неправильно, и за эту вторую часть отвечает тот, кто их выдал. Поэтому перед запуском агента полезно спросить себя, что он сможет сделать, если ошибётся. В PocketOS честный ответ на этот вопрос звучал бы так: удалить рабочую базу за 9 секунд.
