What Is AgentTrust Trace Verification? The Beginner's Guide to Cryptographic Execution-Trace Verification for AI Agents

CodexFuse Team · 2026-11-05T05:36:35.370Z · 15 min read min read

What Is AgentTrust Trace Verification? The Beginner's Guide to Cryptographic Execution-Trace Verification for AI Agents

What Is AgentTrust Trace Verification?

AgentTrust trace verification is a deterministic cryptographic profile that lets a relying party check whether an AI agent's action was authorized before that action is committed. If you searched for what is agenttrust trace verification, here is the short version: instead of trusting an agent's own log entry that says it did the right thing, a verifier re-checks the signed execution trace, the delegation chain behind it, and the keys that signed it, using exactly the same rules every time.

The profile is proposed in Internet-Draft draft-durga-agenttrust-trace-verification-00, dated 29 October 2026, by Raghuvar Karthik Durga of Microsoft Corporation. It is a work in progress, not an adopted standard, and it expires on 2 May 2027 unless a newer version replaces it. That status matters for everything that follows: this guide explains a proposal, not a finished rulebook.

The problem it addresses is easy to state and hard to solve. Autonomous agents increasingly invoke external tools, change enterprise state, and hand subtasks to other agents across Model Context Protocol (MCP), Agent-to-Agent (A2A), and system-of-record boundaries. Without a deterministic, cryptographically verifiable execution receipt, a relying party cannot tell a self-reported agent log apart from an independently verifiable commitment record.

AgentTrust exists to draw that line.

The draft binds four mechanisms together: JSON Canonicalization Scheme (JCS, RFC 8785) pre-image serialization, Ed25519 (RFC 8032) and ECDSA P-256 and P-384 signatures, JSON Web Key (JWK, RFC 7517) thumbprint pinning, and fail-closed revocation and freshness checks. A SHA-256 hash generator shows the smallest piece of the same idea: one input, one deterministic digest, no room for formatting to change the answer. Teams that run agent infrastructure of their own usually host it on infrastructure like VPS hosting, which is the kind of box these verifiers commonly run on.

This guide is agenttrust explained from the draft itself. It covers the verification steps in order, the canonicalization rules, the signature and key rules, the four delegation-chain checks, and the fail-closed rules. It also names, honestly, what the draft does not yet define.

How Does AgentTrust Verification Work, Step by Step?

AgentTrust verification works by re-deriving the exact bytes that were signed, then checking the signature, the key, and the delegation chain against those bytes, refusing the action if any check fails. The verify-before-trust arc runs in five steps.

1. Canonicalize the trace envelope with JCS before any digest or signature work, rejecting the malformed inputs the draft lists.
2. Compute the digest over the canonicalized bytes, so every verifier in every language gets the same pre-image.
3. Verify the detached signature against that digest, using Ed25519 or ECDSA P-256 or P-384.
4. Pin the signing key by its JWK thumbprint against the pinned trust store, and check the confirmation claim, before evaluating revocation.
5. Run the revocation and freshness checks, and fail closed: if anything cannot be verified, the action is not trusted.

Order matters here. Checking a signature over uncanonicalized bytes would let two verifiers disagree about the same trace, which is exactly the drift the draft is written to prevent. Pinning the key before revocation also matters: there is no point asking whether a key was revoked if you have not first confirmed it is the key you trust.

The draft says the profile formalizes fail-closed verification invariants implemented in the open-source AgentTrust conformance suites: agentrust-io/trace-spec, agentrust-io/agent-manifest, and agentrust-io/weight-custody-manifest. Those repositories are named once here as the draft's own references, not as products this article reviews. The draft also cites three technical reports by the same author, TR-2026-01, TR-2026-02, and TR-2026-03, as empirical background.

What Is JCS Canonicalization, and Why Does It Come First?

JCS canonicalization is the rule that turns a JSON object into one single byte sequence before it is hashed or signed, so that key order and spacing can never change the result. The draft requires every execution trace envelope to be serialized according to RFC 8785 before digest calculation or signature verification, specifically to prevent cross-language signature verification drift between Python, TypeScript and JavaScript, and Rust verifiers.

