# Как управлять ИИ-агентами в продакшене

> Когда ИИ-агентам в продакшене нужен внешний руководитель: критерии для учетных данных, согласований, аудита, отката и управления инцидентами.

Доступ ИИ-агента на запись в продакшен выглядит как изменение прав, но на деле это управленческое решение. Основателю стоит привлечь внешнего технического руководителя до выдачи такого доступа, если внутри компании никто не может очертить границы, обеспечить независимое согласование, восстановить цепочку действий агента и принять командование при неудачном развертывании. Если команда уже умеет все это делать, а один конкретный руководитель принимает риск на себя, внешний специалист мало что добавит.

Качество программирования модели не определяет решение. Безопасность продакшена зависит от системы контроля вокруг агента: какую учетную запись он получает, какие действия она разрешает, кто разблокирует остановленную операцию, какие свидетельства сохраняются после сессии и кто может остановить или отменить результат. Я видел, как сильные команды сосредотачивались на качестве кода агента, оставляя неясными учетные данные для развертывания, порядок согласования и роли при инциденте. Это неверный порядок.

## Доступ на запись в продакшен выходит далеко за пределы сервера

Доступом на запись в продакшен считается любая возможность изменить видимое клиентам поведение, сохраненные данные, границы безопасности, доступность или свидетельства для расследования таких изменений. Прямой доступ к оболочке продакшен-сервера очевидно сюда относится. Сюда же входят право слияния в релизную ветку, право редактировать процесс развертывания, доступ к продакшен-флагам функций, миграциям базы данных, планам инфраструктуры, публикации пакетов, ротации секретов и изменению правил мониторинга.

Основатели часто разрешают одно узкое на вид право и не замечают цепочку за ним. Агент с правом изменить файл рабочего процесса может заставить CI-раннер запросить облачную роль. Агент с правом слияния в ветку по умолчанию может запустить автоматическое развертывание. Агенту с доступом на чтение секретов и на запись во внешнюю интеграцию вообще не нужны права на развертывание, чтобы нанести ущерб. Проверяйте достижимый граф действий, а не подпись на первых учетных данных.

Разделяйте три категории:

- Доступ на запись к коду позволяет агенту создать ветку и предложить изменение.
- Полномочия на выпуск позволяют учетной записи согласовать, слить или запустить развертывание этого изменения.
- Полномочия во время работы позволяют учетной записи менять действующую инфраструктуру, данные, конфигурацию или секреты.

Если объединить все три категории в одной учетной записи агента, исчезнет независимый контроль, ради которого нужен разбор изменений. Запрос на слияние не создает границу согласования, если тот же агент может его одобрить или обойти. Журнал развертывания дает слабые свидетельства, если агент может изменить место их хранения. Отдельные учетные записи и разные владельцы политик важнее красивого интерфейса агента.

Это различие меняет и решение о найме. Основателю может не понадобиться внешний руководитель, чтобы разрешить агенту записывать ветки в изолированном репозитории. Потребность резко возрастает, когда предполагаемые учетные данные дают полномочия на выпуск или работу с действующей системой, а за всю цепочку не отвечает ни один опытный специалист.

Явно нанесите на карту косвенные операции записи. Начните со всех инструментов, которые может вызвать агент, затем проследите, что способен запустить каждый из них. Запись в репозиторий может запустить CI, CI может принять облачную роль, эта роль может обновить сервис, а сервис может выполнить миграцию под собственной учетной записью базы данных. Фактические полномочия агента включают последнюю запись в базу, даже если агент никогда не видел пароль от нее.

Учтите и изменения плоскости управления, которые выглядят административными, а не рабочими. Редактирование правила ветки, добавление источника пакетов, смена базового образа контейнера, отключение оповещения или снижение порога теста могут разрешить последующее изменение продакшена. Если право способно ослабить барьер, который защищает другое право, считайте его полномочием в продакшене.

## Нанимайте для устранения пробела в ответственности

Привлекайте внешнего руководителя, когда компании не хватает ответственного суждения, а не когда совет директоров хочет получить солидное одобрение заранее выбранного запуска. Fractional CTO, руководитель по безопасности или опытный специалист по платформе должен иметь право отложить доступ, сузить область и остановить работу с продакшеном. Если основатель намерен отменять каждую неудобную рекомендацию, сотрудничество создаст бумаги вместо контроля.

