PaperlayerView exact revision on arXiv

Source-linked AI summary

Offline-Verifiable Accountability for Cross-Organization Agent Messaging: A Preserved Evidence-Bundle Approach

Adil Alshammari, Hayretdin Bahsi

arXiv:2608.28542v1cs.CRcs.MA

TL;DR

Cross-organization agent workflows need preserved evidence that remains independently verifiable when live systems are unavailable or not trusted. The paper introduces a policy-controlled offline verifier for workflow-event bundles, finding feasibility within bounded claim semantics while rejecting manipulated or policy-insufficient bundles.

  • Problem

    The paper addresses the absence of a verifier-centered event-level bundle for checking whether preserved evidence satisfies an explicit offline policy.

  • Method

    The paper introduces preserved per-event bundles and a policy-controlled offline verifier that checks sender, log, checkpoint, continuity, delegation, and required receipt evidence.

  • Results

    The evaluation shows feasibility within bounded claim semantics, with stronger profiles adding latency and manipulated or policy-disallowed bundles rejected under intended checks.

  • Takeaways & Limitations

    The framework supports evidence-based audit and dispute review without relying on live services or platform-specific logs.

  • Takeaways & Limitations

    Timings are verifier-side prototype measurements, not universal runtime constants, and the negative-evidence suite is targeted rather than exhaustive.

Abstract

from arXiv · show

Cross-organization agent workflows require preserved evidence that remains independently verifiable during later audit or dispute review. They may involve multiple organizations, delegated actions, policy-relevant events, and disputed accountability claims. This is difficult when live systems are unavailable, controlled by one party, or not trusted by all participants. Existing mechanisms provide useful pieces, including authenticated logging, delegation semantics, signed checkpoints, and consistency checks. What remains missing is a verifier-centered event-level bundle for checking evidence sufficiency offline under an explicit policy. We propose a preserved evidence-bundle model and a policy-controlled offline verifier for agent-to-agent workflow events. Each bundle preserves policy-required evidence, including sender authentication, authenticated log commitment, witness-backed checkpoint evidence, append-only continuity, delegation-aware authorization evidence, and explicit receiver-signed receipt evidence when required. The verifier accepts only claims supported by the selected policy-required evidence, giving a later reviewer an offline basis for assessing evidence sufficiency. It does not infer delivery or receipt from transport behavior or log inclusion alone. In a prototype evaluation over 300 complete workflows and 1200 valid preserved bundles, we measure offline verifier-side latency across policy profiles and workflow-event evidence requirements. Checkpoint-context anchoring has the highest latency in the current prototype, while delegation and workflow-prerequisite evidence require additional verification steps. In targeted negative-evidence tests, all corrupted or policy-insufficient bundles were rejected, with no false acceptance observed. These results support evidence-based audit and dispute review without relying on live services or platform-specific logs.

1. Introduction

Cross-organization agent workflows require preserved, independently checkable evidence for later disputes involving authorship, logging, authorization, receipt, and policy compliance. This paper extends message-level evidence into policy-controlled, offline-verifiable workflow-event accountability.

  • Later disputes may concern authorship, authenticated logging, policy compliance, delegated authority, or explicit receiver-signed receipt evidence.
  • 53% of organizations observed AI agents exceeding intended permissions at least occasionally, while 47% reported a security incident involving AI-agent behavior.
  • The research question asks how message-level evidence can become policy-controlled workflow-event evidence for offline policy-satisfaction decisions.
  • The framework preserves evidence per workflow event and bounds acceptance to claims justified by the selected policy, not delivery, endpoint correctness, semantic correctness, or workflow completion.
  • The evidence-bundle model preserves sender, log, receipt, checkpoint, continuity, and delegation evidence as independently checkable classes.
  • The verifier requires policy-selected evidence predicates before Accept and matches stronger claims to corresponding receipt, checkpoint, continuity, context, or delegation evidence.
  • The prototype evaluates verifier-side latency, event-specific evidence requirements, and targeted negative-evidence diagnostics.

2. Related Work

