摘要

当前 OWASP 基金会旗下与 AI Agent 安全直接相关的标准已形成四层体系：Agent Observability Standard（AOS）负责观测与溯源，Agent Control Standard（ACS）负责运行时治理裁决，Artificial Intelligence Security Verification Standard（AISVS）提供分等级的验证清单，Agentic Skills Top 10（AST10）则聚焦技能层风险分类。这四套标准并非竞争关系，而是覆盖 Agent 生命周期不同阶段的互补工具。本文以一段包含参数注入、审计日志、技能覆写与会话交接的同一 Agent 执行轨迹为实验输入，分别让四套标准"过一遍"，用实测数据揭示各自能捕获什么、不能捕获什么、适合在什么阶段使用，并给出建设期、验证期、监控期的具体选型组合。

1. 引言

1.1 问题背景

2025 至 2026 年间，OWASP 基金会围绕 AI Agent 安全连续发布了多套标准与框架。对于正在搭建 Agent 平台、引入第三方技能、或需要对 Agent 行为做审计与合规验证的建设方而言，一个现实问题是：这些标准听起来都相关，但到底该用哪个？它们的边界在哪里？能不能叠加使用？

网络上的现有资料多采用"逐个介绍"的写法，将每套标准的结构、条款、适用场景单独罗列，读者看完后仍然难以回答一个实际操作问题：如果我的系统里发生了一次真实的 Agent 行为事件，四套标准各自会留下什么痕迹？

1.2 本文方法

本文不采用纸面对比或条款搬运的方式。作者构造了一段固定的 Agent 执行轨迹，轨迹中包含五个具有明确安全含义的事件：正常工具调用、参数注入尝试、审计日志记录、技能覆写操作、会话交接。这段轨迹被分别输入四套标准的实测框架中，记录每套标准对该轨迹的捕获结果、阻断能力与缺失项。

实验环境为 Ubuntu 26.04 LTS 虚拟机（192.168.31.129），所有代码使用 Python 3.14.4 标准库编写，可逐字节复现。

1.3 四标准的一句话定位

• AOS（Agent Observability Standard）：负责观测与溯源。将 Agent 执行过程转换为可观测的 trace 与 hook，不负责拦截。

• ACS（Agent Control Standard）：负责运行时治理裁决。通过 Guardian 裁决线协议对每次 Agent 行为做出 deny / proceed / approve 的实时决定，并维护带 HMAC 签名的审计链。

• AISVS（AI Security Verification Standard）：提供分等级的验证清单。提供 Level 1 / 2 / 3 三档验证清单，用于设计审计与合规评估，不是运行时协议。

• AST10（Agentic Skills Top 10）：聚焦技能层风险分类。将技能风险分为 10 个类别（AST01–AST10），覆盖从恶意技能到跨平台复用的完整攻击面。

2. 标准族全景

2.1 四标准关系拓扑

图1 OWASP Agent 标准族四层关系拓扑

如图1所示，四套标准在 Agent 生态中处于不同的抽象层：

• 观测层（AOS）位于最内侧，紧贴 Agent 运行时，负责采集 trace 事件与 hook 回调，是所有上层分析的数据来源。

• 治理层（ACS）位于观测层之上，引入 Guardian 作为裁决节点，对采集到的事件做出实时决策，形成带链式哈希的审计记录。

• 验证层（AISVS）横跨运行时与设计阶段，提供静态的 verification requirement 清单，用于评估系统是否"满足"某类安全控制。

• 技能层（AST10）聚焦于 Agent 所调用的 skill 本身，独立于运行时治理，关注技能代码、元数据、权限与供应链风险。

2.2 各标准核心特征对照

注意：A2A（Agent-to-Agent Protocol）当前处于 v0.2 前瞻阶段，未形成可落地的稳定规范，本文不纳入选型讨论。PQC（后量子密码）签名方案虽与 ACS 审计链结合有研究价值，但受众过窄，本文亦不展开。

3. 实验设计：同一轨迹，四份答卷

3.1 轨迹定义

实验采用单一路径、固定时间戳的确定性轨迹，确保在任何平台上重跑均可得到一致的输出。轨迹包含五个事件：

