From Agent Activity to Verifiable Evidence

Abstract

Autonomous systems produce activity records, traces, state changes and assertions across multiple computational boundaries.

Transforming those records into trustworthy conclusions requires more than event aggregation or anomaly detection.

An independent assurance system must determine what each evidence source actually establishes, evaluate the relationships between observations and distinguish verified facts from assertions, inference and unresolved uncertainty.

The Agentic Provenance Protocol (APP) is being developed around a source-aware evidence model that separates observations, provenance relationships, evaluation criteria and assurance conclusions.

This paper outlines that model, introduces the role of probabilistic inference and describes the requirements for producing defensible Evidence Receipts.

1. The evidence problem

Consider a multi-agent payment workflow.

An authorization service records an approved transaction limit. An agent runtime reports a delegated action. A merchant records a completed checkout. A payment service confirms a financial transaction.

An operational monitoring system may display all four records as one sequence.

However, an independent assurance system must ask a different set of questions.

Were the events produced by their claimed sources?

Can their integrity be verified?

Do they refer to the same transaction?

Was the originating authorization still valid when execution occurred?

Was delegation permitted?

Do the observed outcomes satisfy the applicable authorization constraints?

What conclusions remain unsupported?

These questions cannot be answered simply by accumulating more telemetry.

They require a structured model of evidence and verification.

2. Evidence is not equivalent to truth

APP's proposed evidence model separates three concepts.

Observation: Data obtained from a defined boundary using a known collection method.

Assertion: A claim made by an actor or system, potentially supported by authentication or cryptographic evidence.

Inference: A conclusion derived by evaluating observations, assertions and their relationships.

These categories must not be silently collapsed.

For example, an authenticated webhook may establish that a particular payment provider issued a specified message.

It does not necessarily establish that the provider's underlying business state is correct, that the payment has reached final settlement, or that every earlier action complied with customer authorization.

Similarly, a valid digital signature establishes integrity and signer attribution relative to a trusted key. It does not, by itself, validate every semantic claim in the signed payload.

Independent assurance must preserve these distinctions.

3. A multidimensional verification model

A single Boolean field such as verified: true is insufficient for complex provenance evaluation.

Evidence can be verified in one respect while remaining uncertain in another.

APP's intended evidence model therefore distinguishes separate verification dimensions.

These may include:

• Source authentication.
• Payload integrity.
• Actor identity.
• Authorization validity.
• Temporal validity.
• Event correlation.
• Causal relationship.
• Constraint consistency.
• Outcome confirmation.

For each dimension, a verification state can be assigned.

The APP evidence vocabulary includes:

These states are not interchangeable with a universal risk score.

A conflict in authorization compliance is qualitatively different from an unavailable correlation event.

Likewise, an inferred causal relationship must not be reported as cryptographically verified.

4. Evidence-conditioned conclusions

APP's proposed evaluation logic can be expressed conceptually as:

C = Evaluate(I, O, R, P)

Where:

• I = applicable intent and authorization assertions.
• O = collected observations.
• R = established or inferred relationships.
• P = evaluation policies and evidence conditions.
• C = resulting assurance conclusion.

Each conclusion must retain references to the evidence and evaluation rules that produced it.

Critically, evaluation should be conditioned on evidence sufficiency.

If the required observations are missing, the system should produce an unresolved conclusion rather than treating the absence of evidence as proof of compliance.

Likewise, an anomaly score should not automatically be converted into a confirmed authorization violation.

5. Behavioural envelopes and runtime divergence

An important research direction for APP is comparing expected agent behaviour against actual observed behaviour.

A behavioural envelope describes a set of permitted or expected activities under a particular authorization, agent role or operating context.

Let:

B_A = ExpectedBehaviour(A, Context, Policy)

represent the expected behavioural envelope of agent A.

Let:

B_A,t = ObservedBehaviour(A, t)

represent the agent's observed behaviour over an evaluation window.

A divergence function can then be defined conceptually as:

D_t = Divergence(B_A,t, B_A)

Depending on the underlying data, candidate methods may include:

• Jensen–Shannon or Kullback–Leibler divergence for suitable probability distributions.
• Wasserstein distance for comparing distributions over structured event features.
• Mahalanobis distance for multivariate deviation under appropriate statistical assumptions.
• Learned anomaly scores for sequential or contextual behavioural patterns.

No one metric is universally suitable. Selection depends on the representation, distributional assumptions and quality of training or reference data.

Behavioural divergence can help prioritize investigation or identify unexpected execution patterns.

It cannot, by itself, prove a policy violation or malicious intent.

A strong anomaly signal may correspond to authorized novel behaviour, instrumentation drift or benign environmental changes.

APP should therefore separate behavioural inference from deterministic policy and authorization evaluation.