That requirement is strict in three named ways. Non-string dictionary keys must be rejected with a deterministic type error rather than silently coerced into strings. Lone UTF-16 surrogates, from U+D800 through U+DFFF, and non-finite floating-point values, namely NaN, positive infinity, and negative infinity, must cause canonicalization to fail closed.

Duplicate JSON object member names within signed payloads must be rejected during parsing, before any signature appraisal happens.

Each rule closes a real ambiguity. Coercing a non-string key could let two systems read the same object differently. A lone surrogate or a non-finite number has no single canonical spelling.

A duplicate member name lets a parser pick one value while a signer meant another. The draft's answer to all three is the same: do not guess, do not coerce, refuse.

The same fail-closed instinct governs encoding. Verifiers evaluating detached signatures, witness receipts, or JWK bundles must enforce canonical unpadded base64url encoding, as defined in Section 5 of RFC 4648. Padding characters, non-alphabet whitespace, and non-zero trailing pad bits must be rejected.

A bundle that smuggles extra bits past a lenient decoder is not a verification success; it is a rejection.

What Signatures and Keys Does AgentTrust Accept?

AgentTrust accepts Ed25519 signatures under RFC 8032 and ECDSA signatures on the P-256 and P-384 curves. Those are the only signature schemes the draft's abstract names, and a verifier built to this profile should not silently accept anything else as equivalent.

Keys are identified by JWK thumbprints under RFC 7638, and confirmation claims in the form cnf.jwk must be validated against the pinned trust store prior to revocation list evaluation. Thumbprint pinning is the anchor: the verifier does not ask whether a key looks plausible, it asks whether the thumbprint matches a key it already trusts. Only after that match does revocation enter the picture.

One key-handling rule deserves emphasis because it is easy to get wrong. Verification bundles must not contain private JWK parameters: d, p, q, dp, dq, qi, and oth. Any trust bundle containing a private key parameter must be rejected immediately.

A bundle that carries private material is not merely unusual; under this profile it is invalid on sight, because a trust bundle should never need to prove itself with a secret.

Taken together, the signature and key rules answer a narrow question: was this exact trace signed by exactly this pinned key, in exactly this encoding? If the answer is anything other than yes, the trace is not verified, whatever the agent claims about it.

How Does a Verifier Check a Delegation Chain?

A verifier checks a delegation chain by verifying every hop's signature, the hash link between consecutive hops, the narrowing of granted scopes, and the narrowing of the time window. When an orchestrator agent delegates authority to a sub-agent, each hop record must include a parent_record_hash field containing the lowercase hexadecimal SHA-256 digest of the canonicalized parent record.

The four checks, as the draft states them, are:

The arithmetic of a chain is simple, and it is worth stating because it shows why verification cost grows with delegation depth. A chain of 3 hops requires 3 signature checks and 2 hash-continuity links, since each hop after the first links back to exactly one parent. A chain of 5 hops requires 5 signature checks and 4 continuity links.

Scope and time are then checked at every hop after the first, so a longer chain is not merely longer; it is more places where a widening scope or a stretched deadline can hide.

Scope attenuation deserves a plain-language example. If an orchestrator holds permission to read and refund orders, it can delegate read-only access to a sub-agent, or the same read-and-refund pair, but it cannot delegate permission to delete orders. The sub-agent's authority can stay the same or shrink; it can never grow.

Temporal monotonicity works the same way: a sub-agent cannot be born before its parent's grant or outlive its parent's expiry.

That pair of rules is what makes cryptographic execution trace verification for AI agents different from merely logging who did what. A log can record a widening scope after the fact. A chain check refuses it before the action is trusted.

What Makes a Verifier Fail Closed Instead of Fail Open?

A verifier fails closed when any check it cannot complete, or any input it cannot interpret exactly, causes rejection rather than acceptance. The draft names two fail-open bypass vectors explicitly, and both come from lenient implementations rather than from attackers breaking cryptography.

