入站内容防御 / 供应链完整性 / 出站执行验证——三件事，三种代价，三种工程纪律
作者：Guigui Wang | Correctover — AI Reliability
日期：2026-09-15本文涉及自有 Internet-Draft 内容均为 individual submission，not an RFC or IETF endorsement.
CCS 性能数据均为 Correctover 内部实测，文中逐条标注测量口径；不同口径不可直接比较。
文中提到的项目（CAITLYN、AgentSecCore/ANOLISA）为公开信息事实性引用，不含任何商业评价或排名意图。
当「AI Agent 安全」成为热词时，最危险的动作是把所有技术塞进同一个篮子。今天公开可见的三个代表性方案，恰好站在三条不同的工程边界上。把边界画清楚，比把它们揉成一顶「AI 安全标准」的大帽子，更对得起生产环境。
1. 三条边界
| 边界 | 问题 | 代表工程 | 工程纪律核心 |
|---|---|---|---|
| 入站内容防御 | 非可信内容进入 Agent 前是否被过滤 | CAITLYN（arXiv:2608.27990，PolyU / CUHK） | 双向规格验证（attack 必命中 + benign 零误伤） |
| 供应链完整性 | Agent 运行时加载的技能/代码是否被篡改 | AgentSecCore（Alibaba Cloud Linux，ANOLISA 开源） | Ed25519 签名 + append-only 版本链 + Skill 快照漂移检测 |
| 出站执行验证 | Agent 发出的工具调用是否符合运行时形态 | Correctover CCS（IETF individual draft） | 7 维运行时验证：Structure/Schema/Latency/Cost/Identity/Integrity/Security |
三条边界不是三个竞品，是三个工程问题。任何一个真实的 Agent 部署，都可能同时需要三者的某一层。把它们混为一谈，会让企业误以为「买一个就够」；把它们画清楚，才能让每一层都做到它该做到的程度。
2. 入站内容防御：CAITLYN 的工程纪律
CAITLYN 是香港理工大学（PolyU）与香港中文大学（CUHK）团队 2026 年 8 月公开的研究项目（arXiv:2608.27990，v1 提交于 2026-08-28，CC0），定位是非可信入站内容（用户 prompt、工具返回值、外部网页）的间接提示注入防御中间件。
它最有价值的工程纪律是 System II 的反例引导技能合成闭环（counterexample-guided synthesis）：
- 漏报攻击 → 当作 counterexample
- generator 合成新的防御技能
- 独立 verification sandbox 做双向规格验证——攻击正例必须命中、良性反例必须零误伤
- reviewer 把关 → 带 lineage 写回技能库
可吸收的工程纪律：新 detector 必须通过「正/反」双面语料契约，并且可以追溯到催生它的那个 counterexample。这不是功能列表，是工程纪律。
边界：它解决的是「进来的内容是不是有毒」，不做 Agent 调用工具那一刻的运行时校验，也不做 Skill 文件在磁盘上的完整性守护。论文也如实给出了这条路线的工程代价：云端 LLM 判定路径在其评测中约为数秒至十余秒延迟、每查询约 0.003–0.007 美元量级，并且中间件在多个部署点默认 fail-open。准确率、延迟、适应性三者构成它要权衡的 trilemma。
Correctover 正在把这条工程纪律吸收到自己的规则更新管线（见 §5）。我们学纪律，不抄实现。
3. 供应链完整性：AgentSecCore 的边界
AgentSecCore 是 Alibaba Cloud Linux（Alinux）的本地 Agent 安全内核（官方文档，更新于 2026-09-10），开源版本为 ANOLISA（Apache-2.0），处于持续活跃迭代状态。
它最扎实的工作是 Skill Ledger（技能账本）：
- 每个 Skill 的 manifest（含文件哈希、扫描结果、版本信息）经 Ed25519 签名
- append-only 版本链 + snapshot 机制，支持漂移识别与可信版本回退
- 6 个业务安全状态（pass / none / drifted / warn / deny / tampered）
- 与 SkillFS 职责解耦，已适配 6 类宿主：OpenClaw、Copilot Shell、Hermes、Codex、Qoder CLI、Qwen Code
可吸收的工程纪律：Skill/Plugin 的「身份 + 完整性」必须可校验，且任何漂移都必须可被检测。这是任何 Agent 供应链的基础。
边界：它强覆盖 Integrity 一维，部分覆盖 Identity 与 Security，不做出站工具调用的 Structure / Schema / Latency / Cost 校验（即 CCS 7 维中的 4 维）。在提示词扫描上，官方把强度分为 FAST / STANDARD / STRICT 三档，并注明 STRICT 是为 L3 语义层预留、当前与 STANDARD 等效；本地 L2 判定依赖用户自行部署 Ollama 小模型。处置姿态上，官方文档说明各宿主 hook 在 agent-sec-cli 缺失、超时或返回非法结果时统一 fail-open（放行并记录），优先保障 Agent 可用性。它是 OS 侧内容安全 + Skill 供应链守护，不是 sub-millisecond 的运行时验证引擎。
与 CCS 技术路径重合度最高的点是 Ed25519 签名 + 版本链，但粒度不同：AgentSecCore 守护 Skill 级（文件 / manifest），CCS 守护调用级（每一次工具调用）。fail-open 与 fail-closed 也是两种不同取舍——前者优先可用性，后者优先安全——而非高低之分。两条路径互为补充，不是替代。
4. 出站执行验证：Correctover CCS 的边界
Correctover CCS（Conformance Shape）是我们定义的 Agent 运行时验证标准（IETF Internet-Draft，individual submission），覆盖每一次工具调用的 7 个运行时维度：
- Structure / Schema：调用消息是否符合协议形态与字段约束
- Latency / Cost：响应时间与 token 开销是否符合预期形态
- Identity / Integrity / Security：工具、内容、行为的可信性校验
运行时校验的核心纪律是确定性 + 零 token + sub-millisecond：
- Correctover 核心判定层 Node P50 ≈ 2.7µs
- Python 端到端 P50 ≈ 27µs
- 对外口径：core eval P50 < 10µs / P99 < 25µs（实测 P50 ≈ 7.5µs、P99 ≈ 21µs）
- fail-closed：运行时校验失败 = 拒绝执行，而不是放行
- Ed25519 签名收据（receipt）提供可独立验证的审计证据
为什么有三组性能数字、它们为何不矛盾。 三者测量边界不同，不能直接比较：Node P50 ≈ 2.7µs 是核心判定层在 Node 运行时的单次纯校验耗时，是最优单点；Python 端到端 P50 ≈ 27µs 走的是真实集成路径，含 Python 调用链上的序列化与封装开销；对外承诺的 core eval P50 < 10µs / P99 < 25µs 取的是跨实现的保守口径，并显式覆盖 P99 尾延迟，而不是只报最好看的平均值。对外统一使用保守口径，内部单点数据在此一并披露，只为交代测量边界。
边界：它守护的是「Agent 发出的调用是否合规」。它不做入站内容的间接注入过滤（那是 CAITLYN 一类中间件的地盘），也不做 Skill 文件级的供应链漂移检测（那是 AgentSecCore 的地盘）。
5. 三条边界之间的工程对话
最有意思的工程对话发生在边界之间：
- CAITLYN 的双向规格验证纪律 → 被我们（Correctover）吸收到规则更新管线：每条新规则必须带攻击正例集 + 良性反例集 + 全量回归，门禁 fail-closed（纪律跨边界复用，实现不抄）。
-
AgentSecCore 的 Skill Ledger → 启发 Correctover 的规则包签名链：规则包可 Ed25519 签名，复用
trust.py两级信任模型（VERIFIED → ACCEPTED），与调用级 receipt 互补（资产层 + 调用层双保险）。 - CCS 的调用级 receipt → 对 CAITLYN / AgentSecCore 都透明：它们在决策时产生的记录本身也可以被 CCS 校验，形成「对防御行为的防御」。
这种分层对话，才是对得起生产环境的工程态度。
6. 对 Correctover 自身的要求
我们把自己定位在出站执行验证这一条边界上，不跨边界声称自己覆盖所有 Agent 安全问题。
- 我们有的：CCS 7 维运行时校验、Ed25519 签名收据、sub-ms 确定性引擎、fail-closed 闸门、两阶段信任模型（VERIFIED / ACCEPTED）。
- 我们正在补的：规则入库双向语料门禁（对 CAITLYN 工程纪律的吸收，正在 P0 阶段）；规则包签名链（借鉴 Skill Ledger 的思路）。
- 我们不做的：入站内容防御（CAITLYN 一类中间件的地盘）、Skill 文件漂移检测（AgentSecCore 的地盘）。
我们同时承认：CCS 不是 AI 安全的唯一答案，它只是运行时验证层的一个答案。如果你的威胁模型同时包含入站内容投毒和第三方 Skill 供应链，我们建议在 CCS 之外同时部署入站内容防御与 Skill 完整性方案——任何单一层都不足以覆盖完整的 Agent 攻击面。把边界画清楚，比把功能堆到一起更值得尊重。
7. 术语与事实锚点
- CAITLYN：arXiv:2608.27990（PolyU / CUHK，v1 2026-08-28，CC0）。属入站内容层，不对应 CCS 7 维中的任何一维。
- AgentSecCore / ANOLISA：阿里云 Alinux 官方文档（页面更新 2026-09-10）；开源版 ANOLISA，Apache-2.0，GitHub 活跃维护。在 CCS 7 维中强覆盖 Integrity（1 维），部分覆盖 Identity + Security（2 维），不覆盖 Structure / Schema / Latency / Cost（4 维）。
- Correctover CCS：IETF Internet-Draft individual submission；Correctover 开源实现；性能实测 Node 核心判定层 P50 ≈ 2.7µs、Python 端到端 P50 ≈ 27µs，对外保守口径 core eval P50 < 10µs / P99 < 25µs（实测 7.5 / 21µs）。
- Internet-Draft 免责：本文对 Correctover 自有 Internet-Draft 的引用均为 individual submission, not an RFC or IETF endorsement。
想先看清自己 Agent 的出站调用暴露面，可以用免费自动扫描器建立一条基线（correctover.com）；对于自动规则无法判定的部分（实际可利用性、生产危害、合规证据），再考虑人工运行时审计。
本文是 Correctover 对 AI Agent 安全三条技术边界的工程视角陈述，不是对任何产品或研究的排名或评价。作者对 CAITLYN 团队与 AgentSecCore/ANOLISA 团队公开贡献的工程纪律保持尊重。
Top comments (0)