An Evidence Model for Agentic Processes: Evidence Claims, Trust Assumptions, and Policy Assessment

• Draft v0.9.0.6 is dated 8 September 2026.Source: Arslan Brömme CISSP, CISM, CISA, CAISE · p. 1
• The paper identifies itself as a preprint and working paper.Source: Arslan Brömme CISSP, CISM, CISA, CAISE · p. 1
• The version may be updated, and comments are welcome.Source: Arslan Brömme CISSP, CISM, CISA, CAISE · p. 1

1 Introduction

• Agentic processes involve agents exchanging instructions, invoking tools, changing artifacts, seeking approvals, and deliberating before actions.After an incident or review, organizations may need to reconstruct not only stored records but also which claims those records legitimately support.Source: §1 · p. 1
• The paper extends an earlier capture-to-verification architecture with evidentiary semantics, rather than treating that prior architecture as independent validation [1].The extension includes claims about capture completeness, decision sessions, audits, risk treatment, mitigation implementation, and management response.Source: §1 · p. 1
• The motivating question is which evidentiary claims an agentic black box can support, not whether its records are simply valid or invalid.Records can be integrity-verifiable yet semantically false, signed yet policy-violating, or externally anchored while omitting a suppressed event.Source: §1 · p. 1
• The paper decomposes agentic evidence into explicit claims, mapping mechanisms to supported properties, trust assumptions, and limitations.Its contributions also include an agent-organization model separating operational execution, evidence production, audit assessment, and management response.Source: §1 · p. 1
• This conceptual position and architecture paper offers no empirical performance, security, or compliance evaluation.A simplified governance example illustrates the model and its limits.Source: §1 · p. 1

2 Related Work

• Timestamping, secure audit logs, canonicalization, transparency logs, remote attestation, and threshold signatures provide background mechanisms for different assurance claims.The paper cites timestamping, secure audit logging, canonicalization, transparency logs, remote attestation, and threshold signatures.Source: §2 · p. 2
• No listed mechanism by itself establishes semantic truth, capture completeness, or organizational compliance.Threshold-signature value also depends on key generation, participant independence, threshold assumptions, and operational governance.Source: §2 · p. 2
• Indirect prompt injection is part of the threat context, while EU AI Act and NIS2 obligations apply only within specified scopes and conditions [9].NIS2 addresses governance, cybersecurity risk measures, and reporting for entities in scope, but does not establish a general evidentiary model for AI agents.Source: §2 · p. 2

3 System and Governance Model

• Operational workflows, evidence, and audit are assigned to distinct functional roles under operational and security, risk, or governance executives.Audit may be an internal agent function or separate assurance function; an illustrative CEO agent receives reports, while binding legal authority and final risk acceptance remain with humans or the responsible legal entity.Source: §3 · p. 2
• Operational agents execute tasks and update artifacts, while decision sessions record participants, policy context, arguments, dissent, uncertainty, and outcomes.The logger captures event streams; the historian classifies selected events as relevant and signs relevance claims, but is not a truth oracle.Source: §3 · p. 2
• The evidence supervisor checks capture policies and expected events; the controller canonicalizes records, checks signatures and metadata, computes hashes or Merkle roots, and approves anchoring.An anchoring service publishes commitments to an external evidence layer; its wallet is a governed technical component, not an independent decision authority.Source: §3 · p. 2
• Audit agents assess records against policies and workflow rules, while CEO and executive agents prepare management responses and propose improvements.They may accept or reject risks only within delegated authority; binding legal authority remains with the responsible human officer or entity.Source: §3 · pp. 2–3
• Evidence production and audit assessment should remain distinguishable from operational execution, even when exact reporting lines vary.Where formal agent-executive roles are impractical, separation can be approximated through independent maintainers, separate keys, external auditors, read-only observers, or isolated evidence components.Source: §3 · pp. 2–3

4 Threat Model

