数据保留、Redaction 与 Audit

1. 为什么这组知识要一起学

本章从 blast radius 出发：模型不可完全信任，外部内容也不可完全信任，因此安全必须落在 capability、isolation、identity 和 audit。

这几个知识点处在同一条工程链上。如果只记单个名词，很容易在真实系统里把责任放错层：例如让模型管理程序事实、让数据库 transaction 承担外部 API 原子性，或把一个 provider SDK 的行为误认为 Agent 的通用规律。

2. Mental Model

安全目标不是让模型“永远不犯错”，而是把它可能造成的 blast radius 限制在可接受边界。

Untrusted Input/Content → Model Decision → Capability/Permission → Approval → Sandbox/Network/Credential Boundary → Audit

3. 核心机制

Data Retention / Redaction / Privacy

保留策略区分业务 state、trace payload、artifact 与审计记录；敏感字段脱敏，同时审计必须能回答谁在何时批准/执行了什么。

Audit Log

保留策略区分业务 state、trace payload、artifact 与审计记录；敏感字段脱敏，同时审计必须能回答谁在何时批准/执行了什么。

4. 最小实现 / 伪代码

下面代码只表达边界和生命周期，不要求照抄到项目中：

decision = policy.authorize(
    principal=user,
    capability=tool.capability,
    resource=resource_scope,
    risk=tool.risk_level,
)
if decision.requires_approval:
    return interrupt(decision)

真正实现时应把 I/O、状态持久化、错误翻译和策略注入拆成可测试组件，而不是把示例扩成一个巨型函数。

5. 在 Shadow Harness 中怎么落地

PolicyEngine + CapabilitySet + CredentialBroker + SandboxAdapter + AuditLog；未信任 workspace 配置不应在 trust 建立前执行。

建议为本章涉及的行为留下明确的 domain object、interface 和 trace event；只要一个关键行为只能通过读日志猜测，就说明 Runtime contract 仍不够清晰。

6. Production Engineering 检查项

• least privilege
• 凭证按用户/工具/资源最小授权
• network deny-by-default 视场景
• 多租户数据/secret 隔离
• trace 做 redaction/retention

7. Failure Modes

7.1 只靠 system prompt 防注入

当出现「只靠 system prompt 防注入」时，先画 trust boundary 和 capability graph，复现实际可访问文件/网络/secret/tenant，而不是只看模型文本输出。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.2 container = 完整 sandbox

当出现「container = 完整 sandbox」时，先画 trust boundary 和 capability graph，复现实际可访问文件/网络/secret/tenant，而不是只看模型文本输出。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.3 用户频繁点允许导致 approval fatigue

当出现「用户频繁点允许导致 approval fatigue」时，先画 trust boundary 和 capability graph，复现实际可访问文件/网络/secret/tenant，而不是只看模型文本输出。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

7.4 tool result 里的恶意指令被当高权限指令

当出现「tool result 里的恶意指令被当高权限指令」时，先画 trust boundary 和 capability graph，复现实际可访问文件/网络/secret/tenant，而不是只看模型文本输出。 这类问题通常需要修改 contract、policy、state 或 adapter，而不是只追加 Prompt。

8. Trade-offs

人工逐步审批监督强但疲劳；containment 降低 blast radius；成熟系统组合行为监督与能力约束。

设计记录最好明确：当前约束是什么、备选方案有哪些、为什么现在选这个、未来什么条件出现时需要重构。 这样 ADR 才能随着模型和基础设施变化被重新审视。

9. Experiment / Evaluation

红队 indirect prompt injection、路径逃逸、网络 exfiltration、secret read、跨 tenant access，并验证审计记录。

实验应固定数据集、版本和环境，至少记录 success、latency、token/cost、attempt/step 数以及失败类型；涉及随机模型时需要重复运行而不是只看一次结果。

10. 常见问题

基础：Data Retention / Redaction / Privacy 最容易被误解的点是什么？

保留策略区分业务 state、trace payload、artifact 与审计记录；敏感字段脱敏，同时审计必须能回答谁在何时批准/执行了什么。

机制：这些能力在一次 Run 的哪个生命周期阶段生效？

沿着 Untrusted Input/Content → Model Decision → Capability/Permission → Approval → Sandbox/Network/Credential Boundary → Audit 找位置，并明确它的输入、输出、持久化事实和失败传播。

工程：如果这一层失败，应该由谁恢复？

先区分 transient failure、invalid input、permission、semantic failure 与 irreversible side effect。恢复策略属于拥有该状态与副作用的 Runtime/adapter，而不是交给模型自由决定。

设计：规模扩大 10 倍后，哪个假设最先失效？

优先检查 context/token、并发/连接池、catalog 大小、持久化吞吐、trace 体积、身份与租户隔离。不要默认“多加机器”能解决语义和一致性问题。

11. Sources

• Anthropic — How we contain Claude across products
• OWASP — Top 10 for Large Language Model Applications
• OpenAI Agents SDK — Sandbox concepts

12. 本文结论

掌握本文的标准不是能背定义，而是能画出数据流、写出最小 contract、解释失败恢复，并用测试或 benchmark 证明设计没有只停留在概念层。