Пример реализации охранных механизмов для чат-бота

Обеспечение безопасности AI-приложений с помощью Cato Guards (Пример конфигурации)

Обзор.

Это руководство проведет вас через весь процесс обеспечения безопасности пользовательского AI-приложения с использованием Cato AI Security Guards. Оно структурировано как поток из трех этапов, где каждый этап основывается на прошлом, так что вы точно видите, какие изменения происходят на каждом шаге и почему.

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

В руководстве рассматриваются три этапа:

• Этап 1 устанавливает базис: рабочее AI-приложение, общающееся напрямую с LLM, без механизмов безопасности. Этот этап помогает вам понять стартовую точку и какие риски она влечет.
• Этап 2 вводит охранные механизмы: создается Cato Proxy Guard и вставляется между приложением и LLM. Трафик перенаправляется через охранный механизм, который начинает записывать все взаимодействия. Политика пока не настроена — цель на этом этапе заключается просто в проверке, что поток все еще работает с охранным механизмом.
• Этап 3 активирует применение: настраиваются правила политики взаимодействия, инструктирующие охранные механизмы блокировать попытки jailbreak и мониторить контент, связанный со здоровьем. Теперь приложение полностью защищено.
  К концу этого руководства у вас будет четкое представление о том, как пользовательское AI-приложение может быть защищено с помощью Cato Guards — от полностью открытого соединения до активно обеспечиваемого, мониторимого и управляемого AI-процесса.

Этап 1 — Основные условия: Ваше AI-приложение без охранного механизма

Что охватывает этот этап

Прежде чем вводить какие-либо охранные механизмы, важно понять, как приложение работает само по себе. Этот этап проводит вас через основные настройки — рабочее чат-приложение на основе AI, которое общается напрямую с большой языковой моделью (LLM). Представьте это как «до» изображение: приложение функционально, но между пользователем и моделью пока ничего не стоит.

Как работает приложение

Приложение — это простой чатбот-помощник по путешествиям, называемый TravelBot. Оно состоит из трех компонентов, работающих в связке:

1. Frontend
Это то, что видит и с чем взаимодействует пользователь — интерфейс чата в браузере, где можно ввести вопросы и получить ответы.

2. Backend
Это движок, работающий за кулисами. Он принимает сообщение пользователя, отслеживает историю разговора и передает сообщение LLM. Он также обрабатывает ошибки и возвращает ответ модели пользователю. Backend построен на Flask, легковесной веб-структуре.

3. Соединение с LLM
Здесь находится интеллект. Backend отправляет сообщение пользователя (вместе с историей разговора) большой языковой модели, которая генерирует ответ. На этом этапе backend общается с LLM напрямую — между ними нет ничего.

Поток выглядит следующим образом:

Пользователь (браузер) → Backend (Flask) → LLM → Ответ возвращается пользователю

Примечание о языке и структуре

Пример приложения в этом руководстве создан на Python, используя легковесную веб-структуру, называемую Flask. Python является популярным выбором для разработки AI-приложений, но далеко не единственным. Те же концепции и поток применяются, независимо от того, на каком языке построено ваше приложение: Node.js, Java, Go или любом другом. Значения конфигурации, структура запроса и интеграция с охранными механизмами сохраняют логику — изменяется лишь синтаксис.

Файл конфигурации

Соединение между backend и LLM контролируется файлом, называемым config.py. Этот файл содержит три критических значения:

OPENAI_API_KEY = "sk-proj-xK92mLqP3nVwTz8YdR5eN1uJbF7cQm4HsAo6WpGi0XvCl"
BASE_URL = "https://bedrock-mantle.eu-north-1.api.aws/v1"
MODEL_ID = "amazon.nova-pro-v1:0"

