New IETF draft binds AI agent packages to signed provenance before execution

A new IETF Internet-Draft of 2 November 2026 binds portable AI agent packages to an immutable digest with signed statements about build, review and withdrawal, but covers only the package before execution. Anyone who must justify AI answers also needs a second, separately verifiable trail for the evidence and decisions during execution.

On 2 November 2026 an Internet-Draft from the IETF appeared titled SCITT Profile for Portable AI Agent Package Provenance. It elaborates the existing SCITT framework (a method to record statements cryptographically and verifiably) for portable AI agent packages.

Our reading in advance: the draft solves one half of the problem. It makes verifiable to which exact package the provenance statements are bound, but it does not define per-action execution receipts for what that package did during a specific task.

What does the IETF Internet-Draft say about provenance of AI agent packages?

The draft proposes binding every portable agent package to an immutable cryptographic digest (a cryptographic digest that binds the statements to the exact package content) and linking separate provenance statements to it, such as authorship, builds, transformations, safety reviews, approvals, replacement by a newer version and withdrawal. This creates a verifiable history before execution.

The authors themselves warn against a misunderstanding: a valid signature proves the integrity and the sender of a statement, not that the content of that statement is true. A party that relies on the provenance therefore needs its own policy on which signers and which reviews it accepts. The safety reviews in such a profile align with existing practices, such as the risk categories the OWASP Foundation has published for large language models and agents, and with the risk guidance maintained by the US National Institute of Standards and Technology (NIST). Also important is the status: this is an Internet-Draft, not an established standard.

• Immutable digest: which exact package is admitted.
• Authorship and builds: who made it and how it was built.
• Transformations: which modifications were carried out.
• Safety review: which review applies to this digest, for example against OWASP risk categories or NIST risk guidance.
• Replacement and withdrawal: whether provenance statements exist about supersession or withdrawal of this package.

Why does an identical AI answer not prove that the same evidence was used?

Because the path to the answer can change while the answer stays the same. Researchers behind the study From Tool State to Scientific Action, presented at the NeurIPS 2026 AgenticLS workshop, showed that a biomedical research agent can give the same final judgement while the evidence used and cited differs.

In their recovery and transplantation experiments, citations and decisions changed as soon as the underlying tool state was altered. Their conclusion: an audit must track both the evidence actually used and the final answer. In our assessment this bears directly on the SCITT proposal: a correct package digest says nothing about which numerical values, source artefacts or intermediate results determined a specific conclusion.

How do I link package provenance to the decisions made during execution?

By maintaining two separate, independently verifiable trails and connecting them via the package digest and a timestamp. The first trail is the provenance of the package before execution. The second trail records, per task, which tool results, sources and values influenced the decision and which action or conclusion followed from them.

For the first trail, the peer-reviewed research into an Artificial Intelligence Bill of Materials in Frontiers in Computer Science offers a usable model. The authors link model artefacts, data provenance, software dependencies, runtime configuration, container hashes and output digests, with cryptographic validation and signed provenance artefacts. That framework makes clear that provenance is more than a package name or supplier.

For the second trail, the study Visible Reasoning describes a form that reviewers can use: Filtered Decision Logs with a short rationale, influence-ordered supporting data points and relevance indicators from tool outputs. In our analysis, this suggests a reviewer-facing form in which authorised reviewers can inspect the relevant artefacts and rerun the task after excluding a source.

A concrete link, in our assessment, looks like this:

1. At admission, record the package digest, author, review and withdrawal status.
2. For each task, register the source artefacts, values and intermediate results used.
3. Connect both trails with the package digest and a timestamp; also record explicitly when an organisation accepts a newer version as a replacement.
4. In our analysis, authorised reviewers should be able to exclude a source and rerun the task, with the difference recorded.

For background on this distinction, use the topic hub on agentic AI and AI agents and the analysis of why a plausible AI explanation is not yet proof.

What does this mean for directors, lawyers and CISOs who must justify AI answers?

Our analysis: because the SCITT draft makes the integrity and signer of provenance statements verifiable but does not by itself establish that the statements are true, CISOs and governance owners cannot make do with demanding a valid digest; they must set policy on which signers and safety reviews they accept before an agent is admitted. Because the biomedical agent study shows that an identical final judgement can conceal different evidence, every organisation that justifies sensitive analyses must, from the first pilot onwards, record the evidence used per task alongside the answer. Because the draft makes replacement and withdrawal recordable, organisations must not assume that a previous approval continues to apply to a newer or withdrawn version; for every justified answer, record the exact version with a timestamp and check whether the digest used is still accepted. Because influence scores from Filtered Decision Logs are not causal attribution or a guarantee of correctness, lawyers and directors may not present them as conclusive proof; the professional final judgement should explicitly remain with the human. This approach aligns with an earlier analysis of building an internal provenance record alongside a supplier statement, and with the practice of controlling the risks when an AI agent calls tools itself.

In summary, this news leads to a short priority list:

• Draw up an acceptance policy for signers and reviews of agent packages.
• For each justified task, record two trails: package provenance and the evidence used.
• Link both with digest and timestamp, and check withdrawal and replacement periodically.
• Treat influence scores as a control aid, not as proof of correctness; the final judgement stays with the human.

The four sources come from specific experimental or proposal settings and the IETF text is still a draft. That is a reason to trial this approach now, not to wait for a finished standard.

Sources: The article draws on the IETF Internet-Draft on SCITT provenance, a biomedical agent study from the NeurIPS 2026 AgenticLS workshop, and peer-reviewed research into AIBOMs in Frontiers in Computer Science and into Filtered Decision Logs on arXiv.