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: zhangexample.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 应用安全边界必须放在模型外面。模型可以犯错误系统不能没有防线。