很多人问「AI安全风险有哪些」，得到的大多是从模型本身讲的答案，比如幻觉、越狱、偏见。但如果你的角色是运维、后端或安全负责人，真正会让你半夜被叫起来的是另一类问题：接口被刷、Key 被扒、数据在链路中间被截、第三方依赖偷偷改了行为。这篇按网络安全的视角把风险分类排一遍，每一类给出判断信号和先查什么，不涉及模型能力评价。
很多人搜「AI 安全风险有哪些」，翻出来的答案基本都在讲模型本身：幻觉、越狱、偏见、对齐。这些当然重要，但它们不是运维和后端同学半夜被电话叫起来的原因。真正会把人从床上拽起来的，是接口被人当提款机刷、Key 躺在某个仓库里被扒走、数据在链路中间被截了一道、某个第三方依赖悄悄改了行为而你不自知。
所以这篇换个视角，从网络安全的攻击面出发，把 AI 系统面临的风险按「从哪进来」重新排一遍。每一类都给出判断信号和先查什么，不评价模型能力，也不做绝对化承诺——因为任何一套排查方法都有它不适用的时候，下面会逐条说清楚边界在哪。
先把攻击面画出来：AI 系统比普通 Web 多了哪几块
普通业务系统的入口无非是页面和接口，收住访问控制和参数校验就挡住了大半。AI 系统不一样，它的入口至少多出五块：推理接口、Key 与额度、提示词与上下文、外部工具调用、上游模型服务。风险基本都从这几块进来，而不是从模型权重里长出来。所以第一步不是买工具，是先把这几块在图上标出来。
- 画一张全链路图拿一张纸或画板，从用户输入一路写到模型返回，中间每经过一个组件、一次网络跳转都画上。别嫌土，这一步能暴露八成认知盲区。
- 标出跨信任边界的位置凡是数据从「你控制的」走到「你不完全控制的」地方，都打一个记号。浏览器到你的网关、你到上游模型服务、你到第三方工具，每一处跨边界都是需要单独设防的点。
- 给每个边界配一条验证方式比如网关处看有没有鉴权和限流，上游调用处看有没有加密和凭据隔离，工具调用处看权限是不是最小化。没有验证方式的边界，等于没设防。
凭证与额度类风险：Key 被拿去干什么，你多久能发现
这类风险的表现很有辨识度：额度异常消耗、出现你从没调用过的模型或时段、同一把 Key 从多个地域并发。注意，这些都属于凭证被滥用，不是模型故障，别一上来就去怀疑模型服务商。区分清楚这一点，排查方向能省掉一半时间。
| 观察到的信号 | 更可能的原因 | 先查什么 |
|---|---|---|
| 额度突然升高但业务量没变 | Key 泄露或被人复用 | 该 Key 的调用来源与并发地域 |
| 出现未使用过的模型调用 | 凭证被拿去试别的接口 | Key 的调用日志与权限范围 |
| 同一 Key 多地并发 | 凭证被共享或转卖 | 是否按用途拆开、有无来源绑定 |
| 用量平稳但账单异常 | 计费口径或重复调用 | 调用次数统计与去重逻辑 |
判断标准很简单：如果你从发现异常到能定位出原因，中间超过一小时，那说明日志和告警没留够，而不是运气差。发现得晚不丢人，定位不了才丢人。
可执行的动作有三步：按用途把 Key 拆开，避免一把钥匙开所有门；绑定调用来源，让凭证只在预期的地方可用；设额度上限和告警线，让异常在变成事故之前先响一声。泄露之后的处置顺序可以照着站内 /guides 里的应急流程走，原则层面则去看 Key 安全相关的指南页，这里不重复它们的结论。
传输与中转环节：数据在路上和在别人手里
自己直连官方接口时，风险点主要是传输是否加密、客户端有没有被中间人替换、证书校验有没有被图省事关掉。走第三方中转时，多了一层更现实的问题：对方能不能看到你的请求内容、会不会留存、有没有二次转发给别的上游。这层风险不体现在接口报错上，所以你只能主动去问、去验。
- 确认链路走的是加密通道，且客户端没有关闭证书校验
- 确认对方是否二次转发，转发到了哪一层上游
- 确认日志里有没有落到不该落的字段，尤其是提示词和上下文
- 确认数据留存策略，问清楚留多久、谁能看、怎么删
- 对敏感业务做一次最小化验证：只发必要字段，其余在本地脱敏
什么时候这一节可以简化？完全内网闭环、模型也私有化部署的场景，传输和中转问题基本消失，剩下的主要是出口管控——也就是防内部数据往外走。这时候重点就该从「链路安全」切到「出口审计」。字段该不该发出去的问题，站内 /guides 有专门讲数据边界的页面；链路审计则到 /sites 里找带审计说明的中转服务对照看，这类页面的判断维度比单一指标靠谱。要提具体数字，一律到 /price-watch 核对当时的口径和变化，别记一个旧数就当结论用。
输入驱动类风险：提示词、工具调用与越权
提示词注入和越狱常被混为一谈，其实不是一回事。越狱是用户想让模型说它本来不该说的话，注入更接近传统的外部输入污染：你从网页、文档、邮件里读进来的内容里藏了指令，模型照做了。真正危险的落点不是模型说了什么，而是它去调用了本不该调用的工具，或者把一个动作真的执行了。
- 先看输出能不能影响系统动作如果模型输出只是给人看的文本，影响面有限；如果它能触发下单、发信、改配置、查数据库，风险等级立刻上一个台阶。先判断这一条。
- 再看工具权限是否最小化每个可被模型调用的工具，都应该只拥有完成这件事所需的最小权限。只读的工具别给写权限，查单个库的别给整库权限。这是最有效的一层防护。
- 最后才谈提示词层加固输入过滤、指令隔离、输出校验都值得做，但它们是第三道防线，不是第一道。把顺序搞反了，投入产出比会很难看。
具体原理差异和配置项清单，站内已有文章讲得比较透，这里就不重复了。你只需要记住排查顺序：动作影响面 → 工具权限 → 提示词加固，别倒过来。
依赖与运营环节：最容易漏的一类
上游模型服务、第三方 SDK、插件与工具、以及你自己的发布流程，任何一环发生变更，都可能改变系统行为。这类风险最阴的地方在于它通常不报错：不抛异常、不写错误日志、接口照样返回，只是结果悄悄变差了。你如果只看可用性监控，永远发现不了。
- 版本锁定
- 对关键依赖固定版本，变更时留记录，别让自动升级替你做决定
- 对照测试
- 用同一组固定输入定期跑一遍，观察输出是否漂移，这是发现供应链变更最土但最有效的手段
- 变更记录
- 谁在什么时候动了哪个依赖，要能查得到，出事时这是唯一能回溯的线索
- 误判排除
- 输出变化不等于被攻击，先排除上游正常的版本迭代和参数调整
常见问题
AI 网络安全风险和传统网络安全风险是两回事吗？
不完全是。底层还是那套：身份、权限、传输、日志、依赖。区别在于 AI 系统多了一层「输入会改变系统行为」的特性，所以输入校验和工具调用权限要单独设防，其余部分可以直接沿用你现有的安全基线。
我们只是小团队，接了个第三方接口做功能，需要做这么多吗？
不必全做。优先级排一下：Key 拆分与额度告警、日志里不落敏感字段、确认对方是否留存数据，这三件成本最低、收益最高。其余像工具权限最小化、依赖版本锁定，等你有实际的外发动作或插件集成时再补。
怎么判断一次异常是安全问题还是正常的服务波动？
先看是不是可复现：同一输入重复出现同样异常，偏向安全问题；时好时坏偏向波动。再看范围：只有你能复现偏本地，所有用户都命中偏上游。具体数值别凭记忆，到站内对应的监控与实测页面核对当时的记录。