Пять условий оправдывают участие такого человека до выдачи доступа к продакшену:

1. Ни один действующий руководитель не может описать худшее правдоподобное действие агента с его конкретными учетными данными.
2. Инженер, который создает агента, одновременно согласует его действия в продакшене и владеет системой аудита.
3. У компании нет проверенного отката для изменений схемы, данных, учетных записей или инфраструктуры.
4. При инциденте начнется спор о том, кто вправе отозвать доступ, приостановить развертывание или общаться с клиентами.
5. Клиентские договоры, регулируемые данные или обязательства по доступности делают импровизированный ответ особенно дорогим.

Это проверка решения, а не правило о численности. Компания из четырех человек с дисциплинированным платформенным инженером может быть готова. Компания из сорока человек с общими токенами администратора и неформальным согласованием не готова. Названия должностей не устраняют пробел. Нужны конкретные полномочия, техническая компетентность и время на проверку реализации.

Внешнее руководство будет неверной покупкой и тогда, когда недостающая работа чисто механическая. Если политика уже согласована, а команде нужно только настроить правило среды или экспорт журналов, наймите исполнителя. Руководитель нужен, когда разумные инженеры расходятся в оценке допустимой зоны поражения, требуемых свидетельств, риска для бизнеса или границы автономности.

Дайте внешнему руководителю короткое и конкретное задание. Он должен предоставить карту доступа, матрицу согласований, спецификацию свидетельств, владельца отката, карточку командования инцидентом и рекомендацию с явными условиями. Не просите общую «стратегию ИИ». Такая формулировка позволяет всем уйти от решения о продакшене.

У рекомендации должен быть срок действия. Инструменты агента, модели, рабочие процессы и распределение ответственности в команде меняются достаточно быстро, чтобы разовое согласование устарело. Руководитель должен назвать предпосылки решения и события, после которых нужна новая проверка. Новый коннектор инструментов, более широкий репозиторий, автоматическое развертывание или изменение дежурной смены могут отменить вчерашний вывод.

До выбора советника проверьте его стимулы. Человек, который продает внедрение агентов, не должен в одиночку оценивать его безопасность. Он может предоставить свидетельства и внедрить средства контроля, но основателю нужен проверяющий, чья оплата и власть не зависят от одобрения более широкого доступа. Независимость важна, потому что аккуратное «пока нет» часто создает больше работы, чем быстрое согласие.

## Область учетных данных должна соответствовать одной задаче и одной сессии

Агент должен получать отдельную рабочую учетную запись с минимальной областью ресурсов, действий, среды и срока жизни, достаточной для одной согласованной задачи. Никогда не передавайте ему сессию разработчика, общий токен администратора или секрет, скопированный из менеджера паролей. Такие сокращения уничтожают атрибуцию и усложняют отзыв доступа во время инцидента.

Документ AWS Security Best Practices in IAM рекомендует временные учетные данные для рабочих нагрузок и политики минимальных привилегий. Этот совет появился до агентов для программирования, но отлично к ним подходит. Временные учетные данные не делают ошибочное действие безвредным. Они сокращают время, в течение которого украденные или сохраненные данные остаются пригодными, а отдельная роль дает реагирующим одно место для отключения доступа.

У области доступа четыре независимых измерения:

- Ресурсы: укажите сервис, репозиторий, базу данных, очередь или пространство имен, которые задача может менять.
- Действия: разрешите нужные операции и запретите управление учетными записями, аудитом, резервными копиями и политиками.
- Условия: привяжите доступ к согласованной среде, рабочему процессу, исходной учетной записи и контексту сессии.
- Время: выдавайте учетные данные после согласования и завершайте их действие вскоре после ожидаемого конца задачи.

Список разрешений с `service:*` не становится узким от того, что называет один сервис. Операции с подстановочным знаком часто включают удаление, изменение политики, теги, влияющие на автоматизацию, или создание нового пути в обход задуманного ограничения. Проверяйте фактические права, включая унаследованные роли и политики ресурсов, от имени учетной записи агента. Не делайте вывод по политике, которую вы собирались прикрепить.

Используйте контракт доступа, понятный основателю, согласующему и командиру инцидента. Синтаксис зависит от провайдера, но обязательные факты должны выглядеть примерно так:

```yaml
principal: coding-agent-prod
job: deploy-payments-api
session_ttl_minutes: 30
allow:
  resources:
    - service/payments-api
  actions:
    - release.create
    - release.status.read
deny:
  actions:
    - identity.*
    - audit.*
    - secret.read
    - database.write
approval:
  required_before:
    - release.create
rollback_principal: human-on-call
```

Этот контракт предотвращает частый сбой: задача развертывания незаметно расширяется до управления учетными данными, журналами или данными. Обеспечьте запреты в нижестоящих системах, а не только в промпте агента. Руководство OWASP LLM06 об избыточных полномочиях говорит о том же: сокращайте права расширений, выполняйте действия в контексте авторизации пользователя и требуйте согласования человеком для действий с серьезными последствиями. Промпт «не трогай данные продакшена» дает указание, но не создает границу.

Перед согласованием задайте неудобный вопрос: если атакующий управляет каждым токеном, который агент читает из репозитория, трекера задач и вывода инструментов, сможет ли он вызвать запись в продакшен за пределами этого контракта? Если ответ неизвестен, выдавать доступ рано.

Проверяйте запреты так же серьезно, как разрешенные действия. Пусть сессия попробует прочитать посторонний секрет, изменить свою роль, сменить приемник аудита, обратиться ко второму сервису и продолжить работу после истечения срока. Проверка политики должна безопасно отказать и оставить событие для каждого отклоненного запроса. Ошибка только в расшифровке сессии агента не доказывает, что нижестоящая система обеспечила границу.

Способ доставки учетных данных тоже важен. Выдавайте роль рабочей нагрузке только после прохождения барьера и не помещайте ее в общую среду оболочки, которую наследует каждый дочерний процесс. Если исполнитель поддерживает отдельные учетные данные для каждого инструмента, дайте инструменту развертывания продакшен-роль, а инструментам репозитория и просмотра оставьте отдельные учетные записи. Одна сессия может использовать несколько узких учетных данных, не превращая их в общий набор.

## Согласование должно находиться вне контроля агента

Согласование человеком полезно, только если показывает предполагаемое действие, исходит от независимой учетной записи и происходит в последний практический момент перед эффектом. Одобрение общего плана в начале тридцатиминутной сессии агента не разрешает каждую команду, которую он придумает позже. Одобрение запроса на слияние не разрешает автоматически разрушительную миграцию внутри развертывания.

Определяйте согласование по эффекту. Для обычных обратимых выпусков достаточно одного операционного согласующего. Изменения учетных записей, доступности сети, хранения данных, резервных копий, логики оплаты или разрушительные миграции должен согласовывать владелец, который понимает эту область. Некоторые действия стоит оставить недоступными агенту даже после одобрения, особенно изменение собственных прав, отключение сбора свидетельств и захват пути экстренного доступа.

Запрос на согласование должен содержать достаточно подробностей для решения:

- Точный коммит, дайджест артефакта, миграцию или план инфраструктуры, который будет выполнен.
- Ресурсы и среду, которые изменятся.
- Результаты тестов и проверок политики, привязанные к тому же артефакту.
- Ожидаемый эффект для клиентов, способ отката и каждый необратимый шаг.
- Сессию агента, запросившего человека и срок жизни учетных данных.

После согласования артефакт должен оставаться неизменным. Если агент может изменить ветку, тег образа, файл плана или миграцию после одобрения человеком, контроль становится декорацией. Привяжите согласование к хешу коммита или дайджесту содержимого и отклоняйте несовпадение при выполнении.

Документация GitHub о средах предлагает полезную деталь реализации: задача может ждать обязательного проверяющего, секреты среды могут оставаться недоступными до согласования, а команда может запретить инициатору развертывания одобрять собственный запуск. Общий вывод применим и вне GitHub. Разместите барьер в системе развертывания, которая хранит учетные данные. Кнопка согласования внутри приложения агента слабее, если то же приложение может разблокировать действие.

Усталость от согласований появляется быстро, если каждый безобидный запрос на чтение или повтор требует нажатия. Не пытайтесь исправить это одобрением более длинных автономных запусков. Разделите работу по классам риска. Пусть агент без помех изучает, тестирует и готовит изменения в песочнице. Оставьте внимание человека для небольшого набора эффектов, пересекающих границу продакшена. Если согласующие постоянно нажимают кнопку, не читая запрос, проект контроля уже провалился.