TRAJECTORY = [
    {"event": "tool_call",         "tool": "database.query", "args": {"table": "users", "filter": "active=true"}, "caller": "agent-A", "session": "sess-001", "tenant": "tenant-alpha", "result": "ok"},
    {"event": "parameter_injection","tool": "database.query", "args": {"table": "users", "filter": "active=true; DROP TABLE users; --"}, "caller": "agent-A", "session": "sess-001", "tenant": "tenant-alpha", "injected_by": "skill:data-exporter@1.2.0", "result": "blocked"},
    {"event": "audit_log",         "entry": "parameter_injection detected, query blocked", "caller": "guardian", "session": "sess-001", "tenant": "tenant-alpha"},
    {"event": "skill_override",    "skill": "data-exporter@1.2.0", "action": "change_tool_args", "target_tool": "database.query", "new_args": {"table": "users", "filter": "active=true"}, "caller": "agent-A", "session": "sess-001", "tenant": "tenant-alpha", "approved": True},
    {"event": "session_handoff",   "from_agent": "agent-A", "to_agent": "agent-B", "session": "sess-001", "tenant": "tenant-alpha", "carry_state": ["context", "auth_token"]},
]

轨迹设计意图：覆盖四套标准各自关注的核心事件类型。parameter_injection同时触发 AST01 / AST05（恶意技能与外部指令）、AISVS-AGENT-01（输入验证）、ACS 的 deny 裁决；skill_override同时触发 AST02 / AST03 / AST04（供应链、过权限、不安全元数据）、AISVS-AGENT-04（技能完整性）；session_handoff同时触发 AST06 / AST10（弱隔离、跨平台复用）、AISVS-AGENT-05（会话隔离）。

3.2 实验框架

四套标准分别由独立的 Python 脚本实现，所有脚本共享同一个trajectory.py数据源，在 Ubuntu VM（~/lab64）上通过run_all.py统一调用。代码清单如下：

# run_all.py 核心逻辑（完整代码见 lab64）
import json, subprocess, sys

def run(script):
    result = subprocess.run([sys.executable, script], capture_output=True, text=True, cwd="/home/ubuntu26-04-1/lab64")
    if result.returncode != 0:
        return {"error": result.stderr}
    return json.loads(result.stdout)

# 依次调用 aos_wrapper.py / acs_wrapper.py / aisvs_checker.py / ast10_mapper.py
# 最终生成 matrix.json 供正文引用

实验输出文件：

• aos_wrapper.py：将轨迹事件映射为 AOS trace span

• acs_wrapper.py：对轨迹事件执行 ACS Guardian 裁决，生成带 HMAC 的审计链

• aisvs_checker.py：将轨迹事件与 AISVS Level 2 的 6 条 verification requirement 逐条对照

• ast10_mapper.py：将轨迹事件映射到 AST10 的 10 个风险类别

• matrix.json：汇总四标准对五事件的覆盖矩阵

4.1 标准定位

AOS 的instrument_specification.md定义了 Agent 行为的 trace 结构与 hook 机制。其核心思想是：把 Agent 执行过程拆成 span，每个 span 记录事件类型、时间戳、属性与子事件。AOS 本身不做出任何 deny / allow 决定，它的价值在于完整记录。

4.2 实测结果

aos_wrapper.py将轨迹中的五个事件分别映射为五个独立的 trace span，每个 span 的属性中包含aos.parameter_overrides、aos.skill、aos.tenant、aos.session等字段。

实测输出显示：

• parameter_injection事件的aos.parameter_overrides完整记录了恶意参数值{"table": "users", "filter": "active=true; DROP TABLE users; --"}。

• skill_override事件的aos.skill正确识别为skill:data-exporter@1.2.0。

• 所有 span 的aos.tenant与aos.session均被记录。

图2 AOS trace wrapper 实测输出

4.3 发现：AOS 管得了"看到什么"，管不了"拦不拦"

AOS 的输出中没有任何 decision 字段。parameter_injection的aos.result为"blocked"，但这个值来自轨迹数据本身，而非 AOS 运行时产生。这意味着：如果上游没有注入阻断逻辑，AOS alone 无法阻止一次恶意调用。

AOS 的另一个盲区是链式完整性。AOS trace 是独立的 span 集合，各 span 之间没有 prev_hash 或 HMAC 绑定。篡改某一条 trace 记录不会破坏其他记录，取证价值因此打折扣。

实测结论：AOS 是优秀的"黑匣子"，但不是"门禁"。在监控期与合规审计中，AOS trace 是核心数据源；在建设期单独部署 AOS 不足以满足安全基线。

5. ACS：治理层实测

5.1 标准定位

