实现聊天机器人的保护示例

使用 Cato 守护来保护 AI 应用程序（示例配置）

概览

本指南将引导您从头到尾了解如何使用 Cato AI 安全守护自定义 AI 应用程序的安全措施。 它由三个阶段性流程构成，每个阶段都是在前一个阶段的基础上构建的，因此您可以清楚看到每个步骤发生的变化以及原因。

本指南中使用的应用程序是 TravelBot——一个简单的 AI 驱动的旅游助手聊天机器人。 虽然这个示例是特定的，但概念和步骤适用于您创建并保护的任何自定义 AI 应用程序。

本指南涵盖了三个阶段：

• 阶段 1 建立基线：一个直接与 LLM 通信的工作型 AI 应用程序，没有实施安全控制。 此阶段帮助您了解起点及其引入的风险。
• 阶段 2 引入保护措施：创建了一个 Cato 代理守护并插入在应用程序与 LLM 之间。 流量通过守护重新路由，该守护开始记录所有的互动。 尚未配置任何政策规则—此阶段的目标只是验证流量在守护在位的情况下是否仍然运行。
• 阶段 3 激活执行：配置并发布互动政策规则，指示守护阻止越狱企图并监控健康相关内容。 现在该应用程序已得到完全保护。
  到本指南结束时，您将清楚了解如何从完全开放连接到主动执行监控并管理 AI 工作流程的自定义 AI 应用程序安全化。

阶段 1——基线：没有保护的 AI 应用程序

本阶段涵盖的内容

在引入任何安全控制之前，了解应用程序自身的工作方式很重要。 此阶段将引导您完成基线设置——一个直接与大型语言模型（LLM）通信的工作AI聊天应用程序。 把这个想象成“之前”的图片：应用程序是功能性的，但在用户和模型之间还没有任何保护。

应用程序的工作原理

应用程序是一个名为 TravelBot 的简单旅游助手聊天机器人。 它由三个组件协同工作组成：

1。 前端
这是用户看到和互动的界面—在浏览器中可以输入问题并接收回答的聊天界面。

2。 后端
这是幕后运行的引擎。 它接收用户消息，跟踪对话历史，并将消息传递给 LLM。 它还处理错误并将模型的响应返回给用户。 后端是使用轻量级网络框架 Flask 构建的。

3。 LLM 连接
这是智能所在的地方。 后台将用户的消息（连同对话历史）发送到一个大型语言模型，该模型生成响应。 在此阶段，后端直接与 LLM 通信，没有任何中间环节。

流程如下所示：

用户(浏览器) → 后端(Flask) → LLM → 返回响应给用户

关于语言和框架的注意事项

本指南中的示例应用程序是用 Python 构建的，使用了一个轻量级的网络框架 Flask。 Python 是 AI 应用程序开发的流行选择，但绝不是唯一的选择。 无论您的应用程序是用 Node.js、Java、Go 或任何其他语言构建的，相同的概念和流程都适用。 配置值、请求结构和守护集成都遵循相同的逻辑—只有语法发生了变化。

配置文件

后端和 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 — 这是后台发送请求的地址。 目前，它直接指向 LLM 提供商。
• MODEL_ID — 这告诉 LLM 提供商在生成响应时要使用哪个特定的模型。

在这一阶段运行应用程序时，您（或者您的开发人员）将用 LLM 提供商提供的凭证填写这三个值。

应用程序用您的消息进行什么处理

当用户发送消息时，逐步发生了以下事情：

1. 用户在聊天界面中输入消息并点击发送。
2. 浏览器将消息与标识对话的会话 ID 一起发送到 Flask 后端。
3. 后端将消息添加到对话历史中并将所有内容转发给 LLM，前面附加一条系统说明，告诉模型表现得像 TravelBot。
4. LLM 处理完整的对话并生成回复。
5. 回复被送回后端，添加到对话历史中，并返回给用户的浏览器。
6. 用户在聊天界面中看到响应。

目前尚未发生的

在此阶段，应用程序已经完全功能正常，但完全未被保护。 这意味着：

• 用户发送给模型的内容没有经过任何检查。
• 对于工具调用和响应，没有检查。
• 没有政策执行—任何消息，包括恶意消息，都能到达 LLM。
• 没有看到应用程序是如何被使用的可见性。

例如，用户可以试图操纵模型忽视其指令、提取敏感信息或以违反您组织策略的方式使用应用程序，而这一切都不会被检测到或阻止。

