周二下午，一张工单被提交到系统。连接着Jira、Confluence和Slack的企业AI助手收到指令：产品经理索要"支付服务的事故历史"。模型返回了一份详尽总结——时间线、根因、影响因素，还有一段摘自另一业务单元事后复盘报告的内容。那份报告从未向产品团队开放过。
所有API调用都成功了。每次权限检查都通过了。模型有权访问Confluence。那份复盘报告就在Confluence里。用户会话有效。唯独没人定义过"该用户在此工作流场景下的事故历史"究竟该包含什么。
直到这份总结被粘贴进高管演示文稿，会议室里有人认出自己本不想分享的内容，问题才暴露。这就是大语言模型的授权困境——收紧API权限解决不了它。
系统没故障，故障的是设计
模型没有失灵。它做了被设计来做的事：跨连接系统聚合相关信息，合成有用的回答。Jira集成返回了相关工单，Confluence集成返回了相关文档，Slack集成返回了相关线程上下文。模型把它们组装成连贯答案。
真正的失败在于：没人为这个工作流定义授权边界——只定义了其中单个API调用的边界。
这个区别在架构层面至关重要。传统企业系统中，用户请求数据时，作用域在API层面确定：该用户能读这些记录、这些文档、这些消息。系统每次调用都强制执行这个范围。边界是显式的、强制的、可审计的。
而在连接多个企业系统的AI工作流中，作用域问题发生了转移。用户有权限，模型有连接，但模型不问"该用户本应获取什么"，它问"回答这个问题需要什么"。两个问题返回的结果集不同，两者之间的缝隙就是授权边界崩塌的所在。
API验证身份，大模型聚合上下文
传统企业授权运行着三层模型，大多数架构师都默认理解：
第一层是认证——你是谁？验证身份、确认会话、检查凭证。
第二层是授权——你能做什么？基于角色的访问控制、访问控制列表、策略执行。这是大多数企业安全投入的所在。
第三层是上下文授权——在此特定工作流中，你本应做什么？这一层在大多数企业授权架构中不存在，因为传统系统不需要它。数据库查询返回你确切请求的内容，REST端点返回定义好的资源，响应范围由请求决定。
大模型把第三层撕开了一道口子。连接十个企业系统的模型不是检索单一资源——它
热门跟贴