Agent 安全要在工具执行前设防

Agent 一旦能查数据库、读工单、调用工具，安全问题就从「回答是否靠谱」变成了「它究竟有权做什么」。原文的核心主张很明确：把模型视为不可信组件，在工具执行前实施权限检查，再用运行监控记录和发现异常。

这篇适合正在给 AI 接业务系统的开发者读。它给出了一套清晰的控制顺序，但没有攻击实测或产品对照数据。其中，权限校验的时机、SQL 参数化的作用，还需要分清边界。

工单里的一句话，为什么可能变成数据库操作

原文设想了一个客服 Agent：它能访问工单系统，也能调用数据库查询工具，后者直接接收 SQL 字符串。攻击者在工单中写入提示注入（prompt injection），要求忽略先前指令并执行 SELECT * FROM users。如果 Agent 照做，工具又没有权限和参数检查，恶意文本就可能变成实际查询。

问题出在一条信任链上：工单内容原本只是待处理数据，却被模型当作行动指令；模型生成的工具调用，又被执行系统当作可信请求。

原文还指出了两个扩大风险的条件：Agent 同时连接多个系统，一处受污染的输入可能影响另一处操作；系统没有监控异常查询，即使访问范围突然扩大，也没人及时发现。

这是一个攻击路径示例。作者没有提供真实事故记录、复现过程或攻击成功率，不能把它读成已经完成验证的实验结论。

权限检查应该放在工具真正执行之前

模型可以提出操作请求，执行系统必须独立决定是否放行。

原文建议把控制点放在 Agent 与工具之间，每次调用依次完成：

1. 验证 Agent 身份及其对应的用户上下文。
2. 根据策略检查具体操作是否获准。
3. 校验参数，使用允许列表或参数化查询等约束。
4. 记录调用参数及放行、拒绝的决定。

最小权限也要落实到每个工具和数据源，不能只写一句「允许访问数据库」。调用什么工具、执行什么操作、在什么条件下允许，都需要有明确策略。

这里原文有一句表述容易误导：它把「模型决定调用哪个工具之后才授权」描述成模型在选择自己的权限。准确的分界其实是执行时机。模型先提出工具调用，再由外部系统鉴权，完全可以构成有效控制；危险的是未经授权就执行，或直接相信模型自报的权限。

SQL 参数化也有边界。它能约束参数如何进入查询，却不能自动判断用户有没有资格读取 users。如果工具仍接受任意完整 SQL，仅靠「使用参数化查询」这句原则，还不足以解决示例中的越权读取。

监控负责发现异常，不能代替拦截

原文要求记录每次工具调用，包括用户上下文、参数和权限决策，并监控异常操作序列、访问范围变化、读取量突然增加，以及访问敏感表等行为。

权限控制处理的是「这次操作能不能执行」，监控补充回答「这一连串操作是否反常」。单独记录日志不会阻止查询，但能提供调查证据，并触发自动响应。

作者随后介绍了 RESK 的两个产品：reskSecure 位于 Agent 与工具之间，根据策略实施最小权限，在执行前阻止未授权调用；ReskPoints 记录工具调用、参数和决策，并支持异常告警。

这些属于原文给出的产品能力描述。文章没有展示接入代码、策略样例、拦截效果或性能开销，也没有说明异常检测如何建立正常行为基线。

我的判断

我认同把权限控制移出模型的方向。提示词可以帮助模型理解任务，但业务权限需要由独立的执行机制落实。对于已经能操作业务系统的 Agent，这个边界比再加几句「不要泄露数据」更具体。

不过，原文更接近安全设计清单加产品介绍。它没有证明 reskSecure 和 ReskPoints 比已有网关、业务鉴权或审计系统更有效，也没有给出误报率、漏报率和接入成本。选产品前，仍需要检查它是否覆盖实际工具链，以及能否表达业务需要的权限。

日志也有取舍。完整参数有助于排查问题，却可能包含敏感信息。原文没有交代脱敏、保存期限和日志访问权限，落地时需要补齐这些设计。

能拿来做什么

• 给 Node 服务中的 Agent 工具统一设置执行入口，在真正调用业务接口前检查用户身份、Agent 身份、操作权限和参数，避免各工具遗漏检查。
• 给数据库工具收紧输入范围，优先提供明确用途的查询操作；即使使用参数化查询，也要单独检查读取范围是否获准。
• 为工具调用记录用户上下文、权限决策和必要参数，对敏感值脱敏，并为读取量激增、敏感表访问和跨系统异常调用设置告警。
• 每次给 Agent 增加工具或数据源，都同步复查权限策略和监控规则，避免能力不断增加，控制仍停留在最初版本。