这正是下一个阶段要解决的空白。

概要

阶段 2 — 引入保护措施

本阶段涵盖的内容

在阶段 1 中，我们建立了一个与 LLM 直接通信的工作型 AI 应用程序。 应用程序可以工作，但在用户和模型之间没有任何东西。 在此阶段，我们引入了一个 Cato AI 安全守护——位于应用程序和 LLM 之间的执行层，在流量到达模型之前，以及响应返回给用户之前实时检查流量。

到阶段结束时，所有的LLM通信、用户信息、工具定义、工具使用等，都会经过Cato。 用户体验保持一致——但现在每次交互都会被检查并可被控制。

更新的流程如下所示：

什么是守护？

守护是 AI 安全的执行点。 在这个示例中，使用代理模式作为中介，位于应用程序和LLM之间，并根据您定义的策略评估每个提示和响应。 基于那些政策，守护可以允许、阻止或记录一次互动的内容。

守护有三种类型。 在本指南中，我们使用代理守护。 在代理模式中，守护完全集成在流量路径中。 您的应用程序不再直接发送请求到 LLM，而是发送到守护的端点，经过检查后守护会转发。 不需要更改您的应用程序逻辑——只需更改目标地址。

步骤 1 — 在 Cato 管理应用程序中创建守护

第一步是在 Cato 管理应用程序中创建守护作为一个逻辑实体。 此过程在 UI 中完成——此时无需代码。

1. 从导航菜单中，选择 AI 安全 > 守护，然后点击 新建。
2. 输入描述性 守护名称。 在我们的示例中，我们使用了 E2E 示例用例。
3. 在 选择守护类型 下，选择 代理。
4. 在 选择 AI 服务 下，从下拉菜单中选择 自定义端点。 此选项适用于任何 OpenAI 兼容的端点，这就是我们的应用程序所使用的。
5. 在 端点 URL 字段中，输入您的 LLM 提供商的 URL。 在我们的示例中，这个 URL 是 https://bedrock-mantle.eu-north-1.api.aws/v1。 这与之前在 config.py 中设置为 BASE_URL 的 URL 是同一个——您现在将这个地址交给守护，而不是直接在您的应用程序中使用。
   注意： 网址必须包含到/v1路径。
6. 在 配置守护设置 下，将 守护的主机 保持为 Cato的云。 这意味着守护由Cato管理和托管——您无需部署或维护任何其他基础设施。
7. 点击 保存。

刚刚发生了什么？ 您已经创建了一个知道 LLM 所在位置的守护。 Cato 现在将作为您的应用程序与 LLM 之间所有流量的中介。 守护当前还没有任何政策规则——我们将在阶段 3 中添加这些规则。 目前，我们只是建立连接并验证流量是否仍然正常工作。

步骤 2 — 检索守护的连接详细信息

一旦守护被保存，从守护页打开它并导航到守护的 文档 页面，该页面提供了应用程序需要的一切用以连接到守护，而不是直接连接 LLM。

在这里，您会发现两个关键信息：

• 守护端点（您的新 BASE_URL）— 这是您的应用程序现在发送请求的地址：https://api.aisec.catonetworks.com/fw/v1/proxy/openai

  • 这替换了您配置中的LLM端点 URL。 从现在起，您的应用程序与 Cato 通信，而 Cato 代表您与 LLM 通信。

• 守护 API 密钥（您的新 OPENAI_API_KEY）

  • 文档页面还提供一个 守护 API 密钥——您的应用程序用于与守护认证的凭证。 这替换了之前在您的配置中的 LLM API 密钥。 它看起来像这样：cato-1234-abcde

注意：Cato 提供两个守护 API 密钥。 您只需一个即可提出请求。 存在第二个密钥，以便您可以安全地更换凭证—您可以将应用程序升级为使用新密钥，同时旧密钥仍然活跃，从而避免任何停机时间。

LLM API 密钥

以前，LLM API 密钥保存在您应用程序的配置中。 在守护到位的情况下，该密钥被放置在您的应用程序发送给守护的请求头中——特别是在名为 x-cato-provider-api-key 的头中。 守护用这个来代表您的应用程序在 LLM 认证。

这实际上是一项安全改进：LLM API 密钥不再硬编码在配置文件中，守护充当了该凭证的受控传输通道。

步骤 3 — 更新应用程序配置

现在守护已创建并且您已掌握其连接详细信息，是时候更新应用程序了。 为了保持阶段 1 和阶段 2 清晰分开，我们创建了一组新的配置文件，而不是覆盖原始文件。 这样做，两阶段均保持完好以供参考。

