[Theme] Trust and identity requirements for agentic AI in regulated workflows — evidence, verifier obligations, and cross-jurisdiction interoperability (medical-device compliance as anchor use case)

Theme Name

Trust and identity requirements for agentic AI in regulated workflows — evidence, verifier obligations, and cross-jurisdiction interoperability.

Proposer(s)

• Xinghua Zhao (Steven Zhao) — independent expert; ORCID 0009-0001-0512-1237

Grounding context: the requirements below are drawn from medical-device regulatory
compliance work (NMPA / FDA / EU MDR / JP PMDA) that is carried out by an AI agent team
in production, rather than from a hypothetical scenario. Medical-device compliance is
used here as an anchor case because it combines a regulated regime, an irreversible
downstream action, and a cross-jurisdiction dimension. It is offered as one possible
anchor, in line with the health use case identified in the Terms of Reference.

Summary

We propose a theme on the consumption side of agentic-AI trust: what evidence an
agent must present, what a relying party is obliged to check, and what "verification
passed" must mean when a downstream action is consequential. The material is drawn from
operation in a regulated domain, so the requirements below are stated as observed needs
rather than as design preferences.

The proposal maps onto several deliverables already listed in Annex A of the Terms of
Reference — in particular A.2.7 (trust control plane reference architecture),
A.2.5 (cross-jurisdiction interoperability requirements, which explicitly includes
healthcare), and A.1.1 (agentic-AI identity stack) — and is raised in support of
those, not in addition to them.

Scope / Open Questions

• What is the minimal verifiable-evidence bar for trust claims in FG-TIDA
  deliverables — transparency-log entries, cryptographic timestamping, reproducible
  archives?
• How do verifier-side obligations get expressed, and what should "PASS" mean: that
  a check ran and found no violation within a stated evidence boundary, or something
  stronger?
• Where does the boundary of an attestation's verdict get recorded, so a relying
  party can tell "checked and passed" from "did not check"?
• Should cross-jurisdiction interoperability requirements (A.2.5) be expressed so
  that a verdict obtained under one regime can be re-used, understood, or refused under
  another?
• Should deployability under regulatory constraint be an evaluation dimension when
  comparing trust architectures?

Related Work

• uibc-core — an evidence-package reference implementation: DOI
  10.5281/zenodo.22821834, with a Sigstore
  Rekor transparency-log entry (logIndex 2883389783) and a Software Heritage SWHID
  (swh:1:ori:819530c8…). These anchors are publicly resolvable, so a third party can
  re-derive the verdict without contacting the author.
• silent-failure-catalog — documented failure semantics of "verification passed"
  states, where a check reports success while checking nothing.
• Related standards ecosystems: IETF RATS (attestation consumption), W3C DID/VC,
  Sigstore/Rekor, NIST AI RMF, and the EU MDR / AI Act conformity regimes.

Related Themes

• Contributes to #7 — verifier-side requirements and failure semantics for agent
  evidence: we offer the verifier-obligation perspective plus reference assets.
• Bridges to #22 — Remote Attestation for Agentic AI (RA-AAI): we address the
  consumer side of attestation, with a publicly resolvable transparency-log entry.
• Maps to the Terms of Reference Annex A deliverables A.2.7, A.2.5 and
  A.1.1, and to the health anchor use case in A.3.1.

Discussion

We would be glad to contribute material toward A.2.7 and A.2.5, and to share the
evidence-package construction and the production requirements we have observed with the
group. This issue is raised to put a regulated-domain case on the table for the
deliverables discussion leading up to the Paris meeting, and we welcome co-development
or an alternative framing if the group prefers one.