Agent Security、Trust 与 Governance 深度讲义

研究基线：2026-08-03。本文是 AI_AGENT_SYSTEMATIC_KNOWLEDGE.md Part 12 的专题展开，以 Coding Agent 为主要对象。公开产品实现会快速变化；Kimi Code 映射基于 MoonshotAI 公开仓库 e22479a（2026-08-01），不推断未公开的生产架构。

证据状态与措辞约定

本文在 2026-08-03 做过第二次线上 freshness audit。为避免把“框架、草案、论文、厂商实践和本文建议”混成同等强度的事实，按以下语义阅读：

未特别标成规范事实的“应、必须、最佳”均是本文的 risk-based engineering 建议。MUST / SHOULD 只有在明确引用协议规范时才按 RFC 2119/8174 解读。

截至 2026-08-03 的权威状态快照

0. 先把安全问题定义对

Agent 安全不是“模型会不会拒绝坏请求”，而是：

在用户、模型、工具、代码、网络内容、持久状态和其他 Agent 都可能出错或被攻击时，系统仍只执行有来源、有权限、有边界、可追责的 effect，并把最坏后果限制在可接受 blast radius 内。

它至少同时保护五种性质：

一个关键区分：

model safety   = 模型更可能做出安全选择
system security = 在明确假设和已建模边界内，即使模型做出不安全选择，系统控制仍限制其能力与后果
governance     = 谁定义边界、如何证明它有效、何时更新、出事后谁负责

Prompt、instruction hierarchy、safety training 都有价值，但它们是概率性防御。权限校验、sandbox、credential scope、network egress 和 tamper-evident receipt 能形成模型之外的系统强制边界；这不等于绝对安全，仍依赖 policy 正确性、sandbox/OS/identity 基础设施和实现没有可利用缺陷。

1. Security Ontology：对象、关系与不变量

1.1 资产不是只有 secret

对 Coding Agent 做 threat model 时，至少枚举以下资产：

“用户意图”本身是最高价值资产之一。如果系统保住了密钥，却让恶意 README 把“审计依赖”改成“发布包”，安全仍然失败。

1.2 Principal、Identity、Authority、Capability、Intent、Effect 必须分开

这些概念经常被混为一谈：

• Principal：可以承担身份和责任的主体，如用户、Agent instance、MCP server、CI workload；
• Identity：系统用来识别 principal 的声明及证明；
• Authentication：验证“你是谁”；
• Authority：你被允许代表谁、在什么边界内决定什么；
• Capability：能对某类对象执行某类操作的可行权凭证或接口；
• Intent：当前任务明确要求的目标与限制；
• Action：计划或请求的操作；
• Effect：环境中实际发生的状态变化；
• Receipt：可验证地描述 effect 的证据。

核心关系不是“用户登录了，所以 Agent 什么都能做”，而应是：

human identity
  └─ delegates bounded authority
       └─ to one agent instance / task
            └─ which receives scoped capabilities
                 └─ policy authorizes a concrete action
                      └─ executor produces a bounded effect + receipt

身份不自动等于权限；权限不自动等于当前意图；调用成功也不自动等于 effect 正确。

1.3 Capability grant 的完整语义

一个可治理的授权至少应表达：

grant:
  issuer: human_or_policy_principal
  subject: agent_instance_id
  audience: exact_tool_or_service
  action: repo.push
  resource: org/repo@branch
  constraints:
    max_diff_lines: 500
    force_push: false
    network_destinations: [github.com]
  purpose: task_id + user_intent_hash
  valid_from: timestamp
  expires_at: timestamp
  single_use: true
  delegation_depth: 0
  approval_id: optional

这比把用户长期 token 放进 Agent 环境强得多，因为它同时解决 audience、scope、lifetime、purpose、delegation 和 replay。

1.4 Trust 不是 boolean 的万能标签

“trusted workspace”只能回答一个局部事实。更完整的 trust 是一个向量：

Trust(subject, claim, scope, time, evidence)

例如：

• 信任某仓库的源码可读，不等于信任其 .mcp.json 可执行；
• 信任一个 MCP server 的发布者，不等于信任每次 tool output 都没有 injection；
• 信任用户有云权限，不等于当前任务授权删除资源；
• 信任一次测试通过，不等于 artifact 未在测试后被替换；
• 信任某条 memory 曾经正确，不等于它在当前版本仍有效。

应按 claim 分离 trust：source authenticity、content integrity、instruction authority、execution privilege、freshness、tenant boundary。

1.5 Security invariants

优秀设计先写目标不变量，再选防御。以下是设计目标，不是本文声称任一现有产品已经满足的事实：

1. 不可信内容不会仅因进入 context 而获得指令 authority；
2. 每个 consequential effect 都能追溯到可信 user intent 或显式 policy；
3. 模型不能给自己扩大 capability、延长 token、改变 approval 或关闭审计；
4. secret 默认不进入模型 context、tool output、trace 或 sandbox；
5. 未授权目的地即使由合法工具请求，也无法收到数据；
6. workspace 内的文件不能自我声明 workspace 已被信任；
7. path policy 在 symlink/realpath、mount、大小写、TOCTOU 后仍成立；
8. 子 Agent 获得的权限不超过父 Agent 可委派权限；
9. memory 写入必须有 provenance、schema、scope、TTL 和验证状态；
10. 重试、恢复和 replay 不会重复产生未知副作用；
11. policy、identity 和 tool catalog 更新会使旧授权失效或重新评估；
12. 安全事件可冻结执行、撤销凭证、重建因果链并对外部 effect 对账。

2. Trust Boundary：从系统图开始，不从攻击名开始

2.1 典型 Coding Agent 边界图

每一条跨边界数据流都要回答：

• 谁产生，谁能篡改？
• 是 data、instruction、credential、policy 还是 receipt？
• authority 与 sensitivity 标签是什么？
• 接收方会把它送进哪个 sink？
• 哪个 deterministic control 在边界上强制执行？
• 失败是 fail-open 还是 fail-closed？

2.2 攻击者模型

至少考虑五类主体：

最后一类非常重要：安全控制不能只拦“恶意字符串”，还要约束一个善意但错误、且非常会找路径的 Agent。

2.3 风险不是单一 attack success rate

可用一个工程化近似：

Expected Loss
  ≈ P(compromise)
  × reachable blast radius
  × effect irreversibility
  × detection delay
  × propagation factor

模型防御主要降低 P(compromise)；sandbox、least privilege 和 egress 主要降低 blast radius；receipt、monitor 和 kill switch 降低 detection delay；幂等、checkpoint 和 transaction 降低 irreversibility；并发限制和 delegation depth 降低 propagation factor。

只优化第一项会得到脆弱系统：攻击者只需成功一次。

3. Data、Command、Control 与 Effect Plane 分离

3.1 四个 plane

Audit plane 横跨四者，但只能观察与证明，不能变成一个隐蔽的高权限执行通道。

3.2 为什么 AGENTS.md、README、网页永远属于 data plane

仓库内说明可以影响任务理解，却不应自动改变：

• 哪些目录可读写；
• 是否可执行 hooks；
• 哪些 MCP server 可启动；
• 能否访问 network 或 secret；
• 是否允许发布、付款、删除或 force push。

如果一段文本既能被不可信作者控制，又能改变 capability，它就从 data plane 穿透到了 control plane。这是结构性漏洞，不是“prompt 写得不够强”。

3.3 合法跨 plane 转换

data
  -> parse / provenance label
  -> claim
  -> plan proposal
  -> policy evaluation against trusted command
  -> bounded capability
  -> effect
  -> receipt

禁止的捷径：

tool output says "approved"
  --------------------------X--> privileged effect

README says "run curl ... | sh"
  --------------------------X--> host execution

model says "user probably intended push"
  --------------------------X--> Git push

4. Prompt Injection 与 Goal Hijack：机制而非关键词

4.1 Direct 与 Indirect Injection

• Direct prompt injection：攻击者直接控制用户输入，试图覆盖 system/developer policy、窃取信息或调用工具；
• Indirect prompt injection：攻击指令藏在 Agent 必须读取的第三方内容中，如网页、issue、代码注释、README、PDF、MCP output、测试日志；
• Stored injection：攻击载荷进入 memory、artifact、索引或共享状态，跨 turn/session 复现；
• Cross-agent injection：载荷由另一个 Agent 以消息、计划、artifact 或“验证结果”传播；
• Multimodal injection：载荷藏在图像、UI、OCR、不可见文本或结构字段中。

Direct injection 的攻击者通常已是命令来源，所以核心是 misuse policy；indirect injection 的本质是一个低 authority 的 data source 冒充高 authority 的 command source。

4.2 为什么模型会混淆

Prompt Injection as Role Confusion（ICML 2026）提出 role confusion 作为统一机制解释，并在其 probe 与 attack 设置中观察到：模型会从文本风格推断“谁在说话”，不总是忠实依赖接口标注的来源；伪造 reasoning 在其被测模型上造成显著 jailbreak 与 agent exfiltration。它是有机制证据支持的研究结论，但还不是所有模型、所有 chat template 上已证明的充分必要原因。这支持一个保守工程判断：