Сделайте отказ обычным путем. Согласующий должен иметь возможность отклонить действие, указать причину и вернуть агента к подготовке, не открывая продакшен-учетные данные. Отклоненный запрос нельзя повторно отправлять без изменений, пока на него не нажмет другой человек. Такое поведение превращает согласование в гонку и давит на дежурного инженера, вынуждая его очищать очередь.

Экстренные обходы требуют более строгого владельца, чем обычное согласование. Если человек может обойти барьер во время сбоя, запишите учетную запись, причину, точный артефакт и длительность, а после восстановления потребуйте разбор. Не позволяйте агенту запрашивать или включать обход. Скрытая кнопка администратора, которая пропускает всю защиту, станет настоящим путем развертывания, как только официальный путь покажется медленным.

## Журналы аудита должны отвечать на вопросы инцидента

Цепочка аудита должна позволить специалисту по реагированию восстановить намерение, полномочия, действие и эффект без просьбы к агенту объяснить себя. Итоговое резюме агента не служит свидетельством. В нем могут отсутствовать неудачные вызовы инструментов, промежуточные изменения, отклоненные действия или входные данные, изменившие план.

Записывайте как минимум инициировавшего человека, версию агента и модели, идентификатор сессии, исходный запрос, ссылки на полученный контекст, предложенный план, аргументы и результаты вызовов инструментов, различия файлов, решения политик, учетную запись согласующего, выданную рабочую учетную запись, дайджест артефакта, результат развертывания и результат отката. Используйте временные метки из доверенных систем. Помечайте секреты при сборе, чтобы журнал сохранял ссылку или хеш вместо самих учетных данных.

Событие должно иметь стабильную машиночитаемую форму. Практический минимум выглядит так:

```json
{"event_id":"evt_01","session_id":"agt_42","actor":"coding-agent-prod","requested_by":"user_17","action":"release.create","resource":"service/payments-api","artifact_digest":"sha256:...","decision":"allowed","policy_version":"prod-agent-v3","approved_by":"user_09","credential_id":"role-session-...","result":"started","recorded_at":"..."}
```

Создавайте это событие на границе политики или развертывания. Агент может приложить свои рассуждения как вспомогательный контекст, но не должен быть единственным создателем записи. Отправляйте копии в хранилище, которое агент не может изменить, назначьте срок хранения с учетом инцидентов и договоров, а извлечение включите в учения. Журнал, к которому никто не умеет обратиться под давлением, остается дорогим текстовым архивом.

GitHub описывает журнал аудита организации простыми рабочими понятиями: кто выполнил действие, что именно сделал и когда. Свидетельствам для агента программирования нужны эти основы, а также запросивший человек, согласованный артефакт, решение политики, учетные данные и результат, потому что одна автоматическая сессия может действовать через несколько систем. Идентификаторы корреляции должны сопровождать запрос в агенте, репозитории, системе CI, плоскости управления облаком и развертывании приложения.

Проверяйте цепочку вопросом, а не галочкой. Выберите одно изменение продакшена и попросите человека, который его не запускал, определить автора запроса, точный предмет согласования, каждую запись в продакшен, учетную запись каждой операции и соответствие развернутого артефакта проверенному. Если для ответа приходится визуально сопоставлять временные метки или верить расшифровке чата, улучшите цепочку до расширения доступа.

Отделяйте свидетельства аудита от диагностического вывода. Журналы приложения объясняют поведение программы, трассировки агента показывают, как модель пришла к запросу, а события аудита плоскости управления фиксируют, какое аутентифицированное действие приняла платформа. Во время инцидента могут понадобиться все три источника, но они не заменяют друг друга. Команды часто хранят подробные трассировки модели, а затем не могут доказать, какая облачная учетная запись изменила ресурс.

Решите и то, что записывать не следует. Промпты и результаты инструментов могут содержать данные клиентов, исходный код, токены или закрытые заметки об инциденте. Ограничьте доступ к трассировкам агента и срок их хранения, удаляйте секреты до записи и фиксируйте момент очистки. Система аудита, которая создает вторую неконтролируемую копию всех чувствительных входных данных, увеличивает риск под видом его снижения.

## Полномочия на откат должны быть независимыми и проверенными

