LLM 访问控制核心风险：过度授权凭证

问题不在 Prompt

当团队询问实现 LLM 访问控制和监控的最佳实践时，对话通常从提示词注入开始。这是错误的起点。提示词注入只是攻击的载体。真正将其转化为安全事件的，是藏在模型可调用工具背后的、权限过大的凭证。

一个持有长期有效、权限范围广泛的 API Key 的 Agent，不需要被巧妙地欺骗。它只需要来自检索文档、工具响应或用户输入的一条指令，让现有的权限指向错误的资源。随后的调用在网络层是授权通过的，看起来完全正常。这正是它难以被捕捉的原因。

AI Agent 安全实际涵盖什么

AI Agent 安全是一门控制自主或半自主模型驱动进程允许执行哪些操作的学科，并观察它实际做了哪些操作。它涵盖三个层面：

身份。哪个 Agent 在行动，该身份是否与触发它的人类身份区分开。

授权。该身份可以访问哪些工具和范围，按每次请求进行评估。

可观测性。每一次允许和拒绝的记录，关联到身份和请求的操作。

目前大多数部署中，第一层部分实现，第二层和第三层基本没有实现。模型拿到凭证后就被信任会妥善使用它。

攻击面，具体来说

以一个拥有客户记录读取工具的客服 Agent 为例。该工具背后是一个服务账号密钥，对整个客户表具有读取权限。Agent 被指示只能查询当前用户。

现在，一份检索到的文档包含一条指令，要求查询另一个客户并将结果包含在摘要中。Agent 照做了。工具调用成功了。服务账号对该读取操作是有授权的。堆栈中没有任何环节标记它，因为堆栈中没有任何环节在检查意图与范围的匹配性。它只检查密钥是否有效。

这不是理论上的。它是大多数 Agent 集成的默认形态。任何单个注入指令的爆炸半径，等于该工具背后凭证的权限范围。

阻止它的机制

控制应放在请求路径中，在 Agent 和工具之间。不是在 Prompt 中。不是在事后日志审查中。

顺序很重要：

为此请求解析 Agent 身份。不是单独的用户身份。代表用户行事的 Agent 本身就是一个独立的授权主体。

根据该身份的策略，评估请求的工具和请求的范围。默认拒绝。

仅当策略允许时，发放一个短期凭证，仅限该调用使用。

在调用执行前发出事件，记录身份、工具、范围和决策。

执行。发出完成事件。

第四步是团队最容易跳过的一步。执行后记录日志告诉你发生了什么。执行前记录日志则给你一个决策点和审计跟踪，而不是从副作用重构出来的记录。

结果是，单个注入指令只能触及该 Agent 身份在那一刻已被策略允许的范围。最小权限不再是一个愿景，而成为运行时属性。

使用 RESK 实现

reskSecure 是策略和执行所在的地方。你定义 Agent 身份以及每个身份可以访问的工具和范围。策略在每次请求的路径中、在凭证发放之前进行评估。被拒绝的请求永远不会到达工具。

ReskPoints 是决策落地的地方。每一次允许和拒绝都成为关联到 Agent 身份、工具和范围的事件。这让你无需额外接入独立管道，就能获得监控问题的一半答案。你可以看到哪些 Agent 遇到拒绝、哪些范围被请求、以及策略是否过于宽泛。

它们共同覆盖了通常缺失的两半：请求时的执行，以及与身份绑定而非从日志推断的执行记录。

关于工具级视角下权限应如何结构化，请参阅我们关于 AI Agent 工具权限的文章。

为每个 Agent 分配独立身份。不要复用人类凭证或共享服务账号。

默认拒绝。按身份允许特定工具和范围。

按请求评估策略，在路径中，在凭证发放之前。

为单个调用发放短期、窄范围的凭证。

在执行前发出决策事件，而非执行后。

将每一次允许和拒绝记录到 Agent 身份上。

将拒绝视为信号进行审查。拒绝骤增意味着要么是攻击尝试，要么是策略过严。

将允许视为风险进行审查。宽泛的允许就是下一次注入指令的爆炸半径。

Prompt 不是控制点。凭证才是。

有关进一步操作，你可以考虑屏蔽此人或举报滥用。