AgentCore 授权上下文落地后，卖家 AI 代理要先补权限映射表

AWS Security Blog 最近把一个问题讲得很直白：AI 代理在读 DynamoDB、SaaS、知识库或 CRM 时，不能只知道自己能调用什么工具，还要知道是谁在问、他能看什么、这次请求能不能写回去。否则代理越聪明，越容易把不该看的订单、广告、客户和财务数据一起带出来。

对卖家和服务商来说，这不是抽象的安全讨论。广告代理会碰预算，客服代理会碰订单，品牌代理会碰库存和退货，财务代理会碰回款和发票。只要这些动作仍然被当成“一个智能机器人在帮忙”，权限就会被说得很轻；一旦它进入生产链路，权限就必须先被写进流程表。

运营判断：AI 代理越像能办事的人，越不能只给一把总管理员钥匙。FlyFus 做卖家需求分析时，应该把可见数据、可执行动作和审批人拆开看。

发生了什么

AWS 这组 AgentCore 文章的共同意思很一致：代理可以协调工具，但不应该自己决定谁能看什么。身份先由 IdP 认证，再把用户上下文带进 runtime 和 gateway，由下游服务和策略层做最终拦截。这样即便 prompt 被操控，权限也不会跟着漂移。

对卖家团队而言，这意味着以前“账号能登录”不等于“代理能执行”。账号、角色、部门、客户、站点、币种、广告账户和订单状态都可能影响一条请求是否允许被看见或被改写。

权限映射表

场景	代理可见数据	可执行动作	必须拦截
客服代理	订单、物流、退货状态	查单、回填备注	导出全部客户资料
广告代理	账户、预算、搜索词	生成建议、草稿	直接改高额预算
财务代理	发票、回款、对账单	汇总、标记异常	给外部团队开放原始明细
账号经理	客户合同、目标、周报	归档、分配任务	跨品牌读取私有报表
服务商代理	多客户配置、素材、权限	生成建议、发起审批	混用不同客户的凭证

三步落地框架

第一步：把权限从角色拆到动作

不要只写“客服可见”“广告可见”这种粗颗粒规则。真正有用的表要写到对象级：谁能看哪条订单、哪组广告、哪份报表、哪个 ASIN、哪个客户。只有这样，代理在面对模糊提问时才知道边界在哪里。

第二步：把高风险动作单独挂牌

改价、改预算、导出客户资料、切换站点、重发退款、关闭广告、更新库存状态，这些都不是普通查询。建议把它们放进单独的审批层，至少要求二次确认、阈值和理由字段。

第三步：把审计留在业务表里

不要只在技术日志里记“调用成功”。业务侧要能回溯到请求人、客户、对象、动作、来源工具、审批人和结果。否则出了问题，团队只会知道“代理做过”，不知道“谁授权、为什么授权、授权到哪一步”。

常见误区

• 给代理共享超级账号。
• 只限制读，不限制写。
• 认为多租户隔离只属于工程团队。
• 把审计日志留给安全团队，不放进运营周报。

对卖家和服务商的影响

卖家会很快发现，AI 代理不是单点效率工具，而是新的权限层。广告、客服、财务、库存、品牌和法务如果共用同一个机器人入口，最容易出问题的不是答案质量，而是越权范围。服务商则要从“帮客户搭代理”升级到“帮客户定义代理能做什么、不能做什么、出错后怎么回滚”。

观点分析

AgentCore 这类基础设施把权限问题前置了。短期看，它让代理落地更慢一点；长期看，它让真正可用的代理更快进入生产，因为团队不必先经历一次权限事故再补制度。谁先把权限表做细，谁就更容易把 AI 代理接到 CRM、广告和订单系统上。

执行细节

最现实的做法，是先挑一个高频但低风险的流程试点，比如“查广告周报不允许改预算”或“客服只读订单不允许改地址”。然后把这个流程拆成角色、工具、对象、动作、阈值和审批人六列，强制代理每次输出都带来源和边界。FlyFus 如果要帮助客户做 AI 运营诊断，也应先输出建议，再留人工确认。

一旦这个最小闭环跑通，再慢慢放大到多客户、多地区和多团队。不要一开始就让代理横跨广告、财务和客服。

典型场景

广告代理最常见的边界问题，是同一个账号既能读周报，又能顺手改预算；客服代理最常见的问题，是查得到订单，却能看到整张客户表。权限映射表要把这两类动作拆开，不然团队会把“方便”误当成“安全”。

如果服务商代管多个品牌，更要把客户级隔离写进模板。一个客户的 ASIN、广告账户、优惠规则和库存状态，不应该因为同一个代理会话而混到另一客户的上下文里。

复盘口径

字段	用途	谁看
请求人	谁发起的	运营、审计
对象	哪个 ASIN、账户或订单	业务负责人
动作	读、写、导出、回滚	审批人
结果	成功、拒绝、人工接管	周会复盘

有了这张口径表，团队每周就能看出代理到底是在省时间，还是在制造更多例外处理。

高风险动作清单

改价、导出、退款、关单、发券、改地址、切换付款方式，这些动作都不该和普通查询放在同一层。最稳的做法，是把它们单独列出来，默认要求人工确认，再根据业务成熟度放宽。

如果团队连这张清单都没写，就很难判断代理到底是个助手，还是已经变成了一个不受控的操作员。

为什么要分层

分层不是为了拖慢执行，而是为了让最常见的动作最快完成，最危险的动作最慢发生。这样一来，团队既能享受自动化带来的效率，也不会把事故成本藏进日常流程里。

这也方便法务、客服和运营对齐口径，不会在同一条请求上给出三种说法。

卖家可以马上做的 5 件事

1. 给所有 AI 代理列出可见对象和可执行动作。
2. 把改价、导出、退款、关单、发券列成高风险动作。
3. 为每个动作指定审批人和回滚路径。
4. 要求所有代理建议带来源 URL 和时间戳。
5. 每周用 FlyFus 复盘一次越权请求和人工接管记录。

主要来源

• https://aws.amazon.com/blogs/security/propagate-user-authorization-context-in-ai-agents-with-amazon-bedrock-agentcore/
• https://aws.amazon.com/blogs/machine-learning/agentops-operationalize-agentic-ai-at-scale-with-amazon-bedrock-agentcore/
• https://aws.amazon.com/blogs/machine-learning/securing-ai-agents-with-temporal-policies-in-amazon-bedrock-agentcore/
• https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html