Add privacy-preserving hashes for tool call arguments and results

[AAH20]

Summary

• add gen_ai.tool.call.arguments_hash and gen_ai.tool.call.result_hash to execute-tool spans
• define an algorithm-qualified lowercase hex format without imposing cross-instrumentation canonicalization
• document dictionary-attack risk for small or predictable inputs and require a disable option
• demonstrate capture at the OpenAI Agents function-tool execution boundary

This implements the content-hashing portion of #402 as a focused first change. It deliberately leaves side-effect classification for a separate SIG design discussion because generic instrumentation cannot reliably infer whether an arbitrary tool is read-only, proposed, executed, ambiguous, verified, or compensated.

Why

Raw tool arguments and results are opt-in because they may contain PII or proprietary data. Their hashes let operators verify a known input/output pair after an incident without putting the raw payload in general-purpose trace storage. The attributes hash the exact serialized representation observed at the execution boundary; semantically equivalent values serialized differently are intentionally not comparable.

A concrete implementation of hash-linked effect receipts and explicit ambiguous/verified/compensated outcomes is available as prior art in AAH20/verified-effects-runtime. Those outcome states are not included here pending agreement on a broadly capturable model.

Validation

• make check-policies passes
• Ruff check and format pass
• git diff --check passes
• registry and Markdown generation pass using the pinned Weaver version
• JSON schemas regenerate without changes

The OpenAI Agents conformance scenario is included but could not complete locally: the conformance runner's WeaverLiveCheck child resolved the registry and then exited before its localhost health endpoint became ready. This reproduced twice on different ephemeral ports before scenario execution; CI should determine whether it is specific to this macOS environment.

Closes the content-hashing portion of #402.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on the author · refreshed 2026-09-17 08:01 UTC

Move out of draft to request review.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[socksninja]

I’m testing SABLE from the evidence side: whether a real tool execution can become a compact, independently verifiable Reliability Record without exposing raw tool arguments/results. Your privacy-preserving hash work looks directly adjacent.

Rather than asking you to adopt anything, I’m looking for the next network node who can stress-test this against a real runtime/observability stack. Who is the one person you’d recommend I talk to next — ideally someone working on runtime integrity, telemetry verification, or agent observability?

SABLE: https://github.com/socksninja/sable-agent-reliability