企业级 AI Agent 的护栏
大多数关于 AI 护栏的建议听起来都像是在推销。它们专注于花哨的图表和清单。
真正的生产环境安全并不那么光鲜亮丽。它依赖于在 LLM 出现之前就已存在的技术。
我曾为一家财富 100 强公司构建 AI Agent 长达两年。这些 Agent 处理 CI/CD 故障、Kubernetes 事件以及基础设施文档。
以下是我们用来确保它们安全的层级化技术栈。
Agent 边界的身份验证。每个 Agent 都使用工作负载身份（workload identity）。绝不使用共享凭据。IAM 权限范围是你的安全上限。如果 Agent 不需要数据库访问权限，那么其 IAM 角色绝不能拥有该权限。这是你最重要的控制手段。
工具白名单。平台决定 Agent 可以使用哪些工具。一个代码搜索 Agent 不应该拥有邮件工具。我们为此使用静态配置。我们绝不使用动态工具注册。
网络出站控制。Agent 只能访问白名单中的端点。我们使用 DNS 过滤和出站代理（egress proxy）。这可以防止模型幻觉访问错误的 URL。
密钥隔离。Agent 绝不会看到原始密钥。我们使用在工具调用期间注入的短期会话令牌（session tokens）。永远不要在提示词（prompt）中放入密钥。提示词中的任何内容都可能被记录或重放。
完整的审计追踪。你必须记录每一次模型调用和每一次工具调用。这包括输入、输出、工具参数和用户身份。你需要这些信息来了解在发生事件时哪里出了问题。
人工审批。对于任何会更改记录系统（system of record）的操作，平台必须暂停。必须由人工审批该操作。这是你的安全网。
避免这些常见错误：
提示词层级的指令。告诉模型“永远不要做 X”并不是安全手段。用户可以诱导模型。应将控制权移至 IAM 或工具层。
通用的 PII 过滤器。这些过滤器的错误率很高。更好的做法是通过 IAM 限制数据访问，从而让 Agent 根本看不到敏感信息。
护栏模型。使用第二个 LLM 来给第一个 LLM 打分会增加延迟。这并不是真正的安全控制，而仅仅是模型集成（model ensemble）。
我通过惨痛教训学到的经验：
先修复 IAM，再优化提示词。我曾浪费时间在调整提示词上，而实际上我应该去收紧 IAM 角色。尽可能将控制权下移到技术栈的底层。
构建更完善的审计追踪。仅仅记录提示词（prompt）和回答是不够的。你还需要记录中间的工具调用（tool calls）及其参数。早期记录的成本很低，但后期修复的成本很高。
限制智能体通信。在多智能体系统中，为智能体之间的调用设置硬上限。这可以防止级联故障。
大规模 AI 安全并非模型问题，而是一个平台问题。请像对待其他任何生产系统一样，以同样的运维纪律来对待你的智能体。
可选学习社区：https://t.me/GyaanSetuAi