The first is accepting boolean literals as integer timestamps, which matters in runtimes where a boolean is a subclass of integer. The second is silently truncating recursive argument walks without flagging depth exhaustion. An implementation that does either has introduced a bypass: a timestamp that is not really a timestamp, or a nested argument it never actually inspected, both treated as passing.

The draft's answer is a must, not a suggestion. Implementations must validate exact integer types for sequence numbers, epochs, and clock-skew bounds, and must fail closed when structural nesting bounds are exceeded. Exactness is the point: a verifier that approximates a timestamp or skips a nested argument has not verified the trace, it has sampled it.

Fail-closed is also the draft's answer to malformed input at every earlier stage, from canonicalization failures to private parameters in a trust bundle. The pattern is consistent: when in doubt, reject, and make the rejection visible. A system that proceeds hopefully past a failed check has no safety property at all, while a system that refuses has a property a team can audit.

Who Should Care About Trace Verification?

Teams running agents against production systems should care, because those are the systems where an unauthorized action is not an embarrassment but a corrupted record. The draft's scope names MCP, A2A, and enterprise system-of-record boundaries, which covers the three places an agent's authority is most often assumed rather than checked: tool calls, agent-to-agent handoffs, and writes to the systems other teams treat as truth.

Developers building agents with coding harnesses meet the same problem at a smaller scale. A guide to how to use Claude Code shows an agent reading a project, editing files, and running commands on a developer's behalf, which is exactly the kind of delegated work a trace is meant to make checkable. The draft does not mention any particular coding harness, and this article does not claim it does; the connection is functional, not a claim about the draft's contents.

For a first evaluation, the honest order of work is: read the draft, check whether your traces are canonicalized before signing, check whether your delegation records carry a parent hash, and check whether your verifier rejects malformed input instead of tolerating it. If any of those answers is no, the draft gives you a concrete checklist, not just a philosophy.

AgentTrust vs AER-1: Verification or Receipt?

AgentTrust vs AER-1 is a question about two different jobs, not two rival products. AgentTrust is a verification profile: it defines how a relying party re-checks a trace, a delegation chain, and a weight-custody manifest before trusting an action. AER-1, as covered on this site, is the execution-receipts lane: it concerns the receipt format that records what happened.

The honest limit must be stated plainly. The AgentTrust draft fetched for this article does not mention AER-1, and no sourced technical comparison between the two exists in the draft itself. Any article claiming a detailed technical winner between them would be inventing a comparison the source does not contain.

The functional framing is what can be said: verification asks whether an action was authorized before commit, while a receipt records the action for later audit.

Read together, the two ideas complement each other. A receipt without verification is a claim. Verification without a receipt leaves nothing to audit afterward.

Teams that need both should treat them as separate layers, not as alternatives to choose between.

How Does AgentTrust Relate to PTCL, Mitra, and TRAIL?

AgentTrust relates to the other agent protocols on this site as a sibling in the same safety family, not as a rival or a replacement. Each one covers a different job, and reading them together gives the fuller picture of how agent actions can be made checkable.

The closest link is to PTCL, the pre-write recovery lease.

PTCL reserves recovery before a write, so that a failed or half-finished plan can be undone deterministically, while AgentTrust verifies the trace of what was authorized, after the fact and before commit. The PTCL article notes that its draft complements this draft, and that the PTCL lease carries a trace anchor reference pointing at a trace anchor defined by AgentTrust. That anchor is the visible bridge between reserving recovery and verifying authorization.

The other two lanes are adjacent rather than overlapping. Mitra protocol is the signed-envelope lane on this site, concerned with carrying a message safely, and TRAIL protocol is the audit lane, concerned with proving afterward what happened. Neither is presented here as a competitor to AgentTrust, because they solve adjacent problems: carrying an action safely, and auditing it afterward, versus verifying before trusting it.