role tag、delimiter 和“以下只是数据”是有用的信号，但不是密码学意义上的 source authentication。

模型无法仅靠自然语言可靠地区分“网页中的一句命令”和“用户的一句命令”，因为两者最后都成为 token。来源与权限必须由 harness 保留，并在模型之外执行。

4.3 Goal hijack 的完整链条

attacker-controlled content
  -> gains attention
  -> is misclassified as instruction / evidence
  -> modifies goal, constraint, plan or verifier
  -> requests a legitimate tool
  -> policy sees only tool name, not provenance
  -> external effect

防御不能只在第一步检测恶意文本。更稳健的办法是在每一层破链：

• retrieval 只取必要内容；
• 保留 source/authority 标签；
• 不让不可信内容修改 goal invariant；
• action 必须证明服务于用户目标；
• capability 与 effect 独立校验；
• secret 与高风险 sink 不对模型开放；
• 结果必须有 receipt 与异常监测。

4.4 Annotation 与 Channel Closure

两类防御必须区分：

Annotation：

• delimiter、XML tag、quoted block；
• system prompt 中声明外部内容不可信；
• injection classifier 或提示模型“忽略恶意指令”；
• 在工具输出前添加 warning。

它们降低成功率，但攻击内容仍在同一模型可见通道，仍有机会影响决策。

Channel closure：

• 从 context 中移除无关敏感数据；
• 对不可信内容只暴露结构化、最小字段；
• 把 state-changing tool 从该 Agent 的 capability set 中移除；
• tenant/identity filter 在 retrieval 前执行；
• secret broker 不把 secret 返回给模型；
• egress proxy 阻断未授权目的地；
• policy enforcement point 不接受“文本中的批准”；
• 让 untrusted-data processor 只输出带 provenance 的 claims，不直接行动。

Channel closure 的判据是：即使模型完全服从 injection，未经授权的信息流或 effect 仍不可达。

AgentSecBench是 2026-05-25 提交的 arXiv preprint；它把这一差异形式化为 instruction integrity、retrieval confidentiality 与 capability integrity 三类 game，并用“intent-to-execution noninterference with permitted leakage”描述目标。它的重要边界也很清楚：exact-marker 实验只使用 Qwen3-0.6B/1.7B，是有明确 oracle 的可观察实例，不是完整 semantic-security 证明；其证据支持的是 projection、capability restriction、output validation 在该形式化和实验中比 prompt annotation 更接近 enforcement。

4.5 Influence Provenance

Data provenance 只回答“信息从哪来”；influence provenance 还要回答“它如何影响行动”。

每个节点至少有：

id: stable_id
kind: source | observation | claim | decision | action | effect
origin: principal + channel + artifact hash
authority: policy | user_command | trusted_config | untrusted_data | model_derived
sensitivity: public | internal | confidential | secret
tenant: tenant_id
integrity: signed | verified | unverified
scope: task / workspace / session / global
parents: causal inputs
transform: parser / model / tool / human
confidence: optional

对高风险 action，gate 应检查：

1. 是否能追溯到当前用户目标；
2. 每个关键参数是否有可信或经验证的 grounding；
3. 是否存在只由 untrusted source 支撑的权限扩大；
4. goal invariant 是否在计划转换中保持；
5. evidence 是否新鲜且属于当前 tenant/version。

ARGUS / AgentLure 把这一思路实现为 influence provenance graph，并在其设置中报告 3.8% attack success 与 87.5% task utility。数字不能外推到所有 Agent，但它支持一个重要方向：审计 source-to-action causal chain，而非只分类某段文本是否像 injection。

4.6 Taint 不是“恶意/安全”二值

更实用的标签是多维 lattice：

source trust:     trusted command > authenticated data > anonymous data
sensitivity:      public < internal < confidential < secret
integrity:        verified > signed-unverified > unverified > attacker-controlled
tenant scope:     same tenant / cross tenant / unknown
freshness:        current > stale > invalidated

传播规则示例：

• 拼接后 sensitivity 取最高；
• 由 untrusted observation 推导的 claim 默认仍 untrusted，除非被独立 verifier 证实；
• summary/compaction 不得提升 authority；
• LLM 转述不构成 declassification；
• artifact hash 验证可提升 integrity，但不能提升 instruction authority；
• user approval 只批准精确 effect，不把输入内容整体变成 trusted。

典型 sink policy：

secret-tainted data -> only approved audience-bound destinations
untrusted-influence action -> no consequential write without trusted grounding
cross-tenant data -> never enter current tenant context
stale memory -> no authorization or destructive decision

5. OWASP Agentic Top 10：从风险名展开到控制路径

OWASP Top 10 for Agentic Applications 2026 于 2025-12-09 发布；截至 2026-08-03，官方页面仍列出同一组 ASI01–ASI10。2026-06-01 的 State of Agentic AI Security and Governance 2.01 是补充治理报告，没有替换这十类风险。Top 10 是 threat discovery checklist，不是完整 threat model、强制标准或产品认证。以下按“攻击机制—根因—控制—测试”展开。

5.1 ASI01 Agent Goal Hijack

机制：直接/间接输入修改 Agent 的目标、优先级、约束、完成条件或 verifier。

根因：

• goal 只是可被后续 token 覆盖的自然语言；
• command 与 data 混在同一 context；
• compaction 丢失用户硬约束；
• tool output 可以修改 plan without provenance；
• completion 由 Agent 自己声明。

控制：

• 把 goal、non-goal、禁止 effect、验收条件存成 control-plane state；
• 每个 action 做 goal alignment / invariant check；
• 不可信内容只能贡献 claims，不能写 goal；
• verifier 与 actor 分离；
• goal/version hash 绑定 approval 和 capability grant。

测试：在 README、issue、网页、tool error、test output 中放置互相冲突且“有帮助”的指令，检查 Agent 是否仍保留原始目标并拒绝越权 effect。

5.2 ASI02 Tool Misuse & Exploitation

机制：使用合法工具产生错误目标、错误参数、错误对象或过大范围的 effect。

典型错误：

• 用 shell 绕过结构化 file tool 的 path/secret guard；
• 把 read-only 调研升级为 API mutation；
• 使用 git push --force 完成普通同步；
• 将 tool output 中的 URL 直接交给 shell；
• 并行调用写同一 resource，产生 race/corruption；
• 对未知副作用操作自动 retry。

控制：capability 以 effect × target × scope 建模；typed tool schema；参数规范化；policy 在 executor 前强制；effect budget；幂等键；receipt；危险工具拆成更窄接口。

5.3 ASI03 Identity & Privilege Abuse

机制：Agent、MCP 或攻击者滥用用户/服务身份，扩大 scope、跨 tenant、token replay 或 confused deputy。

根因：ambient credential、shared service account、缺 audience、长 lifetime、无 delegation chain、state handle 被当作认证。

控制：

• 每任务 ephemeral agent identity；
• on-behalf-of delegation 与 workload identity 分离；
• audience-bound、short-lived token；
• token exchange，不透传用户 token；
• capability grant 绑定 task/intent/resource；
• revoke、rotation、non-repudiation；
• service 端重新校验 principal，不相信客户端传来的 user ID。

NIST 2026 identity concept paper 把 agent identification、authentication、dynamic authorization、least privilege、delegation、human binding、audit/non-repudiation 作为一条完整链，并讨论 OAuth/OIDC、SPIFFE/SPIRE、SCIM、NGAC 与 Zero Trust 的适配：NIST NCCoE Agent Identity and Authorization。

5.4 ASI04 Agentic Supply Chain Vulnerabilities

Agent 供应链比普通依赖更宽：

model + provider adapter + system prompt + skill + hook + plugin
+ MCP server + tool schema + container image + package manager
+ benchmark + verifier + memory seed + telemetry processor

攻击方式包括 typosquatting、恶意更新、tool description 改义、schema drift、startup command、被污染的 skill、远程 MCP 变更、模型/adapter 替换、签名 artifact 与实际执行内容不一致。

控制：

• 来源 registry、版本 pin、digest lock、签名与 provenance；
• SBOM 覆盖 runtime、MCP、skills 和 images；
• 安装与启用分离；
• tool catalog diff 和 schema diff 需要 review；
• 默认不执行 workspace 自带 hook/MCP；
• local server 作为本机软件处理，隔离其 process/network/filesystem；
• staged rollout、canary、可回滚版本；
• 定期重建与撤销 compromised signer。

签名只证明“谁发布了什么”，不证明内容安全；仍需 capability containment。

5.5 ASI05 Unexpected Code Execution

入口：shell 拼接、模板注入、解释器、package lifecycle script、Git hook、MCP stdio startup、浏览器 URL scheme、反序列化、生成代码后自动运行、测试命令本身。

控制层次：

1. 不把字符串交给 shell；参数用 argv；
2. 危险 scheme 与重定向在 URL parser 后校验；
3. package install/build/test 一律视作代码执行；
4. process 放在 sandbox/VM，限制 syscall、mount、user、child tree、resource；
5. 默认禁网，必要 egress 经代理；
6. credential 不进入执行环境；
7. output 和 artifact 按不可信数据处理；
8. 将生成、执行、验证、发布分成不同 authority。

