LLM 访问控制与监控的实战避坑指南

dev.to · AI#AI安全#LLM#Agent

Editor brief · 编辑速览

文章列出 AI Agent 边界安全的三大高频失误：身份混淆、参数 scope creep、工具权限失控，并给出实际防御顺序。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

团队总会问一个类似的问题：我们已经把 LLM 接入了工具，它跑起来了，上线之前到底还要建什么。这篇文章用具体的顺序和失败模式来回答这个问题，而不是甩出一个成熟度模型。

AI Agent 是一个能够发出动作的模型。模型本身是无状态的文本生成。安全问题始于生成的文本变成工具调用、数据库查询、文件读取或 HTTP 请求的边界处。

这个边界就是你承担风险的地方。模型会根据其上下文生成概率最高的 token 序列，它对你的授权模型没有任何概念。如果你的处理器执行了模型输出的内容，那模型就成了你的授权层——而它根本不是。

三件事反复出问题。

混乱委托（Confused deputy）。 Agent 以托管它的服务的凭证运行。一个只允许读取的用户触发了写入工具。工具看不出区别，因为它看到的身份是服务账号。

通过参数实现权限蔓延（Scope creep through arguments）。 工具被允许了，身份被允许了，但参数没有。一个搜索工具带了一个本不该触及某租户的过滤器。一个文件工具带了一个逃逸出目标目录的路径。

静默成功（Silent success）。 调用被阻止了（或者说应该被阻止），但没有记录原因。几周后没人能区分一次被拒绝的攻击和一次坏的集成，于是控制被移除以让仪表盘变绿。

以上都不需要什么新型漏洞，只需要一次在错误粒度上被授权的工具调用。

把决策放在请求路径中，执行之前，并确保有序。

身份（Identity）。 确认是谁在请求。不是服务账号，而是发起请求的最终用户或工作负载，通过 Agent 传播过来。

工具（Tool）。 这个身份是否被允许调用这个工具。

资源（Resource）。 这个工具对这个身份是否被允许操作这个资源。

参数（Arguments）。 这组具体参数是否在授予的范围内。

任何一步失败，调用就到达不了执行器。顺序很重要：在身份验证之前检查参数意味着你在为一个尚未认证的 actor 验证输入。

监控是同一套决策流，只是写下来。对每次工具调用记录：身份、工具、资源、参数、决策和原因。原因是被团队跳过的部分，也是让日志可用的部分。

假设一个客服 Agent 有工单查询工具和工单更新工具。用户让它总结一个工单。模型为了帮忙，同时也调用了更新工具来添加一条备注。

处理器执行了两个调用。服务账号有写权限。用户没有。提示词里没有任何恶意内容。本可以捕获问题的授权检查从未进入执行路径。

用上面的顺序，步骤二会失败：这个身份不被允许调用更新工具。调用被拒绝，原因被记录，而总结仍然返回。

reskSecure 在工具执行之前强制执行有序决策，所以执行器只看到通过了身份、工具、资源和参数检查的调用。它是强制执行点，不是事后报告的扫描器。

ReskPoints 提供监控侧：带身份、工具、资源、参数、结果和原因的决策流，所以一次拒绝可以明确地显示为拒绝，而不是错误率。

关于权限模型本身，工具权限设计在 AI agent tool permissions 中单独讲解。如果尚未定义每个工具被允许做什么，请先阅读那篇。