AI 安全护栏：Prompt 规则不是最后一道防线
AI 安全护栏：Prompt 规则不是最后一道防线
一、只靠 Prompt 很脆
AI 应用上线后，安全问题会变得非常现实：越权查询、敏感信息泄露、工具误调用、提示词注入、恶意内容生成。很多团队会在系统提示词里写一堆规则，希望模型自觉遵守——"不要回答政治敏感问题""不要泄露用户隐私""不要调用删除接口"。Prompt 有用，但它不是最后一道防线。
模型的本质是统计预测下一个 token，它不理解"规则"，只理解"什么序列在这个上下文中更可能"。攻击者可以通过精心构造的输入绕过 prompt 规则，或者通过多轮对话逐步突破限制。我亲眼见过一个案例：系统 prompt 里明确写了"不要透露任何内部系统信息"，但攻击者用了五轮对话逐步引导，模型最终在第六轮回答了"我们的后端用的是 Kubernetes 1.28，数据库是 PostgreSQL 15"。Prompt 没有失效，是模型被绕过了。
安全护栏要放在模型外面，用代码逻辑、策略配置和审计记录共同兜住。模型说什么只是建议，系统的安全决策必须由系统自己做出。这就像飞机的自动驾驶和人工干预——自动驾驶可以提建议，但最终执行权在机长手里。
二、护栏要分层防御
flowchart TD A[用户输入] --> B[输入检测] B -->|通过| C[权限校验] C -->|通过| D[模型生成] D --> E[工具调用校验] E -->|通过| F[输出审查] F -->|通过| G[审计记录] B -->|拦截| H[安全拒绝] C -->|拦截| H E -->|拦截| H F -->|拦截| H输入检测负责识别注入和明显越权意图，权限校验负责确保用户只能访问属于自己的资源，工具调用校验负责确保模型生成的函数调用是合法的（正确的函数名、参数范围在允许值内），输出审查负责防止敏感信息从回答中泄露。四层之间不互相替代，任何一层触发拦截都应该终止请求。
ai_safety_layers: input_guard: true # 输入检测：注入、敏感词、越权意图 tool_policy: true # 工具调用校验：白名单、参数范围、资源归属 output_filter: true # 输出审查：脱敏、合规、引用校验 audit_log: true # 审计记录：全量可追溯每层都要能独立拒绝请求，不要只把规则塞给模型。输入检测里可以做注入识别——不只是简单关键词匹配，还要检查用户输入是否试图覆盖 system prompt（如"ignore previous instructions"句式），是否包含明显的 prompt injection 模式。对于已知攻击模式可以用规则拦截，未知模式用另一个轻量分类模型做检测。
三、工具调用必须独立授权
模型生成的工具调用只是建议，不能直接执行。函数名、参数值、资源范围、用户身份都要由后端校验。
type ToolCall struct { Name string Args map[string]any UserID string TenantID string } func AuthorizeTool(call ToolCall) error { // 1. 工具白名单：这个用户/租户能调用这个工具吗？ if !toolWhitelist.Contains(call.TenantID, call.Name) { return ErrToolNotAllowed } // 2. 参数校验：参数类型和范围合法吗？ if err := validateToolArgs(call.Name, call.Args); err != nil { return fmt.Errorf("tool args invalid: %w", err) } // 3. 资源归属：操作的资源属于这个用户吗？ if resourceID, ok := call.Args["resource_id"]; ok { if !userOwnsResource(call.UserID, resourceID) { return ErrResourceNotOwned } } return nil }删除、付款、发消息、修改配置这类高风险操作，必须有明确的授权流程和审计记录。对于删除这类不可逆操作，除了权限校验之外，还应该加入二次确认——由用户显示确认而非模型代为确认。
工具调用的返回结果如果包含敏感字段，也不应该原样塞回模型上下文。模型看到了，就可能在后续回答中泄露出去。可以在工具返回和模型上下文之间加一层过滤器，按字段级别的敏感程度做脱敏。比如工具返回{"user_email": "zhang@example.com", "order_amount": 1000}，脱敏后只传给模型{"user_email": "z***@example.com", "order_amount": 1000}。
还要防止工具被间接调用——攻击者可以通过多轮对话引导 Agent 调用不该调的工具。这种攻击不直接写"调用删除接口"，而是说"帮我清理不再需要的文件"让 Agent 自行推理出删除操作。工具白名单和风险等级要结合任务类型判断，而不只是看工具名。
四、输出也要能拦截
输出审查不只是做内容安全关键词过滤。还要检查：是否暴露了内部系统信息（错误堆栈、内网 IP、数据库表名），是否包含了用户无权查看的引用内容，是否在"无证据"的情况下仍然生成了看似可信的结论。
output_guard: mask_secrets: true # 脱敏密钥/Token block_internal_error: true # 不暴露错误细节 verify_citations_acl: true # 引用的文档用户有权查看 require_safe_fallback: true # 拦截后返回安全降级话术 audit_full_response: true # 完整记录原始输出被拦截后，返回给用户的应该是安全降级话术，而不是把拦截器的内部错误暴露出去。可以说"当前问题缺少可用证据"或"没有权限访问相关信息"。安全策略也要做回归测试——用提示词注入样本、越权请求、敏感字段、恶意工具参数构造测试集，每次模型或 prompt 更新都跑一遍。安全护栏如果没有回归测试，很快会被功能迭代悄悄绕开。
高风险场景还要支持灰度——新规则先观察命中样本再逐步加强拦截，避免误杀正常用户。一个安全规则第一天可能只记录不拦截，确认无误杀后再升级为拦截模式。
输出审查还要注意时间窗口。某些信息在请求时是敏感的，但过一段时间后可能已经公开——比如已发布的公关稿件、已更新的产品版本说明。输出审查不应该用过期策略拒绝合规内容。
最后，审计要完整。谁问了什么、模型想调用什么工具、策略为什么拒绝、最终返回了什么，都要能查。安全问题发生后，没有审计就只能靠猜。
安全护栏还要支持分级处置。轻微风险可以要求模型改写，高风险直接拒绝，疑似攻击可以提高审计级别或触发风控。所有问题都用同一种拒绝话术，会让用户体验和安全响应都变差。
safety_action: low_risk: rewrite # 让模型改写安全版本 medium_risk: ask_clarification # 追问用户意图 high_risk: block # 直接拒绝 suspected_attack: alert # 告警并提升审计级别还要给安全策略做灰度。过滤规则过严会误伤正常用户，过松会漏掉风险。新规则先观察命中样本，再逐步进入强拦截，更适合真实业务。安全护栏的最终目标不是"拒绝一切风险"，而是"让风险可控、可审计、可改进"。
五、总结
AI 安全护栏要分成输入检测、权限校验、工具授权、输出审查和审计记录多层。每层用代码逻辑独立判断，不把安全决策委托给模型。Prompt 规则只是提示，不是防火墙。真正上生产的 AI 应用，安全边界必须放在模型外面。模型可以犯错误，系统不能没有防线。