AI 安全领域典型的安全风险原理：出问题的地方多半不在模型本身

搜「ai安全领域典型的安全风险原理」的人，通常已经在踩坑了：输出被带跑、数据发错了地方、Key 用着用着不对。这些事看着都像模型不听话，实际成因分散在输入、权限、数据和运维四层。这篇不堆名词，先把每类风险的触发原理讲透，再给一张能照着走的对照表和排查顺序。

搜这个词的人，多半已经在踩坑了：输出被网页内容带跑、附件不知道发去了哪、Key 用着用着账单不对。第一反应往往是「模型不听话」，但把日志摊开看，问题经常出在你自己的拼装和权限上。

这篇按输入、数据、权限、运维四层拆开讲成因，每层给一个能马上用的判断标准。先记住一句话：模型不记事、不存状态，它只是照着上下文往下写。真正决定安全边界的，是你喂了什么、给了多大权限、留下了什么痕迹。

先纠一个误判：很多「安全事件」不是模型被攻破

换模型这个动作很好用。遇到一次奇怪的输出，先假设明天换成另一家的模型，同样的问题还会不会出现。会，那基本和模型无关，是你这条链路上的某个环节漏了。模型厂商迭代的是能力，不是替你兜流程的底。

实际排查时我见过一种典型误判：团队把「客服机器人答了不该答的话」直接归因于模型对齐不足，结果一看系统提示词，把整份内部 FAQ 原文粘进去了，里面本来就有不该对外的表述。模型只是老老实实复述。

输入层：提示词注入和越狱靠的是同一条缝

这条缝叫「指令与数据不分」。模型看到的是连续文本，它没有天然的语法去区分「这是我要执行的命令」和「这是我该阅读的材料」。所以网页正文、PDF 页脚、检索回来的文档片段，只要被拼进上下文，就都有机会被当成命令执行。

越狱和注入经常被混着说，但防护思路不一样。越狱是用户自己想绕限制，靠策略约束和输出过滤能挡一部分；注入是第三方内容偷偷夹带指令，用户自己都不知道，得靠隔离和来源标注。

• 外部内容永远不要和系统提示词拼在同一段，中间加明确的分隔标记
• 检索片段进上下文前，标注来源和「这是资料不是指令」
• 敏感动作前加一次意图确认，不让模型单方面决定执行
• 纯人工对话、不接外部文档也不调工具的场景，这层风险会小很多，不必过度设计

数据层：发出去的那一刻风险就已经转移了

很多人以为风险点在「发请求」这个动作，其实点下去就结束了，后面你控制不了。链路要自己走一遍：提示词、附件、检索片段、请求日志、响应缓存，每一环都可能落到你看不见的地方。中转站和自建网关的差别，也主要落在这些环节上。

判断顺序建议从「谁最不需要看见」开始，而不是从「哪些字段可以脱敏」开始。先删硬密钥、个人身份信息、内部编号，再谈语义层面的脱敏。顺序反了，容易删了一堆字段，核心意思还在。

权限层：工具调用把「说错话」变成「做错事」

纯文本应用里，注入成功最多让模型说一段错话。一旦接了工具，同样的注入就可能变成改文件、发请求、读数据库。危害性质变了，防护也得跟着变，光靠提示词里写「不要执行危险操作」是不够的。

1. 列出可触碰资源把这个 Agent 能访问的文件目录、接口、数据表全列出来，别凭印象写，按配置一份份抄。
2. 逐个降权对每一项问「它真的需要写权限吗」。大多数问答类场景只需要读，写权限能砍就砍。
3. 设人工确认点批量删除、对外发送、金额相关操作，一律插一步人工确认，不做自动放行。
4. 验证兜底故意构造一段带指令的外部内容喂进去，看它会不会触发工具调用。触发不了才算这层做完了。

只读型问答、没有工具接口的应用，这层可以少花力气。但一旦接上写操作，就得按上面的顺序做一遍，别跳步。

运维层：日志、Key 和异常调用才是长期隐患

前面几层是单次请求的事，运维层是时间累积出来的。Key 外泄、多人共享同一个 Key、图省事写进公开仓库的配置文件，后果从账单异常一路延伸到数据外流。这类事不发生则已，一发生往往已经持续了一阵。

日志是双刃剑。排查要靠它，留存和脱敏没做好，它本身就是新的泄露面。我的建议是给关键调用留可追溯记录，同时明确哪些字段禁止落库，两件事同时做，别只做一半。

可追溯

每次调用能对上是哪个 Key、哪个应用、什么时间发起的

可回答

能当场说清上周某天谁用某个 Key 调了什么，答不上来就是可观测性不足

可止损

发现异常调用后，能不能立刻吊销单个 Key 而不影响其他业务

顺带提一句，做中转站选型时，Key 是怎么管的、日志留多久，这两件事比价格更值得先问清楚。价格可以到 核对当时的数字，但账号和日志策略得单独问。