AI Agent权限安全实践：从登录态到工具层的完整身份链路

AI Agent 在自动化完成任务时最常见的权限事故不是模型答错而是安全边界没有从登录态一路传到工具层。“AI 识别用户身份并授予完全访问权限”这句话看上去是模型能力问题实际上是一个完整的身份链路问题用户如何登录系统如何把用户身份转交给 AgentAgent 调用的每个方法如何确认这是同一个用户并且只有在授权匹配时才放行。如果只把用户信息写进提示词让大模型“根据角色决定能不能做”那几乎一定会在真实场景里失控。用户可以构造提示词覆盖系统规则模型也可能因为工具返回内容被间接注入而误解权限。身份识别和授权判断必须放在模型之外的确定代码里。这篇博客用一个可运行的 Spring Boot 工程来说明这条链路怎么搭。1. 先理清AI 权限问题的本质是身份链路不是模型判断1.1 一次 AI 授权请求会经过七步链路一个 AI Agent 要代替用户执行操作不能直接把用户的账号密码传给模型也不能只把“用户叫张三”放在对话里。正确的职责链大致长这样用户通过网页登录、OAuth2 授权、SSO 或 CLI 登录拿到可识别的身份凭证。后端拦截器校验凭证并把登录用户转换成一个新的对象这个对象只包含这个会话需要的信息。后端把用户对象放进当前请求的安全上下文中。Agent 服务开始处理用户提示词时从安全上下文取出用户对象构造带用户身份的会话。模型根据用户提示词决定下一步调用哪个工具这个过程可以理解成“识别用户意图”。Agent 真正执行工具方法前由代码、注解或切面再次检查当前用户是否具备这个操作的权限。每一次授权结果都写入审计日志。这里最容易误解的是第 1 步和第 6 步的关系。第 1 步确认“你是谁”第 6 步确认“你能做什么”。模型处于第 5 步它只负责把自然语言翻译成工具调用不应该拥有最终权限判断权。1.2 “完全访问权限”应该如何落到代码里“完全访问权限”这个词如果不在工程里定义清楚会变成事故源头。实际项目里应该把它拆成几个维度权限维度含义例子功能权限用户能调用哪个业务方法report:export、report:delete资源权限用户能操作哪些数据范围只能导出自己部门的报告租户权限用户属于哪个组织或项目tenant:10086管理员权限用户是否拥有兜底放行逻辑ROLE_ADMIN或*在真实系统里即使是管理员也不建议把“完全访问权限”理解为每个方法都无条件放行。比较安全的做法是普通用户按最小权限集授权管理员账号拥有更高权限但高风险操作仍然需要二次确认或者单独审批。代码上的表现是管理员身份里可以包含*这样的通配权限但*依然要经过同一个方法级校验器检查。它不是绕过鉴权而是代表“拥有全部已注册权限”的授权结果。1.3 为什么不能让大模型做最终授权权限判断是确定性逻辑而大模型生成结果是概率性的