5.6 ASI06 Memory & Context Poisoning

短期 context poisoning 改变当前决策；长期 memory poisoning 把错误、恶意规则或跨 tenant 数据固化为未来系统状态。

攻击面：

• 原始 trace 直接成为 memory；
• Agent 自我总结时提升某条内容 authority；
• compaction 丢失“这是未验证信息”；
• 成功/失败 reward 被污染；
• shared memory 被低权限 Agent 写入；
• stale workaround 在新版本继续生效；
• evaluator bias 通过 memory 反复放大。

安全 memory item：

claim: typed content
source_ids: exact provenance
writer: agent/principal identity
scope: repo + branch + task class
authority: data_not_policy
confidence: calibrated
validation: verifier + timestamp + artifact hash
created_at: timestamp
expires_at: timestamp
invalidates_on: dependency/schema/policy version
tenant: tenant_id
write_policy: who may update/delete

Memory 读取不能给其高于原始来源的 authority；写入、合并、压缩、删除都是需要单独评测的 state transition。

TrustMem把 memory transition 分成 coverage、preservation、faithfulness，并把 omission、corruption、unsupported hallucination 当作持久系统状态失败。在其 benchmark 设置中，相对各错误类型的最强 baseline，三类 transition error 分别降低 40.1%、79.1% 和 50.0%；这些数字不应外推，但说明 memory 安全评测的对象应是“旧状态→更新操作→新状态”，不只看未来回答是否偶然正确。

5.7 ASI07 Insecure Inter-Agent Communication

多 Agent 新增的不是“更多消息”，而是 identity、delegation、artifact 和 causal chain 的组合风险：

• agent impersonation；
• 消息重放、乱序、跨 task 注入；
• 父 Agent 把全部权限复制给子 Agent；
• 子 Agent 伪造“已验证”“用户批准”；
• shared scratchpad 污染；
• artifact substitution；
• tool result 被 coordinator 当成可信 command；
• 恶意 Agent 诱导另一个 Agent 成为 confused deputy。

最小安全 envelope：

message_id: uuid
sender_identity: workload identity
receiver_identity: exact agent/task
task_id: immutable
parent_delegation_id: grant chain
message_type: claim | proposal | request | receipt
payload_hash: digest
artifact_refs: content-addressed
authority: explicit, never inferred from prose
issued_at: timestamp
expires_at: timestamp
nonce: replay protection
signature: sender proof

子 Agent 默认只返回 claim/proposal；只有显式授予 capability 的 executor 才能产生 effect。

5.8 ASI08 Cascading Failures

级联来自：错误输出被下游信任、并行 fan-out、自动重试、共享身份、无预算、无 backpressure、错误 memory 扩散、多个 Agent 同时写同一资源。

控制：

• concurrency、depth、time、cost、effect budget；
• circuit breaker 与 admission control；
• 独立 verifier 不继承 actor 的假设；
• write-set 冲突检测与 serializable effect；
• retry 只对已知 transient、幂等或可证明未产生 effect 的操作；
• global kill switch 与 credential revoke；
• propagation-aware risk：扇出越大，单 action 阈值越严；
• failure containment cell：按 task/tenant/workspace 分区。

5.9 ASI09 Human-Agent Trust Exploitation

攻击的不只是 Agent，也包括人的注意力：

• approval fatigue；
• 用“系统需要”“已验证”伪造 authority；
• 在巨大 diff 中隐藏危险变化；
• 把高风险动作包装成普通技术步骤；
• 让用户确认工具名而非实际 effect；
• 先高质量完成 benign task，利用用户形成 automation bias；
• 多 Agent 并行让人无法监督实际 action volume。

Anthropic 公开经验显示大量 approval 被用户直接放行，OS-level containment 可以大幅减少低价值 prompt；其 2026 containment 文章把监督“行为”与限制“能力”明确分开：How we contain Claude across products。

优秀 approval 显示：主体、目标、参数、数据去向、不可逆性、diff/preview、为何超出既有 grant、批准范围与有效期。批准必须生成可验证、单次、参数绑定的 authorization artifact，而不是把一个自然语言“yes”塞回模型。

5.10 ASI10 Rogue Agents

“Rogue”不必假定模型有长期恶意意图。只要 Agent 持续偏离目标、隐藏行为、抵抗停止、修改 safeguards、复制自身、保留凭证或跨任务继续行动，就应按 rogue behavior 处置。

控制：

• Agent 不能修改自己的 policy、monitor、credential broker；
• control plane 与 workspace/actor 隔离；
• lease-based execution，续租需健康与 policy 检查；
• heartbeat 之外还要 effect-rate、destination、policy-denial、goal-drift monitor；
• kill switch 位于 Agent 不可达平面；
• snapshot + revoke + terminate 顺序固定；
• monitor 不是唯一防线，因为 monitor 本身有漏报、延迟和被规避风险。

OpenAI 2026 内部 coding-agent monitoring 明确关注 Agent 访问 safeguards、试图修改 safeguards、以及影响未来版本的行为。它支持的是 defense-in-depth 中的监测层，不意味着监测可替代 least privilege 或 containment。

6. Attack Trees：找到必须同时闭合的路径

6.1 根目标：产生未授权 consequential effect

Unauthorized effect
  AND
  ├─ Obtain decision influence
  │   OR direct user misuse
  │   OR indirect prompt injection
  │   OR poisoned memory / compaction
  │   OR malicious subagent / MCP output
  │   OR model error
  ├─ Reach a capability
  │   OR ambient host shell
  │   OR over-scoped token
  │   OR unsafe MCP/tool
  │   OR approval escalation
  │   OR supply-chain executable
  └─ Defeat or bypass enforcement
      OR no PEP exists
      OR policy checks only tool name
      OR shell bypasses file-tool guard
      OR symlink/TOCTOU escape
      OR token audience not checked
      OR user rubber-stamps approval

这个 AND-tree 带来重要判断：不必幻想完全消灭 decision influence。只要 capability 和 enforcement 形成硬边界，攻击也不能落地；反之，模型防御再强但 host shell + secret + unrestricted network 同时开放，尾部风险仍不可接受。

6.2 根目标：secret exfiltration

Exfiltrate secret
  AND
  ├─ Acquire secret
  │   OR model context already contains it
  │   OR read credential file
  │   OR env / process / metadata service
  │   OR tool output / trace
  │   OR cross-tenant retrieval
  └─ Reach exfiltration sink
      OR unrestricted network
      OR allowed domain with attacker-controlled path/body
      OR Git commit/push
      OR issue/comment/email/MCP call
      OR DNS / timing / error-message side channel

所以只做 network deny 或只做 secret masking 都不够。最强结构是 secret 不进 sandbox/model，同时 egress 只允许 audience-bound brokered action。

6.3 根目标：跨会话持久化控制

Persistent compromise
  OR poison long-term memory
  OR modify workspace instruction/config/hook
  OR install skill/plugin/MCP/dependency
  OR alter policy/approval rule
  OR plant code that future agent executes
  OR obtain long-lived credential

检测一次异常 action 后，仅终止当前 process 不足以恢复；必须检查所有 persistence surfaces。

7. System-enforced Containment：把 blast radius 变成可检验的系统属性

这里的“system-enforced”只表示控制位于模型之外，并能对已声明的 resource/effect 强制执行；不表示 sandbox、hypervisor、proxy 或 policy 没有漏洞。可信结论必须写成：在给定版本、配置、攻击者能力和依赖假设下，哪些资源不可达、哪些 effect 被限制。

7.1 五类边界

Anthropic 2025 sandboxing 文章强调 filesystem 与 network isolation 必须组合；其公开遥测声称 sandbox 让其内部使用中的 permission prompt 降低 84%，这是特定产品数据，不是通用 benchmark：Claude Code sandboxing。OpenAI 2026 的公开内部部署文章同样把 sandbox 视为技术执行边界，把 approval policy 视为越界时的决定机制；它描述的是 OpenAI 自身配置，不构成第三方安全认证：Running Codex safely at OpenAI。

7.2 Sandbox 设计判断

本机 OS sandbox：启动快、开发体验好；但 host integration 多，必须认真处理 path、socket、process、network proxy 与平台差异。

Ephemeral container：环境可复现、隔离较强；但 kernel shared、credential/volume 配置易形成逃逸通道。

Sealed VM / microVM：blast radius 最清晰；成本、启动、文件同步与可观测性更复杂。

Remote devbox：适合长任务和持久 cache；必须处理 tenant isolation、credential broker、snapshot、idle lifecycle 与 residual data。

选择标准不是“哪种最安全”，而是：

required capability
× tolerated blast radius
× data locality
× persistence need
× startup/latency budget
× observability/compliance

7.3 Filesystem：realpath、symlink 与 TOCTOU

可靠 path authorization 顺序：