План отката заслуживает доверия, когда конкретный человек может выполнить его с учетными данными, которые агент не способен заблокировать, по процедуре, проверенной на том же классе изменений. «Отменить коммит» охватывает только изменения исходного кода. Такая команда не восстанавливает удаленные данные, не обращает миграцию с потерями, не возвращает замененный секрет, не отменяет внешний побочный эффект и не исправляет замену инфраструктуры с уничтожением состояния.

Классифицируйте каждое предлагаемое действие в продакшене как обратимое, компенсируемое или необратимое. Для обратимого действия известна операция, возвращающая прежнее состояние. Компенсируемое требует нового действия, например возврата платежа или перестроения индекса, и может оставить последствия для клиентов. Необратимые действия, включая некоторые удаления и раскрытие данных, нельзя сделать безопасными кнопкой отката. Не отдавайте их автономному исполнению.

Оператору отката нужны отдельная учетная запись, экстренный путь, не зависящий от сломанного пути развертывания, и доступ к заведомо исправным артефактам и резервным копиям. Агент не должен контролировать эту учетную запись или репозиторий с определением ее прав. Если продакшен-агент может удалить резервную копию, изменить процесс отката и переписать хранилище свидетельств, у вас одна большая область отказа.

Проведите репетицию отката до выдачи постоянного доступа. Разверните безобидную версию через предполагаемый путь агента, отзовите его сессию и поручите назначенному оператору восстановить предыдущую версию по экстренному пути. Проверьте, может ли оператор найти нужный артефакт и определить момент завершения восстановления. Цель заключается в доказательстве работоспособности пути, а не в эффектно коротком времени.

Изменения базы данных требуют отдельного подхода. Предпочитайте поэтапные совместимые миграции: добавьте совместимые структуры, разверните программу, которая понимает оба состояния, перенесите данные, проверьте их и лишь затем удалите старую структуру. Задержка кажется неэффективной, поэтому команды ее пропускают. Она сохраняет период, в течение которого приложение еще можно откатить. Агенту нельзя сворачивать эти фазы в одну умную миграцию лишь потому, что тестовая среда ее приняла.

Определите завершение восстановления до инцидента. Успешный откат означает больше, чем зеленый отчет инструмента развертывания. Проверьте состояние приложения, долю ошибок, глубину очереди, целостность данных и конкретную клиентскую операцию, затронутую изменением. Для компенсирующего действия отслеживайте исправленные последствия и те, что требуют участия поддержки или финансовой команды. Командиру инцидента нужна эта разница при решении о возобновлении развертывания.

Резервные копии требуют проверки восстановления, а не снимка экрана с выполненной задачей по расписанию. Владелец отката должен знать точку восстановления, ожидаемое окно потери данных, учетные данные, целевую среду и проверочный запрос. Если восстановление продакшен-данных занимает часы, этот факт должен влиять на решение о доступе. Обычное на вид действие агента может оказаться слишком рискованным для автономного выполнения.

## Командование инцидентом начинается до первой сессии агента

Еще до выдачи первых учетных данных один человек должен получить полномочия командовать инцидентами в продакшене, вызванными агентом. Он решает, когда остановить агента, отозвать роли, заморозить развертывание, запустить откат, сохранить свидетельства и передать деловую коммуникацию на более высокий уровень. Роль может переходить между людьми, но ее нельзя выяснять в групповом чате после жалоб клиентов.

Составьте короткую командную карточку с именами или дежурными ролями для пяти решений: командование инцидентом, отзыв доступа, техническое восстановление, сохранение свидетельств и общение с клиентами или юристами. В маленькой компании несколько решений может принять один человек. Важнее всего разделить автоматического исполнителя и человека, который способен его сдержать.

У сдерживания должен быть явный порядок. Остановите новые сессии агента, запретите принятие новых ролей, отзовите или отключите активные сессии, если платформа это позволяет, приостановите путь развертывания, сохраните журналы, оцените эффект для клиентов, затем выберите откат или исправление вперед. Не начинайте с удаления рабочей среды агента. Вместе с ней может исчезнуть контекст, нужный для понимания событий.

Документация AWS отмечает деталь, которую команды часто упускают: временные учетные данные роли действуют до истечения срока, если не отозвать сессии или не изменить фактические права. Короткий срок помогает, но сам по себе не заменяет аварийный выключатель. Проверьте конкретный механизм отзыва для своего провайдера учетных записей и облака, включая задержку распространения и уже выполняемые задачи.