6. Establishing causal relationships

Cross-system provenance is fundamentally a relationship-evaluation problem.

An event occurring after another event does not necessarily result from it.

A shared trace identifier may establish a correlation convention, but does not inherently provide independent proof of causation.

APP's proposed evidence graph should record the basis of each relationship.

Examples include:

Observed relationship: An instrumented boundary directly records a tool invocation and its corresponding response.

Cryptographically supported relationship: An authenticated message explicitly references a predecessor event or authorization artifact, subject to verified binding rules.

Corroborated relationship: Independent sources agree on relevant transaction attributes and state transitions.

Inferred relationship: An association is proposed using probabilistic matching or temporal evidence, without sufficient direct proof.

The evaluator should preserve the provenance and confidence of each relationship independently of the associated event.

7. Evidence Receipts as inspectable assurance artifacts

APP is designed to produce an Evidence Receipt that summarizes an evaluated activity without concealing its evidentiary limitations.

A conceptual receipt might contain:

{
  "receipt_id": "app_demo_receipt_001",
  "schema_version": "illustrative-0.1",
  "evaluation_scope": {
    "workflow_id": "demo_workflow_42",
    "boundaries_observed": [
      "agent_gateway",
      "merchant_checkout",
      "payment_provider"
    ]
  },
  "authorization": {
    "reference": "intent_demo_001",
    "maximum_amount": 500,
    "currency": "USD",
    "verification_state": "VERIFIED"
  },
  "observed_outcome": {
    "amount": 540,
    "currency": "USD",
    "verification_state": "VERIFIED"
  },
  "relationships": {
    "intent_to_payment": "VERIFIED"
  },
  "evaluation": {
    "constraint": "amount <= 500",
    "result": "CONFLICTED",
    "reason": "OBSERVED_AMOUNT_EXCEEDS_LIMIT"
  },
  "evidence_references": [
    "ev_intent_001",
    "ev_payment_002"
  ],
  "limitations": [
    "No claim regarding unobserved agent reasoning"
  ]
}

Illustrative synthetic data, not a production-generated APP receipt or finalized protocol specification.

This example assumes the authorization, payment amount and their relationship have been independently established to the level required by the evaluation policy.

If the intent-to-payment relationship were unresolved, the amount discrepancy alone would not justify declaring a verified violation of that specific intent.

In production, receipt design must also account for integrity protection, source timestamps, policy versioning, sensitive-data redaction and the ability to reproduce or independently inspect evaluation results.

8. Falsifiability and independent verification

An assurance claim has greater technical value when another party can test the conditions under which it succeeds or fails.

APP's verification model should therefore be evaluated against controlled scenarios including:

1. Valid authorization with consistent execution.
2. Valid authorization with a confirmed constraint violation.
3. Expired or revoked authority.
4. Unauthorized or unproven delegation.
5. Missing observation boundaries.
6. Conflicting assertions from independent sources.
7. Replayed, tampered or stale evidence.
8. Malformed or incomplete evidence relationships.

Each scenario should define the expected conclusion and the evidence required to support it.

A credible assurance system should demonstrate not only the ability to identify violations but also the ability to abstain when the available evidence does not justify a conclusion.

The distinction is fundamental.

False certainty can be more dangerous than explicitly unresolved evidence, particularly when agentic systems control payments, sensitive information or operational infrastructure.

9. Toward evidence interoperability

Agent execution environments, payment networks, merchant systems and infrastructure providers will continue to produce different forms of evidence.

A cross-ecosystem assurance architecture must preserve those differences while enabling consistent evaluation.

Interoperability does not require every provider to adopt a single internal event model.

It requires a sufficiently precise exchange representation for evidence origin, integrity, relationships, evaluation methods and conclusions.

APP's proposed contribution is an independent framework for that exchange and evaluation.

This does not replace protocol-specific authentication, issuer controls, runtime safety mechanisms or regulatory obligations.

Instead, it aims to make observable claims about agentic activity independently inspectable across participating systems.

Conclusion

Autonomous execution creates a growing gap between the authority granted to a system and the evidence available to establish what that system actually did.

Bridging that gap requires more than identity, authorization tokens or traditional monitoring.

It requires explicit evidence provenance, relationship verification, uncertainty-aware evaluation and reproducible assurance conclusions.

The Agentic Provenance Protocol is being developed to transform distributed agent activity into independently evaluable evidence, without confusing observation, assertion, inference and proof.

Trust in autonomous systems should not depend on accepting an actor's account of its own behaviour.

It should depend on what the available evidence can defensibly establish.

---

INEVRI | Independent provenance infrastructure for the agentic economy

The technical examples and evaluation models in this publication are conceptual and non-normative. Statistical methods described are research directions, not claims of validated production detection performance.