Amazon Quick 的概念验证通常能很快做出漂亮的仪表板、知识库和智能代理，但真正进入生产环境时，安全评审往往会追问几个问题：代理能访问哪些数据？文档是否经过分类？Spaces 之间是否隔离？哪些动作必须由人批准？
要让项目顺利跨过这道门槛，安全控制需要从数据集塑形开始，一直延伸到 Agents、Flows 和 Spaces 的运行边界。核心不是给 POC 外面再套一层权限，而是让每个组件只接触完成任务所需的最小数据和能力。
生产化的四个控制面
1. 数据集先塑形，再交给仪表板和代理
不要直接把生产数据库的宽表交给 Amazon Quick。宽表通常包含客户联系方式、内部成本、员工信息或其他不适合被自然语言查询暴露的字段。
可以先建立面向业务场景的分析数据集：
- 只保留当前用例需要的列。
- 将内部标识符替换为业务可读但不可逆的键。
- 在数据集层面预先计算指标，减少代理自行拼接敏感字段的机会。
- 按组织、区域或项目写入可用于过滤的授权属性。
- 为数据集标注负责人、用途、保留周期和敏感级别。
这一步直接影响后续所有组件。仪表板、知识库检索和 Agent 工具调用都应该建立在经过筛选的数据面上，而不是依赖提示词提醒模型“不要展示某些字段”。
2. 用 Spaces 和 Agents 划清工作边界
Spaces 可以理解为面向团队或场景的工作区域。生产环境中，不同 Space 不应共享一套默认的知识库和代理工具配置。
一种可执行的边界设计是：
- 财务 Space 只连接财务数据集和经过财务分类的文档。
- 客服 Space 使用脱敏订单数据和公开产品资料。
- 运营 Space 可以访问聚合指标，但不能直接读取个人级明细。
- 每个 Agent 使用专属身份、专属工具列表和专属知识源。
- 代理的读取权限与执行权限分开管理。
Agent 隔离尤其重要。一个能够查询知识库的 Agent，不应自动拥有修改工单、发送邮件或执行数据库写入的能力。需要执行动作时，可以通过 Flow 将“生成建议”和“执行变更”拆成两个阶段，并在中间插入审批门。
3. 文档分类要成为检索前的硬条件
知识库的风险经常被低估。即使文档本身存储安全，只要检索层把内部政策、合同或个人资料混入普通问答，权限边界就已经失效。
建议为每份文档保存至少以下元数据：
classification：public、internal、confidential或更高敏感级别。owner：文档负责人或业务团队。allowed_spaces：允许检索该文档的 Space。expires_at：复核或失效日期。source：文档来源与版本信息。
检索请求必须同时满足用户身份、Space 边界和文档分类条件。提示词中的“只回答公开内容”只能作为辅助约束，不能替代服务端过滤。
一个可改造的安全配置示例
下面的 YAML 是一个与具体 AWS API 解耦的配置模型，适合放进配置仓库，再由部署脚本转换为实际的 IAM、数据集、知识库和 Flow 配置。运行前请将示例资源名替换为实际资源，并在落地时映射到组织现有的身份与审批系统。
spaces:
finance:
members_group: quick-finance-users
datasets:
- finance-aggregates
knowledge_filters:
classification:
- internal
- confidential
allowed_spaces:
- finance
agents:
- finance-analyst
support:
members_group: quick-support-users
datasets:
- support-orders-sanitized
knowledge_filters:
classification:
- public
- internal
allowed_spaces:
- support
agents:
- support-assistant
agents:
finance-analyst:
identity: quick-agent-finance-readonly
tools:
- query_finance_aggregates
write_actions: []
support-assistant:
identity: quick-agent-support
tools:
- search_product_docs
- lookup_sanitized_order
write_actions:
- create_refund_request
flows:
create_refund_request:
steps:
- validate_user_entitlement
- validate_order_scope
- generate_refund_recommendation
- require_approval:
group: support-supervisors
amount_limit: 500
- execute_refund
audit:
record_prompt: true
record_decision: true
record_approver: true
这个配置体现了几个关键决策：财务 Agent 是只读的；客服 Agent 虽然可以提交退款请求，但不能跳过主管审批；知识库过滤器同时检查文档分类和允许访问的 Space；Flow 负责把校验、建议、审批和执行分开记录。
把审批门做成可测试的代码
审批逻辑不应只存在于流程图或提示词里。可以先用一个小型 Python 函数验证高风险动作是否被拦截，再将相同规则实现到实际 Flow 或后端服务中。
下面的示例只使用 Python 标准库，可以直接运行：
from dataclasses import dataclass
@dataclass
class RefundRequest:
user_role: str
order_owner: str
requester: str
amount: float
reason: str
def decide_refund(request: RefundRequest) -> str:
if request.requester != request.order_owner:
return "deny: order scope mismatch"
if request.amount <= 0:
return "deny: invalid amount"
if request.amount > 500 and request.user_role != "support_supervisor":
return "pending: supervisor approval required"
if not request.reason.strip():
return "deny: reason is required"
return "approved: send to execution flow"
if __name__ == "__main__":
request = RefundRequest(
user_role="support_agent",
order_owner="customer-123",
requester="customer-123",
amount=680,
reason="Duplicate charge",
)
print(decide_refund(request))
将 amount 改为 300 可以看到普通客服请求进入批准状态；将 requester 改成其他客户标识，则会触发范围拒绝。真实系统还应补充租户校验、幂等键、审批超时、审计日志不可篡改存储，以及执行失败后的补偿策略。
从 POC 到生产的验证清单
上线前可以按以下顺序进行一次针对性评审：
- 数据集：确认是否删除了不必要的敏感列，行级过滤是否在服务端生效。
- 身份：确认用户、Agent 和 Flow 使用的身份彼此区分，避免所有组件共用管理员权限。
- Spaces：用不同团队账号交叉测试，确保一个 Space 无法检索另一个 Space 的知识文档。
- 文档：验证分类、负责人、版本和失效日期是否完整；过期文档是否自动停止检索。
- 工具：为每个 Agent 建立允许调用的工具白名单，默认禁止写操作。
- 审批：对退款、导出、发送消息和数据修改等动作设置明确的审批门。
- 审计：记录请求者、Agent 身份、检索来源、Flow 决策、审批人和最终执行结果。
- 异常路径：测试权限不足、知识库不可用、重复执行和审批超时，而不只是测试成功案例。
安全设计的价值不在于让 POC 看起来更复杂，而在于让生产系统的权限边界可以解释、可以测试、也可以追责。Amazon Quick 项目一旦把数据塑形、组件隔离、文档分类和审批控制作为同一条链路设计，安全评审就不再是上线前突然出现的阻塞点，而会成为系统架构的一部分。