AI Agent Evidence Export: A Verifiable Handover

An AI agent evidence export should let an authorised recipient understand what was handed over, verify its integrity and identify what is missing without relying on the original application's interface. A ZIP file alone does not provide that assurance. Define a manifest, scope, trust information, verification procedure and acknowledgement that refers to the exact exported package.

This article is for platform and audit teams transferring evidence between operational owners, customers or independent reviewers. It focuses on package handover rather than the cryptographic design of individual receipts. The example is a synthetic case bundle containing decision records, action references and a later outcome observation. It contains no customer payloads or credentials.

Agree the recipient's question before exporting

Ask what the recipient must establish: that a specific action was approved, that a provider reported acceptance, or that all known operations in a period have related evidence. These are different claims. A package designed for one case may be unsuitable for a population-level audit, even if every file is correctly signed.

Define the recipient, permitted purpose, case population, time boundary and expected handling restrictions. Confirm that sharing the evidence is authorised separately from performing the underlying action. A mandate to prepare a document does not automatically grant permission to distribute its supporting material to every reviewer or train a model on it.

The NIST AI RMF Playbook provides suggested risk-management activities, including documentation. The package design here is our proposed engineering method. It is not a regulatory export format, a legal admissibility determination or a claim that one technical bundle satisfies every organisation's evidence obligations.

Create a manifest with explicit omissions

List included files, their intended roles, byte digests and the references linking them to the case. Record the export format version and the exporter identity. Where a referenced source is deliberately excluded, explain whether it is retained elsewhere, unavailable, outside scope or withheld under an access rule. Silence should not be interpreted as completeness.

Keep file paths safe for extraction. Reject absolute paths, parent-directory traversal and unexpected executable content in the receiving workflow. Put resource limits on archive size and extraction. These are package-handling controls proposed for the workflow; they do not replace the organisation's existing malware and data-loss checks.

Verify integrity before interpreting the evidence

The recipient should validate the package structure, expected file inventory and digests before reading the substantive records. Verify signed material against independently trusted keys and the applicable lifecycle information. A public key included inside an untrusted archive cannot, by itself, establish who should be trusted to issue the evidence.

Then check relationships: approvals should refer to the exact prepared object, dispatch records to the intended operation, and outcomes to authoritative observations. Distinguish a provider's acceptance from final completion. A valid signature protects the signed statement's integrity and attribution under the verified key; it does not prove that every underlying fact is true.

Preserve the verification report with the package identifier and tool version. Report unsupported formats or unavailable lifecycle information as limitations, not as successful checks. If a tool ignores unknown fields, document that behavior so reviewers do not assume it validated semantics that it never examined.

Make redaction a visible transformation

Do not edit signed payloads in place and expect the original signature to verify. Where possible, export a purpose-limited reference or a separately defined derived record. Preserve the relationship to the original evidence and state which information was withheld. The appropriate mechanism depends on the evidence format and the recipient's permitted scope.

If the recipient needs a fact that was removed, resolve that through an authorised disclosure process. Do not send a second informal copy over email and leave the package history unchanged. Record the supplemental handover and its relationship to the first package. This keeps the actual review basis reconstructable.

Exercise the recipient workflow independently

Prepare a synthetic package and give it to a reviewer who did not create it. Ask them to identify the case, expected claims, omitted material and verification procedure using only the accompanying instructions. Record ambiguous terms and missing dependencies. A package that requires its author to explain every file is not yet portable.

Repeat after changing one byte, removing a referenced record and replacing a verification key with an untrusted one. These should produce different findings. Add a valid but unrelated record and check that it does not satisfy a missing relationship. Integrity, trust, scope and completeness need separate outcomes in the report.

Finally, verify the package without access to the original application where the chosen format permits it. Record any checks that still require online state, such as current revocation information. “Offline verification” should describe the checks actually available offline, not imply that all current lifecycle facts can be established from a frozen archive.

Close the handover without overstating acceptance

Record delivery, successful extraction, technical verification and substantive acceptance separately. A recipient may receive the archive but be unable to verify it, or verify the bytes while disputing the claims. The acknowledgement should identify the exact package and which stage has completed.

For a replacement export, retain the previous package's identifier and explain whether the new version supplements or supersedes it. Do not silently replace a download under the same immutable reference. Existing reviews must remain tied to the material that was available when they were made.

Use the worksheet to rehearse one bounded case handover before attempting a large export. Assign owners for missing evidence, trust configuration and recipient questions. The goal is a transfer that another qualified team can interpret and challenge, with limitations preserved, rather than a folder whose completeness is asserted only by its sender.

Use the worksheet and related implementation guides

Use the parent guide for the wider architecture, then apply this article to one bounded implementation. The adjacent articles cover related decisions without replacing this worksheet.

• Parent guide
• Related implementation
• Adjacent control

Download the editable worksheet. Next step.

Engineering draft, 18 October 2026. Primary sources checked on this date; specialist review remains pending. The worksheets describe proposed tests, not measured customer results. OATI remains a developer preview. Local implementation evidence does not establish independent assurance, customer acceptance or production readiness for a particular deployment.