Proving the AI Agent Version Approved by Validators Is the Version Running in Production

Define the version before you try to prove it

Validators rarely approve a model alone. They approve a behavior produced by a configuration: the model and its version identifier, the system prompt, the tool and MCP server definitions, the policy configuration, the orchestration code, and any retrieval configuration. If the approval names only a code release or a ticket number, "approved equals running" cannot be tested, because most of what shapes behavior sits outside that identifier.

NIST guidance on agent identity points the same way. It describes agent identity as cryptographically verifiable and ideally tied to a specific workload, environment, and approved configuration. It also separates an agent's persistent identity from its credentials and runtime instances, and says the identity model should distinguish changes that preserve identity from changes that create a new agent.

That last point is a decision to make up front. Write a continuity rule that states which changes keep the same agent identity and which require a new identity and re-approval. A credential rotation should not change identity. A prompt edit, a tool swap, or a model change is a candidate for a new version. Without the rule, every change is argued after the fact.

Binding an approval to a deployed artifact

The mechanism has four parts. First, build a manifest that lists each component with a digest: an image digest for code, a hash of the prompt text, a hash of each tool and MCP definition, a hash of the policy configuration, and the pinned model identifier. Second, hash the manifest itself. That hash becomes the version identifier. Third, store the identifier in the approval record, so the validator's sign-off refers to a specific artifact and not a description of one. Fourth, have the release process sign the manifest so that anyone downstream can check who produced it and that it has not changed.

Verification then happens twice. At deploy time, the release pipeline compares what is about to be deployed with a signed, approved manifest and refuses a mismatch. At runtime, the running agent presents its identity and manifest hash so that a separate component can confirm that only expected agents are operating. NIST IR 8596 draft material supports this direction: it describes signing and verifying agent assertions and tokens, and blocking unapproved model downloads and agent scripts so only vetted components are integrated. It is a draft and does not specify that assertions carry a configuration hash, so that binding is a design choice you validate yourself.

Version control and rollback capability belong in the same design. A rollback is a deployment of a previously approved manifest, and it should be provable in the same way as any other release.

Where drift occurs and what can cover it

Drift usually enters through hotfixes, prompt edits, tool or model swaps, and configuration changes made outside the release path. Each component has a different binding mechanism and a different gap.

• Orchestration code: Binding: immutable image digest and signed build output. Gap: hotfixes applied to a running instance or deployed outside the pipeline.
• Model: Binding: for artifacts you control, signatures and file hashes, which OWASP recommends to compensate for weak model provenance. Gap: hosted endpoints, where no file is available to hash and the provider's version label is an assertion rather than proof.
• System prompt: Binding: hash of the exact text in the manifest. Gap: prompts held in a database or admin console that can be edited at runtime.
• Tool and MCP definitions: Binding: hash of each schema and endpoint definition. Gap: a remote server that changes its tool descriptions or behavior after approval.
• Policy configuration: Binding: versioned, hashed policy sets recorded in the manifest. Gap: policy edited in place without a new version.
• Retrieval configuration: Binding: hash of index settings, sources, and ranking parameters. Gap: content in the underlying corpus changing while the configuration hash stays the same.

Deploy-time evidence and runtime evidence are different things

Deploy-time evidence shows what was released: the manifest, its signature, the approval reference, and the result of the admission check. Runtime evidence shows what happened while the agent served traffic. Neither substitutes for the other. OWASP's Agentic Evidence initiative, a research project and not a standard, notes that execution signals alone do not establish whether an action was properly authorized, what context influenced it, which tool or resource was accessed, or whether the recorded events are complete.

NIST's tenets add a structural requirement: an append-only, tamper-evident body of evidence covering agent identity, delegated intent, and resulting actions, held in logging infrastructure that is independent of the agent so the agent cannot modify its own records.

This is where runtime policy enforcement contributes, and where its scope ends. Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, with actions such as allow, redact, block, rate limit, and escalate for human approval. Because enforcement happens at runtime, not in a review after the fact, the audit-ready evidence it generates shows what was allowed and what happened for each interaction and tool call. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which helps keep the evidence store separate from the agent.

That evidence does not prove build lineage or show that the validated artifact matches the released one. Trussed does not provide model provenance, model lineage, or end-to-end tracing of agentic workflows. Those questions depend on build, release, and validation tooling, and the two layers should be designed to reference the same version identifier.

Evaluating tooling against these expectations

Start with coverage. Ask which version components carry a verifiable identifier and which do not, and expect honest gaps around hosted model endpoints and remotely managed tools. Ask whether the tool shows when a configuration change creates a new identity, or whether it silently treats the change as the same agent.

Then test the evidence. Is it append-only, tamper-evident, and independent of the agent runtime? Can a per-interaction record show what was allowed or blocked, and under which policy configuration? Can the whole chain be reconstructed end to end for one interaction, from approval to deployment to enforcement record? Finally, check what the tool exports for auditors: drift results, exceptions, rollbacks, and retention settings.

There is a tradeoff in granularity. A strict continuity rule produces more re-approvals but a cleaner evidentiary chain. A loose rule reduces friction but widens the space in which an auditor can reasonably ask whether the validated agent is the one that ran. Choose the rule deliberately and document it, because it determines what "same version" means in every later record.