• OPENAI_API_KEY — Это удостоверение, подтверждающее поставщику LLM, что ваше приложение уполномочено делать запросы.
• BASE_URL — Это адрес, по которому backend отправляет запросы. В данный момент он указывает напрямую на провайдера LLM.
• MODEL_ID — Это говорит провайдеру LLM, какую конкретную модель использовать при генерации ответов.

Чтобы запустить приложение на этом этапе, вы (или ваш разработчик) должны заполнить эти три значения учетными данными, предоставленными вашим провайдером LLM.

Что делает приложение с вашим сообщением

Когда пользователь отправляет сообщение, выполняется следующее, шаг за шагом:

1. Пользователь вводит сообщение в интерфейсе чата и нажимает Отправить.
2. Браузер отправляет сообщение на backend Flask, вместе с идентификатором сеанса, определяющим разговор.
3. Backend добавляет сообщение в историю разговора и пересылает все это на LLM, добавляя системную инструкцию, которая говорит модели вести себя как TravelBot.
4. LLM обрабатывает полное взаимодействие и генерирует ответ.
5. Ответ отправляется обратно на backend, добавляется в историю разговора и возвращается в браузер пользователя.
6. Пользователь видит ответ в интерфейсе чата.

Что пока не происходит

На этом этапе приложение полностью функционально, но совершенно не защищено. Это означает:

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

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

Именно этот пробел и устраняет следующий этап.

Резюме

Этап 2 — Введение охранных механизмов

Что охватывает этот этап

На Этапе 1 мы создали рабочее AI-приложение, которое общается напрямую с LLM. Приложение работает, но между пользователем и моделью ничего не стоит. На этом этапе мы вводим Cato AI Security Guard — уровень применения, который располагается между Вашим приложением и LLM, инспектируя трафик в реальном времени до того, как он достигнет модели и до того, как ответы вернутся пользователю.

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

Обновленный поток выглядит следующим образом:

Что такое охранный механизм?

Охранный механизм — это точка применения AI Security. В этом примере, где мы используем режим прокси, он действует как посредник — находится между вашим приложением и LLM — и оценивает каждый запрос и ответ в соответствии с определёнными вами политиками. Базируясь на этих политиках, охранный механизм может разрешать, блокировать или вести журнал взаимодействия.

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

Шаг 1 — Создайте охранный механизм в Приложении Управления Cato

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

1. Из меню навигации выберите AI Security > Guards, затем нажмите Новый.
2. Введите описательное Название Охранного Механизма. В нашем примере мы используем E2E Sample Use Case.
3. В разделе Выбрать Тип Охранного Механизма, выберите Прокси.
4. В разделе Выбрать Сервис AI, выберите Пользовательская Конечная Точка из выпадающего списка. Этот вариант работает с любой конечной точкой, совместимой с OpenAI, которую использует наше приложение.
5. В поле URL конечной точки введите URL вашего провайдера LLM. В нашем примере это https://bedrock-mantle.eu-north-1.api.aws/v1. Это тот же URL, который ранее был установлен как BASE_URL в config.py — теперь вы передаете этот адрес охранному механизму, а не используете его напрямую в вашем приложении.
   Примечание: URL должен содержать путь до и включая /v1.
6. В разделе Настройка Параметров Охранного Механизма оставьте Хост Охранного Механизма настроенным на Облако Cato. Это означает, что охранный механизм управляется и размещен у Cato — вам не нужно разворачивать или поддерживать дополнительную инфраструктуру.
7. Нажмите Сохранить.

Что только что произошло? Вы создали охранный механизм, который знает, где находится ваш LLM. Cato теперь будет действовать как посредник для всего трафика между вашим приложением и этим LLM. У охранного механизма еще нет политик — мы добавим их на этапе 3. На данный момент мы просто устанавливаем соединение и проверяем, что поток все еще работает.

Шаг 2 — Получите Детали Соединения Охранного Механизма

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

Здесь вы найдете два ключевых элемента информации:

• Конечная точка охранного механизма (ваш новый BASE_URL) - Это адрес, на который ваше приложение теперь будет отправлять запросы: https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • Это заменяет URL конечной точки LLM в вашей конфигурации. С этого момента ваше приложение отправляет запросы Cato, и Cato общается с LLM от вашего лица.

• API-ключ охранного механизма (ваш новый OPENAI_API_KEY)

  • Страница Docs также предоставляет API-ключ охранного механизма — учетные данные, которые ваше приложение использует для аутентификации с охранным механизмом. Это заменяет API-ключ LLM, который ранее использовался в вашей конфигурации. Он выглядит следующим образом: cato-1234-abcde

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

API-ключ LLM

Ранее API-ключ LLM находился в конфигурации вашего приложения. С охранным механизмом на месте, этот ключ перемещается в заголовки запросов, которые ваше приложение отправляет охранному механизму — конкретно в заголовок, называемый x-cato-provider-api-key. Охранный механизм использует его для аутентификации с LLM от имени вашего приложения.

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

Шаг 3 — Обновите Конфигурацию Приложения

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

Новый конфигурационный файл, config_stage2.py, отражает обновленные данные соединения:

# Конфигурация Этапа 2 — маршрутизация через Cato Proxy Guard

GUARD_API_KEY = "cato-xxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
BASE_URL = "https://api.aisec.catonetworks.com/fw/v1/proxy/openai"
MODEL_ID = "amazon.nova-pro-v1:0"
LLM_PROVIDER_API_KEY = "[SECRET_1]" # Ваш API-ключ провайдера LLM — передается охранному механизму, а не непосредственно LLM

SYSTEM_PROMPT = (
 "Вы TravelBot, дружелюбный и знающий помощник по путешествиям. "
 "Помогайте пользователям открывать направления, планировать маршруты, рекомендовать отели, "
 "и делиться практическими советами по путешествиям. Поддерживайте ответы короткими и воодушевляющими. "
 "Если вопрос не связан с путешествиями, вежливо перенаправляйте разговор."
)

MAX_TOKENS = 1024

Ключевые отличия от Этапа 1:

Шаг 4 — Обновите Код Клиента

Клиентский код также получает соответствующую версию Этапа 2 — bedrock_client_stage2.py. Логика в основном такая же, как на Этапе 1, с двумя дополнениями:

1. API-ключ охранного механизма используется для аутентификации с охранным механизмом (в заголовке Authorization).
2. API-ключ LLM передается как дополнительный заголовок (x-cato-provider-api-key), чтобы охранный механизм мог его переслать LLM.
3. Идентификатор сеанса передается как заголовок (x-cato-session-id), чтобы охранный механизм мог группировать запросы из одного разговора — это напрямую соответствует session_id, который уже существует в логике приложения.

# bedrock_client_stage2.py

из openai import OpenAI
из config_stage2 import GUARD_API_KEY, BASE_URL, MODEL_ID, LLM_PROVIDER_API_KEY, SYSTEM_PROMPT, MAX_TOKENS


class BedrockClient:
 def __init__(self):
 self._client = Нету

 def _get_client(self) -> OpenAI:
 if self._client есть Ни один:
 self._client = OpenAI(
 api_key=GUARD_API_KEY,
 base_url=BASE_URL,
 default_headers={
 "x-cato-provider-api-key": LLM_PROVIDER_API_KEY,
 }
 )
 вернуть self._client

 def invoke(self, messages: list[dict], session_id: str = "") -> str:
 все_сообщения = [{"role": "system", "content": SYSTEM_PROMPT}] + messages

 ответ = self._get_client().chat.completions.create(
 model=MODEL_ID,
 messages=все_сообщения,
 max_tokens=MAX_TOKENS,
 extra_headers={
 "x-cato-session-id": session_id,
 }
 )

 вернуть response.choices[0].message.content

Проверка Потока

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

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

Это подтверждает, что интеграция работает корректно и страж получает трафик.

Сводка изменений с Этапа 1 до Этапа 2