Two companion drafts by the same author are named once here to avoid confusion: draft-durga-pquip-pqc-agentic-delegation-00, on post-quantum hybrid delegation, and draft-durga-wimse-ctx-isolation-00, on context-taint isolation. They are separate drafts with separate jobs, not versions of AgentTrust, and this article does not conflate them.

What Does AgentTrust Not Cover, Yet?

AgentTrust does not yet cover everything its abstract names, and the gaps are worth naming because a seven-day-old draft is easy to overclaim. The draft's abstract names execution traces, delegation chains, and weight-custody manifests as its objects, and its normative detail in the text fetched for this article centers on trace envelopes, signatures, keys, and delegation chains. Readers building against it should verify the weight-custody manifest details in the draft itself rather than assuming this guide has summarized fields the draft leaves elsewhere.

The draft's formal status is equally limited. Its intended status is Informational, which is an aspiration for a published RFC track, not an adoption. The draft states that it has no IANA actions, so no registries or media types are requested, let alone granted.

And the standard Internet-Draft warning applies: drafts are working documents valid for a maximum of six months, and it is inappropriate to cite them other than as work in progress.

No implementations, vendors, or adoption figures are claimed in this article, because none are claimed in the draft text fetched for it. The draft says its invariants are implemented in open-source AgentTrust conformance suites and empirically evaluated in three technical reports, and those claims are reported here as the draft's own statements, not as independent verification. A reader who needs adoption evidence should look for a newer draft revision or independent coverage, and should treat the 2 May 2027 expiry as the date by which -00 either gets replaced or lapses.

Sources

Durga, R. K., "Cryptographic Execution-Trace Verification, JCS Canonicalization, and Fail-Closed Delegation Attestation for Autonomous AI Agents", Internet-Draft draft-durga-agenttrust-trace-verification-00, 29 October 2026, expires 2 May 2027. Fetched 5 November 2026 from the IETF Datatracker HTML edition. (Abstract, JCS rules, signature and key rules, delegation-chain checks, fail-open vectors, no IANA actions.)

Internet-Draft archive text edition, draft-durga-agenttrust-trace-verification-00.txt, IETF archive, 29 October 2026. Fetched 5 November 2026. (Same draft text, used to confirm dates and author affiliation.)

Datatracker history for draft-durga-agenttrust-trace-verification, IETF Datatracker. Fetched 5 November 2026. (Posting history: version -00 uploaded and approved 29 October 2026; author Raghuvar Karthik Durga.)

Rundgren, A., Jordan, B., and Erdtman, S., "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020. (The canonicalization scheme the draft binds, cited by the draft as a normative reference.)

Josefsson, S. and Liusvaara, I., "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017. (The Ed25519 signature scheme the draft binds, cited by the draft as a normative reference.)

Frequently Asked Questions

What is AgentTrust trace verification in one sentence?

It is a proposed deterministic cryptographic profile that lets a relying party verify, before commit, whether an AI agent's action was authorized, by re-checking its signed execution trace, delegation chain, and signing key under identical rules every time.

Is AgentTrust a standard?

No. It is Internet-Draft draft-durga-agenttrust-trace-verification-00, dated 29 October 2026, with intended status Informational, and it expires on 2 May 2027 unless a newer version replaces it. It should be cited only as work in progress.

What is the difference between AgentTrust and a normal agent log?

A normal log is self-reported: the agent writes what it claims it did. An AgentTrust trace is independently verifiable: a verifier re-derives the canonical bytes, checks the signature against a pinned key, and checks the delegation chain, so a tampered or unauthorized entry fails instead of merely looking suspicious.

Can a sub-agent grant itself more permission than its parent?

Not under this profile. Scope attenuation requires each hop's granted scopes to be a subset of, or equal to, its parent's scopes, and temporal monotonicity requires each hop's time window to sit inside its parent's window. A hop that widens scope or stretches its lifetime fails verification.

What happens when verification fails?

The verifier fails closed: the action is not trusted. Malformed canonicalization input, a bad signature, an unpinned key, a broken hash link, a widened scope, or a private parameter in a trust bundle each cause rejection rather than acceptance.