build(deps): bump agentrust-trace from 0.9.0 to 0.10.0 in /integrations/ramen-ai-cmcp

[dependabot]

Bumps agentrust-trace from 0.9.0 to 0.10.0.

Changelog

Sourced from agentrust-trace's changelog.

[0.10.0] - 2026-09-05

Security

• cnf.jwk no longer accepts private key material (GHSA-vc4p-h84j-7qxj). RFC 8747 defines cnf as a confirmation key: the public half, carried so a verifier can bind the record to the key that signed it. models.TrustRecord already refused d, p, q, dp, dq, qi and k via _JWK_PRIVATE_PARAMS, with the comment "cnf.jwk is a public proof-of-possession key". The verification path validates against the schema rather than the model, and the schema's jwk block constrained only the kty/crv/x/y shapes, so everything else fell through additionalProperties. A Trust Record carrying its own private key validated and sign.verify_record() accepted it. The rule existed, and only in the half verification does not call.

  No attacker step is involved, and that is not a mitigation. A Trust Record is signed, self-authenticating and typically anchored, so once such a record is out the key is out and the only remedy is to revoke the identity. sign.sign_record() could never produce one, because it builds cnf from key_to_jwk(), which returns the public half only; the exposure is a record assembled by hand or by another implementation, which is the population a published schema exists to constrain.

  Both schema copies carry the constraint and a test holds them byte-identical. agentrust-io/trace-tests carried a third copy with the same gap and its conformance suite passed such a record, since TR-ENV-004 checks only that kty is present; that repo adds TR-ENV-005 for it.

  Breaking for producers emitting a private cnf.jwk: those records were always invalid per the reference model and are now rejected by the schema too.

Added

• verify_record() consumes the section 3.2.3 revocation bundle and reports what it checked (#190, closes #246). The bundle format merged with #187 and nothing read it. verify_record() now takes revocation_bundle, trusted_bundle_keys, max_bundle_age_seconds and now, and returns a VerificationResult whose revocation field carries one of section 3.2.3's three states as a value: verified, unverified_for_revocation, or no_check_performed, with the cause and the evidence a second verifier needs. Previously the function returned None and a caller could not tell a verified key from one nobody checked, which is #246. Two bounds govern bundle age, the issuer's valid_until and the caller's maximum measured from issued_at, and the tighter governs; an expired outcome names which bound tripped. examples/revocation-bundle/ carries 25 conformance vectors, generated, covering both bounds with margin and every non-verified state. No appraisal.status value is named; where an unresolvable check is recorded in the record stays open on #190. Callers that ignored the old None return are unaffected; a caller asserting is None on the return will see a change.

• Section 3.3.4: disclosed gaps in a receipt chain (#117). Under a profile requiring action receipts, a specification that offers only "complete" and "broken" rewards concealment: an operator who backfills a lost receipt scores better than one who reports the loss. A GapDisclosure is a signed chain element stating that receipts which would have occupied its position were never emitted. Coverage is structural rather than asserted: the disclosure links back to the element before the gap, the next element emitted links back to the disclosure, and verification is two link checks a verifier already performs on every ordinary element. No range fields exist, because a hash chain cannot express a range and an emitter cannot know its successor's hash at write time.

  The action-receipt outcome receipt_missing_required is narrowed to silent absence, and receipt_gap_disclosed is added beside it, distinct by requirement, with acceptance a verifier policy input. It never satisfies a profile requiring independently proven completeness: a disclosed gap does not establish that the missing receipts existed, how many were lost, or that omission was not selective. A disclosure at the live tail, where no successor exists to seal it, is unverified rather than disclosed or invalid: a chain truncated immediately after a disclosure is indistinguishable from an honest tail, so whatever the tail is granted, truncation is granted too. Conformance vectors in examples/action-receipts/gap-disclosure/, two per rule with a byte-for-byte generator; the tail case is pinned by its own test. Proposed and authored from production operation of a per-action receipt emitter; carried per the maintainer-carry provision in CONTRIBUTING.

  Two cross-references that predate the renumbering which introduced section 3.3.1 are updated to name section 3.3.2, where the text they cite now lives.

• examples/delegation-link/ closes the canonicalization gap spec section 3.1.3 names. That section states the corpus was entirely ASCII, so it could not discriminate an implementation that canonicalizes the parent-record digest by RFC 8785 (UTF-16 code-unit key order) from one that takes the code-point shortcut sort_keys=True takes in several JSON libraries, since the two agree everywhere except where an object key holds a supplementary-plane character. 24-parent-key-supplementary-plane.json is that vector: the root's cnf.jwk carries an additional member keyed outside the Basic Multilingual Plane (permitted by schema/trace-claim.json's additionalProperties on cnf.jwk, covered by the chain digest per section 3.1.3), and the leaf's parent_record_hash is reachable only under the correct ordering. A code-point canonicalizer computes a different digest for the same root and reports parent_not_found on a chain that is otherwise vector 01's. docs/rfcs/a2a-delegation-profile.md and the corpus's own README are updated to 24 vectors; the profile's ten rules and their margins are unchanged, since this vector tests the shared digest primitive rather than any one rule.

Fixed

• docs/trust-levels.md now states that runtime.measurement under software-only is a documented software commitment, not a hardware measurement forced to all-zero. runtime.measurement is required on every record. Under software-only (no hardware root of trust), the field carries a software commitment whose preimage the producing profile MUST document, so a verifier can recompute it for example, sha256(image_digest + "\n" + bundle_hash) (TraceSandboxAdapter.software_measurement) or SHA-256 of the Merkle chain tip (TraceAGTAdapter), both already documented in docs/integration/sandbox-runtime.md and docs/integration/agt.md. All-zero (sha256:000...000) is reserved for a producer with no commitment to offer at all, such as a bare development record with nothing measured; it is not the default for software-only in general. The earlier draft of this fix would have declared both released reference adapters non-conformant, since they emit non-zero measurements under software-only by design. The schema (schema/trace-claim.json, src/agentrust_trace/schema/trace-v0.2.json) is unchanged: once the rule reads this way there is nothing left for the schema description to narrow. spec/trace-v0.2.md doesn't mention this convention and is unaffected. Resolves #240.

• runtime.platform's description now reads its two situations as examples rather than as the whole set. #234 aligned the schema description with spec 3.1.1, whose lead clause is "no hardware root of trust" and whose enumeration names a development-mode execution and a record assembled from evidence produced outside the runtime. A production runtime emitting for its own executions, origin.kind: self, with no TEE anywhere in its stack, is covered by the lead clause and named by neither example, so the enumeration read as exhaustive and narrowed the rule again in a smaller way. "For example" restores the reading without adding a case or diverging from docs/schema.md. Both schema copies carry it. Raised by @​chernistry on #232 and on #234.

... (truncated)

Commits

• 3a561d8 release: trace-spec 0.10.0 (#298)
• 8aebaa0 docs: make first TRACE record reproducible and clarify verification (#295)
• 4383b14 test(provenance): reject digest under wrong algorithm label (#278)
• a8b7620 docs(trust-levels): all-zero measurement means no commitment, not software-on...
• 891427b fix(schema): refuse private key material in cnf.jwk (#296)
• a6c3c3d test(delegation): add supplementary-plane parent-key vector (closes gap named...
• 1042273 docs: run the checks CI runs, and what a green one does not prove (#293)
• a1ea835 fix(security): pin 14 action refs to SHAs and add a token permissions floor (...
• fc38496 spec: state what delegation.parent_record_hash is a digest of (#245) (#276)
• 5c69dc1 docs: say the rule about understanding what you submit (#273)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)