先承认现实：LLM 系统的风险主要来自“会动手”
纯聊天的风险有限；一旦你接了工具、接了外部系统、能写入数据，风险会急剧上升。
这篇只讲“工程上能落地的护栏”，不讲口号。
威胁模型：先列出你可能遇到的 6 类风险
- 越权：模型调用了不该调用的工具或资源
- 提示注入：外部内容（网页、文档、issue）诱导模型执行危险动作
- 数据泄漏：把 token、密钥、内部数据输出到外部
- 误写入：把错误内容写入外部系统（评论、工单、数据库）
- 资源滥用：无限循环调用导致成本爆炸（DoS 式成本）
- 供应链风险：工具/依赖/插件引入不可信行为
工具层防线 1：最小权限 + 读写分离
最有效的护栏往往不是“更聪明的提示词”，而是更硬的权限控制：
- 读工具与写工具拆分
- 写工具默认需要人类确认点
- 对资源做白名单（repo、db schema、namespace）
工具层防线 2：强校验与拒绝未知字段
防注入与防幻觉参数的基础是强校验：
- schema 严格，拒绝
additionalProperties - 输入长度与内容限制（例如禁止把“密钥”作为普通字段传入）
- 重要字段要白名单（repo 列表、允许的表名）
工具层防线 3：敏感数据脱敏与最小化回传
工具返回给模型的数据要“最小化”：
- 只回传需要的字段
- 对密钥、token、个人信息做脱敏
- 对日志/文档只回传相关片段（避免全量泄漏）
人类确认点：把“危险动作”做成显式步骤
强烈建议对以下动作设置确认点：
- 对外写入（评论、邮件、消息、工单、PR）
- 对内写入（数据库、配置、发布）
- 成本超过阈值（预计 N 次调用或预计金额）
- 置信度不足（证据不足、引用不足）
确认点不是让模型“自我确认”，而是把操作内容展示给人或系统规则审核。
注入防护：把外部内容当成不可信输入
当你把网页/issue/文档作为上下文时，必须假设它包含注入指令。
工程上你至少要做：
- 明确分区：把“外部内容”标记为 data，而不是 instruction
- 只提取结构化事实（标题、作者、时间、关键段落）
- 对外部内容不直接执行写操作，必须经过确认点
动手做：一个可落地的“护栏清单”
你可以把下面清单贴到你的 Skill 评审流程里：
- 工具是否读写分离？写工具是否有人类确认点？
- schema 是否严格？是否拒绝未知字段？
- 是否有资源白名单？是否限制表/仓库/namespace？
- 工具返回是否最小化？是否脱敏？
- 是否有预算上限与停止条件？
- 是否记录审计日志（谁、何时、做了什么）？
常见坑
- 只靠 prompt 做安全：很快会被绕过
- 把密钥放进上下文：等于主动泄漏
- 写操作无确认点：迟早会写错并造成不可逆影响
至此，12 篇主线完成。接下来你可以读扩展篇：模板库、框架选型、RAG 模块、成本治理。