新配置文件 config_stage2.py，反映了更新的连接细节：

# 阶段 2 配置 — 通过 Cato 代理守护路由

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]" # 您的 LLM 提供商 API 密钥—传递给守护，而不是直接给 LLM

SYSTEM_PROMPT = (
 "你是TravelBot，一个友好且知识渊博的旅行助手。"
 "帮助用户发现目的地、计划行程、推荐酒店，"
 "并分享实际的旅行提示。保持回复简洁并富有热情。"
 "如果问题与旅行无关，请礼貌地引导对话。"
)

MAX_TOKENS = 1024

与阶段 1 的关键区别：

步骤 4 — 更新客户端代码

客户端代码也有相应的阶段 2 版本—bedrock_client_stage2.py。 逻辑基本上与阶段 1 相同，增加了两点：

1. 守护 API 密钥用于认证与守护的连接（在 Authorization 标头中）。
2. LLM API 密钥作为一个额外的头部传递（x-cato-provider-api-key），以便守护程序可以将其转发给 LLM。
3. 会话ID被作为头部传递（x-cato-session-id），以便守护程序可以将同一对话中的请求分组——这直接映射到应用程序逻辑中已存在的session_id。

# bedrock_client_stage2.py

从 openai 导入 OpenAI
从 config_stage2 导入 GUARD_API_KEY、BASE_URL、MODEL_ID、LLM_PROVIDER_API_KEY、SYSTEM_PROMPT、MAX_TOKENS


类 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,
 }
 )
 return self._client

 def invoke(self, messages: 列表[字典], session_id: 字符串 = "") -> 字符串:
 all_messages = [{"角色": "系统", "内容": SYSTEM_PROMPT}] + messages

 response = self._get_client().chat.completions.create(
 model=MODEL_ID,
 messages=all_messages,
 max_tokens=MAX_TOKENS,
 extra_headers={
 "x-cato-session-id": session_id,
 }
 )

 return response.choices[0].message.content

验证流程

更新的配置和客户端文件就位后，从用户的角度来看，应用程序应该与阶段 1 完全相同。 TravelBot的响应旅行问题的方式相同——但现在每次交互都通过了守护程序。

此时，守护程序尚未配置任何策略规则，因此并未阻止或修改任何流量。 然而，它正在记录每一次交互。 您可以通过打开 Cato 管理应用程序中的守护程序并查看 Guard 日志 页面来验证这一点，在应用程序使用时会话会出现。

这证实了集成工作正常且守护程序正在接收到流量。

从阶段 1 到阶段 2 的变更摘要

阶段 3 — 配置策略规则

本阶段涵盖的内容

在阶段 2 中，我们引入了守护程序并验证了流量正在正确通过它。 守护程序是活跃的，但尚未执行任何规则——它正在观察流量而不对其采取行动。 在本阶段中，我们配置 守护交互策略：这是指示守护程序在检测到特定类型的内容时的处理规则集。

到本阶段结束时，守护程序将对实时流量主动执行两条规则：

• 阻止和匿名任何包含PII或密码的信息交互。
• 监控任何涉及医疗建议或健康相关数据的交互

注意： 我们建议你先通过设置监控来测试规则，在确认检测效果后再将其设置为阻止。

什么是守护交互策略？

守护交互策略是您AI安全守护程序的规则基础。 可以将其视为 AI 流量的防火墙——它不是检查网络数据包，而是检查 AI 交互的内容，并在找到匹配项时应用您定义的操作。

策略中的每条规则指明：

• 适用于哪个守护的规则
• 要查找的内容—由引擎配置文件定义，指检测类别（例如越狱尝试、PII或医疗数据）
• 找到匹配时要做什么—阻止、监控、匿名化和阻止或匿名化和监控
• 检查流量的哪个方向—来自用户的传入消息、来自助理的响应、工具输入或工具输出

需要注意的重要行为：守护交互策略中的规则不论在规则基础中的位置如何都会被评估。 例如，如果一条规则要求监控而另一条规则要求阻止，则阻止操作优先。 例如，如果一条规则说明监控而另一条规则说明阻止，则应用阻止操作。

步骤 1 — 创建规则 1：阻止越狱尝试

我们创建的第一条规则针对越狱尝试——用户故意操纵模型以忽略其指令或绕过其保护措施的努力。 对于像 TravelBot 这样的面向客户的应用程序，这是一种有意义的风险：用户可能尝试迫使模型表现出其定义角色之外的行为或暴露不应有的信息。