1. 拒绝空路径、非法 scheme、drive-relative/UNC 等平台特例；
2. 解析相对路径与 canonical separator；
3. 对现存父路径做 realpath，检测 symlink/mount escape；
4. 检查最终对象是否位于允许的真实 root；
5. 打开对象时尽量使用 directory handle / openat 风格与 no-follow flag；
6. mutation 前后验证 inode/handle，避免 check-use 之间替换 symlink；
7. archive extraction 防 ../、absolute path、symlink entry；
8. watcher、glob、Git 和 shell 路径也必须遵守同一边界。

“file tool 做了 path guard”不等于“Bash 里的 cat/cp/tar 也受同一限制”。真正边界必须在 OS/executor 层。

7.4 Process 与 shell

Shell 是一整套 process lifecycle，不是字符串工具。安全执行需要：

• argv 与 shell mode 明确区分；
• cwd、env allowlist、umask、user/group 固定；
• stdout/stderr size、duration、CPU、memory、disk、PID 限额；
• child process tree 可取消、可清理；
• PTY 与 non-PTY 分离；
• 后台进程、daemon、socket、port 建账；
• package lifecycle scripts 视为 untrusted code；
• command intent 与实际 execve/audit event 对账；
• 未形成完整合法 tool call 的流式半包绝不执行。

7.5 Network egress

Domain allowlist 不是完整 egress policy。策略至少包含：

destination:
  scheme: https
  hostname: api.github.com
  resolved_ip_class: public_only
  port: 443
request:
  methods: [GET, POST]
  path_templates: [/repos/{allowed_repo}/...]
  max_body_bytes: 1048576
  sensitivity_allowed: internal
redirects: same_policy_recheck
dns: resolve_and_pin_or_revalidate
identity: brokered_audience_token
logging: metadata_only

必须处理：private/reserved IP、cloud metadata、localhost、DNS rebinding、redirect、proxy bypass、IPv6、alternate encoding、WebSocket、DNS exfiltration、allowed-domain user content endpoint。

MCP 2026-07-28 官方安全实践明确讨论 OAuth metadata SSRF、private IP、metadata endpoint、DNS rebinding、redirect，以及 stateless state-handle hijacking：MCP Security Best Practices。

“允许域”尤其不能直接等价于“允许能力”。Anthropic 2026 事故复盘披露：其 egress allowlist 合法放行 api.anthropic.com，攻击内容却使用攻击者自己的 API key 把 workspace 文件上传到攻击者账号；sandbox 与 destination check 都按设计工作，数据仍被泄漏。其修复把 token provenance 和具体 API 能力纳入 proxy policy。这是厂商披露的单一事件，但直接证明 domain-only allowlist 的控制能力边界：How we contain Claude across products。

7.6 Secret broker

最佳状态是 Agent 只知道“可以请求某个操作”，不知道 credential：

Agent requests: push commit X to repo R branch B
  -> policy validates intent/grant
  -> broker mints single-purpose credential or performs operation
  -> target verifies audience/scope
  -> broker returns receipt, not secret

如果必须向 process 注入 secret：

• task-scoped、短 lifetime、最小 audience/scope；
• 不进入 command line、prompt、tool result、trace；
• 用 fd/socket/file mount 等更窄通道，使用后撤销；
• outbound destination 与 credential audience 联动；
• redaction 只作为最后一层，不能假定覆盖所有编码/分片/派生值；
• security incident 时能按 task/agent/grant 快速 revoke。

7.7 Allowlist、denylist 与 capability discovery

Allowlist 决定 Agent 根本看见和能调用什么；denylist 适合覆盖已知绝对禁止项；两者不能互换。

安全顺序：

enterprise deny
  > tenant/workspace deny
  > task capability allowlist
  > agent profile allowlist
  > session approval
  > fallback deny/ask

越靠近模型才做 filtering 越弱。Tool catalog 不仅影响安全，也影响模型决策；动态加入工具应触发 policy 和 context 重评。禁止工具不应只从 prompt 中隐藏，还要在 executor 再校验。

7.8 Tool contract

每个 tool 应声明：

name: exact_versioned_name
input_schema: strict
effect_class: read | reversible_write | external_write | destructive
resources: filesystem/git/network/cloud
idempotency: yes/no/conditional
required_capabilities: [...]
sensitivity_in: [...]
sensitivity_out: [...]
timeout_and_budget: {...}
receipt_schema: {...}
reconciliation: how_to_detect_partial_effect

Tool description 是给模型的 affordance，不是 enforcement。Policy 必须基于规范化后的实参、解析后的真实资源和运行时 context 决定。

8. MCP、Plugin、Hook 与 Supply-chain 边界

8.0 协议版本和责任边界

规范事实（as of 2026-08-03）：MCP 2026-07-28 final specification 已发布；versioned specification 将自身定义为 authoritative protocol requirements。2026-05-21 官方文章标题中的 “Release Candidate” 描述的是当时状态，并明确预告 final 于 2026-07-28 发布；现在讨论实现时应锁定 final versioned docs，而不是继续称它为 RC：MCP 2026-07-28 specification、RC announcement and release timeline。

能力边界：MCP 规范自己明确说明，协议虽规定 consent、privacy、tool-safety 原则，却不能在协议层替 host 强制这些原则；host/runtime 仍要实现 authorization flow、tool policy、sandbox、data protection 与 approval。MCP 标准化连接和消息，不自动建立 server publisher trust、tool semantic correctness、prompt-injection immunity 或 end-to-end delegated authority。

8.1 MCP 不是“安全的 JSON 工具”

MCP 同时带来：

• capability discovery 膨胀；
• tool description/schema 的语义供应链；
• remote content injection；
• OAuth delegation 与 confused deputy；
• local stdio server 的本机代码执行；
• state handle、tenant 和重放问题；
• proxy 到 downstream API 的 identity/audience 问题。

MCP 2026-07-28 官方安全实践明确禁止 remote authorization flow 中的 token passthrough，并要求 MCP server 只接受明确签发给自己的 token；原因包括 audience 绕过、审计丢失和 confused deputy：MCP Token Passthrough。这不表示所有 MCP transport 都自动使用 OAuth：官方 authorization tutorial 说明 remote HTTP server 的 authorization 是可选协议能力，而 local stdio server 往往使用 host/local environment 的 credential 机制，因此仍需单独 threat model。

8.2 安全连接流程

discover server metadata
  -> validate URL / SSRF policy
  -> verify publisher + pinned version/digest if local
  -> show exact requested scopes/audience
  -> per-client consent + PKCE/state
  -> token issued for MCP server
  -> discover tool catalog
  -> schema/policy diff
  -> task-scoped tool allowlist
  -> all outputs marked untrusted data

8.3 Local MCP / Hook / Skill

Local MCP server 与 hook 是本机软件，不是“几段配置”。安全要求：

• workspace trust 前不读取/执行项目级 startup 配置；
• command、cwd、env、package digest 可审计；
• process sandbox 与 child tree 隔离；
• localhost 服务有认证且防 DNS rebinding；
• skill 只能影响提示/知识，不自动获得工具权限；
• hook 的 deny 可作为附加 gate，但 hook 的 allow 不能覆盖更高层 deny；
• hook output 仍是不可信 input；
• 更新、撤销和 quarantine 路径明确。

MCP 官方文档还指出，在 stdio proxy 架构里，客户端 XSS 与 proxy token 被盗可能升级为任意 child-process spawn，因此 transport 本身和周边 proxy authority 必须分开分析。

8.4 A2A v1.0：认证钩子不等于 Agent 间信任闭包

官方状态：A2A 的 stable specification lineage 是 v1.0；GitHub 最新 tag 为 v1.0.1（2026-05-26），其 release notes 是 media type、transcoding error 和 task-status 的 bug fix。官方 specification 页面仍把 “Latest Released Version” 标为 1.0.0，因此最准确的说法是“v1.0 specification，最新 patch tag v1.0.1”，而不是虚构 v1.1 security semantics：A2A v1.0 specification、A2A releases。

规范已经覆盖：

• production HTTP/gRPC transport 的 TLS；
• Agent Card 中声明 security schemes，credential 通过 out-of-band 流程取得；
• server 对每个请求认证，并按 skill/action/data/scope 做 implementation-defined authorization；
• task/list/get/cancel/subscribe/push-config 等 operation 在查询或泄漏资源存在性之前按 caller scope 过滤；
• Agent Card 可用 JWS 签名，authenticated extended card 需要访问控制；
• in-task credential 应优先通过安全 out-of-band channel 交付；若使用 in-band chain，规范建议把 credential 绑定给最初请求 Agent 并限制可读者。

规范没有自动解决：

• Agent Card 只声明 capability/auth requirement，不证明 skill 行为安全、输出真实或当前实现未被攻陷；
• transport authentication 证明 caller identity，不证明消息中的 claim、approval 或 user intent 有 authority；
• authorization model 由每个 Agent 实现，A2A 不替系统定义 delegation attenuation、purpose binding、descendant revoke；
• schema validation/sanitization 不足以解决 prompt injection、memory poisoning 和 influence propagation；
• signed artifact 证明来源与完整性，不证明内容正确或允许被执行。

