AWS Security Blog 8月19日介绍了在Amazon Bedrock AgentCore中传递用户授权上下文的方案。文章以销售与财务共用一个CRM聊天入口为例：两个部门可以使用同一个Agent，但销售只能访问合同、定价和管道范围，财务只能访问发票、付款和财务记录。AWS的核心原则是，Agent负责协调请求，不负责决定谁可以看什么；访问应由身份、基础设施和下游系统执行。

共用界面不等于共用数据权限

外贸企业常希望销售、跟单、供应链和财务在一个AI入口查询客户信息。如果后台只给Agent一个高权限服务账号，再依赖提示词告诉它“不要展示敏感数据”，一旦提示注入、工具调用错误或过滤逻辑失效，全部数据就处在同一暴露面。

正确边界是先确认发起者身份，再把部门、角色、区域、项目或客户归属等授权属性传到后续调用。销售查看自己的商机，不应顺带获得其他团队价格策略；跟单查询交期，也不应读取与任务无关的收款信息。

权限判断要下沉到真实系统

CRM、数据库、文档库和SaaS平台应根据用户范围拒绝未授权请求，而不是相信Agent会主动过滤。AWS示例采用用户级临时凭据、属性访问控制和代表用户的令牌交换，让下游服务继续执行原有共享规则。

企业不必照搬某个云架构，但要保留同一原则：Agent不保存长期明文凭证，每次调用只获得完成当前任务所需的短期权限。无法在基础设施层执行时，应用层过滤只能作为补充，还要记录限制与复核责任人。

外贸工作流要保留请求证据

每次敏感调用应记录谁发起、以什么角色、访问哪个系统、读取或改变什么对象、使用何种授权范围和结果状态。日志不应保存不必要的客户秘密，却要能回答一次异常访问的责任链。

对于修改报价、发送邮件、变更回款状态等动作，还要增加明确确认和写后回读。查询权限与写入权限分开，批量导出与单条查看分开，避免“能回答问题”被误解为“可以改变业务记录”。

对中国外贸企业的经营含义

AI跟单的价值来自跨系统协同，但跨得越多，权限边界越不能依赖口头规定。客户价格、付款、合同、样品和供应链信息分别属于不同责任域。把所有权限集中在一个Agent账号，会让效率提升与风险扩散同时发生。

管理层应把Agent权限设计纳入岗位与数据治理，而不是只交给提示词工程。权限变化还要跟随入职、调岗、项目结束和离职及时更新。

可执行建议

参考来源