PaperlayerView exact revision on arXiv

Source-linked AI summary

Poster: Towards ProofWeave: A Privacy-Minimised, Integrity-Anchored Evidence Plane for Continuous Agentic Assurance

Guy Lupo, Nguyen Hung Nguyen, Viet Vo, Chamikara M. A. P., Guangdong Bai

arXiv:2609.35234v1cs.CR

TL;DR

Agentic systems’ actions cannot be reliably attributed from final responses alone, and existing mechanisms rarely bind evidence to the policy in force when an action was attempted. ProofWeave binds agent, control, and policy evidence at record time and anchors accepted records in an append-only ledger. It reduces candidate bindings and estimated evidence storage while enabling continuous control testing.

  • Problem

    Final responses alone cannot distinguish whether a risky action was never attempted, blocked, or executed, while existing mechanisms rarely bind control evidence to the policy in force at the time.

    Source: §1 · p. 1

  • Method

    ProofWeave binds agent intent and run context, control action and decision, and the policy snapshot into a privacy-minimised record anchored in an append-only ledger.

    Source: §2 · p. 2, §1 · p. 2

  • Results

    Up to 10,201 candidate bindings per verdict fall to one, validation operations from up to 10,201 to approximately 26, and evidence storage from 0.79 to 0.15 MiB per project.

    Source: §3.3 · p. 3

  • Takeaways & Limitations

    ProofWeave shifts forensic queries from retrospective reconstruction to evidence admission, supporting continuous control testing.

    Source: §1 · p. 2

    The prototype evaluates only the API path and does not prove that every submitted statement is true or every event was reported.

    Source: §3.3 · p. 3

Abstract

from arXiv · show

Agentic AI systems increasingly act via tools, memory, delegation, and external services. Existing observability and provenance mechanisms can reconstruct events post hoc, but they rarely show, at the time of the record, whether each policy-relevant action was checked by the intended control before execution. This leaves a trust-observability gap for continuous monitoring, detection, and response: later assurance may rest on evidence that is incomplete, privacy-leaking, mutable, or detached from the policy context that governed the event. What's missing in the literature is contemporaneous, policy-bound evidence that the intended control was evaluated under the policy in force at the time. We introduce ProofWeave, a record-time chain-of-evidence concept for agentic AI assurance. At each policy-relevant action boundary, ProofWeave generates a privacy-minimised and integrity-anchored evidence transaction that binds (i) agent intent or action, (ii) control response, and (iii) a policy-at-time snapshot. Each transaction is committed to an append-only ledger and materialised into a derived proof graph. A bounded Weaver Agent translates policy intent into proof obligations, while deterministic validators check evidence completeness, privacy minimisation, policy binding, and integrity. In the minimal scenario, an agent attempts to transmit a secret to an unapproved external sink. The audit compares a logs-only correlation baseline with ProofWeave across verdict latency, join ambiguity, privacy exposure, tamper detection, and resistance to graph-only proof injection. ProofWeave reduces candidate bindings per verdict from up to `10,201` to one, validation operations from up to `10,201` to approximately `26`, and assurance evidence storage from `0.79`\~MiB to `0.15`\~MiB per project.

1 Motivation and Practical Demands

Agentic actions make final outputs insufficient for attributing whether a risky action was attempted, blocked, or executed. ProofWeave addresses the resulting evidence-plane gaps with policy-bound, integrity-protected evidence for continuous assurance.

1 Motivation and Practical Demands

  • Final responses cannot distinguish a risky action never attempted from one blocked by runtime control or executed with little visible trace.This is the enforcement attribution problem.Source: §1 · p. 1
  • Trust observability requires linking attempted action, control decision, and policy in force while preserving source identity, privacy, and integrity.Post-hoc joins also depend on identifiers, event ordering, retained context, and confidence in the reconstructed graph.Source: §1 · pp. 1–2
  • Logs, provenance systems, agent-native representations, and graph reasoning address parts of the problem, but typically do not combine the required evidence-plane properties.The missing combination includes policy-at-time binding, attributable agent and control evidence, privacy minimisation before persistence, and an external integrity root.Source: §1 · p. 2
  • Up to 10,201 candidate bindings per verdict fall to one, validation operations from up to 10,201 to approximately 26, and evidence storage from 0.79 to 0.15 MiB per project.ProofWeave replaces post-hoc candidate matching with indexed proof-path validation.Source: §1 · p. 2

