AgentLock 首跑不要先测“能否拦截”：先验证 ALLOW、DENY、DEFER 与版本边界

很多 Agent 安全测试一上来就塞一段提示注入，然后看工具有没有被拦住。这个顺序不可靠：如果你没有记录安装的版本、策略文件、上下文来源和最终决策，测试结果无法复现。

我在 AgentLock 的首跑里先做四件事。

第一，分清证据版本。Doramagic manual 当前写的是 AgentLock v1.2.1，说明了 ALLOW、DENY、DEFER 三态、签名 receipt 和 hash-chained context；upstream README 当前已经列到 v1.5.0，并新增 grant basis、execution confirmation、provenance on denials 和 deferred-resolution logging。两者不能混成一个版本结论。先执行：

~~~bash
python -m pip install agentlock
python -m pip show agentlock
~~~

把版本、安装来源和 extras 记录下来。需要 Ed25519 receipt 时再安装：

~~~bash
python -m pip install "agentlock[crypto]"
~~~

第二，先验证三态决策，而不是只验证拒绝。ALLOW 表示策略允许动作，DENY 表示动作被拒绝，DEFER 表示风险信号无法由当前策略自动决定，需要人工或更高等级处理。一个好的最小测试矩阵至少包含：明确允许的低风险工具、命中 deny 规则的工具、第一次调用中风险工具，以及策略无法判断的参数。

第三，给上下文来源做标记。upstream README 把来源分成 authoritative、derived 和 untrusted，并用 session write-gate、parameter lineage、deferred commit 约束后续动作。同一个 send_email 调用，如果参数看起来完全相同，但它是在用户指令之后还是网页内容之后形成的，决策应该分别回读。测试时不要只比较字符串。

第四，验证 receipt 是否真的能解释结果。至少保存 request hash、policy hash、verdict、session ID 和异常类型。DENY 不等于系统崩溃；如果调用方把 AuthorizationDenied、RateLimitExceeded 和 ContextIntegrityError 都吞成一个“失败”，后续审计仍然无法定位原因。

AgentLock 的关键价值不是“让模型变得更安全”，而是把工具调用前的授权变成可重放的规则判断。它也有明确边界：模型只在文本里完成了说服，不产生工具调用时，write-gate 无法拦截；只读操作造成的风险，也不是写门可以全部覆盖；工具的 authority 标记错误时，策略会建立在错误输入上。

因此首跑验收的结论应该写成：安装了哪个版本、哪些来源被标记为 untrusted、哪些动作进入了 DEFER、receipt 能否重放，以及 benign workflow 的通过率是多少。不要只写“成功拦截提示注入”。

来源：

- Doramagic manual：https://doramagic.ai/en/projects/agentlock/manual/
- upstream README：https://github.com/webpro255/agentlock