ACS 的instrument_specification.md定义了 Guardian 作为裁决节点。每次 Agent 行为在执行前必须经过 Guardian 裁决，裁决结果与 prev_hash、HMAC 一起写入审计链。ACS 的核心价值是运行时控制 + 不可抵赖的审计记录。

5.2 实测结果

acs_wrapper.py对轨迹中的五个事件依次执行裁决，生成五条审计链条目。关键输出如下：

审计链摘要：total 5，proceed 2，deny 1，approve 1。

图3 ACS Guardian 裁决链实测输出

5.3 发现：ACS 管"能不能执行"，不管"执行过程可不可见"

ACS 对parameter_injection做出了明确的 deny 裁决，chain_hash 从4c438445变为0fdecd83，并附带 HMAC 签名9325846b0a5dfaa4。这条记录一旦写入，篡改任何字段都会破坏链式哈希，这是 AOS trace 不具备的属性。

但 ACS 也有盲区。在本次实验中，skill_override被裁决为 approve，原因是"override approved by policy"。这意味着只要策略允许，技能可以修改工具参数。ACS 并不审查技能代码本身的安全性，也不检查技能元数据的完整性——它只判断"这次覆写是否符合当前策略"。

另一个关键发现：session_handoff被裁决为 proceed，因为交接发生在同一 tenant 内。但 ACS 不验证接收方 agent-B 的身份或权限，只检查 tenant 标签。如果 attacker 在同一 tenant 内冒称合法 agent，ACS 不会阻止。

实测结论：ACS 是运行时治理的核心，但它的安全边界由策略决定，而非绝对拦截。建设期部署 ACS 时，必须同步设计精细的 policy 规则，否则 approve 逻辑可能成为绕过通道。

6. AISVS：验证层实测

6.1 标准定位

AISVS 1.0 将 AI 应用安全验证分为 Level 1（ Essential baseline ）、Level 2（Standard controls ）、Level 3（Advanced controls ）三档。与 Agent 直接相关的章节包括 Agentic Security、Agentic Applications、Input Validation、Output Control & Safety、Access Control & Identity、Supply Chain 等。

AISVS 的核心交付物是 verification requirement 清单，每个条目包含：需求 ID、名称、验证等级、验证方法、通过标准。它不是运行时协议，而是审计清单。

6.2 实测结果

aisvs_checker.py从 AISVS Level 2 抽取了 6 条与本次轨迹直接相关的 verification requirement，逐条对照：

AISVS 实测摘要：total 6，pass 4，partial 2，fail 0。

图4 AISVS Level 2 验证清单实测输出

6.3 发现：AISVS 是审计清单，不是运行时协议

AISVS-AGENT-01（输入验证）在本次实验中标记为 PASS，因为parameter_injection事件确实被拦截。但 AISVS 本身不做拦截，它只记录"系统是否具备输入验证能力"。验证结果的依据来自外部系统（本例中来自 ACS Guardian 的 deny 裁决）。

AISVS-AGENT-04（技能完整性验证）标记为 PARTIAL，因为轨迹中虽然记录了skill_override事件，但没有验证data-exporter@1.2.0的代码签名、发布来源或哈希完整性。AISVS 要求"技能来源可验证"，但本次实验环境未集成技能签名机制，因此只能算部分满足。

AISVS-AGENT-06（租户数据隔离）同样标记为 PARTIAL。轨迹中tool_call与parameter_injection都携带了tenant-alpha标签，说明租户信息被记录，但没有验证跨租户访问是否被阻止。本次实验只在单租户内运行，无法验证跨租户隔离的有效性。

实测结论：AISVS 是合规团队的评估框架，不是开发团队的操作指南。验证结果的高度依赖底层系统是否真的实现了对应控制。建设期用 AISVS Level 1 做基线清单是合适的；验证期用 Level 2 做逐条审计也成立；但期待 AISVS 本身能发现运行时漏洞是不现实的。

7. AST10：技能层实测

7.1 标准定位

OWASP Agentic Skills Top 10（AST10）将 AI Agent 技能的安全风险分为 10 个类别，覆盖技能从开发、发布、安装到运行的完整生命周期。十个类别的名称与严重程度如下：

7.2 实测结果

ast10_mapper.py将轨迹中的五个事件逐一映射到 AST10 类别：

AST10 实测摘要：total 10，hit 9，miss 1，critical_hit 2。

图5 AST10 风险类别映射实测输出

7.3 发现：AST10 管"技能本身安不安全"，不管运行时治理

