New IETF draft binds AI agent packages to provenance

You must maintain two separate, independently verifiable audit trails for any AI agent whose outputs you must justify: one recording the package provenance before execution, and a second documenting the evidence and decisions during the task itself.

An analysis of 4 November 2026 of the IETF Internet-Draft binding portable AI agent packages to signed provenance statements argues that cryptographic binding of agent packages to build, review and withdrawal records solves only half the accountability problem. The draft proposes immutable digests linking provenance statements to exact package content, creating a verifiable history before execution. In our assessment, this addresses package integrity but leaves a critical gap: it does not define per-action execution receipts showing what the package actually did during a specific task, which research has shown can vary even when final answers remain identical.

Why a package digest alone does not establish what an agent actually decided

A valid cryptographic signature proves the integrity and sender of a provenance statement, not that the statement's content is true. Researchers studying a biomedical research agent found that identical final judgements could rest on different evidence, citations and intermediate results once the underlying tool state changed. An audit trail recording only the package before execution therefore cannot answer the question a reviewer or regulator will ask: which specific data, sources and values determined this particular conclusion? You need a second trail that records, per task, which tool results and sources influenced the decision and what action followed from them.

Which two trails must you keep separate and verifiable

The first trail documents the provenance of the package itself before it runs. This includes model artefacts, data provenance, software dependencies, runtime configuration, container hashes and output digests, with cryptographic validation and signed provenance statements. The IETF draft handles this through immutable digests and linked statements on authorship, builds, transformations, safety reviews, approvals and withdrawal.

The second trail records the evidence actually used during execution. Peer-reviewed research describes a practical form: Filtered Decision Logs containing a short rationale, influence-ordered supporting data points and relevance indicators from tool outputs. This allows an authorised reviewer to inspect the relevant artefacts and, if necessary, rerun the task after excluding a source. Both trails must connect via the package digest and a timestamp, so you can verify which exact version of the package produced which specific output.

What policy must you set before admitting an agent to justified use

The IETF draft is still an Internet-Draft, not an established standard, and the authors themselves warn against misreading a valid signature as proof of truthfulness. Before an agent handles sensitive analyses, you must set explicit policy on which signers and which safety reviews you accept. This aligns with existing risk frameworks from the OWASP Foundation and guidance from the US National Institute of Standards and Technology, but you cannot delegate the decision to the presence of a valid digest alone.

Your governance obligations now include:

• Demand a valid digest and signer policy — do not admit an agent unless you have documented which signers and safety reviews you accept for that package.
• Record the exact version with timestamp — for every justified answer, store the package digest and the execution timestamp, because replacement and withdrawal are now recordable in provenance statements.
• Maintain Filtered Decision Logs per task — document the evidence used, influence-ordered supporting data and relevance indicators so a reviewer can inspect the artefacts and rerun the task if needed.
• Verify the digest remains accepted — do not assume that approval of an earlier version continues to apply to a newer or withdrawn version; check the digest against your current policy before relying on the output.
• Keep human judgement explicit — influence scores from decision logs are not causal attribution or proof of correctness; the professional final judgement must remain with the human reviewer.

How should you structure the execution trail in practice

The second trail should be reviewer-facing and allow authorised personnel to inspect the relevant artefacts without requiring them to rerun the entire agent workflow. A practical structure includes the task identifier, the package digest and timestamp, the sources and tool results that influenced the decision, a short rationale for the conclusion, and a flag indicating whether the digest used is still within your current acceptance policy. This approach aligns with earlier practice on building internal provenance records alongside supplier statements and with the established controls for managing the risks when an agent calls external tools.

Tooling can automate the recording of package digests, timestamps and tool outputs, and can flag when a digest falls outside your acceptance policy. What remains your own professional responsibility is the decision about which signers to trust, which safety reviews to require, and the final human judgement on whether the evidence supports the conclusion. The standards and frameworks are still evolving; starting this practice now in pilot work will establish the baseline you need when the standards mature.