Related work supplies authenticated logging, consistency, delegation, authorization, and accountability mechanisms, but generally treats these evidence properties separately. The paper positions its contribution as an offline verifier-centered bundle that checks evidence sufficiency for one workflow event under a selected policy.

  • Transparency logging and key-transparency work provide authenticated commitments, signed states, consistency checks, and identity-to-key binding support.
  • Delegation-aware authorization work preserves evidence about authority transfer and policy-governed actions in multi-party settings.
  • Merkle/hash-tree commitments and certificate-transparency-style logging underlie inclusion proofs, signed checkpoints, and consistency proofs.
  • Authenticated storage and transparency systems address scalable storage, monitoring, and infrastructure verification but do not define the proposed policy-controlled workflow-event bundle.
  • Multi-ownership service-chain research supports focusing on verifier-centered artifacts across providers and administrative domains.
  • Table 1 compares studies by evidence bundle, offline verification, signed checkpoint, inclusion proof, witness/consistency, and delegation evidence dimensions.
  • Prior message-level work checked authorship, payload binding, log inclusion, and signatures offline, whereas this paper extends that foundation to policy-controlled workflow-event accountability.
  • The paper identifies a missing verifier-centered preserved workflow-event bundle whose evidence sufficiency can be checked offline under a selected policy profile.

3. System Model, Assumptions, and Threat Model

The system evaluates bounded accountability claims for specific message events from preserved evidence bundles, using local trust inputs and a selected policy profile rather than runtime state. Its threat model focuses on evidence manipulation while excluding compromised trust anchors, signing keys, and unrestricted runtime attacks.

  • Deployment Context and Accountability Scope: Each accountability decision targets a specific message event and its preserved evidence bundle, not generalized application state.The verifier checks bounded claims about authorship, logging, receipt, continuity, and delegation-aware authorization.
  • Trust Assumptions, Adversary Scope, and Claim Boundaries: Transport success is operational information, not accountability evidence, because messages or artifacts may be delayed, replayed, omitted, reordered, modified, or replaced.Reordering is detected only when it causes a policy-required evidence check to fail.
  • Trust Assumptions, Adversary Scope, and Claim Boundaries: The adversary may present incomplete bundles, inconsistent checkpoints, invalid witness evidence, or forged capability and workflow references.The model does not claim protection against compromised signing keys or collusion among all evidence-producing parties.
  • Trust Assumptions, Adversary Scope, and Claim Boundaries: The verifier relies on preserved artifacts, public keys, trust anchors, policy inputs, and permitted offline references without querying runtime services.It does not perform online freshness checks or reconcile live system views.
  • Trust Assumptions, Adversary Scope, and Claim Boundaries: A witness independently observes checkpoint material, checks applicable consistency, and co-signs checkpoints without receiving payloads or issuing receipts.Witness evidence supports checkpoint validity and, when required, append-only continuity validation.
  • Trust Assumptions, Adversary Scope, and Claim Boundaries: Verifier acceptance supports only claims justified by preserved evidence and policy, so it does not establish delivery, endpoint correctness, semantic correctness, or runtime LLM safety.Explicit receiver-signed evidence is required for a receipt claim.

4. System Design and Evidence Lifecycle

The design separates live evidence issuance from later offline review: validated sender-authenticated messages are logged, augmented with policy-required artifacts, and preserved per workflow event. The architecture supports cross-organization workflows while keeping evidence generation and verification independent of live services.

  • Architecture Overview: The architecture uses sender, receiver-side decision, append-only logging, checkpoint-witnessing, and offline-verifier roles.The receiver-side decision point may be an agent, gateway, policy service, or workflow controller.
  • Evidence Lifecycle: Live processing validates a canonical message, commits its digest to an append-only log, obtains authenticated logging artifacts, and preserves the resulting bundle.Logging artifacts include an inclusion proof and signed checkpoint evidence.
  • Running Workflow Example: Events refer_patient, order_mri, send_result, and submit_claim form the running workflow example.The first three share signed-message, validation, logging, and storage steps; submit_claim adds delegation and workflow-prerequisite evidence.
  • Evidence Lifecycle: Issuance applies sender, workflow, policy, and delegation validation before deriving h(m), logging the commitment, and attaching required evidence.Required artifacts must be issued and preserved when receipt, witness, continuity, checkpoint-context, or delegation checks apply.
  • Evidence Lifecycle: The preserved bundle contains sender-authentication and authenticated log-commitment evidence, plus policy-required receipt, witness, checkpoint-context, continuity, or delegation artifacts.The bundle is the main accountability artifact evaluated offline.

5. Offline Verification and Policy-Controlled Evidence

