让助手按请求借用用户权限

AI 助手接入内部系统时，最省事的做法是给它一个公共账号，谁来提问都用这套凭证。作者认为，这恰好把权限关系搞反了：助手应该临时代理当前用户，只能做这个人原本就有权做的事。

这篇文章讨论的不是怎样让模型更听话，而是模型被诱导之后，系统还能守住什么。它给出的答案很具体：个人凭证、按角色提供工具、服务端填写身份，以及按当前权限执行请求。对于正在做内部 AI 助手或 MCP 服务的团队，这比再加几句安全提示词更值得优先考虑。

公共账号为什么会越用越危险

一个助手同时服务客服、财务和管理层，公共账号就得满足这些人的不同需求。权限不断叠加，最终得到的是所有用户权限的并集，可能比任何单个员工的权限都大。

问题在攻击发生之前就存在了。

下游系统只知道助手账号读取了合同，却不知道它代表谁读取。审计人员想收回一项权限，也很难判断会影响哪些人。于是，增加权限容易，删除权限困难。作者把这种持续扩张归因于共享身份的结构，而不是某个人配置失误。

助手应该增加操作便利，不应该增加用户的权限。

按这个原则，助手只是代理。用户直接访问内部系统能看到什么，通过助手也只能看到什么。每次下游调用都应携带可归属到具体用户的身份，权限范围则按请求发生时的当前状态判断，不能一直沿用接入时的快照。

作者举的例子是：中午撤销的权限，助手中午就应该失去。员工离职也不需要额外处理一个助手账号，撤销个人访问权时，代理能力一起失效。

这里还有一层管理收益。日志从「助手查询了薪资」变成「助手代表某位已认证用户查询了薪资」，调查才有明确起点。不过，可追溯不等于操作合理，它只是让后续核查有据可查。

把身份和范围留在服务端，模型只负责提出请求

作者正在测试的内部 MCP server，会根据已认证用户的角色生成可见工具列表。某个角色不该使用的工具，从一开始就不出现在列表里。

这样做能减少模型接触到的能力，也能减少它尝试越权调用的机会。相比在提示词里要求「不要调用财务工具」，服务端直接不提供这项工具，约束更明确。

但这里要区分两件事：模型看不到工具，不代表服务端可以省掉调用时的鉴权。作者强调「不可见」强于「被禁止」，这个表述用来说明工具暴露策略有价值；如果把它理解成隐藏工具名就能保证安全，就过头了。文章没有给出完整协议实现，不能据此推断所有绕过路径都已封住。

另一个关键点是参数归谁填写。

身份、角色、数据范围，以及决定归属的 region、owner 等字段，应由服务端根据认证会话填写。模型可以决定查询什么，却不能通过自己生成的参数决定「现在代表谁查询」。

例如，一次请求是否只能读取当前用户负责区域的数据，应由服务端确定。不能把这个决定交给模型填写一个区域值，再期待提示词阻止它改成别人的区域。

模型生成的是请求，真正的权限约束必须由代码执行。

角色设计也不用一开始就追求极细。作者建议先沿用组织已有角色，把角色映射到工具列表，再通过服务端身份字段限制个人范围。后续根据审计日志里的实际需求细化，避免先做一张复杂却难以维护的逐人权限矩阵。

提示注入拦不干净，权限决定失守后的损失

作者引用了一份 2026 年、覆盖 247 篇论文的 agent 安全综述。按其转述，提示注入和借助工具劫持控制流程，仍然是主要问题；现有防御虽然有用，但组合起来未必能持续保持效果。

这里的提示注入，可以理解为：助手读取的网页、文档或工具结果中混入指令，试图让它偏离用户任务。尤其棘手的是，恶意指令可能藏在助手必须阅读的证据里。

文章引用的 ARGUS 就针对这类上下文感知攻击。在 AgentLure 基准上，攻击成功率从 28.8% 降到 3.8%，同时保留 87.5% 的正常任务效用。攻击成功率约降为原来的七分之一，是明确的进步，但仍有剩余风险。

这些数字需要连着适用范围一起看。它们是特定基准上的结果，不能直接当成某家公司上线后的攻击概率；87.5% 的正常任务效用，也不能直接理解成所有业务都能保留同等比例的可用性。原文没有展开指标定义和具体业务条件。

作者据此提出的工程判断仍然成立：应该预先考虑一次注入成功后，助手究竟能碰到什么。

公共账号让攻击者有机会借用所有用户的权限并集。个人权限范围则把可达能力限制在当前用户之内，并保留对应的操作归属。检测负责降低攻击成功的机会，权限负责限制成功之后的影响，两者需要叠加。

不过，「只影响一个人的范围」也未必很小。当前用户如果本来就有高权限，助手失守后的后果依然可能严重。个人权限解决了无故扩权的问题，并没有自动解决全部风险。

我的判断

我赞同作者把权限设计放在提示词之前。它把安全要求落到可以审计、可以执行的系统边界上，也让离职撤权、权限复核这些已有流程继续发挥作用。相比「公共账号加严格提示词」，这套方案更容易解释清楚谁能做什么。

但文章呈现的是一个仍在测试的设计，没有生产规模的对照数据。它没有证明个人凭证方案的接入成本、维护成本或性能开销有多大，也没有证明工具隐藏本身能降低多少攻击成功率。这些部分属于作者的设计经验和推理，不能当作已完成验证的结论。

两个未解决的问题尤其实际。第一是委托：经理的助手使用分析师的数据访问能力准备材料时，究竟按谁的权限执行、日志如何记录，作者尚未确定。第二是长任务：启动时有效的权限，运行中可能被撤销；每一步重新检查又有成本，而作者还没有测量这个成本。

因此，「撤权立即生效」目前更适合作为设计目标。要兑现它，系统还需要处理运行中的任务，而不只是下一次新请求。

能拿来做什么

• 给内部 AI 助手接工具前，先画清现有调用链中的身份传递。如果所有请求到了 Node 服务或数据库都变成同一个助手账号，就先确认服务端如何识别真实用户、检查权限并记录操作归属。
• 实现 MCP server 时，可以先按已有组织角色生成工具列表，并从只读工具开始。涉及身份和数据归属的字段由服务端填写，同时在每次工具调用时执行鉴权。
• 检查工具参数时，重点看 region、owner 这类会改变数据范围的字段。模型提供的业务查询条件可以接收，但不能让它借参数切换调用身份或扩大可访问范围。
• 在开放后台长任务或代他人操作前，先明确撤权后的停止规则和委托记录方式。原文尚未解决这两项，不宜直接把短请求的权限方案当成完整答案。