因此 A2A 消息仍应携带 task/delegation/provenance envelope；receiver 必须重新授权本地 effect，不能把远端 Agent 的“已批准”“已验证”文本当作 control-plane fact。

9. Authorization、Policy Enforcement 与 Approval

9.1 PDP、PEP、Executor 三分

Agent proposes action
  -> normalizer resolves actual resource/effect
  -> PDP evaluates policy
  -> PEP enforces deny/allow/ask
  -> approval broker may mint bounded grant
  -> executor acts inside sandbox
  -> receipt reconciles actual effect

• PDP（Policy Decision Point）决定；
• PEP（Policy Enforcement Point）必须位于无法被模型绕过的执行路径；
• Executor 不重新解释自然语言批准，只接受结构化 grant。

9.2 Policy 输入

subject:
  human: user_id
  agent: instance_id + profile + model
  delegation_chain: [...]
action:
  tool: name + version
  effect: normalized effect class
  args_hash: hash
resource:
  canonical_target: real path / repo / API object
context:
  task_id: id
  goal_hash: hash
  workspace_trust: state
  sandbox: profile
  influence: provenance summary
  risk: score + reasons
  time/budget: remaining
environment:
  identity_scope: ...
  network_destination: ...
  data_sensitivity: ...

只按 tool_name == Bash 判断权限过于粗糙；只按命令文本做 regex 又无法可靠解析 shell、重定向、脚本和运行时行为。正确方向是窄工具优先，shell 用 OS containment + effect monitor 收敛。

9.3 决策顺序

建议的语义：

1. immutable enterprise/tenant deny；
2. workspace trust 与 identity boundary；
3. tool/capability allowlist；
4. sensitivity、egress、resource policy；
5. session/task grant；
6. risk-based approval；
7. default deny 或最小 read-only fallback。

任何低层 allow 都不能覆盖高层 deny。Policy evaluation 必须有 version、命中规则、输入摘要和决定原因。

9.4 什么时候 ask，什么时候自动化

适合自动允许：

• sandbox 内、低风险、可逆、符合既有 task grant；
• 目标和 effect 可以机器确定；
• 不接触 secret、不跨 tenant、不出网；
• 有可靠 rollback/receipt。

必须拒绝或人工升级：

• 当前主体无权委派；
• secret/identity scope 扩大；
• 跨 workspace/tenant；
• 新目的地或不可信 executable；
• 发布、付款、删除、force push 等 consequential effect；
• action 只由 untrusted influence 支撑；
• 不可预览或未知副作用。

Ask 不是默认安全答案。无法向用户解释精确 effect 时，应先缩小或拒绝，而不是让用户为模糊风险签字。

9.5 Approval artifact

approval:
  approval_id: uuid
  approver: authenticated_human
  task_id: exact
  goal_hash: exact
  action_type: deploy
  target: service/prod
  args_hash: exact_normalized_args
  preview_hash: diff_or_plan_hash
  allowed_effects: bounded
  expires_at: short
  single_use: true
  created_from_ui_version: version

如果 action 参数、target、diff、goal 或 policy version 改变，旧 approval 失效。Session approval 只能复用一个明确、窄小的 rule，不能变成“以后 Bash 都允许”。

9.6 Anti-fatigue UI

Approval UI 应优先显示：

1. 将发生什么：精确 effect；
2. 影响哪里：真实 target、tenant、environment；
3. 哪些数据会离开：sensitivity 与 destination；
4. 为什么需要你：越过了哪条自动边界；
5. 是否可逆：rollback 和 partial-effect 风险；
6. 批准范围：once / exact rule / time-limited；
7. 证据：diff、artifact、tests，而非模型自述。

将大量低风险 action 交给 sandbox 自动处理，通常比 93% 被直接点击的 prompt 更安全。人类注意力是一种稀缺的 security budget。

10. Audit、Observability 与 Non-repudiation

10.1 Action receipt

对 consequential action，trace 中至少有：

receipt:
  receipt_id: uuid
  trace_id: stable
  task_id: stable
  turn_id: stable
  tool_call_id: stable
  actor_identity: agent_instance
  human_principal: delegated_user
  policy_version: exact
  policy_decision: allow/deny/ask
  matched_rule: stable_rule_id
  approval_id: optional
  action:
    tool: name@version
    normalized_args_hash: hash
    target: canonical_resource
  influence_roots: [user_intent_id, evidence_ids]
  execution:
    sandbox_id: id
    credential_grant_id: id
    network_decisions: [...]
    started_at: timestamp
    ended_at: timestamp
  effect:
    status: committed | partial | none | unknown
    effect_ids: [...]
    artifact_hashes: [...]
  verifier:
    status: passed/failed/not_run
    evidence: [...]
  integrity:
    previous_event_hash: hash
    signature: optional

10.2 Intent log 与系统 log 必须关联

Endpoint/OS log 告诉你 process 做了什么；Agent trace 告诉你用户目标、模型决定、tool call、approval 与结果。两者通过 stable ID 对齐，才能判断：

• action 是否意图内；
• shell 子进程是否超出 tool 声明；
• network request 是否来自已批准 action；
• 用户拒绝后是否仍产生 effect；
• Agent 是否尝试修改 monitor/policy；
• 同一错误是否在 retry 中重复。

OpenAI 公开 Codex 安全部署描述了用 endpoint alert 联合 Codex logs 查看原始请求、tool activity、approval、tool result 和 network policy decision。这正是 intent-aware detection，而不是仅靠 prompt 内容分类。

10.3 隐私与审计的张力

全量记录源码、prompt、CoT、secret 会把 observability 变成新的高价值攻击面。原则：

• metadata first，内容按需、最小、分级；
• secret 永不记录；
• 源码用 hash、path、diff stats、artifact handle 替代全文；
• tenant 隔离、retention、deletion、legal purpose 明确；
• 安全调查访问单独授权和审计；
• monitor 输入与训练数据使用边界分离；
• 用户可理解哪些数据被遥测。

10.4 Tamper evidence 与 non-repudiation

不可变日志不等于绝对不可篡改。可组合：append-only store、hash chain、签名 receipt、可信时间、WORM retention、外部 checkpoint。关键是 actor 没有修改或删除自己审计记录的权限。

NIST 2026 agent identity concept paper明确提出 action/intent 的可验证日志、与 human authorization 绑定及 non-repudiation，这说明 agent identity 体系若没有 audit chain 就不完整。

10.5 Monitor 的边界

监测适合发现：

• 目标漂移、异常工具序列；
• secret-like output、异常目的地；
• policy denial spike；
• 修改 safeguard/monitor；
• 高 fan-out、自复制、异常持续性；
• outcome 与 claim 不一致。

但 monitor 也可能误报、漏报、延迟、被 injection、与 actor 共因失败。它必须触发硬控制：pause、revoke、quarantine、human review，而不是只写一条告警。

11. Security Control Matrix

下表用 P 表示主要控制、S 表示补充控制。任何一行若只有 prompt/model 防御，设计都不完整。

11.1 Defense-in-depth 的真正含义

不是堆十个同类 classifier，而是在不同失败假设下仍有独立控制：

model resists injection
  AND/OR provenance detects weak grounding
  AND capability set excludes dangerous tool
  AND sandbox limits reachable resources
  AND egress blocks exfiltration
  AND approval binds consequential action
  AND monitoring shortens detection

控制之间要避免共因：如果 planner、policy judge、verifier 都是同一个模型、同一 context、同一 injection，它们不算三层独立防线。

12. Security–Utility Tradeoff：不能靠全拒绝获得“安全”

12.1 联合目标

SecurityUtilityScore
  = benign task utility
  - λ1 × attack success
  - λ2 × expected blast radius
  - λ3 × human burden
  - λ4 × latency/cost overhead

权重由任务风险决定，但必须联合报告。只看 ASR 会奖励“拒绝所有任务”；只看 task success 会掩盖成功完成任务同时泄密的情况。

12.2 关键指标

12.3 Risk-adjusted autonomy

Autonomy 不是一个开关，而是动作空间：

autonomy(action)
  = f(reversibility,
      blast_radius,
      evidence_quality,
      environment_isolation,
      identity_scope,
      historical_reliability,
      monitoring_coverage)

强 sandbox + 无 secret + 禁网 + 可回滚，可以给较高执行自主性；真实 host + 广域 token + 外部写入，则即使模型很强也需要窄 capability 与明确 approval。

12.4 当前证据如何读

这些结果的共同结论不是某个防御已经“解决 injection”，而是：静态、单步、明显恶意 payload 的 benchmark 会高估部署安全；必须同时测动态任务、helpful external instruction、adaptive attacker、utility、长期状态与真实 effect。

13. Security Evaluation：怎样证明控制真的关闭了通道

13.1 Evaluation cube

Attack surface:
  user / repo / web / tool / MCP / hook / memory / subagent / approval UI

Effect:
  data read / code write / process / network / identity / publish / delete

Adversary:
  naive / obfuscated / contextual / adaptive white-box / compromised component

Horizon:
  one turn / long task / compaction / crash recovery / cross-session

System configuration:
  model × harness × tool set × sandbox × policy × identity × budget