The offline verifier checks preserved bundles against local inputs and a verifier-selected policy profile, accepting only when mandatory and policy-required evidence succeeds. Different checks support distinct claims, and broader claims remain outside the evidence supported by the selected profile.

  • Offline Verification Procedure: The verifier uses local keys, trust anchors, and the selected policy profile rather than transport logs, online responses, or live infrastructure queries.The policy profile is selected on the verifier side, not by the evidence producer during later review.
  • Policy-Controlled Evidence: Accept is returned only when all mandatory and policy-required checks succeed; otherwise the bundle is rejected.Stronger profiles may require receipt, witness, checkpoint-context, continuity, or delegation evidence.
  • Receipt Evidence: Receipt verification proves only the validity of a preserved receiver-signed receipt object when the selected policy requires it.It does not imply human reading, semantic understanding, successful downstream processing, or delivery.
  • Append-Only Continuity: Authenticated log commitment proves inclusion relative to a signed checkpoint, while append-only continuity requires evidence linking two authenticated checkpoints.AOEP verification checks checkpoint signatures, ordering, applicability, and the extension proof.
  • Delegation-Aware Authorization: Delegation-aware authorization evidence checks actor-target consistency, audience progression, scope, temporal validity, message binding, and delegation signatures.It supports authorization-related claims separately from logging, receipt, and workflow-completion claims.
  • Policy-Controlled Evidence: Checkpoint-context anchoring is a policy-controlled check implemented with preserved WCL/checkpoint-context material.The fully enabled profile evaluates distinct controls that strengthen different parts of the preserved evidence chain.

6. Acceptance Semantics and Bounded Claims

Acceptance is defined relative to a selected policy and preserved evidence bundle: every required predicate must succeed, and accepted bundles support only claims whose predicates the policy requires. The verifier therefore does not infer delivery, receipt, execution, or workflow correctness from acceptance alone.

  • Acceptance Conditions: The verifier models bundle format, hash binding, sender authentication, log inclusion, checkpoints, witnesses, context, continuity, capability, and signed receipts as distinct predicates.The full predicate set is selected according to the active policy profile.
  • Acceptance Conditions: Acceptance holds only when every mandatory and policy-required verifier predicate succeeds on the preserved bundle.A weaker policy may accept a bundle that a stronger policy rejects because it requires fewer evidence checks.
  • Evidence Checks: A preserved message commitment binds the canonical message representation to a hash or commitment function, while signed tree heads authenticate checkpoint context and log state.The signed tree head contains an authenticated root, tree size, checkpoint context, and log signature.
  • Bounded Claims: Acceptance and claim support differ: an accepted bundle supports only evidence-level claims whose required predicates are included in the selected policy and succeed.Claims requiring predicates outside the policy do not follow from Accept.
  • Bounded Claims: An authenticated logged-message claim does not imply delivery, receiver acknowledgment, endpoint execution, or workflow completion.Receipt claims require explicit receiver-signed evidence; transport, storage, log inclusion, and checkpoint evidence cannot replace that predicate.
  • Policy Relations: Policy monotonicity holds only when one profile strengthens another by adding predicates under fixed verification semantics and shared trust inputs.The converse can fail when the stronger profile requires additional predicates, and the statement does not cover policies with changed anchors, freshness rules, keys, or contexts.

7. Evidence-Level Security Assessment

The security assessment maps evidence-level threats to the preserved evidence classes and verifier-supported properties they may affect. Its scope is narrower than a deployment-wide runtime threat analysis.

  • Supported Properties: Supported properties cover message binding, authenticated logging, checkpoint reasoning, and delegation-aware authorization.Explicit receipt semantics are handled separately because receipt claims require a preserved, valid receiver-signed receipt object.
  • Checkpoint Properties: Append-only extension, witness-contributed checkpoint evidence, and checkpoint-context anchoring are treated as distinct properties.The distinction separates continuity, witness evidence, and contextual anchoring under the selected policy.
  • Threat Mapping: The assessment maps identity spoofing, log tampering, rebinding, repudiation, tampering or omission, and unauthorized delegation to affected evidence and verifier-supported properties.The mapping is evidence-level rather than deployment-wide.
  • Scope: The assessment identifies which preserved evidence a threat may invalidate, omit, modify, or rebind and supports the targeted negative-evidence cases evaluated later.It does not provide a full runtime threat inventory or runtime-security analysis.

8. Evaluation