• The threat model distinguishes internal, external, and evidence-infrastructure threats.These groups cover deployed agents and users, malicious inputs, and attacks against evidence components.Source: §4 · p. 3

4.1 Internal Threats

• Operational self-reporting is useful but cannot guarantee completeness because the agent being evaluated may also report its own actions.Internal threats include policy violations, event suppression, logging bypass, and unauthorized tool calls, whether intentional or caused by system or oversight failures.Source: §4.1 · p. 3

4.2 External Threats

• External threats include prompt injections and manipulated inputs that can influence agents to ignore policy, misuse tools, or rely on corrupted context.Reconstruction may require showing which external content and embedded instructions were accessed, which agent processed them, and which checks and actions followed.Source: §4.2 · p. 3

4.3 Threats Against Evidence Infrastructure

• Evidence infrastructure can be attacked through logging bypass, misclassification, compromised keys, delayed anchoring, or selective anchoring of benign records.Audit-agent findings also require scrutiny because the evaluator can be misconfigured, compromised, or manipulated through its inputs.Source: §4.3 · p. 3
• The model requires controls but cannot establish that no off-system event occurred; capture completeness is assessed only against an expectation model.Mandatory-event coverage compares expected events with validated observations, but its usefulness depends on the independence and quality of the expectation model.Source: §4.3 · p. 3

5 Evidence Claim Model

• An evidence claim states what a retained record, artifact, process step, or audit result can support.Its strength depends on the mechanism and assumptions behind the claim.Source: §5 · pp. 3–4
• The model describes a claim through an event, property, mechanism, assumptions, limitation, and threat scope.Events can include messages, approvals, tool calls, decision sessions, audit findings, risk treatments, mitigation records, or management decisions.Source: §5 · p. 4
• A canonicalized approval record, SHA-512 digest, and external anchor support record integrity and existence by anchor time, but not legal validity or complete discussion history.The model presents this claim structure as conceptual, not a full formal semantics for composing or resolving claims.Source: §5 · p. 4
• The central design question is which property a mechanism supports, under which assumptions, and against which threat.A verifiable record can still be semantically false or incomplete.Source: §5 · p. 4

6 Evidence Capture and Policy Assessment

• A capture policy should define mandatory, risk-based, and historian-nominated evidence so selection is not arbitrary.Mandatory capture includes approvals, privileged tool calls, policy exceptions, important artifact changes, audit findings, and risk and mitigation records.Source: §6 · p. 4
• A minimal event record binds an identifier and type to an actor, policy version, asserted time, prior-record reference, artifact hash, classifications, and signatures.The common envelope can support different record types through extensions; interoperability does not require one universal schema.Source: §6 · p. 4
• Historian classifications should be separately recorded with the event, applied policy or heuristic, rationale, time, and historian identity.Sampling, monitoring, or batch commitments can make selective suppression of low-relevance classifications harder to hide.Source: §6 · p. 4
• Immediate anchoring offers stronger temporal granularity but raises cost and metadata exposure, while Merkle batching reduces cost and leakage but weakens immediacy.Broader capture and added signatures or review steps also raise privacy, retention, deletion, and operational concerns requiring deployment-specific analysis.Source: §6 · p. 4
• An audit-agent output is a signed policy-assessment claim over selected records, not compliance itself.The finding should bind the checked record set, input commitments, policy version, audit-agent configuration, and output commitment.Source: §6 · pp. 4–5

7 Decision Sessions and the Management Cycle

