智能体接入多源数据，别让用户权限在中途丢了

同一个销售助手里，销售问“本季度重点客户合同”，财务问“某客户付款记录”。它们都在和同一个智能体对话，也都在说“客户”。如果智能体拿着一把能打开全部 CRM、文档库和数据库的总钥匙，真正的风险不在它会不会答错，而在它会不会把本不该看见的内容答得太流畅。

8月19日，AWS 发布了一套面向多数据源智能体的授权上下文传递实践：让用户身份与部门、角色、区域或项目等业务范围，从登录入口一路传到数据库、知识库和外部 CRM；每个下游系统仍按自己的规则决定放行或拒绝。它的价值不在于多加一层“提示词防护”，而是把权限判断从智能体的临场判断，移回更可靠的基础设施与业务系统。

真正要区分的，是“谁在执行”和“替谁执行”

很多企业已经给智能体配了身份、密钥和工具权限，却仍少了一段关键链路：当它替某位员工查资料时，下游系统如何知道这不是智能体自己的需求，而是某个具体用户、在某个具体业务范围内发起的请求？一旦这层上下文断掉，智能体往往会退化为“高权限服务账号”，再靠代码里的筛选条件承诺只返回该看的内容。

这种设计把最后一道门交给了最不该当门卫的角色。提示词注入、工具调用逻辑出错，甚至一次看似普通的查询改写，都可能让筛选失效。AWS 的示例把入口用户的已签名身份令牌交给运行环境验证，再将用户范围绑定到临时、按请求签发的访问凭证；智能体负责理解问题和编排工具，但不自行裁定“谁能看什么”。

把智能体当成业务协调员，而不是权限裁判：它可以提出查询，但不应拥有绕过数据系统授权模型的能力。

三类数据源，三种不能省略的“接力”

第一类是结构化业务数据，例如订单、客户、库存或付款记录。更稳妥的做法不是让智能体先读全表再过滤，而是用用户范围绑定的短期凭证访问，让数据库或访问策略在查询发生前就拒绝跨部门、跨区域的数据。这样，即使智能体被诱导去查不该查的分区，也拿不到结果。

第二类是企业知识库。文档入库时就要带上部门、项目、客户或密级等元数据，检索时将用户范围变成硬性过滤条件。这里要诚实面对一个细节：有些知识库的元数据过滤仍在应用层实现。涉及高度敏感信息时，不能只满足于“检索时记得加筛选”，还应考虑按租户或安全域物理/逻辑隔离知识库，并由资源策略控制访问。

第三类是外部 SaaS，例如 CRM、工单或财务系统。若智能体用统一服务账号调用，它天然看得比普通员工更多。AWS 的实践建议采用“代表用户”的令牌交换：把已认证的用户身份换成该外部系统认可的、用户范围内的临时令牌，让 CRM 自己的共享规则、角色规则继续生效。这样既不需要智能体保存每个人的凭证，也不必为每次后台工具调用重新弹出授权窗口。

给每个跨系统任务配一张“授权接力卡”

对企业而言，这不是 AWS 专属的实现问题，而是一条通用的智能体设计原则。我建议在每个会跨系统取数或执行动作的工作流前，先补齐一张授权接力卡：发起人是谁、当前任务为谁服务、可传递哪些范围属性、每个数据源在哪一层强制校验、令牌多久失效、读写动作分别由谁批准，以及被拒绝后智能体该提示什么、转交给谁。

STARBOX 的组织→BOX→智能体三层架构，适合承接这类“不断链”的授权设计：组织层先定义岗位、数据归属与升级责任；BOX 层沉淀客户旅程、字段字典、数据分级、可调用工具和审批规则；智能体层只携带当次任务所需的上下文，在授权范围内读取、生成或提交。DDABC 闭环再把越权拒绝、人工补批、误授权和例外处置回写，成为下一次配置的依据。

这比给智能体叠更多“不要泄露数据”的指令有效得多。前者是在系统层承认模型会犯错，因此预先设计它犯错时仍打不开的门；后者则是假设它永远能正确理解边界。企业开始把智能体接进真实生产数据时，应该问的不是“它有没有权限”，而是“它替谁、带着什么范围、在哪一站被再次核验”。

智能体越能横跨系统，权限越不能只停留在入口。把用户授权上下文一路送到最后一个数据源，才是让自动化既能做事、又不越界的基础。资料来源：AWS Security Blog《Propagate user authorization context in AI agents with Amazon Bedrock AgentCore》（2026年8月19日）。