轨迹中parameter_injection同时命中了 AST01（恶意技能）和 AST05（不可信外部指令）。这说明同一次攻击在 AST10 视角下可以从多个维度归类，这种重叠是设计特征，而非冗余——不同的风险类别对应不同的缓解策略。

AST07（Update Drift）在本次轨迹中未命中。Update Drift 指的是技能版本更新后安全配置丢失或行为漂移，需要跨时间段的版本对比才能检测。本次实验使用固定版本data-exporter@1.2.0，不存在版本变更，因此不触发该类别。这一点恰好说明 AST10 的某些类别需要持续监控而非单次审计。

AST10 的一个实操难点是分类边界模糊。skill_override同时命中了 AST02（供应链，因为技能来源未经严格验证）、AST03（过权限，因为技能修改了工具参数）、AST04（不安全元数据，因为技能的权限声明可能与实际行为不符）。在实际运营中，一个事件可能需要同时触发三条缓解路径，这对安全团队的响应流程提出更高要求。

实测结论：AST10 是技能准入与持续监控的核心框架。建设期应将其作为技能上架的安全 checklist；监控期应定期扫描已安装技能是否触发 AST01–AST10 中的任何类别。

8. 实测对照总表

8.1 同一轨迹在四标准下的覆盖矩阵

图6 同一轨迹在四标准下的覆盖矩阵热力图（行=轨迹事件，列=四标准，颜色深度=覆盖强度）

8.2 对照分析

从矩阵可以得出三个关键结论：

1. 四标准互补，非竞争。没有任何一个标准能独立覆盖全部安全维度。AOS 记录最全但无法拦截，ACS 能拦截但不审查技能代码，AISVS 能做合规审计但不介入运行时，AST10 能识别技能风险但不控制执行。

2. ACS 是唯一的运行时决策层。在本次实验中，只有 ACS 对parameter_injection做出了 deny 裁决。如果系统只部署 AOS + AISVS + AST10，恶意调用仍然会发生，只是会被记录下来。

3. AST10 的覆盖最广但最间接。轨迹中的五个事件命中了 AST10 的 9/10 个类别，但 AST10 本身不做任何拦截或验证，它只是告诉你"这里有风险，属于哪一类"。 remediation 需要依赖 AOS 的可观测性、ACS 的裁决能力或 AISVS 的验证清单。

9. 选型决策树

9.1 建设期：搭 Agent 平台

推荐组合：AISVS Level 1（基线清单） + AST10（技能准入 checklist）

建设期的核心任务是"把基础控制项对齐"。AISVS Level 1 提供 15 条左右 essential baseline controls（根据 AISVS 1.0 文档结构），涵盖输入验证、输出控制、访问控制、供应链安全等维度。团队应逐条核对当前实现状态，标记 gaps。

同时，任何将引入系统的第三方或自研技能，必须经过 AST10 checklist 审查。至少应覆盖：AST01（是否为恶意技能）、AST03（权限是否最小化）、AST04（元数据是否完整可信）、AST05（是否包含不可信外部指令）。

不建议在建设期单独部署 ACS。此时策略规则尚未稳定，过早引入 Guardian 可能导致大量误拦截，反而阻碍迭代。

9.2 验证期：上线前审计

推荐组合：AISVS Level 2（标准控制审计） + AOS trace 抽样

验证期的核心任务是"证明系统满足某等级的安全控制"。AISVS Level 2 适用于生产系统、客户-facing AI、处理个人数据或做出 consequential decisions 的场景。审计团队应抽取关键 Agent 轨迹，逐条对照 AISVS-AGENT-01 至 AISVS-AGENT-0X 的 verification requirement。

同时，启用 AOS instrumentation 采集一段时间的 trace，抽样检查 parameter_overrides、skill 标识、tenant/session 标签是否完整。AOS trace 是 AISVS 审计的证据来源。

可以开始试点ACS Guardian，但建议先以 observe 模式运行（记录裁决结果但不强制执行 deny），积累一段时间的数据后再切换到 enforce 模式。

9.3 监控期：持续运营

推荐组合：ACS Guardian（实时裁决） + AOS 观测 + AST10 技能扫描

监控期的核心任务是"持续检测 + 快速响应"。ACS Guardian 应处于 enforce 模式，对已知攻击模式（如 SQLi 参数、越权工具调用）做出实时 deny。AOS trace 持续采集，用于事后取证与异常检测。AST10 扫描应定期运行（建议每周或每次技能更新后），检查已安装技能是否出现新的风险类别命中。