The evaluation measures offline verifier-side latency and diagnostic rejection behavior across policy controls and workflow-event evidence requirements. It finds that checkpoint-context anchoring is the largest latency contributor, submit_claim is slower because it requires additional evidence, and all targeted invalid bundles were rejected.

  • Evaluation Design: The evaluation separates verifier-side latency attribution, workflow-event evidence requirements, and diagnostic rejection behavior rather than measuring general throughput.It excludes memory utilization, network delay, delivery, runtime LLM safety, end-to-end orchestration, and workflow throughput.
  • Evaluation Design: The corpus contains 300 complete four-event workflows and 1200 valid preserved evidence bundles.Each case uses signed agent-to-agent events with identifiers, timestamps, commitments, authenticated logging artifacts, and policy-required evidence references.
  • Policy-Level Latency: E1 accepted all 300 valid submit_claim bundles under every tested profile, with median latency ranging from 183.04 ms under NO_EPOCH to 785.52 ms under ALL_ON.The ALL_ON profile is the within-experiment baseline for the single-control comparison.
  • Policy-Level Latency: Disabling checkpoint-context anchoring produced the largest E1 median reduction: 76.7% relative to ALL_ON.The comparison exposes a latency–assurance trade-off because each disabled control removes a specific assurance component.
  • Workflow-Event Evidence Requirements: The first three event types had nearly identical median latencies—399.98 ms for refer_patient, 400.37 ms for order_mri, and 401.13 ms for send_result—whereas submit_claim reached 680.21 ms.Submit_claim also had a higher P95 of 712.70 ms versus 429.83–434.84 ms for the other events, with a significant event-type effect.
  • Workflow-Event Evidence Requirements: Submit_claim adds prior-event and delegation/workflow-prerequisite checks beyond the core evidence path, identifying where additional verifier-side latency is introduced.The event comparison is interpreted as an evidence-requirement analysis, not a throughput benchmark.
  • Negative-Evidence Diagnostics: Across 17 targeted diagnostic cases, every manipulated or policy-disallowed bundle was rejected, with no false acceptance observed.The first-failing check provided a structured signal for why each bundle was insufficient under the selected policy.

9. Discussion

The discussion interprets offline verification as a policy-relative evidence-sufficiency decision, with latency varying by required evidence and workflow event. It also bounds the results to prototype measurements, a fixed workflow, targeted diagnostics, and available preserved bundles.

  • Interpretation of Results: Accept supports only evidence-level claims justified by the preserved evidence required under the selected policy profile.Sender signatures support authorship, log evidence supports authenticated commitment, receiver-signed receipts support receipt claims, and capability evidence supports delegation-aware authorization.
  • Interpretation of Results: Checkpoint-context anchoring contributes most to verifier-side latency in the current prototype.The additional work involves parsing, matching, resolving references, and validating WCL/checkpoint-context material against the evidence bundle.
  • Interpretation of Results: submit_claim requires more verification time because it adds prior-event dependency checking and delegation/workflow evidence, while three other events follow a similar core evidence path.refer_patient, order_mri, and send_result remain close to core logged-message verification under the implemented policy.
  • Interpretation of Results: Rejected bundles provide a structured reason identifying the first failed verifier check, supporting audit and dispute resolution.Examples include failed Merkle inclusion, witness support, or workflow-prerequisite checks.
  • Interpretation of Results: Stronger verifier profiles introduce additional verifier-side latency, so profile selection should match the dispute’s evidence requirements.Lighter profiles may suffice for authorship and log-commitment disputes, whereas stronger profiles address receipt, delegation, continuity, context, or workflow prerequisites.
  • Limitations and Threats to Validity: The evaluation is bounded by prototype measurements, a fixed four-step workflow, targeted negative-evidence mutations, and the availability of preserved bundles.It does not establish universal runtime constants, coverage for all workflows, exhaustive adversarial robustness, or support for claims when no bundle exists.

10. Conclusion and Future Work

The paper introduces a preserved evidence-bundle framework and policy-controlled offline verifier for workflow-event accountability across organizations. The evaluation supports feasibility within bounded claim semantics, while future work targets larger deployments, longer workflows, optimization, and reduced disclosure.

  • Conclusion: The framework extends message-level authorship and log-inclusion evidence into policy-controlled workflow-event accountability.Accept supports only claims justified by preserved evidence required under the selected policy.
  • Conclusion: Stronger verifier profiles add latency, submit_claim takes longer because of delegation and workflow-prerequisite evidence, and manipulated or policy-insufficient bundles are rejected.These findings support feasibility within the framework’s bounded claim semantics.
  • Future Work: Future work will evaluate larger multi-host deployments, optimize checkpoint-context and WCL validation, study longer workflows and multi-hop delegation, and investigate reduced-disclosure evidence views.The planned evaluations address concurrency, longer histories, branching dependencies, and cross-organizational delegation.
Loading 2608.28542v1…