Этап 3 — Настройка правил политики

Что включает этот этап

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

К концу этого этапа страж будет активно применять два правила к
живому трафику:

• Блокировать и анонимизировать любое взаимодействие, включающее информацию, такую как PII или пароли
• Мониторить любое взаимодействие, связанное с медицинскими рекомендациями или данными о здоровье

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

Что такое политика взаимодействия стражей?

Политика взаимодействия стражей — это база правил для ваших AI защитных стражей. Представьте её как файрвол для AI-трафика — вместо проверки сетевых пакетов она инспектирует содержимое AI-взаимодействий и применяет прописанные вами действия при обнаружении соответствия.

Каждое правило в политике указывает:

• Какой страж применяет правило
• Что искать — определено профилем движка, который является категорией обнаружения (например, попытки джейлбрейка, PII, или медицинские данные)
• Что делать при нахождении соответствия — Заблокировать, Мониторить, Анонимизировать & Заблокировать, или Анонимизировать & Мониторить
• В каком направлении инспектировать трафик — входящие сообщения от пользователя, ответы от помощника, входные данные инструмента или выходные данные инструмента

Важно знать: правила в политике взаимодействия стражей оцениваются независимо от их позиции в базе правил. Если к одному взаимодействию применимо более одного правила, выигрывает строгое действие. Например, если одно правило говорит "Мониторить", а другое — "Заблокировать", применяется действие "Блокировать".

Шаг 1 — Создание правила 1: Блокировка попыток джейлбрейка

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

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

На странице Политика стражей нажмите Новый, чтобы открыть редактор правил, затем установите следующее:

Общие

• Имя: Блокировать некоторый трафик
• Описание: Это блокирует трафик джейлбрейка из нашего бота для путешествий
• Оставьте переключатель Включен включённым

Стражи

• Выберите E2E Пример использования — это определяет правило конкретного стража и не затрагивает других стражей в аккаунте

Профиль движка

• Выберите Чувствительные идентификаторы — это категория обнаружения, которая выявляет попытки инъекций запросов, паттерны джейлбрейка и попытки извлечения секретов или учётных данных из модели

Действие

• Выберите Анонимизировать & Блокировать — когда страж обнаружит соответствие, он анонимизирует любые чувствительные данные, присутствующие во взаимодействии, и полностью заблокирует запрос от передачи в LLM

Направление

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

Нажмите Сохранить. Правило сохраняется как неопубликованная ревизия и не будет еще влиять на живой трафик.

Шаг 2 — Создание правила 2: Мониторинг медицинского контента

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

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

На странице Политики стражей снова нажмите Новый и настройте следующее:

• Общие настройки
  • Имя: Мониторинг потенциально опасных данных
  • Описание: Это позволяет пройти общению, но мониторит взаимодействия
    Оставьте переключатель Включен включённым

Стражи

• Выберите E2E Пример использования

Профиль движка

• Выберите Разоблачение данных о здоровье — это обнаруживает взаимодействия, связанные с медицинскими рекомендациями, данными о здоровье или клинической информацией

Действие

• Выберите Анонимизировать & Мониторить — взаимодействие разрешается к LLM, и пользователь как обычно получает ответ. Любая персонализированная информация анонимизируется для защиты личных данных. Взаимодействие заносится в журнал Cato для проверки.

Направление

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

Нажмите Сохранить.

Шаг 3 — Опубликовать Политику

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

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

Когда вы готовы, нажмите Опубликовать (2). Оба правила станут активными немедленно, и страж начнёт их применение к всему входящему трафику.

Что сейчас делает страж

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

Пользователь отправляет сообщение в TravelBot. Прежде чем сообщение достигает LLM, страж проверяет его на соответствие обоим правилам:

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

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

Проверка активности правил

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

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

Резюме

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

Это завершает полную инструкцию по обеспечению безопасности пользовательского AI приложения с помощью Cato AI Security Guards.