Защитные механизмы и средства обеспечения безопасности при использовании ИИ-агентов в Jira

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

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

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

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

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

• Проверка вывода. Перед поставкой проверьте работу агента по стандартной процедуре рассмотрения запроса pull.

• Ведение журнала. Каждое действие агента записывается в истории задачи с указанием, кто его подтвердил.

Что такое защитные механизмы в агентной разработке?

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

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

На практике защитные механизмы для агентов охватывают несколько взаимосвязанных областей.

• Доступ и область действий. С какими данными и инструментами агент может работать, а также в каких областях он может действовать.

• Ограничение задач. Какие задачи агент может выполнять самостоятельно, а какие остаются за человеком.

• Подтверждение человеком. Точки контроля, в которых человек проверяет или подтверждает выполнение задачи, прежде чем она перейдет на следующий этап.

• Проверка результатов. Проверка результатов работы агента перед поставкой.

• Ответственность и аудит. Запись о том, что и почему сделал агент, а также кто это одобрил.

• Управление. Средства постоянного контроля, которые обеспечивают соблюдение этих принципов по мере расширения использования агентов.

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

Зачем ИИ-агентам нужны защитные механизмы?

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

Далее перечислены ключевые риски, на которые направлены защитные механизмы, а также ситуации, в которых по-прежнему необходимо участие человека.

• Несоответствие. Агент отклоняется от задачи или оптимизирует не то, что нужно.

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

• Слишком широкий доступ. Агент обращается к данным или системам, к которым у него не должно быть доступа.

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

• Нет ответственности или прозрачности. Без записи невозможно понять, что сделал агент или кто это одобрил.

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

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

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

Как безопасно управлять ИИ-агентами в Jira?

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

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

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

Доступ: чем можно управлять в Jira

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

• Как это работает в Jira? Вы выбираете, от чьего имени действует агент. По умолчанию он действует от имени стоящего за ним человека и получает доступ только к тем данным, проектам и задачам, к которым может получить доступ этот человек. Либо можно предоставить агенту собственный аккаунт и права, чтобы его доступ не зависел от конкретного человека. Администраторы управляют тем, какие агенты активны и где они могут работать. Что агент может делать с собственными инструментами, определяет он сам, а не Jira. Оставляйте широкий доступ или строго ограничивайте его и расширяйте по мере роста доверия.

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

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

Как контролировать действия агентов в рабочем процессе?

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

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

• Как это настроить в Jira? Откройте рабочий процесс для нужного типа задачи и подключите агента к переходу, например в статус «На проверке». Агент будет запускаться, когда задача перейдет в этот статус. При подключении агента определяется момент его запуска, а не необходимость подтверждения человеком. Подтверждение человеком — это отдельный элемент управления, который ограничивает переход между этапами. Его можно использовать вместе с правилом автоматизации или собственными инструкциями агента о том, когда следует приостановить работу и запросить подтверждение. Переход — одна из нескольких точек запуска агента. Вот примеры других таких точек:

  • В системе создана задача, и агент запускается для ее первичной обработки.

  • Агент запускается при изменении метки или поля либо по расписанию на основании правила автоматизации.

  • Агент запускается в фоновом режиме для выполнения рутинных задач, таких как подготовка заметок о выпуске.

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

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

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

Проверка результатов работы агента: как оценивать вывод?

Третий защитный механизм — это проверка результатов работы на предмет низкого качества и вымышленных данных до того, как результаты будут переданы дальше. В случае с агентом написания кода человек проверяет созданный им запрос pull.

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

• Посмотрите, какая работа стоит за полученным результатом. Оценивайте не только конечный результат. На вкладке «Сеансы агентов» в Jira указывается, что и зачем сделал агент. Таким образом, проверяющий получает контекст для оценки результата, а не восстанавливает его самостоятельно.

Пример: задайте стандарты проверки кода с помощью ИИ в Bitbucket Cloud и автоматически применяйте их к каждому запросу pull.

Журнал учета: кто, что и когда сделал

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

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

• Фиксация сведений о работе локальных агентов. Отслеживание сеансов агентов позволяет собирать данные об активности локальных ИИ-агентов для написания кода, которая связана с задачей, в локальных IDE или терминалах. Таким образом работа, выполняемая вне Jira, также отражается в едином журнале учета. Зарегистрироваться в списке ожидания.

Каковы рекомендации по использованию защитных механизмов для агентов?

• Предоставляйте агенту права доступа, соответствующие задаче, и расширяйте их по мере укрепления доверия (агенты используют ваши существующие права в Jira).

• Давайте агентам четкие инструкции, как действовать и когда нужно остановиться, чтобы задать вопрос.

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

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

• Проверяйте вывод агента так же, как и человеческую работу (проверка и слияние запросов pull).

• Сохраняйте каждое действие агента в протоколе, привязанном к задаче (история и журнал).

• Предоставляйте агентам контекст, чтобы контролировать расходы. Когда агенты строят догадки и переделывают работу, это приводит к лишним тратам.

По данным Atlassian, в результате использования ИИ, встроенного в Teamwork Graph, качество ответов повысилось на 44 %, а расход токенов при этом снизился на 48 %.

Какие защитные механизмы реализованы в Jira, а какие — на других уровнях?

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

Jira определяет, что могут делать агенты, и регистрирует их действия. Этот инструмент дополняет средства контроля безопасности на уровне модели и на уровне среды выполнения, а не заменяет их.

Как добавить первый защитный механизм для агентов в Jira

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

1. Выберите одну стандартную обратимую задачу, например исправление нестабильного теста или обновление зависимости (это ограничит цену ошибки).

2. Запустите агента с теми же правами доступа, которые вы бы предоставили новому участнику команды, — не более того, что нужно для выполнения задачи.

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

4. Проверьте запрос pull по обычной процедуре (это позволяет выявить низкокачественный вывод или галлюцинации).

5. Убедитесь, что действие записано в истории задачи (для отслеживаемости, если потребуется отменить изменения).

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

Изучите наше честное руководство по ответственному управлению ИИ в рамках принципов ответственных технологий Atlassian.

Часто задаваемые вопросы о защитных механизмах для ИИ-агентов

Как обеспечить безопасность ИИ-агентов?

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

Как Jira управляет ИИ-агентами?

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

Могут ли ИИ-агенты в Jira запрашивать подтверждение от человека?

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

Предусмотрена ли защита от промпт-инъекции с помощью ИИ-агентов?

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