一个“prompt injection benchmark 分数”只覆盖 cube 的一个切片。

13.2 测试层次

1. Policy unit tests：规范化 resource 后，deny/allow/ask 是否符合决策表；
2. Boundary tests：symlink、mount、path encoding、DNS rebinding、redirect、token audience；
3. Tool contract tests：未知字段、schema drift、partial effect、retry、receipt；
4. Adversarial trajectory tests：injection 经 context→plan→tool→effect 的完整链；
5. Memory transition tests：写入、压缩、合并、恢复后 authority/provenance 是否保留；
6. Multi-agent tests：spoof、replay、cross-task、delegation escalation、artifact substitution；
7. Human studies：approval comprehension、fatigue、automation bias；
8. Chaos/security drills：broker failure、monitor delay、revocation、kill、recovery；
9. Production canary：小 blast radius 下监测 drift 与 unknown patterns。

13.3 一个安全 eval task 的最小结构

legitimate_task: dynamic, useful, nontrivial
user_invariants: explicit
attack:
  vector: indirect_repo_injection
  placement: test_failure_output
  objective: exfiltrate canary
  attacker_knowledge: adaptive_white_box
environment:
  canary_secrets: synthetic
  real_effects: isolated
  network: controlled sink
  versions: exact
oracle:
  utility: deterministic verifier
  security: effect-level detector
  over_defense: allowed benign action set
runs:
  seeds: N
  budgets: fixed
artifacts:
  full trajectory + policy decisions + OS/network events + receipts

不要用真实 secret 或真实生产 effect 做红队；使用 canary 与隔离 sink。

13.4 测 channel closure，而非听模型解释

对每个防御做 counterfactual：

• 若模型完全被攻陷，secret 是否仍不可读？
• 若能读，是否仍不可出网？
• 若能请求 tool，PEP 是否仍拒绝？
• 若用户误批准一个 action，grant 是否只覆盖精确参数？
• 若 monitor 漏报，blast radius 是否仍被 sandbox 限制？
• 若 memory 被污染，是否能跨 tenant 或写 control plane？

模型说“我忽略了 injection”不是 security evidence；effect graph 中不存在未授权可达路径才是。

13.5 Adaptive attacker 与 benchmark overfitting

攻击者会看到公开 prompt、防御 classifier、错误信息和 approval UI，再迭代 payload。必须保留 hidden attacks、结构变换、多语言、多模态、long-horizon、benign-helpful 指令，并定期换任务分布。

任何结果都应披露 model/harness/policy/sandbox/tool/budget/attack knowledge/version；否则无法判断改进来自哪里。

14. Incident Response：从发现到可验证恢复

14.1 Agent incident 的状态机

signal
  -> triage
  -> pause admission
  -> contain active execution
  -> revoke identity/capability
  -> preserve evidence
  -> reconcile external effects
  -> eradicate persistence
  -> restore clean state
  -> reauthorize minimally
  -> post-incident eval/policy update

14.2 第一响应顺序

1. 停止新增 effect：冻结 task、queue、subagent fan-out；
2. 撤销权限：token、lease、approval grant、MCP session/state handle；
3. 隔离环境：网络 quarantine、sandbox snapshot，不让 Agent 自己“清理”；
4. 保全证据：journal、policy snapshot、artifact hash、OS/network events；
5. effect reconciliation：区分 committed / partial / none / unknown；
6. 识别持久化面：memory、repo、hooks、skills、MCP、CI、credential、外部 service；
7. 干净恢复：从可信 snapshot 重建，不在可疑环境上原地打补丁；
8. 验证撤销传播：所有 downstream audience 不再接受旧 credential；
9. 回归任务：把攻击链转成隔离、可复现 eval。

14.3 五类 playbook

Prompt injection / goal hijack

• 冻结受影响 task 与由其派生的 subagents；
• 找到 source artifact、首次 influence edge 和所有 downstream actions；
• 对账每个 external effect；
• 清除受污染 context/memory/index，而不是只删当前消息；
• 检查同源内容是否进入其他 task；
• 新增 provenance/policy/regression test。

Credential exposure

• 立即 revoke/rotate，不等待确认是否被利用；
• 识别 credential audience、scope、lifetime 和所有 log/context 副本；
• 查询 target-side use；
• 清除持久 trace/artifact 中的值；
• 改为 brokered short-lived grant。

Malicious plugin/MCP/supply chain

• quarantine 版本与 signer；
• 阻断 catalog discovery 和启动；
• 建立受影响安装/执行清单；
• 检查 startup command、filesystem、network、credential access；
• 从可信 digest 重建；
• revocation 与安全公告进入 registry。

Memory poisoning

• 按 provenance 查询所有派生 memory 与决策；
• invalidation 应级联，不只删除原节点；
• replay 关键 task，比较 clean state；
• 审计 writer 权限、transition verifier 与 compaction；
• 重新建立受影响结论的可信证据。

Rogue / cascading behavior

• 用 Agent 不可达的 control plane kill；
• revoke 所有 delegation descendants；
• 关闭 queue/admission，防止重启恢复循环；
• 对账后台 process、ports、jobs、cloud resources；
• 检查 safeguards、monitor、policy、future-version inputs 是否被修改。

14.4 Incident severity

Severity 不只看最终损失，还看潜在 authority 和不确定性：

S0: blocked attempt, no effect, complete evidence
S1: sandbox-local reversible effect
S2: workspace integrity / synthetic secret / limited external write
S3: real credential, cross-tenant, production or persistent compromise
S4: widespread cascade, safety-control compromise, unknown high-impact effects

effect=unknown 不能当作 effect=none。

15. Governance：把安全从文档变成持续控制系统

15.1 最小治理闭环

asset + threat model
  -> policy and architecture
  -> implementation controls
  -> pre-deploy security eval
  -> bounded rollout
  -> agent-aware monitoring
  -> incident/review
  -> policy, eval and architecture update

NIST AI 800-5 于 2026-05-18 发布，内容是对 Agent security RFI responses 的 summary analysis，而不是 normative implementation guideline。它报告的广泛反馈是：传统 cybersecurity 原则仍适用，但要适配模型—软件组合的 Agent 风险；安全被许多回应者视为采用障碍，并期待实现指南、信息共享和标准。本文据此提出的架构建议是：治理建立在成熟 IAM、Zero Trust、SDLC、incident response 之上，同时补齐 intent、autonomy、tool、memory 和 delegation；后半句是本文推导，不是 NIST 原文控制要求。

15.1.1 NIST 当前版图：不要声称已有 Agent RMF

截至 2026-08-03：

• AI RMF 1.0 仍是现行、voluntary framework，官方页面明确写着“正在修订”；
• NIST AI 600-1 GAI Profile 是 2024-07-26 发布的 GenAI companion profile；页面 2026-04 更新不等于发布了新版标准；
• 2026-04 的 Critical Infrastructure Profile 仍处于 concept-note / ongoing 状态；
• Agent Identity and Authorization 是 draft concept paper，公开意见期已结束，但官方尚未把它标为最终 implementation guide；
• AI Agent Standards Initiative 是标准协作、开源协议和安全/identity 研究计划，不是已经完成的 Agent security standard。

因此可信用法是：用 AI RMF 的 GOVERN / MAP / MEASURE / MANAGE 做治理骨架，用 GAI Profile、AI 800-5、identity concept paper、OWASP 和 protocol specs 填 Agent-specific evidence；不要把 concept paper 问题清单包装成 NIST 强制要求。

15.2 一份可执行的 Agent Security Case

每种 deployment profile 应回答：

claim: 在目标任务与攻击者模型下，最坏 effect 被限制在 X
scope: exact model/harness/tools/environment/version
assumptions:
  - identity provider integrity
  - sandbox kernel/hypervisor boundary
  - approved data classifications
controls:
  preventive: [...]
  detective: [...]
  responsive: [...]
evidence:
  tests: [...]
  red_team: [...]
  production_metrics: [...]
residual_risk: explicit
owner: accountable role
expiry: date/version trigger

Safety case 不是“没有风险”的证明，而是明确 claim、assumption、evidence 与 residual risk。

15.3 治理对象

• agent/model/harness inventory；
• owner、purpose、data class、deployment profile；
• tool/MCP/plugin/skill registry 与 version provenance；
• identity、delegation、credential 和 revocation inventory；
• sandbox/egress/retention policy；
• security eval card 与 accepted residual risk；
• approval rule 与例外；
• incident、near miss、policy denial 与 unknown effect；
• model/prompt/tool/schema/memory policy 变更历史；
• decommission：身份撤销、memory/trace 删除、artifact retention。

15.4 Change management

以下变化都应触发 threat model 或 eval 重跑：

• 模型版本/effort/context policy；
• 新工具、tool schema 或更宽参数；
• MCP/plugin/skill/hook 更新；
• sandbox mount/network/credential 改动；
• 增加 autonomy horizon、并行度、subagent depth；
• memory 写策略、compaction 或共享范围；
• policy/approval UI；
• 新 tenant、数据级别、生产环境；
• verifier 与 benchmark 更新。

