cs.CRSep 19, 2026
SaveWhen Agentic Trust Crosses Organizational Boundaries: Structural Externalization and a Reference Model for Trust Evidence
Organizations: China Mobile Jiutian Artificial Intelligence Technology (Beijing) Co., Ltd.
Abstract
Agentic systems increasingly invoke tools, services, data, and other agents across organizational boundaries, yet a relying party cannot assess a delegated action solely from producing-domain controls and records. This paper develops Trustworthiness as a Service (TaaS) through a synthesis of trustworthy-AI governance, agent security, distributed trust management, identity, provenance, assurance, and control-plane research. The analytical unit is a cross-domain reliance proposition that names the issuer, subject and action, relying party, administrative boundary, evidence dependencies, adverse condition, and required verification or adjudication semantics. The three-condition structural-externalization diagnostic identifies propositions that depend on multiple domains, require producer-independent reliance, and must remain reviewable after revocation, failure, conflicting records, or dispute. For such propositions, the paper specifies a trust-evidence envelope: an immutable workflow manifest linked to append-only, issuer-attributed attestations for task-scoped authority, policy and execution decisions, provenance, validity, disclosure, status, challenge, and recovery. A topology-neutral logical reference model assigns these functions to explicit roles and trust domains. Three analytical scenarios and the TaaS-Eval protocol proposal define manifests, independent consumers, hard gates, adversarial evidence tests, metrics, and reproducible artifact reporting. By composing established identity, authorization, provenance, assurance, and governance mechanisms around a bounded delegated action, TaaS provides a reusable profile for cross-domain reliance. It makes evidence dependencies, independent verification, challenge, and recovery explicit, supporting interoperable governance and future evaluation without treating producer assertions as ground truth.
Figures & tables
Fig. 1: For a proposition that satisfies the structural-externalization diagnostic, the trust-evidence envelope carries action-specific evidence across the administrative trust boundary for verification under the relying domain’s accepted roots and policy.
| Case | Target proposition and boundary | Adverse condition | Classification and required semantics |
|---|---|---|---|
| Cross-organization tool invocation | A provider decides whether an enterprise agent was authorized to invoke the provider’s resource for the stated task at that time. The boundary is the delegating enterprise / tool provider boundary. | Revoked delegation or replayed request | Positive. Bind issuer, audience, task authority, resource, decision time, and request identifier; expose status, revocation, and challenge semantics. |
| Internal allow/deny decision | An enterprise uses its own policy decision point and enforcement point to decide whether an action was permitted by internal policy. No administrative trust boundary is crossed. | Policy update or runtime outage | Negative. Local policy version, decision, and logging semantics suffice for the stated proposition; a later external-certification proposition would be separate. |
| Selective provenance disclosure | An external auditor assesses whether a disclosed trace faithfully represents the execution relevant to the audit purpose. The boundary is the system operator / auditor boundary. | Selective omission, conflicting record, or producer compromise | Borderline. Classification depends on audit purpose and accepted assurance; define disclosure scope, lineage, status, challenge, and any independent corroboration. |
| Post-incident recovery proof | A counterparty assesses whether compromised authority was revoked, affected actions were isolated, and agreed recovery postconditions were met. The boundary is the affected operator / counterparty boundary, with a named adjudication forum. | Conflicting logs, unavailable status, or continuing dispute | Positive. Preserve timed revocation and recovery events, causal links, opposing evidence, verification status, and adjudication semantics. |
TABLE I: Representative applications of the structural-externalization diagnostic. Each classification is specific to the stated proposition, boundary, and adverse condition; it does not attach to the capability label.
Fig. 2: The trust-control lifecycle separates runtime evidence consumers from three review-triggered feedback paths; arrows denote explicit control, evidence, review, or feedback relations, not capability sufficiency.
| Envelope component | Required fields | Issuer/owner | Verification rule | Failure or challenge semantics |
|---|---|---|---|---|
| Common attestation fields: stable attestation_id ; explicit manifest_id and manifest_version reference; schema/type/version; issuer and verification method; subject, audience, and action/resource; delegated authority and policy basis; decision or asserted event; evidence references and causal parent; issue/effective/expiry times; disclosure profile; status/revocation endpoint; challenge/remedy path. | ||||
| Manifest | Stable manifest_id and manifest_version ; schema/version; issuer and verification method; integrity reference; workflow; participants and administrative trust domains; subject; audience; relying party and reliance purpose; action/resource; creation time; causal predecessor; disclosure profile; endpoint directory | Workflow initiator or coordinating domain; ownership conveys no authority over later issuers | Verify issuer, method, integrity reference, and immutable identifier/version; match domains, audience, relying party, reliance purpose, action/resource, and predecessor | Unsupported version or unresolved parent causes rejection or quarantine; correction requires a new linked manifest version |
| Authority attestation | Common fields; delegation and credential references; action/resource scope and constraints | Delegator, credential authority, or other recognized authority | Validate issuer and delegation chain, manifest reference, audience, scope, time, constraints, and status under the accepted authority policy | Missing, stale, revoked, or out-of-scope authority causes denial or uncertainty; status and challenge records target its attestation ID |
| Policy/decision attestation | Common fields; policy authority, identifier, and version; request identifier; decision vocabulary and reason | Policy decision point operating for the named policy authority | Match request and decision; verify issuer, manifest reference, applicable policy version, evidence links, event time, and decision vocabulary | Policy mismatch or unavailable basis causes rejection or escalation; a counter-decision names the target attestation ID |
| Execution/provenance attestation | Common fields; event identifier/type; authorization and policy-decision references; outcome; ordering information; capture scope | Enforcement point, agent runtime, resource provider, tool, or independent observer | Check attribution, manifest reference, decision-to-event linkage, ordering, causal consistency, replay state, evidence integrity, and declared capture scope | Missing, replayed, contradictory, or unverifiable events are marked as gaps; counter-records target event and attestation IDs |
| Assurance/status attestation | Common fields; target manifest version, attestation, credential, event, or evidence identifier; status scope; assessed object/control; method, period, result, assumptions, and limits | Qualified assessor, status authority, or accepted assurance service | Verify target identifiers, issuer qualification, assessment scope and method, sampled evidence, time window, expiry, and historical status | Stale assurance, scope mismatch, revocation, or endpoint outage produces uncertainty rather than an inferred pass; unresolved cases escalate |
TABLE II: Proposed trust-evidence envelope schema for a bounded agentic action and a named cross-domain reliance context.
Fig. 3: Topology-neutral logical reference model: panel (a) separates required operational roles from optional oversight roles; panel (b) preserves manifest-referenced, issuer-attributed records through verification and response.
Fig. 4: Proposed TaaS-Eval sequence in which a harness injects adversarial conditions before or during execution and capture. Captured envelopes then pass through validation, independent consumption, hard gates, and artifact reporting.
| Gate/checkpoint | Observable evidence | Oracle or validator and metrics | Failure rule |
|---|---|---|---|
| Task/threat manifest | Versioned scenario, boundary, SUT, task classes, policy, threat schedule, required envelope profile, repetition policy, and artifact plan. | Schema and version check; configuration digest; oracle fixed before runs; required-field coverage. | Undeclared oracle, policy, threat, or required record invalidates the task; no score is assigned. |
| G1: identity and authority | Subject credential, delegation chain, audience, action and resource scope, validity interval, status endpoint, and authority attestation. | Harness delegation matrix and external or harness-owned status timeline; correctly bound claims / required authority claims. | G1 fails if missing, revoked, audience-mismatched, or out-of-scope authority is accepted. |
| G2: runtime decision | Policy-versioned decision, request ID, enforcement and execution attestations, and instrumented resource effect for allow, deny, quarantine, degrade, or escalate outcomes. | Harness reference-policy cases, expected-action matrix, and deliberate version mismatch; , , , task utility, and operational cost. | G2 fails if no decision is linked to enforcement, policy substitution is accepted, or an oracle-invalid action proceeds. |
| G3: independent consumption | Permitted disclosure view, event and attestation IDs, causal parents, capture scope, consumer trust roots, policy, schemas, evidence access, and terminal reliance disposition. | Harness event graph, omission record, valid/invalid matrix, and expected disposition independent of producer output; , , , causal accuracy, and . | G3 fails if the consumer needs private SUT state, infers completeness from missing links, or returns a non-oracle disposition. |
| G4: status, disclosure, and failure handling | Target IDs, external status history, event time, observation horizon , outage schedule, disclosure allowlist, tampered or conflicting evidence, counter-records, challenge records, and recovery attestations. | External or harness-owned status timeline and expected-disposition matrix; , non-rejection count, , disclosure-minimization error, and recovery correctness. | G4 fails if revoked, stale, leaking, unavailable, or conflicting evidence is silently accepted, or if an unresolved conflict is reported as resolved. |
TABLE III: TaaS-Eval hard gates, observable evidence, oracles, metrics, and failure rules.
More in this topic
Trust in AI
Trust in artificial intelligence concerns when people and institutions should rely on AI, and how systems can make that reliance warranted and safe.
See all 175 papers