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

很多 Agent 安全测试一上来就塞一段提示注入然后看工具有没有被拦住。这个顺序不可靠如果你没有记录安装的版本、策略文件、上下文来源和最终决策测试结果无法复现。我在 AgentLock 的首跑里先做四件事。第一分清证据版本。Doramagic manual 当前写的是 AgentLock v1.2.1说明了 ALLOW、DENY、DEFER 三态、签名 receipt 和 hash-chained contextupstream README 当前已经列到 v1.5.0并新增 grant basis、execution confirmation、provenance on denials 和 deferred-resolution logging。两者不能混成一个版本结论。先执行~~~bashpython -m pip install agentlockpython -m pip show agentlock~~~把版本、安装来源和 extras 记录下来。需要 Ed25519 receipt 时再安装~~~bashpython -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 manualhttps://doramagic.ai/en/projects/agentlock/manual/- upstream READMEhttps://github.com/webpro255/agentlock