Командиру инцидента также нужен порог объявления события. Необъясненная запись в продакшен, несовпадение артефакта, попытка обхода политики, пропавшие события аудита, применение неожиданных учетных данных или потеря готовности к откату должны остановить расширение доступа, даже если клиенты еще не заметили ошибку. Ожидание видимого ущерба поощряет пробелы в мониторинге.

После сдерживания сравните задуманный контракт с фактическим графом действий. Исправьте системную границу до изменения промпта. Правка промпта может снизить вероятность повтора, но именно учетные данные, барьеры политик и правила развертывания решают, достигнет ли повтор продакшена.

## Расширяйте доступ через барьеры, подтвержденные свидетельствами

Не переходите сразу от помощи в репозитории к открытому доступу в продакшен. Увеличивайте полномочия только после того, как текущий этап дал свидетельства безопасности следующего. Разумная последовательность включает создание ветки в изолированном репозитории, предложения изменений в настоящем репозитории, развертывание в изолированной среде, чтение продакшена, согласованный человеком выпуск в продакшен и лишь затем узко определенный автономный выпуск для сервиса с малым влиянием.

Для каждого повышения нужны критерии выхода. До чтения продакшена докажите фильтрацию чувствительных полей и невозможность спрятать путь записи в полученном контексте. До согласованного человеком выпуска докажите привязку артефакта, независимое согласование, полную корреляцию событий, завершение сессии и экстренный отзыв. До любого автономного выпуска покажите повторяющиеся чистые запуски для того же класса действий, а изменения учетных записей, данных и политик оставьте за барьером.

Ведите запись решения для каждого расширения:

- Укажите новое действие, точные ресурсы, деловую причину и ожидаемую частоту.
- Назовите режимы отказа, которые становятся возможными на этом этапе.
- Приложите проверку прав, воспроизведение аудита, репетицию отката и владельца инцидента.
- Назначьте дату завершения исключения или доступа.
- Запишите, кто принял оставшийся риск.

Этот процесс разоблачает популярную, но неверную рекомендацию: ненадолго дать агенту широкий доступ, посмотреть на его действия и сузить права по наблюдаемому применению. Совет привлекает тем, что поиск нужных прав утомителен. В продакшене он ошибочен, потому что период наблюдения одновременно становится периодом широких полномочий, а обычные запуски не показывают, что запросит подмененный вход или отказавшая зависимость. Выявляйте действия в песочнице, затем разрешайте в продакшене проверенный набор.

Считайте автономность доверием к отдельному действию, а не постоянным статусом агента. Одна система может безопасно перезапускать сервис без состояния, но требовать согласования миграции схемы и запрещать изменение учетных записей. Так модель контроля остается понятной при смене инструментов и промптов.

Назначьте повторную проверку при любом изменении модели, системного промпта, инструментов, источников получаемых данных, процесса развертывания, политики прав или архитектуры продакшена. Успешная оценка не переносится автоматически на существенно другую систему. Расширение контекста способно расширить фактические полномочия даже при тех же учетных данных.

## Внешний руководитель должен оставить компании право сказать «нет»

Хороший внешний руководитель оставляет систему контроля, которой внутренняя команда умеет управлять и которую способна оспаривать. Работа завершена, когда основатель видит достижимые действия, согласующий проверяет неизменный артефакт, специалист по реагированию запрашивает свидетельства, а командир инцидента отзывает доступ и восстанавливает систему без консультанта.

Для команд, которым нужна независимая оценка, Team & AI Audit на oleg.is помогает найти экономию в разработке и рабочие средства контроля для преобразования команды с помощью ИИ. Такая оценка может прояснить ответственность и приоритеты, но ни один советник не должен превращаться в постоянное узкое место согласования или давать основателю повод игнорировать оставшийся риск.

Не выдавайте доступ на запись в продакшен лишь потому, что агент хорошо показал себя при разработке. Разрешите одно ограниченное действие, когда компания умеет его сдерживать, согласовывать, наблюдать, отменять или компенсировать и командовать инцидентом при сбое. Если внутри никто не способен доказать эти условия, наймите внешнего руководителя до выдачи учетных данных и дайте ему право принести неприятный ответ.