企业 Agent 为什么总卡在上线前：从 Amazon Quick 的五部门权限模型谈起

企业 Agent 为什么总卡在上线前：从 Amazon Quick 的五部门权限模型谈起

Amazon Quick 团队 9 月 1 日发布了一份从 POC 走向生产的安全指南。文章开场并不讨论模型参数，而是描述了一个常见的尴尬：十个人试用时运行顺畅的权限方案，一旦扩到五个部门，就可能让 Agent 返回超出岗位范围的数据，安全团队也很难从日志里还原数据集、知识库、Agent 和工作流之间的关系。

AWS 为此构造了一个 5000 人、5 个部门、5 个办公地点的企业。人力负责人需要查看工资和离职风险，部门经理只能看到本部门指标，普通员工只应访问制度与匿名趋势。同一份人力数据如果直接交给所有用户，再把希望寄托在应用层的权限开关上，误配置的后果会被 Agent 的检索和工具调用进一步放大。

权限要跟着数据视图走

指南给出的做法，是把源数据加工成三个与授权边界一致的视图，再分别连接专用 Agent 和仪表盘。面向部门经理的视图同时移除敏感列并启用行级控制；面向全员的视图只保留“部门 × 地点”粒度的聚合结果，不暴露个人记录。这种设计的重点在于，越权请求即使抵达模型，底层数据面也没有可返回的敏感内容。

知识库同样需要分层。公共制度、限制访问文档与敏感材料应使用独立索引或访问范围，文档分类不能只写在文件名和提示词里。Agent 的工具权限也应按职责拆分：查询类工具可以自动运行，写入、发送、审批等外部动作则进入带人工确认的 Flow。模型生成了一条合理指令，不等于它已经获得执行权限。

这套方法对使用 Claude、GPT、GLM 等多模型的企业仍然成立。模型可以更换，业务身份、数据范围和工具授权必须保持稳定。统一模型网关适合集中处理 API Key、模型白名单、调用日志和费用归属，但它不能替代业务系统自己的行列权限。网关控制“谁能调用哪类模型”，数据层决定“这个人能看到什么”，两者缺一层都会留下空档。

上线评审应检查四条链路

很多团队的安全评审只测试提示注入和敏感词过滤，却没有把一次完整请求画出来。更实用的评审对象，是用户身份到数据视图、数据视图到知识库、Agent 到工具、工具到最终动作这四条链路。每一段都要能回答授权依据、失败方式、日志位置和撤销手段。测试账号也应覆盖普通员工、跨部门经理、离职员工和临时协作者，而非只用管理员账户演示成功路径。

审计日志要记录模型名称、调用时间、用户与租户、检索来源、工具参数、审批人和最终结果。提示词与知识库版本也应进入变更记录，否则同一问题在模型升级后出现不同答案时，团队只能看到一次 API 调用，无法复盘上下文。涉及工资、医疗、合同等高敏感领域，发布前还应让独立模型或人工审核一组越权与边界案例，避免测试设计本身遗漏风险。

生产门槛可以设得很朴素：任何敏感字段都不能仅靠提示词隐藏；任何不可逆动作都必须有明确授权或人工确认；任何回答都能追溯到当时的数据、模型与策略版本。做到这些，POC 才算获得了扩展到更多部门的资格。

对于正在统一接入多家模型 API 的团队，可以在 [AnyAIS 模型列表](/models) 中先确认可用模型，再把身份、路由、日志和费用策略写进同一份上线清单。模型选择可以灵活，权限边界不要随接入方式漂移。

来源：[AWS：Securing Amazon Quick from POC to production](https://aws.amazon.com/blogs/machine-learning/securing-amazon-quick-from-poc-to-production-agents-flows-and-spaces/)