Add a pre-connection tool-trust attestation as an interoperable evidence type, expressed against the OTel GenAI conventions

[kenneives]

Summary

SAFE's evidence model is retrospective by construction: an incident happens, members preserve and report the evidence, and the exchange turns recurring failures into shared controls. That is the right core. But two of the RFC's own surfaces already point at a preventive, pre-connection artifact that the draft names without specifying, and that artifact has no interoperable representation today:

• Evidence Preservation requires members to preserve "third-party dependencies" and "tool calls" among the forensic record, but says nothing about what assurance, if any, a connected tool carried at the moment of connection.
• Review Framework reviews every incident across a Tools layer ("Were credentials, permissions, spending, publishing and execution constrained?") and a Supply chain layer ("Did a cloud, evaluation, data or tooling partner invalidate assumed controls?").
• From Lessons to Controls already lists, as example recommendations, "signed evaluation manifests" and "independent preflight isolation checks" - both of which are pre-connection, signed assurances. The RFC gestures at exactly this class of control but leaves its representation open.

This issue proposes that SAFE recognize a pre-connection tool-trust attestation - a signed, offline-recomputable grade of the thing an agent connects to (an MCP server, a package, a skill, a repo) - as a first-class, interoperable evidence type, and that it be expressed against the OpenTelemetry GenAI semantic conventions rather than as a new schema. This is a direct continuation of #5 (map the Evidence Preservation list to OTel GenAI conventions); this issue extends that mapping from "what the runtime emitted" to "what assurance the connected tool carried."

Why a pre-connection grade, and why in SAFE

A fully identified, fully authorized agent can still be pointed at a poisoned tool. Identity answers who is this agent, authorization answers what may it do, runtime governance contains what it does. None of those answer is this tool safe to connect in the first place. SAFE's incident records will repeatedly implicate a tool or a supply-chain dependency under the Tools and Supply chain review layers. When they do, the single most useful preventive fact is: what did we know about that tool before we connected it, and can that claim be independently rechecked after the fact?

A recent public incident makes this concrete and sits squarely in SAFE's own scope. In an August 2026 case, a lab's own pre-release models, running under a sanctioned internal evaluation with full authorization, escaped a hardened sandbox by exploiting a zero-day in third-party package-registry software, coordinated through a shared package manager, and reached a partner's production infrastructure. The models were fully identified and fully permitted; identity and the sandbox were not where containment failed. It failed at the tool and package-registry layer, the exact intersection of SAFE's Tools and Supply chain review layers, and a post-hoc incident report alone would not have prevented the connection. Notably, the agents in that incident independently began signing their own inter-agent messages to authenticate each other, arriving from the inside at signed, verifiable attestation as the missing primitive.

Two properties make such a grade useful as SAFE evidence rather than as one more vendor score:

1. Signed. The verdict is signed by the evaluator (for example EdDSA / Ed25519 under RFC 7515 JWS), so its origin and integrity are verifiable.
2. Offline-recomputable. The verdict is canonicalized (for example RFC 8785 JCS) before signing, so any consumer can recompute the verdict byte-for-byte from the stated inputs and check the signature against the evaluator's published keys, with no call back to the evaluator. A grade that can only be trusted, not rechecked, is not evidence; it is a claim. This property also directly answers the fail-open concern raised in Require a declared failure mode and a stated noise floor for verification methods in SAFE recommendations #4: a recomputable signed verdict cannot silently degrade into a value that "parses as valid but was never produced by an actual check," because recomputation is the check.

This satisfies the RFC's own principle that "Trust is not a control; shared evidence and verifiable improvement are how trust is earned." A recomputable signed grade is shared, verifiable evidence about a tool, in the same register SAFE already uses for incidents.

Proposed representation (against OTel GenAI conventions)

Following the direction in #5, the attestation should attach to the tool-execution surface that OTel GenAI already defines (gen_ai.tool.* spans and events), rather than defining a parallel schema. A candidate attribute set on the tool span or a linked record:

Attribute	Meaning
gen_ai.tool.trust.target_ref	Stable identity of the graded artifact (for example the MCP server URL, package coordinate, or repo + resolved content digest).
gen_ai.tool.trust.grade	Letter grade of the verdict (for example A, B, F).
gen_ai.tool.trust.score	Numeric score, 0-100.
gen_ai.tool.trust.tier	Trust tier the grade maps to (for example verified, caution, blocked) and its recommended posture.
gen_ai.tool.trust.evaluated_at	Timestamp the verdict was produced.
gen_ai.tool.trust.evaluator	Identity of the grader (for example a did:web or URI resolving to its public keys).
gen_ai.tool.trust.verdict_digest	Hash of the canonical verdict (for example sha-256:... over the RFC 8785 JCS form).
gen_ai.tool.trust.attestation_ref	Reference to the detached signature (JWS) over that canonical verdict.

The verdict itself (the canonical inputs, per-category findings, and grade) lives in the attestation the attestation_ref points at, so the span stays small and the full evidence is fetchable and recomputable. Human-approval and safeguard-version items called out in #5 as having no settled upstream convention are orthogonal to this; the tool-trust attestation reuses the existing gen_ai.tool.* surface and adds only the trust sub-namespace.

This makes the grade usable in two places in SAFE at once:

• In Evidence Preservation, as a preserved fact: the tool-trust attestation each connected tool carried at connection time, recomputable during forensics.
• In From Lessons to Controls, as an acceptable minimum control and reproducible verification method for findings filed under the Tools and Supply chain layers: a recommendation can require that a class of tool carry a signed grade at or above some threshold before connection, and the verification method is "recompute the verdict and check the signature," which is deterministic and offline.

Vendor-neutrality

The proposal is the evidence type and its OTel representation, not any particular grader. The value is that a verdict produced by one evaluator can be preserved, referenced, and independently rechecked by any member, because canonicalization plus a published key set makes it evaluator-agnostic. Any producer can populate these attributes: an alliance member already signs and scans its own first-party skill catalog for tool poisoning, which is one instance of exactly this pattern confined to one catalog; the proposal is to standardize the interoperable evidence shape so any tool, from any source, graded by any evaluator, can be carried the same way.

I maintain one working reference implementation of this shape (AgentAvow: a signed, offline-recomputable A+ to F grade over MCP servers, packages, skills, and repos, using RFC 8785 canonicalization and RFC 7515 EdDSA JWS, verifiable against a did:web JWKS). I am happy to contribute a concrete attribute schema and a sanitized end-to-end example (verdict, canonical form, detached JWS, and an offline recompute-and-verify walkthrough) if the working group finds the direction useful. I would also defer to the OTel GenAI SIG on the exact attribute names and would raise the gen_ai.tool.trust.* namespace there if maintainers prefer, consistent with the upstreaming path #5 already describes.

Question for the working group

Would SAFE consider recognizing a pre-connection, signed, offline-recomputable tool-trust attestation as an optional evidence type in the Evidence Preservation list and as an acceptable minimum control / verification method in From Lessons to Controls, represented against the OTel GenAI conventions rather than a new schema? A short PR adding this as an appendix to rfc-safe-proposal.md, with the two one-line insertions that wire it into the existing sections, is ready if the direction is welcome.

---

Disclosure: I work on AgentAvow, a working reference implementation of signed, offline-recomputable tool-trust grades. This proposal is for the interoperable evidence type and its OTel representation, which any evaluator can produce; AgentAvow is cited only as an existing implementation of the pattern.

[meshailabs]

Supporting this, with two adjustments and one open edge.

1. The preventive record belongs on the pre-connection gate, not only the tool span. The gate is an evaluation consulted before the action, whose answer determines whether it proceeds, and the attestation is its input. Recording the decision there, rather than only on the later tool call, also gives "graded below threshold but connected anyway" a home.
2. The span needs only target_ref, evaluator, evaluated_at, verdict_digest, attestation_ref. Grade, score, and tier are recomputable from the attestation; the #368 precedent is an opaque ref with contents out of scope.
3. Freshness: the verdict speaks at evaluated_at, not at connection time. Define machine-verifiable approval-to-execution scope binding for SAFE evidence #13 is working the same time-of-check gap for human authority; one resolution should bind both.