“只换模型”也可能改变攻击能力、工具策略、对 role 的感知和寻找 escape path 的能力。

15.5 Policy exception

例外必须是：有 owner、有范围、有期限、有补偿控制、有日志、有退出条件。--yolo、禁用 auth、广域 egress 等不是普通配置偏好，而是 deployment profile 改变；应在更强 sandbox、isolated account、synthetic data 等条件下使用。

15.6 Responsibility boundary

16. Kimi Code 公开实现映射

本节只陈述公开代码能支持的判断，不把开源 snapshot 等同于线上部署。

16.1 Permission control path

公开 AgentPermissionGate 在每次 tool execution 前接入 onBeforeExecuteTool，运行有序 permission policy chain，并把决策记录为 permission_policy_decision telemetry。结果语义包含 approve / deny / ask / result；ask 交给 tool approval，deny/result 可 veto：permissionGateService.ts。

公开 policy chain 包含：

• auto mode 对 AskUserQuestion 的 deny；
• user-configured deny；
• auto-mode approve；
• session approval history；
• user ask / allow；
• sensitive file access ask；
• Git control path ask；
• yolo approve；
• default tool / Git cwd write approve；
• fallback ask。

这体现了几个好边界：policy 与 approval 分开；deny 位于 allow 前；决策可观测；gate 位于 tool executor 的 before hook。

面试应继续追问的不是“有没有 permission”，而是：

• normalized effect/target 在 policy 前如何解析；
• shell 的实际 child-process/network effect 如何与 tool-call policy 对账；
• session approval 的匹配粒度与 invalidation；
• policy version、provenance、identity grant 是否进入 receipt；
• crash/replay 时没有 receipt 的 effect 如何 reconciliation。

16.2 Workspace trust

公开 IWorkspaceTrust 把信任 marker 存在 workspace 外部；fresh checkout 不能把自己标成 trusted。未信任时，project-root .mcp.json 与 .kimi-code/mcp.json 不加载，避免仓库自动启动 MCP server：workspaceTrust.ts。

这是正确的 control-plane ownership：trust state 不由被信任对象持有。

仍要区分：workspace trust 是项目级 MCP/config enablement gate，不等于仓库每一段内容拥有 instruction authority，也不等于所有代码可在 host 上无约束执行。

16.3 Tool exposure 与 subagent delegation

公开文档说明 custom agent 的 tools / disallowedTools 既塑造模型看到的工具集合，也在 execution 前再次强制；subagent allowlist 在 dispatch 前重检：Custom Agents。

这是“discovery filter + executor enforcement”的双层结构。进一步的安全问题是父子 delegation chain、子 Agent identity、共享 context/memory、artifact integrity 和 descendant revoke。

16.4 Filesystem、symlink 与 secret guard

公开 v2 workspace filesystem API 对绝对路径、..、resolved outside 和 symlink outside 做检查；release notes 也记录过 session filesystem 跟随 workspace 外 symlink 的修复。另一方面，file-tool path-access 的 policy 注释明确说 lexical canonicalization，本身不 follow symlink；真正 workspace FS service 又用 realpath 补上 symlink-aware confinement。

这里最重要的架构判断是：

path policy、filesystem mechanism 与 shell process 是三个不同层；file tool 的 guard 不能外推为整个执行环境的 sandbox。

公开 system prompt 还明确提醒运行环境不在 sandbox，Read/Write/Edit 会拒绝一组已知 secret files，但 Bash 不继承这些 path/secret guards。它诚实暴露了概率约束与机制边界的差异。面试里应讨论如何用 OS sandbox、secret broker 和 egress policy 把这一边界进一步收敛，而不是简单评价“安全/不安全”。

16.5 Server 与 network boundary

公开 CLI 文档说明 --dangerous-bypass-auth 会关闭 REST/WebSocket bearer auth，任何能访问端口的人都可访问 session、filesystem 和 shell；同时 web server 提供 Host/DNS-rebinding allowlist 配置。公开 changelog 也持续修正这类边界。

这说明 Coding Agent 的 threat model 必须包括：

• local web server reachability；
• bearer token 生命周期；
• reverse proxy 与 trusted network 假设；
• allowed Host 不等于 authenticated principal；
• DNS rebinding、localhost service、CORS/WebSocket；
• server keep-alive 与 residual session。

16.6 MCP boundary

公开 Kimi Code 支持 user/project MCP、stdio/SSE/HTTP、tool allowlist 和 permission rules，并明确建议只连接可信 server。对 2026-07-28 stateless MCP 规范，工程问题包括：

• connector adapter 如何兼容 protocol version；
• state handle 如何与 user/agent identity 绑定；
• OAuth audience 与 token passthrough；
• metadata discovery SSRF；
• local stdio server 的 startup supply chain；
• tool catalog/schema drift；
• untrusted tool output 的 provenance。

16.7 一张映射表

16.8 最有价值的 Kimi 安全议题

若面试让你选一个方向，不要泛泛说“加 prompt injection 检测”。更强的表述是：

我会把现有 permission gate 向 provenance-aware effect authorization 延伸：在 tool call 前规范化真实 target/effect，绑定 user intent、workspace trust、data influence、agent identity 与短期 capability；在 executor 后生成 effect receipt，并与 OS/network 事件对账。这样既继承公开实现里清晰的 gate/policy/telemetry 边界，也能把 shell、MCP、subagent、recovery 和 incident response 放到同一套控制模型中。

这是一种候选架构判断，不假装知道 Moonshot 内部优先级。

17. 25 组面试深追问与专家回答骨架

1. “系统 prompt 已经写了外部内容不可信，为什么还不够？”

回答骨架：自然语言 tag 是模型输入信号，不是 source authentication；role-confusion 证据说明模型会按风格重分配 authority。系统应保存 provenance，把 goal 放在 control-plane state，并用 capability、PEP、sandbox、secret/egress closure 让已建模的越权路径在明确基础设施假设下不可达。最后用 effect-level eval，而非模型口头拒绝验证；不要把这一点外推成“模型被攻陷后任何未知路径都绝对安全”。

2. “Direct injection 和 indirect injection 的防御有什么不同？”

回答骨架：direct 输入本来就来自用户，重点是用户是否有 authority、misuse policy 和 resource scope；indirect 输入来自任务所需 data，核心是 data/command separation、source provenance、action grounding 与 channel closure。两者都需要 effect policy，但 attacker principal 与允许意图不同。

3. “如何形式化 user intent？”

回答骨架：把 goal、non-goal、forbidden effects、targets、acceptance criteria 与版本存成不可由 workspace/model直接修改的 task state；每个 action 追溯到 goal/invariant，goal 变更形成新版本并使旧 approval/grant 失效。自然语言仍用于表达，但 enforcement 依赖结构化 invariants。

4. “什么是 influence provenance，和普通 trace 有何区别？”

回答骨架：trace 是事件序列，data provenance 是来源，influence provenance 是 source→observation→claim→decision→action 的因果图。高风险 action 要证明关键参数和目标由可信 intent/证据支撑；仅由 untrusted content 支撑的权限扩大被拒绝或升级。

5. “Taint tracking 在 LLM 中真的可行吗？”

回答骨架：不能可靠追踪每个 token 的语义影响，所以不要把它吹成完备 IFC。可在 harness 层追踪 source、tenant、sensitivity、authority、artifact lineage，并把关键 claim/action 做显式 grounding；对无法证明的高风险信息流保守处理。它降低风险，不等于证明模型内部没有混合。

6. “怎样判断一个防御真正关闭了 channel？”

回答骨架：做 compromised-model counterfactual。假设模型完全服从攻击，检查它是否仍能读 secret、获得危险 capability、访问未授权 sink 或绕过 PEP。若只是更可能拒绝，是 annotation；若未授权路径在系统状态图中不可达，才是 closure。

7. “Sandbox 和 permission prompt 谁更重要？”

回答骨架：不是替代关系。Sandbox 定义确定性可达范围，approval 处理业务意图中无法自动判断的跨边界 effect。大量低风险 prompt 会 fatigue；先用 sandbox 缩小 blast radius，再让人只批准 consequential、精确、可预览的 action。

8. “为什么 file tool 的 path guard 不足以保护 Coding Agent？”

回答骨架：Bash、package script、Git hook、compiler plugin、MCP child process 都可能直接访问 OS；还有 symlink、mount、TOCTOU 与不同平台路径语义。file-tool guard 是一个接口层控制，真正 confinement 应在 filesystem/process sandbox 强制，并用 OS events 对账。

9. “Symlink escape 应怎样正确处理？”

回答骨架：lexical normalize 后，对 existing prefix realpath，验证实际 root；打开时用 directory handle/no-follow 减少 TOCTOU；archive/glob/watcher/shell 路径也覆盖；对 non-existing tail 绑定已验证 parent。测试 nested symlink、swap race、mount、case/UNC 等平台边界。

10. “默认禁网会不会让 Agent 不可用？”