AISVS 的角色变化：在监控期，AISVS 不再是主要工具，但应在重大变更（如新增 Agent 能力、引入新技能类型）后触发 re-verification，确保系统仍然满足当前等级的控制要求。

9.4 "只用一个够不够"的直接回答

• 只用一个就能上线？不够。至少需要 AISVS（验证控制是否到位）+ ACS（运行时拦截）+ AOS（事后可观测）三件套。AST10 在技能密集场景下也是必需的。

• 四套标准必须同时部署？不必须。建设期可以先只上 AISVS + AST10；验证期再加 AOS；监控期才上 ACS。分期落地比一次性全上更实际。

10. 避坑与落地经验

10.1 元数据对齐是最大实操坑

四套标准对同一概念使用不同的命名。AOS 使用aos.tenant/aos.session，ACS 使用tenant/session字段，AISVS 文档中可能使用 "tenant_id" 或 "data_segregation_label"，AST10 讨论的是 "skill_publisher" 与 "skill_version"。在系统设计阶段必须建立元数据映射表，确保同一概念在四套标准中保持一致性。否则，trace 里的tenant-alpha在 AISVS 审计时可能找不到对应的字段，导致验证失败。

10.2 AISVS 的 PARTIAL 陷阱

AISVS 的验证结果分为 PASS / PARTIAL / FAIL / N/A 四档。PARTIAL 是最容易被忽略的状态：它表示"部分满足"，但具体缺了什么没有强制格式要求。在审计实践中，建议为每个 PARTIAL 结果附加缺失项描述与** remediation 计划**，否则合规报告会留下灰色地带。

10.3 AST10 分类重叠的处理

如第 7.3 节所述，一次skill_override事件可能同时命中 AST02 / AST03 / AST04。安全团队应避免"只选一个最严重的类别上报"的做法。正确的处理方式是保留多类别标记，因为每个类别对应不同的 remediation 路径：AST02 需要检查供应链，AST03 需要收紧权限，AST04 需要修复元数据。

10.4 确定性实验环境的重要性

本次实验使用冻结时钟（NOW = "2026-09-16T08:00:00Z"）与确定性 UUID（uuid5(NAMESPACE_DNS, seed)），确保在任何平台上重跑python3 run_all.py都能得到完全相同的输出。对于需要跨团队共享实验结论的场景，确定性环境是基本要求。如果使用uuid4()或time.now()，审计链哈希与 trace_id 都会变化，文章中的数字将无法被读者复现核对。

10.5 不推荐的方向

• A2A 前瞻类：当前 A2A Protocol 处于 v0.2 阶段，规范未稳定，大量细节仍处于讨论中。本文不纳入选型，是因为"基于未发布规范的选型指南"对读者没有落地价值。

• PQC 签名单独成文：后量子密码与 ACS 审计链的结合是值得研究的方向，但受众过窄（主要面向密码学团队与高合规场景），不适合作为通用选型指南的内容。

11. 总结

OWASP Agent 标准族当前已形成四层互补体系：

• AOS是观测基础，负责把 Agent 执行变成可追溯的 trace；它不说话，但记得最全。

• ACS是治理核心，负责在运行时做出拦截决策并维护不可抵赖的审计链；它说话算数，但只按策略行事。

• AISVS是验证标尺，提供分等级的合规 checklist；它不介入运行，但能告诉你"有没有做到"。

• AST10是技能安检，覆盖技能从代码到供应链的 10 个风险维度；它不控制运行时，但能识别"带什么上船"。

四套标准的关系不是"选一个淘汰其他"，而是"在不同阶段用不同的组合"。建设期用 AISVS Level 1 + AST10 做基线；验证期用 AISVS Level 2 + AOS trace 做审计；监控期用 ACS + AOS + AST10 做持续运营。理解每套标准的能力边界，比知道它的条款数量更重要。

附录 A：实验环境与复现命令

实验环境：Ubuntu 26.04 LTS，Python 3.14.4，IP 192.168.31.129，用户名 ubuntu26-04-1。

# 1. 创建实验目录
mkdir -p ~/lab64 && cd ~/lab64

# 2. 上传 trajectory.py 与四个 wrapper 脚本（见 lab64/）

# 3. 运行全量实验
python3 run_all.py > run_output.txt 2>&1

# 4. 查看结果
cat run_output.txt
cat matrix.json

附录 B：四标准术语映射表

附录 C：AST10 完整类别与本次轨迹命中情况