作者元宝元宝说 AI 安全一个安全研发的 AI 安全观察与实践笔记。下面是两条经过简化的模拟日志10:03:17 useru-173 toolquery_ticket ticketT-1042 result200 10:03:19 useru-173 toolquery_ticket ticketT-1043 result200u-173属于采购项目T-1042也是采购工单。问题出在第二条T-1043属于支付项目这名用户既不在项目组也没有临时授权。系统没有被绕过登录没有出现伪造 Token工具也只允许后端调用。越权仍然发生了。如果你在值班现场会先查哪一处登录服务、模型 Prompt还是工单 API我的顺序会是工单 API。因为日志已经证明用户身份被识别真正缺失的证据是API 是否检查了这名用户与T-1043的关系。登录成功不代表对象属于你这类问题经常被归因于“模型选错了参数”。模型确实可能从上下文里提取到错误的工单号也可能受到文档中隐藏指令的影响。但从安全研发角度看这只是入口不是根因。一个普通用户手动修改 URL把/tickets/T-1042改成/tickets/T-1043后端也应该拒绝。参数改成由模型生成后这条要求并没有变化。事故链路其实很短用户通过认证Agent 获得他的会话身份模型生成ticket_idT-1043工具服务使用高权限服务账号查询工单 API 只检查服务账号没有检查发起用户结果被返回给无权访问该工单的用户。这里最值得注意的不是模型“猜到了”另一个编号而是系统把两个身份混在了一起执行调用的是服务账号承担业务权限的却应当是最终用户。从两条日志继续追证据我会沿着T-1043往回查四项信息工具请求里是否携带可信的用户与租户上下文ticket_id是否完全来自模型参数工单服务是否做了对象级授权审计日志能否同时还原发起用户和执行身份。只在 Prompt 里写“不得访问其他项目”无法补齐这些证据。它可以减少误调用却不能保证拒绝越权请求。同样给工单号增加格式校验也不够。T-1043是格式正确的真实工单只是它不属于当前用户的授权范围。输入校验回答“参数是否合法”资源级授权回答“这个人能否读取这个对象”两者守的是不同边界。修复不应从模型开始更可靠的改法是在工单服务或紧邻工单服务的策略层根据可信身份重新计算权限用户身份和租户来自认证上下文不能由模型填写工单归属从服务端数据库读取不能相信请求声称的租户权限判断至少包含主体、动作和对象高权限服务账号代用户调用时必须保留委托关系拒绝事件记录资源、策略版本和发起用户但不把敏感正文写入日志。有团队会选择先在 Agent 编排层过滤一次这可以作为提前失败和减少无效调用的优化但不能成为唯一防线。编排层看到的可能只是模型生成的参数真正掌握工单归属和最新权限状态的仍然是工单服务。这次处置应该留下什么如果这是一场真实值班我不会把“优化 Prompt”写成关闭事件的条件。至少需要完成三项处置记录确认是否存在更多跨项目读取、补上资源级授权、为历史调用建立发起人与执行身份的映射。还有一项容易被漏掉检查返回内容是否进入了对话记忆、向量库或后续摘要。越权响应即使只出现过一次也可能被新的检索链路继续传播。下一次看到“接口已经要求登录”时可以顺手多问一句登录以后哪段代码证明这个对象属于他这个问题通常比继续调整 Prompt 更快接近根因。