Agent安全防线应落在工具调用上

Agent 能读数据库、能发邮件，攻击者就未必需要让它输出违规内容。只要在工单里塞进一段指令，诱导它把查到的数据发往指定地址，数据就可能在最终回复生成之前离开系统。只过滤回答文本，拦不住这条路径。

作者的核心主张是：把安全边界放到工具调用执行之前。每次调用都要对应明确身份，由模型之外的策略层检查权限和参数，并留下可追溯的记录。这套思路值得参考，但文中没有测试数据，后半段还包含 RESK 的产品推介，需要分开看。

为什么一句工单内容能变成数据外发

作者把 Agent 拆成三个部分：模型、可调用的工具，以及调用工具所需的凭据。危险来自三者组合后获得的行动能力。

提示注入（prompt injection）不一定要攻破模型。攻击者只需让模型选中一个已有工具，再让 Agent 使用手里的权限执行。

原文给出的场景是：Agent 可以读工单、查询数据库和发送邮件，共用一份拥有数据库读取权限和邮件发送权限的服务凭据。有人在工单正文里要求它生成摘要，并发给正文中的地址。模型照做，邮件内容却混入了刚从数据库查到的信息。

工单是待处理的数据，却被当成了可以支配工具的指令。与此同时，邮件工具不知道 Agent 正在为哪个用户办事，数据库工具也不知道查询结果即将被发到外部。

攻击者借用的是 Agent 已有的权限，最终回复是否安全并不能证明执行过程安全。

作者认为，这种路径也适用于代码执行、文件读取，以及能访问外部端点的工具。不过，文中没有提供具体事件、攻击样本或复现实验，不能把这个示例当作已经验证过的案例。

每次调用都要回答：替谁做，允许做什么

作者提出的控制位置很明确：模型先提出工具调用，策略层检查通过后，工具才执行。

策略层首先解析主体（principal），也就是这次行动代表的具体用户或服务身份。Agent 不能只凭一个笼统的自身身份行事。解析不出主体，就默认拒绝。

接下来检查工具权限。凭据应该按当前任务收缩，而不是覆盖 Agent 将来可能承担的所有工作。一个只要求生成摘要的任务，不需要邮件发送权限；不能因为系统另有发邮件功能，就让每次摘要任务都带着这项能力。

权限还要细到参数。直接禁用邮件工具容易损伤正常功能，而检查收件人是否属于当前用户所在域，可以保留部分发送能力，同时阻止示例中的外部地址。

这里的参数感知策略（argument-aware policy），就是不仅看「能不能发邮件」，还看「这封邮件发给谁」。工具能访问外部端点时，这类检查尤其关键。

模型负责提出调用，权限由模型之外的代码决定。

原文要求授权作为模型与工具之间的前置关卡，不能等工具开始执行后再补审计。至于策略怎样编写、身份怎样传递、凭据怎样按任务缩小，作者没有给出实现细节。

日志要记录执行决定，不能只存聊天记录

只有最终回复，无法回答几个关键问题：哪个用户触发了数据库查询？邮件发给了谁？哪些调用被拦截？当时传入了什么参数？

作者要求每次调用都记录主体、工具、参数和授权决定，允许与拒绝都要留痕。监控的价值是重建 Agent 的行动过程，而不只是展示一个仪表盘。

拒绝记录尤其值得观察。同一 Agent 会话突然连续出现被拒绝的调用，可能是提示注入正在试探权限边界。作者把它视为攻击信号，但没有提供告警阈值、误报率或识别效果。

产品部分，作者称 reskSecure 位于模型与工具之间，负责解析调用主体并在执行前应用策略；ReskPoints 提供策略决策和日志记录能力，让允许、拒绝的结果可以事后追溯。

原文没有展示 SDK、API、配置或部署方式，因此能确认的是作者宣称的职责划分，不能据此判断接入成本或实际防护效果。

我的判断

我认同把授权放在工具执行前。对具有行动能力的 Agent，只审查回答文本，确实遗漏了数据库查询、文件访问和对外发送这些实际操作。身份、权限、参数和日志，也都是程序员可以落实到系统中的控制点。

但作者给出的更多是架构原则，缺少对照数据。文中没有证明这套方案相较于现有权限网关、业务服务鉴权或工具白名单，能降低多少风险；RESK 的效果也没有独立证据支撑。

两个边界需要补清。第一，收件人属于内部域，只能说明目的地址满足一条规则，不能证明邮件内容允许发送，也不能证明当前用户有权读取其中的数据。第二，前置策略层不能成为工具服务放弃自身鉴权的理由。原文强调统一关卡有道理，但没有论证工具内部校验为何应当被排除。

最小权限也是权限上限，不是对用户意图的证明。即使一次调用通过授权，它仍可能偏离用户真正交代的任务。原文解决的是 Agent 能动用多大权力，没有完整解决它该在什么时候动用这些权力。

能拿来做什么

• 给 Node Agent 的工具执行入口加一道授权检查，让每次调用携带明确的用户或服务身份；身份缺失时直接拒绝，不用共享凭据替它兜底。
• 按任务配置工具权限。摘要任务只开放必要的读取能力，需要发邮件时再授予对应权限，并检查收件人等关键参数。
• 把工具调用日志与聊天记录分开保存，至少记录主体、工具、参数和允许或拒绝的决定，让一次数据访问或发送行为能够被追溯。
• 用原文的工单场景检查现有流程：当正文要求把数据库内容发往外部地址时，确认拦截发生在发送之前，并观察连续拒绝能否被监控发现。