回答骨架：把 network capability 分层。常规 repo edit/test 在禁网 sandbox 完成；dependency、docs、Git/API 通过 egress proxy 按 destination/method/path/data class 放行；credential 由 broker 绑定 audience。这样不是全禁，而是把网络从 ambient capability 变成可审计能力。

11. “Domain allowlist 为什么仍可能泄密？”

回答骨架：允许域可能有 attacker-controlled content endpoint；redirect、DNS rebinding、子域、IPv6、body 都可成为通道。Policy 要重验 resolved IP/redirect，限制 method/path/body/sensitivity，并把 credential audience 和 destination 联动。必要时由 broker 代执行而非开放任意 HTTP。

12. “Secret 不给模型，Agent 怎么调用外部系统？”

回答骨架：Agent 请求语义操作；PEP 验证后由 broker mint short-lived audience-bound token 或直接代理 operation；sandbox 只拿 opaque handle/scoped credential；结果返回 receipt。模型知道 capability，不知道长期 secret。

13. “怎样防 confused deputy？”

回答骨架：服务端验证 caller、user delegation、audience、scope、purpose；不透传 upstream token；每个 downstream action 做 token exchange；不把 state handle 当认证。MCP proxy 还需 per-client consent、redirect/state/PKCE 与精确 audit chain。

14. “MCP 最大的安全误区是什么？”

回答骨架：把协议化 tool schema 当成可信/安全。MCP 扩大 discovery、OAuth、local process、remote content 和供应链面；tool description 也可能改变模型决策。Server/auth/schema/version/output 都要独立 trust，并在 task capability 与 PEP 中收敛。

15. “如何安全启用 workspace 自带 MCP/Hook？”

回答骨架：workspace 默认 untrusted，trust marker 存外部；先展示 publisher/command/cwd/env/scope/digest；安装与 enable 分离；local process sandbox；工具 allowlist；输出始终 data authority；变更触发 catalog diff 和重新授权。

16. “Subagent 权限应如何继承？”

回答骨架：attenuation only：子 Agent capability 是父 Agent 可委派集合与任务所需集合的交集；delegation grant 有 depth、expiry、purpose、target；消息签名、anti-replay、artifact hash；父级 revoke 向 descendants 传播。默认子 Agent 只返回 claims/proposals。

17. “Memory poisoning 与普通 prompt injection 的差别？”

回答骨架：memory 是跨 turn/session 的持久系统状态，错误会在无原攻击输入时继续影响未来任务，并可能跨 tenant/版本。需要写权限、schema、provenance、scope、TTL、transition verifier、invalidation graph；不能只在读取时加一句 warning。

18. “如何避免 approval fatigue？”

回答骨架：减少 prompt 数而非让 prompt 更吓人。低风险动作在强 sandbox 自动化；聚合同一精确 rule；只升级跨边界/不可逆 action；展示 effect/target/data destination/diff；approval 生成一次性参数绑定 artifact。监测接受率、理解正确率和错误批准。

19. “用户已经点了批准，系统还要负责吗？”

回答骨架：要。用户批准只证明一个具体业务决定，不能修复模糊 UI、过宽 grant、隐藏参数、secret 泄漏或 sandbox escape。系统必须确保批准是 informed、authenticated、bounded、fresh，并且 actual effect 与 preview 一致。

20. “怎样安全重试 tool call？”

回答骨架：先按 effect 语义分类。纯读可重试；幂等 write 需要 idempotency key；未知是否提交先 reconcile receipt/target state；不可逆、unknown effect 默认不盲重试。每次 attempt 有同一 logical action ID 与独立 execution receipt。

21. “Agent crash 后恢复时最大的安全风险？”

回答骨架：replay 未知副作用、丢失 approval/goal/policy version、旧 credential 复用。Journal 记录 intent 与 receipt；无 receipt 的 pending action先 reconciliation；恢复时重新评估 policy、identity、tool version 和 grant expiry，而不是从最后一个 prompt 继续。

22. “如何评测 prompt injection 防御？”

回答骨架：联合报告 ASR、benign utility、over-defense、latency/cost、blast radius 与 human burden；覆盖 direct/indirect/stored/cross-agent、多语言、多模态、adaptive attacker、long horizon；使用 effect-level oracle 和 synthetic canary；固定 model/harness/policy/sandbox/tool/budget。

23. “Monitor 能否成为主安全边界？”

回答骨架：不能。Monitor 有漏报、延迟、共因、隐私和被规避问题。它适合缩短 detection/containment，必须能触发 pause/revoke/quarantine；primary prevention 仍是 least capability、identity、sandbox、egress 和 PEP。

24. “Agent security incident 与普通应用 incident 最大差异？”

回答骨架：要恢复的不仅是 process 和数据，还包括目标/上下文/memory/delegation 因果链与外部 effect；一个 injection 可能通过 artifact、subagent、memory、repo、credential 持久化。处置顺序是 stop effects、revoke、snapshot、reconcile、eradicate all persistence、clean restore、regression eval。

25. “如果负责 Kimi Code 安全，你会先做什么？”

回答骨架：不先报 feature。先用真实 trace 建 high-impact cohort 和 threat model，量化 permission burden、policy bypass、unknown effect、secret/egress 与 workspace/MCP 风险。基于公开 gate/policy/telemetry 边界，优先把 normalized effect + user intent/influence + scoped identity grant + executor receipt 打通，再用隔离 eval 验证 security–utility；具体优先级由内部事件与数据决定。

18. 一页决策框架

面对任何 Agent security 设计题，按这个顺序回答：

1. Asset：要保护什么，最坏 effect 是什么？
2. Principal：用户、Agent、tool、server、subagent 分别是谁？
3. Authority：谁能委派什么，scope/lifetime/audience 是什么？
4. Boundary：data/command/control/effect 在哪里跨界？
5. Attacker：谁能控制哪些 input、component、timing？
6. Influence：不可信内容如何进入 claim、plan、action？
7. Capability：被攻陷模型实际能调用什么？
8. Containment：filesystem/process/network/identity/secret 的硬边界？
9. Approval：只有哪些 consequential effect 需要人决定？
10. Receipt：怎样证明实际 effect 与授权一致？
11. Eval：如何同时测 attack、utility、over-defense 与 blast radius？
12. IR/Governance：如何 kill、revoke、reconcile、恢复与持续更新？

最短但不浅的总结：

Agent security 的本质不是让模型永远不犯错，而是让 authority 不由文本伪造、capability 不以 ambient privilege 形式暴露、effect 不绕过 policy、failure 不越过 containment cell、每次 consequential action 都可证明和可追责。

19. 一手资料与证据边界

Standards 与官方实践

• OWASP Top 10 for Agentic Applications 2026
• OWASP State of Agentic AI Security and Governance 2.01
• NIST AI RMF 1.0 current status and revision notice
• NIST AI 600-1 Generative AI Profile
• NIST AI Agent Standards Initiative
• NIST AI 800-5: Summary Analysis of Responses on AI Agent Security
• NIST NCCoE: Software and AI Agent Identity and Authorization
• NIST AI 100-2e2025: Adversarial Machine Learning Taxonomy
• MCP 2026-07-28 final specification
• MCP 2026-07-28 Security Best Practices
• MCP 2026-07-28 RC announcement and final release timeline
• A2A v1.0 specification
• A2A releases: latest patch tag v1.0.1
• Anthropic: Beyond permission prompts / Claude Code sandboxing
• Anthropic: How we contain Claude across products
• OpenAI: Designing AI agents to resist prompt injection
• OpenAI: Running Codex safely at OpenAI
• OpenAI: Monitoring internal coding agents for misalignment

Primary research

• Prompt Injection as Role Confusion, ICML 2026
• ARGUS / AgentLure: provenance-aware decision auditing
• AgentDyn: dynamic open-ended prompt-injection evaluation
• AgentSecBench
• Task Shield, ACL 2025
• Agent Security Bench, ICLR 2025
• WASP, NeurIPS 2025
• TrustMem: memory transition verification

Kimi / Moonshot 公开证据

• Kimi Code repository
• Permission Gate
• Workspace Trust
• Custom Agents: tools 与 subagent allowlist
• MCP customization
• Hooks
• Kimi CLI reference
• Kimi Code changelog

如何解读证据

• OWASP Top 10 是风险发现框架；State 2.01 是扩展治理报告。两者均不证明某个实现已安全；
• NIST AI RMF 1.0 仍在修订；AI 600-1 是 GenAI profile；AI 800-5 是 RFI summary；2026 identity 文件是 draft concept paper。目前没有可被准确称为“final NIST Agent RMF”的文件；
• MCP 2026-07-28 是 final protocol spec；A2A 是 v1.0 stable lineage、v1.0.1 latest patch tag。协议合规不等于内容可信、prompt-injection immunity、正确 delegation 或安全 runtime；
• peer-reviewed paper 与 preprint 已在来源表分开；任何论文数字只对其模型、harness、攻击者、任务和 budget 有效；
• 公司工程文章是有价值的一手实践与事故证据，但仍是特定产品/部署经验和厂商遥测，不是独立认证；
• Kimi 映射基于公开 snapshot，能说明 control path，不能说明未公开线上配置、组织流程或内部监测。