Verifying Third-Party Agent Execution Evidence Cheat Sheet / 验证第三方代理执行证据速查表¶
Introduction / 介绍¶
This cheat sheet helps developers assess execution records supplied by an agent, a Model Context Protocol (MCP) server, or a service they do not control. A supplier can sign a record that omits actions or describes a run that never happened. Verify the specific claim you need, and identify who could fabricate the evidence supporting it.
此速查表帮助开发者评估由代理、模型上下文协议(MCP)服务器或他们无法控制的服务提供的执行记录。供应商可以签署省略操作或描述从未发生过的运行的记录。验证您需要的具体声明,并确定谁可能伪造支持该声明的证据。
Supply-chain Levels for Software Artifacts (SLSA) verification guidance) (软件工件供应链级别(SLSA)验证指南) separates checking signatures and artifact identity from deciding which producers to trust. Apply the same distinction to execution records. Use these outcomes for each question below:
| Outcome / 结果 | What the evidence supports / 证据支持的内容 |
|---|---|
| Independently re-checkable 可独立验证 |
Another reviewer can verify the stated property using authenticated evidence and trust material the supplier does not exclusively control. This does not establish other properties of the execution. 另一位审阅者可以使用经过验证的证据和供应商不独家控制的信任材料来验证所声明的属性。这并不建立执行的其它属性。 |
| Supplier assertion 供应商声明 |
The supplier claims the property, but independent evidence is missing. The record can still help with debugging and routine operations. 供应商声称具有该属性,但缺乏独立证据。记录仍有助于调试和日常操作。 |
| No information 没有信息 |
The evidence does not let you assess this property of the execution. Do not infer that the run was clean. 证据不允许你评估执行的此属性。不要推断运行是干净的。 |
A signature may establish who made an assertion without establishing that the assertion is true. Do not use supplier assertions alone to resolve an incident attribution or dispute involving that supplier.
签名可以确定谁做出了声明,但并不确定该声明是真实的。不要仅使用供应商声明来解决涉及该供应商的事故归因或争议。
For producing and protecting your own logs, see the Logging Cheat Sheet. For optional message integrity and replay protection between agent and server, see MCP Security Section 7. These checks assess individual records; they do not establish end-to-end completeness across a chain of delegated actions.
有关生成和保护您自己的日志,请参阅日志速查表。有关代理和服务器之间可选的消息完整性和重放保护,请参阅MCP安全部分7。这些检查评估单个记录;它们不建立委托动作链的端到端完整性。
Six Questions to Ask About an Execution Record / 关于执行记录的六个问题¶
1. Who could have written or altered it? / 1. 谁可能编写或修改它?¶
List the component, host, recorder, operator, and signing-key holder. Count independent parties, not processes: several services under one supplier's control remain one party. A recorder fed only by the component preserves that component's account of events. A signing service that accepts arbitrary content from the component does not independently confirm the content.
列出组件、主机、记录器、操作员和签名密钥持有者。计算独立方,而非进程:受同一供应商控制的多个服务仍算作一方。仅由组件提供数据的记录器保留了该组件的事件描述。接受来自组件任意内容的服务不独立确认内容。
- Identify an observer that obtains event data independently of the component's own reports.
中文:识别一个独立于组件自身报告获取事件数据的观察者。 - Keep its records where the component and supplier cannot rewrite them.
中文:将记录保存在组件和供应商无法重写的地方。 - Corroborate the supplier's record against calls recorded at a gateway or other boundary you control.
中文:将供应商的记录与您控制的网关或其他边界记录的调用进行核实。
A boundary recorder covers only what crosses that boundary. It cannot establish local file writes or in-process actions, and it cannot inspect encrypted request bodies without access to their plaintext. Where independent observation is unavailable, classify the account of execution as a supplier assertion and limit the decisions you base on it.
边界记录器仅覆盖跨越该边界的部分。它不能建立本地文件写入或进程中的操作,并且在没有访问其明文的情况下不能检查加密的请求体。在独立观察不可用的情况下,将执行描述分类为供应商声明,并限制基于此做出的决策。
2. What does the timing evidence actually establish? / 2. 时间证据实际上确立了什么?¶
A timestamp written by the supplier is a supplier assertion. To check freshness, send a fresh, unpredictable challenge value (a nonce) and require it to be signed together with the execution claims. Verify the signature and compare the returned nonce with the one you sent.
供应商写入的时间戳是供应商的声明。为了检查新鲜度,发送一个新鲜、不可预测的挑战值(nonce)并要求它与执行声明一起签名。验证签名并比较返回的nonce与您发送的nonce。
RFC 9334 Section 10) (RFC 9334 第10节) explains the limit: a matching nonce bounds signing to after the challenge was generated; it does not show when the individual claims were captured. A trusted timestamp bound to the signed record can establish that it existed by a particular time, but does not establish that its contents describe real events.
Record which timing property you checked. Do not label capture as contemporaneous merely because a signature is fresh or a record appears in a transparency log. That claim needs evidence from an observer positioned to witness the execution.
记录您检查的时序属性。不要仅仅因为签名新鲜或记录出现在透明日志中就将其标记为同时发生。这一主张需要来自能够见证执行过程的观察者的证据。
3. Does it identify the intended artifact and execution? / 3. 是否识别了预期的工件和执行?¶
A valid signature on a record about another artifact or run does not answer your question.
关于另一个工件或运行的记录上的有效签名并不能回答您的问题。
- Recompute a collision-resistant digest of the expected artifact and compare it with the signed subject. Obtain the expected artifact or digest independently of the report being assessed.
中文:重新计算预期工件具有抗碰撞性的摘要,并将其与已签名的主题进行比较。独立于正在评估的报告,获取预期的工件或摘要。 - Separately match the signed execution identifier or challenge to the run you intended to review.
中文:单独将已签名的执行标识符或挑战与您打算审查的运行进行匹配。 - Check which relevant inputs are covered, such as tool definitions, configuration, prompts, model version, and policy. A binary digest alone does not identify these inputs.
中文:检查哪些相关输入被覆盖,例如工具定义、配置、提示、模型版本和政策。仅二进制摘要本身并不能识别这些输入。
An artifact digest can legitimately stay the same across many runs. The problem is using that digest as the only binding to an execution. A matched digest establishes artifact identity; a matched run identifier establishes which execution the supplier is claiming to describe. Neither establishes that the reported actions occurred.
工件摘要可以在多次运行中保持合法的一致性。问题是使用该摘要作为执行的唯一绑定。匹配的摘要确立了工件的身份;匹配的运行标识符确立了供应商声称描述的执行。但它们都不能确立报告中的操作是否发生。
4. Would an omitted event be detectable? / 4. 被省略的事件是否可检测?¶
Define the execution or time window and the events an independent observer was positioned to see. Reconcile the record against an expected-event list or per-execution sequence that the supplier cannot silently redefine. A supplier-maintained sequence counts only what the supplier chose to include.
定义执行或时间窗口以及独立观察者所看到的事件。将记录与供应商无法静默重新定义的预期事件列表或执行序列进行核对。供应商维护的序列只计算供应商选择包含的内容。
A transparency log can make changes after entry detectable; it cannot reveal an event that was never submitted. RFC 9162 describes inclusion and consistency checks and warns that a log can present inconsistent views to different clients. Verify those proofs and check how the deployment detects inconsistent views, such as by comparing signed log states across independent observers. The log operator remains a trust dependency.
透明度日志可以在记录后检测到更改;它无法揭示从未提交的事件。RFC 9162 描述了包含和一致性检查,并警告日志可能向不同的客户端呈现不一致的视图。验证这些证明并检查部署如何检测不一致的视图,例如通过比较独立观察者之间的签名日志状态。日志操作员仍然是一个信任依赖。
A log's total entry count is not an execution's event count. Unrelated entries can increase it while events from the run are missing. Likewise, injecting one expected event and finding it in the returned record is a useful spot-check, not a completeness test. Any coverage claim must remain limited to the events the independent observer could see and reconcile.
日志的总条目数不是执行的事件数。无关条目可能会增加它,而运行的事件可能会缺失。同样,注入一个预期事件并在返回的记录中找到它是有效的抽查,而不是完整性测试。任何覆盖率声明必须限制于独立观察者可以看到并核对的事件。
5. What happens when recording or delivery fails? / 5. 记录或交付失败时会发生什么?¶
Determine whether the component continues and drops events, buffers and retries, or stops execution. Check buffer overflow behavior as well as normal operation.
确定组件是否继续并丢弃事件、缓冲和重试,或者停止执行。同时检查缓冲区溢出行为以及正常操作。
- In an environment you control, interrupt the recording path and observe whether execution continues and gaps become visible.
中文:在一个你控制的环境中,中断记录路径并观察执行是否继续以及是否存在空白。 - Where you cannot test, request evidence from an outage or an exercised failure scenario. Treat documentation alone as a supplier assertion.
中文:在你无法测试的地方,请求故障或已练习的故障场景的证据。将文档视为供应商的声明。 - Preserve independently observed delivery failures outside the component's control. A gap marker written solely by the component is still its assertion, even when stored elsewhere.
中文:保留独立观察到的组件控制之外的交付失败。仅由组件编写的空白标记仍然是其声明,即使存储在其他地方。
A test establishes the behavior observed under its conditions; it does not prove that another execution had no gaps. An empty report from a recorder that may have dropped events provides no basis for declaring that run clean. Stopping execution on every logging failure is not automatically appropriate: it turns a recording outage into an availability failure. Choose the behavior according to the action's risk and make any loss of evidence visible.
测试在特定条件下确定观察到的行为;它并不能证明其他执行没有漏洞。如果记录器可能已丢失事件,则空报告不能作为声明运行干净的依据。在每次日志失败时停止执行并不自动合适:它将记录中断转变为可用性故障。应根据操作的风险选择行为,并使任何证据损失可见。
6. Can the reviewer verify it without being able to forge it? / 6. 审查员能否在没有伪造的情况下验证它?¶
Use a maintained verifier with trusted signer identities, keys or certificate roots, and permitted algorithms configured independently of the record. A key packaged with the record is not a trust anchor merely because it verifies that record; it must connect to trust you already established. The SLSA verification steps illustrate checking the signature, subject digest, and expected producer before relying on provenance.
使用维护的验证器,具有受信任的签名者身份、密钥或证书根,以及独立于记录配置的允许算法。与记录一起打包的密钥并不是仅因为它验证了该记录就成为了信任锚;它必须连接到您已经建立的信任。SLSA验证步骤https://slsa.dev/spec/v1.2/verifying-artifacts说明了在依赖来源之前检查签名、主题摘要和预期生产者。
Validate applicable certificate paths and revocation information, as described in RFC 9334 Section 12.4. Do not accept a signature solely because the cryptographic calculation succeeds.
验证适用的证书路径和撤销信息,如RFC 9334第12.4节所述。不要仅因为加密计算成功就接受签名。
Public-key verification does not require the signing secret. By contrast, everyone holding the shared secret needed to verify a message authentication code can also create one. Such a record cannot independently attribute authorship between those key holders. Asking the supplier's service whether its own record is valid also leaves the supplier as the source of the assertion.
公钥验证不需要签名密钥。相比之下,持有验证消息认证码所需共享秘密的每个人都可以创建一个。这样的记录不能独立地将作者身份归因于这些密钥持有者。询问供应商的服务其记录是否有效也将供应商作为声明的来源。
Worked Examples / 工作示例¶
These examples describe evidence after the stated checks, rather than assigning guarantees to a file format.
这些示例描述了在所述检查之后的证据,而不是将保证赋予文件格式。
| Evidence and checks performed / 执行的证据和检查 | What you may conclude / 你可以得出什么结论 | What remains unestablished / 尚未确定的内容 |
|---|---|---|
| Vendor-exported traces, with no independent corroboration 没有独立佐证的供应商导出的跟踪信息 |
The vendor supplied these claims. 供应商提供了这些主张 |
Whether the actions occurred and whether the record is complete. 是否发生了这些操作以及记录是否完整 |
| A signed record verified against your trusted signer, with artifact digest and run identifier matched to your expectations A 签名记录经过您信任的签名者验证,与您期望的工件摘要和运行标识符匹配 |
That signer asserted these bytes about the expected artifact and run. 该签名者声明了关于预期工件和运行的这些字节。 |
Whether the assertions are true or complete. 这些断言是否为真或完整。 |
| The same record, with verified log inclusion and consistency evidence plus an independently trusted timestamp over the signed record 相同的记录,包含经过验证的日志包含和一致性证据,以及独立信任的时间戳覆盖签名记录 |
The signed record existed by the supported time and is included in the checked log state. 签名记录在支持的时间内存在,并包含在检查的日志状态中。 |
When events were captured, whether they occurred, or whether any were omitted before submission. 在事件被捕获时,它们是否发生,或者是否有任何在提交前被省略。 |
| The record reconciled against events captured by an independent boundary observer 记录与独立边界观察者捕获的事件进行了核对 |
Whether the record includes the events that observer saw in the stated window. 记录是否包含观察者在指定窗口内看到的那些事件。 |
Internal actions, other boundaries, or events outside the observer's coverage. |
Do's and Don'ts / 该做什么和不该做什么¶
Keep the verification policy and expected values outside the evidence under review, following the separation in SLSA verification guidance.
将验证策略和预期值保留在审查证据之外,遵循SLSA验证指南中的分离原则。
Do / 做¶
- State the exact property being checked: signer, artifact, execution binding, timing, or coverage.
中文:明确指出正在检查的确切属性:签名者、工件、执行绑定、时间或覆盖率。 - Record the trust assumptions and limits alongside each result.
中文:将信任假设和限制与每个结果一起记录。 - Reconcile supplier reports with observations you control when possible.
中文:在可能的情况下,将供应商报告与您控制的观察结果进行核对。 - Exercise recording failures in an environment you control and preserve the results.
中文:在您控制的环境中记录失败,并保留结果。
Don't / 不¶
- Treat a valid signature or log inclusion proof as proof that an action occurred.
中文:将有效的签名或日志包含证明视为已发生动作的证据。 - Confuse a stable artifact digest with a unique execution identifier.
中文:将稳定的工件摘要与唯一的执行标识符混淆。 - Treat a fresh signature as proof of live capture, or a successful spot-check as proof of completeness.
中文:将新的签名视为实时捕获的证据,或成功的现场检查作为完整性的证据。 - Treat missing entries as evidence that nothing happened when recording could have failed.
中文:将缺失条目视为记录失败时未发生任何事件的证据。
References / 参考¶
- SLSA: Verifying Artifacts) (SLSA: 验证工件)
- RFC 9334: Remote ATtestation procedureS (RATS) Architecture) (RFC 9334: 远程认证程序(RATS)架构)
- RFC 9162: Certificate Transparency Version 2.0) (RFC 9162: 证书透明度版本 2.0)