要开始，请导航到守护策略页面。 您可以从主导航菜单通过选择 AI 安全 > 守护交互策略 执行此操作，或直接从守护的 概览 页面点击 管理策略 在活动规则部分下。

从守护策略页面，点击 新建 打开规则编辑器，然后配置以下内容：

常规

• 名称：阻止一些流量
• 描述: 这会阻止来自我们旅行机器人越狱的流量
• 保持 已启用 开关打开

守护

• 选择 E2E 样例使用案例—这将该规则范围锁定到我们的特定守护，不会影响帐户中的其他守护

引擎配置文件

• 选择敏感标识符—这是用于检测提示注入尝试、越狱模式，以及从模型中提取秘密或凭据尝试的检测类别。

动作

• 选择匿名化和阻止—当防护检测到匹配时，它会匿名化交互中任何敏感数据，并彻底阻止提示到达LLM。

方向

• 勾选用户和工具输入——该规则适用于来自用户的内容和来自任何工具输入的内容。 来自助理的响应和工具输出不在该规则的范围内。

点击 保存。 该规则被保存到一个未发布的修订版，不会影响实时流量。

步骤 2 — 创建规则 2：监控医疗内容

第二个规则采用不同的方法。 与其阻止流量，不如允许交互进行，同时标注以供审查。 这适用于不一定是恶意，但可能需要可见性的内容——在这种情况下，涉及医疗建议或健康相关数据的交互。

对于 TravelBot，用户询问有关医疗旅行建议（如疫苗接种要求或目的地健康预防措施）并非本质上有害，但这是您的组织可能希望跟踪以确保合规或质量用途的内容。

从守护策略页面，再次单击 新建 并配置以下内容：

• 常规
  • 名称：监控潜在有害数据
  • 描述：这允许通信通过，但监控交互
    保持 已启用 开关打开

守护

• 选择 E2E 样例使用案例

引擎配置文件

• 选择健康数据外泄—这检测涉及医学指导、健康数据或临床信息的交互。

操作

• 选择匿名化和监控—允许交互通过LLM，响应正常返回给用户。 任何个性化信息都已匿名化，以保护个人详细信息。 该交互在 Cato 中记录以供审查。

方向

• 检查所有四个方向：用户、助理、工具输入和工具输出——此规则监控每个方向的流量，让您充分了解对话双方

点击 保存。

步骤 3 — 发表策略

保存两个规则后，守护策略页面将在右上角显示 未发布修订版 状态和 发布 (2) 按钮，表明有两个规则可以上线。

重要事项： 在您发布之前，活动策略是未更改的。 您的规则处于草稿状态，不会对实时流量执行。 这为您提供了在更改生效之前审查您的更改的机会。

当您准备就绪时，点击 发布 (2)。 两个规则立即生效，守护程序开始在所有传入流量上执行它们。

守护程序现在做什么

随着两个规则的发布，通过E2E 样例使用案例守护的每个交互现在都根据策略进行评估。 以下是实践中的实际情况：

用户向 TravelBot 发送消息。 在消息到达 LLM 之前，守护程序会根据两个规则检查它：

• 如果消息包含越狱模式或试图提取机密，守护程序会匿名化并阻止它。 LLM从未看到该消息，用户收到被阻止的响应。
• 如果消息包含医疗建议或健康相关内容，守护程序允许它通过但记录交互以供审查。
• 如果消息不符合任何规则，则无影响地传递给 LLM。

同样的评估适用于助理的响应、工具输入和工具输出，具体取决于为每条规则配置的方向。

验证规则是否处于活动状态

要确认规则的活动状态及其是否应用于您的守护程序，请导航到守护的概览页面。 在活动规则下，您现在应该看到列出了两个规则。 随着流量通过守护并发生检测，交互随时间变化图表和违规拆分面板将开始填充。

您还可以导航到守护日志记录以查看单个会话，查看触发的规则，并检查标记交互的详细信息——前提是您有必要的权限查看敏感内容。

概要

在这两条规则下，现在应用程序具有活动安全性执行。 恶意提示尝试在到达模型之前被阻止，敏感的健康相关交互对您的安全团队可见——所有这些不会对应用程序代码进行任何更改或对合法交互的最终用户体验产生任何影响。

这完成了使用 Cato AI 安全守护程序保护定制AI应用程序的端到端指南。