从概念验证到生产环境：如何确保 Amazon Quick 的安全（Agents、Flows 和 Spaces）
Amazon Quick 的概念验证（POC）项目往往在小型试点团队中进展顺利，但当安全和合规团队审查生产计划时，项目常常会停滞不前。一个适用于十名试点用户的权限模型，在扩展到五个部门时往往就会失效。Agents 可能会返回其预期范围之外的数据，合规团队也难以审计数据集、Agents 和 Spaces 之间的关联。Amazon Quick 将仪表板、Chat Agents、Flows 和 Spaces 与知识库相结合，每种功能都引入了标准仪表板控制无法覆盖的安全面。本文以 AnyCompany 场景为例，介绍如何设计仪表板、Spaces、知识库、Agents 和 Flows，并确保安全控制能够随着用户和部门的增加而保持有效。文章涵盖四种模式：数据集整形、Agent 隔离、文档分类和审批门控，并提供了治理框架和生产就绪检查清单。
场景概述
假设 AnyCompany 有 5,000 名员工、5 个部门和 5 个地点，三类受众需要不同级别的相同数据：
- HR 领导层：需要完整的员工数据，包括薪资和流失风险。
- 部门经理：只需自己团队的运营指标。
- 全体员工：可访问公司政策和匿名化趋势。
如果仅依赖权限控制，将所有数据暴露给三类受众，极易出现配置错误。
解决方案概览
该方案将一份源数据集整形为三个符合授权级别的视图，并为每个视图连接一个专用 Agent。同时，为每个受众发布对应的仪表板，将 Spaces 范围限定为内容所有权，并通过带有“人在环”控制的 Flow 来门控出站操作。
- HR 领导仪表板：提供全员工可见性，包括薪资、流失风险和职位级别细分。
- 部门经理仪表板：通过行级安全（RLS）将操作指标限定在单个部门内，移除敏感列，每位经理只能看到自己部门的员工。
- 公司趋势仪表板：提供匿名化趋势和政策信息。
四种安全模式
数据集整形
通过创建视图或数据集副本，仅保留特定受众所需的列和行，从而减少敏感数据暴露面。例如，部门经理视图不包含薪资列，并应用 RLS 过滤行。
Agent 隔离
每个 Agent 仅连接到为其受众整形后的数据集或知识库。Agent 的系统提示和防护栏进一步限制其行为，确保其不会跨出预期范围。
文档分类
在将文档添加到知识库之前，根据敏感级别（如公开、内部、机密）进行分类，并设置相应的访问策略。
审批门控
通过 Flow 实现人工审批环节，例如当 Agent 尝试访问高权限数据或执行出站操作时，需要指定审批人批准。
治理框架
建立跨职能团队（包括安全、合规、数据所有者和 IT）来定义数据所有权、访问策略和审计流程。定期审查权限和日志，确保合规。
生产就绪检查清单
- 所有数据集是否已整形并应用 RLS？
- 每个 Agent 是否仅连接至授权数据源？
- 文档分类是否已实施并验证？
- 审批门控是否覆盖高风险操作？
- 是否建立了监控和审计机制？
通过从 POC 阶段就融入这些安全控制，企业可以顺利将 Amazon Quick 扩展到全组织，同时满足安全与合规要求。