# Привилегированный доступ ИИ-агентов требует двух владельцев

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

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

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

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

## Ответственность делится по типу решения

Внешний CTO должен отвечать за то, зачем ИИ-агент получает доступ, а руководитель безопасности за ограничения и их проверку. Генеральный директор или другой ответственный руководитель сохраняет за собой принятие существенного риска для компании. Это разделение прав на решения, а не коллективная ответственность, при которой каждый надеется, что действовал кто-то другой.

Несколько разных решений часто сводят в один запрос на согласование. Для них нужны разные владельцы и записи:

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

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

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

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

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

## Внешний CTO отвечает за цель и архитектуру

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

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

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

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

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

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

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

## Руководитель безопасности отвечает за границы и проверку

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

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

NIST Special Publication 800-207 вводит еще одно полезное различие: аутентификация и авторизация выполняются как отдельные функции до открытия сеанса с ресурсом, а расположение в сети не дает неявного доверия. Я бы продолжил эту логику до каждого чувствительного вызова инструмента. Процесс агента, прошедший аутентификацию, не получает постоянную авторизацию только потому, что его сеанс начался правильно. Точка применения политики должна заново учитывать исполнителя, запрошенное действие, ресурс, состояние среды выполнения и свидетельство согласования.

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

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

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

## Политики должны ограничивать действия, а не должности

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

Краткая политика может выглядеть так:

```yaml
agent: release-bot-prod
purpose: deploy approved application builds
identity:
  type: workload
  session_ttl_minutes: 15
resources:
  allow:
    - service/payments-api
    - deployment/payments-api
  deny:
    - identity/*
    - secrets/*
actions:
  allow:
    - deployment.read
    - deployment.create
    - deployment.rollback
  deny:
    - deployment.delete
    - policy.write
conditions:
  source_ref: refs/heads/main
  artifact_attestation: required
  approval:
    deployment.create: service-owner
    deployment.rollback: on-call-engineer
limits:
  max_actions_per_run: 8
  max_parallel_runs: 1
on_control_failure: deny
expires: 2026-10-31
```

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

Считайте `purpose` свидетельством для проверки, а не средством контроля. Механизм политик не способен сам определить, соответствует ли запрошенное действие текстовому описанию. Инженеры должны преобразовать цель в список разрешений. Явные запреты полезны как дополнительная защита, но список запретов не исправит открытое разрешение, потому что новые действия появляются быстрее, чем проверяющие успевают добавлять исключения.

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

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

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

## Согласование должно зависеть от зоны ущерба

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

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

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

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

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

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

## Руководителя инцидента нужно назначить до запуска

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

NIST Special Publication 800-61 Revision 3 разделяет обязанности руководства и специалистов по реагированию. Руководство может разрешать действия с серьезными последствиями, например отключение или перестройку важных сервисов. Специалисты подтверждают инцидент, анализируют свидетельства, ограничивают ущерб, находят причины и помогают восстановлению. Отсюда следует ясное разделение: руководитель безопасности ведет работу по реагированию, а CTO или другой руководитель разрешает бизнес-последствия за пределами полномочий специалиста.

Представим агента выпуска, который читает отравленное описание задачи. Текст велит ему проверить переменные окружения и приложить диагностические данные к записи сборки. Токен репозитория не позволяет агенту читать секреты, но токен деплоя позволяет запросить описание задачи со ссылками на секреты. Агент публикует эти ссылки и внутренние адреса в журнале с широким доступом. Через несколько минут он пытается изменить срок хранения журнала, потому что та же инструкция объявляет старые записи ненужными.

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

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

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

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

## Обе роли нужны при изменении границ

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

Совместно проверяйте следующие изменения:

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

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

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

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

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

## Маленькой компании тоже нужно разделение

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

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

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

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

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

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

## Проверьте ответственность одним запросом

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

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

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

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

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