Искусственные интеллекты-агенты все чаще применяются в различных приложениях. Однако внедрение агентов в систему требует не только предоставления модели доступа ко всем данным и инструментам. Необходимо также разработать надежные защитные барьеры, которые гарантируют доступ агента только к подходящим данным и предотвращают неправильное использование функций. При этом важно сохранить возможность эффективной работы модели с необходимыми ресурсами, задействуя максимум доступных инструментов без постоянного вмешательства человека.
В этой статье я хочу на высоком уровне осветить подходы к созданию эффективных защитных механизмов для агентов, обеспечивая доступ только к требуемым данным и функциям при сохранении высокого качества пользовательского опыта, например, минимизируя случаи, когда человеку приходится одобрять доступ агента. Сначала я объясню, почему такие барьеры жизненно важны, затем перейду к ключевому элементу — детализированной авторизации. Далее рассмотрю создание защит для данных и продолжу обсуждение барьеров для функций.
Почему необходимы защитные механизмы для агентов
Сначала стоит пояснить, зачем нужны барьеры безопасности для ИИ-агентов. Теоретически можно просто предоставить агенту полный доступ ко всем базам данных и инструментам в приложении, верно?
Существует несколько причин, по которым такие меры обязательны. Основная — предотвращение нежелательных действий со стороны агента, например, удаления таблиц в базе данных. Кроме того, требуется гарантировать, чтобы агенты получали доступ только к данным в пределах определенного контекста, скажем, чтобы агент одного клиента не мог использовать информацию другого.
Некоторые барьеры можно настроить автоматически, без участия человека. Доступ к базе данных — один из таких примеров: вы определяете область действия агента (например, в рамках одного клиента) и разрешаете доступ исключительно к данным этого клиента. Другие барьеры, напротив, предполагают взаимодействие с человеком. Представьте, что агент хочет выполнить команду: как убедиться, что это не разрушительное действие (вроде удаления таблицы в базе), и что пользователь согласен на ее выполнение?
В подобных ситуациях задействуется механизм с участием человека: агент запрашивает разрешение на конкретное действие. Если пользователь одобряет, агент продолжает работу; если нет — ему приходится выбирать альтернативный путь.
Детализированные разрешения
Работа с агентами часто подразумевает необходимость в детализированных разрешениях. Это позволяет просто проверять доступность функции или данных в конкретном контексте, таком как:
- Имеет ли клиент 1 доступ к таблице A в базе данных?
- Разрешен ли пользователю 2 доступ к функции B?
- Может ли организация 3 использовать функцию C?
Внедрение детализированной авторизации в приложение крайне важно. На рынке есть множество поставщиков, предлагающих такие решения.
После реализации детализированной авторизации ее следует интегрировать во все функции приложения, учитывая как положительные, так и отрицательные сценарии. В случае отказа в доступе, например, можно добавить уведомление о необходимости запросить у администратора соответствующий уровень прав для выполнения действия.
Защитные механизмы для данных в агентах
После настройки детализированных разрешений можно перейти к барьерам безопасности вокруг данных. Агент должен иметь доступ к максимально возможному объему информации, чтобы точно отвечать на запросы пользователей. При этом нужно сбалансировать это с запретом на использование ограниченных данных или загрузку избыточной информации, не связанной с запросом.
Доступ к ограниченным данным
Ограничение доступа к данным для агентов в основном зависит от детализированной авторизации. В функциях, отвечающих за поиск данных (запросы к базе, извлечение из хранилищ и т.д.), сначала проверяйте область доступа пользователя.
Кроме того, полезно указывать агенту в инструкциях, что ему разрешено делать. Попытка агента получить доступ к данным с последующим отказом окажется затратной — как по расходу токенов, так и по времени.
Избежание загрузки ненужной информации
Если предоставить агенту доступ ко всем таблицам базы и хранилищам, могут возникнуть проблемы: у агента окажется слишком много вариантов, и ему будет сложно выбрать правильную таблицу документов и поля. Эта тема недавно поднималась в материалах о создании инструментов для эффективных агентов.
Чтобы решить эту задачу, стоит информировать агента только о релевантных источниках данных. Если задача решается исключительно с помощью базы A, укажите агенту только о ней, исключая остальные из инструкций. Конечно, это предполагает, что вы заранее знаете, какие данные потенциально полезны для ответа на запросы.
Защитные механизмы для функций в агентах
Тема создания барьеров для функций представляется еще более увлекательной. Здесь приходится учитывать множество аспектов:
- Как предотвратить разрушительные действия?
- Как сократить количество взаимодействий с человеком?
Как предотвратить разрушительные действия
Самый ключевой аспект в барьерах для функций — избежание разрушительных операций. Для этого маркируйте все функции по признаку выполнения необратимых действий. Например:
- Удаление таблицы в базе данных — необратимая операция (хотя можно восстановить из резервной копии, но это требует усилий).
- Чтение из таблицы не несет разрушительного эффекта.
Если действие легко обратимо (например, с помощью кнопки отмены) или вообще не вредит, агенту можно разрешить его выполнение без ограничений.
Однако для необратимых действий стоит уведомить агента об этом и, вероятно, запросить подтверждение у пользователя перед выполнением.
Как минимизировать взаимодействия с человеком
Естественно, разрушительные действия нужно пресекать. Но при этом не стоит утомлять пользователя постоянными запросами на одобрение каждой операции.
Отличный способ сократить такие взаимодействия — внедрение белых списков функций, подобно тому, как это делает Cursor для команд терминала: в первый раз, когда Cursor хочет выполнить команду, такую как:
- Переход в папку с помощью cd.
- Запуск pytest tests.
- Перемещение файла из одной директории в другую.
Cursor запрашивает у пользователя разрешение. Доступны три варианта:
- Отказать в запросе.
- Одобрить запрос (одноразово).
- Добавить в белый список (одобрить сейчас и на будущее).
Белые списки эффективны, поскольку гарантируют одобрение пользователем, но избавляют от повторных вопросов по той же функции. Впрочем, есть минус: некоторые команды нельзя добавлять в список, так как контекст требует проверки каждый раз (например, при предложении удалить таблицу в базе данных).
Заключение
В этой обзорной статье я рассмотрел, как подойти к разработке агентных приложений с учетом защитных механизмов. Такие барьеры обязательны, чтобы агент вел себя предсказуемо, не выходил за пределы доступа к информации и не выполнял разрушительные операции без явного согласия пользователя. Я описал создание барьеров для данных и функций, доступных агенту. Я убежден, что защитные механизмы — неотъемлемая часть построения агентных систем, которую всегда стоит держать в фокусе. Правильно реализованные барьеры сделают агентов безопаснее в использовании, что критично: потеря доверия пользователя к агенту может быть трудно восстановима.