2 ProofWeave: One Evidence Chain

ProofWeave binds agent intent and run context, the control decision, and the policy snapshot into one evidence record. Accepted records are privacy-minimised and ledger-anchored, then used to build a provenance-linked graph and support assurance queries.

2 ProofWeave: One Evidence Chain

  • One evidence record binds agent intent and run context, the control action and decision, and the policy snapshot in force at decision time.This lets a reviewer determine what was attempted, what the control did, and which policy governed the outcome.Source: §2 · p. 2

2.1 Record-Time Binding

  • The binding API writes the three record identifiers into a signed record while preserving each producer; shared episode identifiers and related metadata connect records across a run.Before append, it checks required identifiers, policy reference, payload hash, signature, and sequence, and removes or protects unnecessary fields.Source: §2.1 · p. 2

2.2 Ledger, Graph, and Queries

  • Accepted records enter an append-only ledger, from which the Graph Weaver builds a source-linked graph; lineage, policy replay, and detector-health APIs return pass, fail, or indeterminate.Model-suggested graph links remain marked as inferred and are validated before insertion; incomplete or interrupted evidence yields indeterminate.Source: §2.2 · p. 2

3 Case Study: RepoAudit Through ProofWeave

The case study integrates RepoAudit with ProofWeave so each run can be checked against its recorded evidence and policy context. It describes run-health checks, prototype fault cases, and estimated assurance costs.

3 Case Study: RepoAudit Through ProofWeave

  • RepoAudit is an LLM-based repository code auditor; ProofWeave records how each run was carried out without changing its audit method.RepoAudit selects audit starting points, follows inter-procedural paths, stores intermediate facts, runs validators, and emits findings [1].Source: §3 · p. 2

3.1 RepoAudit Evidence Flow

  • During adoption, RepoAudit can retain its file output while sending records to the ProofWeave API; each run becomes an episode linked to repository, commit, policy, model, prompt template, and control definition.The history supports checks for missing validators, incomplete runs, provider errors, stale evidence, and unexpected changes between runs.Source: §3.1 · p. 3

3.2 Checking RepoAudit Run Health

  • The Detector Health API passes a run only when all required conditions hold; policy conflicts, rejected findings, missing validators, or blocked configurations fail, while missing evidence or interruption yields indeterminate.Comparable runs are also checked against policy limit τ_P, with larger changes flagged for review rather than treated as proof RepoAudit is wrong.Source: §3.2 · p. 3

3.3 Prototype Checks, Limits, and Cost

  • Prototype checks cover complete and incomplete runs, provider failure, graph-only finding insertion, changed or replayed ledger records, and unexplained differences between comparable runs.Expected outcomes include pass, fail, indeterminate, rejected graph insertion, integrity failure, and a cross-run change flag.Source: §3.3 · p. 3
  • The cost analysis assumes 101 action records, 101 control records, one policy snapshot, and matched query size k=6; its values are analytical estimates.For matched query size k, indexed queries cost O(k) excluding index lookup; hashchain append averages O(1), while graph updates cost O(v_r + e_r).Source: §3.3 · p. 3
  • The prototype evaluates only the API path and does not prove submitted statements are true or every event was reported; a separately protected collector could provide stronger coverage.The ledger records which authenticated producer submitted each record and whether it was later modified.Source: §3.3 · p. 3
  • Up to 10,201 candidate bindings per verdict become one record-time-bound path, with approximately 26 lookup and integrity-checking steps; estimated storage falls from 0.79 to 0.15 MiB per project.The comparison is illustrative and concerns one RepoAudit project.Source: §3.3 · p. 3, Table 2 · p. 3
Loading 2609.35234v1…