• Decision sessions can record participants, inputs, policy context, arguments, dissent, confidence, required approvals, and outcomes for high-impact or policy-sensitive actions.Specialized agents may assess plans, risks, security, and compliance, while a human approver can accept, reject, or escalate recommendations.Source: §7 · p. 5
• A decision session documents an internal process but does not itself create organizational authority; that remains with the responsible human role, function, or legal entity.Its evidentiary value is preserving the discussion, warnings, and rationale available when approval or escalation occurred.Source: §7 · p. 5
• Audit findings can lead to risk-treatment records naming the risk, affected policy, proposed mitigation, owner, due date, residual risk, and management decision.Mitigation implementation is also recorded, including changed policies or workflows, affected agents or tools, and required follow-up verification.Source: §7 · pp. 5–6
• The plan–do–check–act-inspired loop connects policies and execution to audit assessment, management decisions, mitigation implementation, follow-up verification, and policy improvement.Decision-session records primarily support Do; audit, risk-treatment, mitigation, and verification records support Check and Act.Source: §7 · p. 6

8 Example: Agent Organization and Decision Session

• Agents preserve proposed actions, external input, policy version, risks, prompt-injection warnings, approval requirements, dissent, and recommendations in a decision record.The evidence supervisor checks mandatory capture rules, and the audit-agent later evaluates whether approval preceded execution and the mitigation workflow was followed.Source: §8 · p. 6
• Approval event ae-0042 uses a signed approval record, sequence reference, and anchored hash to evidence a recorded approval, not actual authorization, wisdom, or legal sufficiency.The claim assumes a valid approver key, active capture path, and available role record and policy version.Source: §8 · p. 6
• Mitigation-031 uses an owner-signed implementation record, but does not by itself establish mitigation effectiveness or residual-risk reduction.The claim assumes valid owner binding, captured implementation evidence, and correctly linked affected agents and tools.Source: §8 · p. 6
• The CEO agent prepares a management response and tracks mitigation implementation through later audit verification, with human review or ratification when legal authority or formal risk acceptance is required.Committed records can show that findings, risks, mitigations, and responses existed, but cannot establish that no unobserved communication occurred or that the organization was legally compliant.Source: §8 · p. 6

9 Limitations and Future Work

• The model cannot guarantee truthful agent behavior, complete capture, correct policy interpretation, legal compliance, effective mitigations, or adequate management decisions.Uncaptured events cannot be recovered by hashing; capture components, historian classifications, and signing keys can also be compromised or wrong.Source: §9 · p. 6
• A compromised or misconfigured audit-agent could produce a signed, anchored finding that misrepresents underlying evidence when its assessment shares infrastructure with the evidence it evaluates.Proposed controls include a distinct trust domain, separately governed keys, immutable policy versions, recorded assessment commitments and configuration, independent capture, and periodic human sampling.Source: §9 · pp. 6–7
• Evidentiary strength depends on governance choices, and capture completeness can be assessed only against defined expectations and independent signals, not every unobserved communication or side channel.Blockchain is one possible externalization mechanism; timestamping services, transparency logs, or permissioned ledgers may fit other threat models and regulatory environments.Source: §9 · p. 7
• Future work should formalize claim composition and confidence, interoperable schemas, canonicalization and Merkle strategies, adversarial capture testing, remote attestation, and independent review of audit findings.It should also study privacy-preserving external verification of selected evidence.Source: §9 · p. 7
• Realistic multi-agent deployments should test mandatory-event expectations, the coverage indicator C, and reconstruction of adversarial workflows, missing approvals, and privileged tool misuse.The stated objective is usability under realistic communication, execution, and governance conditions, not product benchmarking.Source: §9 · p. 7

10 Conclusion

• The model separates claims about integrity, temporal existence, provenance, approval, ordering, capture, relevance, deliberation, monitoring, anchoring authorization, policy assessment, risk treatment, mitigation implementation, and management response.It maps evidentiary claims to mechanisms, assumptions, limitations, and threats.Source: §10 · p. 7
• Semantic validity remains a recurring limitation; signing or anchoring records alone does not establish it.Source: §10 · p. 7
• A well-designed agentic black box should make evidentiary meaning explicit and support a management cycle from capture and audit findings through treatment, implementation, verification, and policy improvement.Source: §10 · p. 7