Введение в агенты (Часть 12)

Обеспечение безопасности единственного агента: компромисс между доверием и безопасностью

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

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

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

Идентичность агента: новый класс принципала

В традиционной модели безопасности есть человеческие пользователи, которые могут использовать OAuth или SSO, и есть службы, которые используют IAM или служебные учетные записи. Агенты добавляют третью категорию принципалов. Агент — это не просто кусок кода; это автономный участник, новый вид принципала, который требует собственной проверяемой идентичности. Так же, как сотрудникам выдают идентификационные бейджи, каждому агенту на платформе должен быть выдан безопасный, поддающийся проверке «цифровой паспорт». Этот агент Идентичность отличается от идентичности пользователя, который ее вызвал, и разработчика, который ее создал. Это фундаментальное изменение в подходе к управлению идентичностью и доступом (IAM) в предприятии.

Проверка каждой идентичности и контроль доступа для всех из них являются основой безопасности агента. Как только агент получает криптографически проверяемую идентичность (часто с использованием стандартов, таких как SPIFFE), ему могут быть предоставлены собственные специфические права с минимальными привилегиями. SalesAgent получает доступ на чтение/запись к CRM, в то время как HRonboardingAgent явно лишается такого доступа. Такой детальный контроль имеет решающее значение. Он гарантирует, что даже в случае компрометации одного агента или его непредвиденного поведения потенциальный радиус поражения будет ограничен. Без конструкции идентичности агента агенты не могут работать от имени людей с ограниченными делегированными полномочиями.

Основная сущностьАутентификация / ВерификацияПримечания
ПользователиАутентифицированы с помощью OAuth или SSOЛюди, обладающие полной автономией и ответственностью за свои действия
Агенты (новая категория принципов)Проверенные с помощью SPIFFEАгенты наделены полномочиями и действуют от от имени пользователей
Служебные учетные записиИнтегрированы в IAMПриложения и контейнеры, полностью детерминированные, не ответственность за действия

Политики ограничения доступа

Политика — это форма авторизации (AuthZ), отличная от аутентификации (AuthN). Как правило, политики ограничивают возможности субъекта; например, «Пользователи из отдела маркетинга могут получить доступ только к этим 27 конечным точкам API и не могут выполнять команды DELETE». При разработке агентов нам необходимо применять разрешения к агентам, их инструментам, другим внутренним агентам, контексту, которым они могут делиться, и удаленным агентам. Подумайте об этом так: если вы добавляете все API, данные, инструменты и агенты в свою систему, то вы должны ограничить доступ только к тому поднабору возможностей, который необходим для выполнения их задач. Рекомендуемый подход: применять принцип минимальных привилегий, оставаясь контекстуально релевантным.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

19 + шесть =

Прокрутить вверх