Independent Provenance Across Agentic Trust Boundaries

Abstract

Autonomous AI systems increasingly operate across organizational, computational and commercial boundaries.

A single workflow may involve multiple agent runtimes, tool servers, external APIs, payment processors, digital wallets and delegated execution environments.

Although individual platforms can authenticate participants and record events occurring within their own infrastructure, reconstructing the complete execution chain across independent systems presents a distinct technical challenge.

The Agentic Provenance Protocol (APP) is being developed to provide an independent evidence layer capable of observing, correlating and evaluating agentic activity across heterogeneous trust boundaries.

This paper outlines a proposed architecture for that capability, including observation interfaces, evidence provenance, causal relationships, trust evaluation and independently inspectable evidence receipts.

1. The limits of local observability

Modern distributed systems provide mature observability primitives, including structured logs, distributed traces, metrics and event streams.

These mechanisms are essential to operational diagnostics.

However, operational observability and independent provenance assurance are not equivalent.

A distributed trace can help reconstruct the execution path of a request. Its identifiers and spans do not inherently prove the identity, authorization, integrity or causal correctness of every participating system.

Consider an agentic workflow:

Customer → Agent A → Agent B → Tool Server → Merchant → Payment Provider

Each participant may maintain different representations of the transaction.

Agent A may record an instruction and a delegated task. Agent B may record a tool invocation. A merchant may record a completed checkout. A payment processor may record an authorized payment.

The existence of these records does not necessarily establish their relationship or prove that each action was consistent with the originating authorization.

A trustworthy provenance architecture must evaluate those relationships explicitly.

2. Trust boundaries as first-class objects

APP treats observation boundaries as foundational architectural components.

An observation boundary is a defined interface at which evidence of an activity, assertion or state transition can be obtained under known trust and collection conditions.

Examples include:

• API gateways and reverse proxies.
• Model Context Protocol (MCP) gateways and tool invocation interfaces.
• Agent runtime instrumentation.
• Service mesh and inter-service communication boundaries.
• Signed event streams and webhook endpoints.
• Merchant checkout and payment integrations.
• Controlled execution environments and security policy enforcement points.

Boundaries differ in what they can legitimately establish.

An API gateway may observe a request and response but not the internal reasoning of an agent.

A payment webhook may provide an authenticated statement of payment status but not establish that the originating customer approved every delegated decision.

An agent runtime may report its own execution path, while still requiring independent validation of the source and integrity of its telemetry.

APP must preserve these differences rather than treating all observations as equivalent.

3. Boundary-first integration

APP's intended integration strategy supports two complementary approaches.

Outside-In Observation

Evidence is obtained at existing infrastructure boundaries, minimizing changes to agent application code.

Potential integration points include gateways, service meshes, webhooks, signed transaction events and OpenTelemetry pipelines.

Inside-Out Instrumentation

An application or agent runtime supplies additional structured evidence through instrumentation or an SDK.

This can provide richer execution context, subject to the trustworthiness of the instrumented runtime and evidence source.

The architecture prioritizes non-invasive observation where practical.

Crucially, the ability to observe an event does not imply authority to enforce policy or block execution. Observation, evaluation and enforcement must remain separately defined capabilities.

4. A proposed normalized evidence representation

To evaluate heterogeneous events, APP requires a normalized evidence model while retaining the underlying source-specific records.

A conceptual evidence object can be represented as:

{
  "evidence_id": "ev_example_001",
  "observation_boundary": "merchant_checkout",
  "origin": {
    "system": "synthetic_merchant",
    "asserted_actor": "agent_b",
    "origin_class": "asserted_agent"
  },
  "activity": {
    "type": "checkout.created",
    "correlation_id": "workflow_example_42"
  },
  "time": {
    "observed_at": "2026-10-14T09:00:00Z",
    "source_timestamp": "2026-10-14T08:59:59Z"
  },
  "integrity": {
    "signature_status": "unavailable",
    "digest": null
  },
  "verification": {
    "state": "asserted",
    "method": "authenticated_source_transport"
  }
}

Illustrative schema only. Not a published normative APP schema or production API contract.

An evidence object should preserve:

• The original evidence source.
• The observation boundary and collection method.
• Asserted actor and principal identities.
• Activity type and relevant attributes.
• Event time and collection time.
• Integrity and authentication properties.
• Correlation and causal relationship claims.
• Verification status and outstanding uncertainties.

Normalizing data must not elevate unverified source assertions into independently verified facts.

5. Reconstructing the provenance graph

APP's proposed evidence model represents execution as a graph:

G = (V, E)

Here, V contains evidence objects, actors, authorization assertions and observed state transitions.

E represents relationships such as:

• AUTHORIZED_BY
• DELEGATED_TO
• INVOKED
• OBSERVED_AT
• CORRELATED_WITH
• RESULTED_IN
• CONTRADICTS

These are conceptual relationship types rather than finalized protocol identifiers.

Importantly, edges must also carry provenance.

A relationship inferred from temporal proximity or matching transaction metadata is not equivalent to one established through a valid cryptographic statement.

For example, two events sharing a correlation identifier may support a candidate association. They do not automatically establish a causal relationship.

APP must distinguish observed, cryptographically supported, independently corroborated and probabilistically inferred relationships.

6. Cross-boundary consistency evaluation

Suppose a customer authorizes an agent to purchase an item from an approved merchant for a maximum value of $500.

The originating agent delegates checkout execution.

Subsequent observations include:

• An authenticated authorization assertion setting the $500 constraint.
• A delegation event referring to the originating workflow.
• A merchant checkout event for $540.
• A payment-provider confirmation for $540.

If the evidence is sufficiently authenticated, correctly correlated and complete for the relevant evaluation, APP should be able to identify a conflict between the authorized amount and the observed transaction.

Conversely, if the merchant event cannot be reliably linked to the original workflow, the system should not automatically conclude that a violation occurred.

It should report the relationship as unresolved or insufficiently supported.

The objective is evidence-based consistency evaluation, not speculative reconstruction presented as fact.

7. Independence as an architectural property

Independent provenance requires more than hosting monitoring software outside the agent's infrastructure.

The evaluator must retain meaningful separation between:

1. The actor generating an action.
2. The system reporting the action.
3. The evidence collector.
4. The party evaluating the resulting claims.

Where these functions overlap, the trust implications must be explicit.

A self-reported agent event may still be useful evidence. Its provenance and confidence must reflect that it is self-reported.

Similarly, independently hosted evaluation cannot compensate for missing, falsified or inaccessible underlying evidence.

APP's independent assurance proposition therefore depends on transparent provenance, inspectable evaluation criteria and defensible limits on conclusions.

8. Security and privacy requirements

Cross-boundary assurance introduces its own security obligations.

The evidence infrastructure must not become an uncontrolled aggregation point for sensitive instructions, credentials, customer records or payment data.

The architecture should implement:

• Data minimization and selective collection.
• Credential and payment-secret redaction.
• Explicit tenant and organizational isolation.
• Authenticated evidence ingestion.
• Replay protection and integrity verification where supported.
• Least-privilege access to observation interfaces.
• Configurable retention and deletion policies.
• Tamper-evident evidence storage.
• Auditable evaluation and administrative actions.

No raw payment credential, secret-bearing request or private customer instruction should be included in a publicly shareable receipt merely to support provenance claims.

9. Evidence Receipts

An Evidence Receipt is a proposed machine-readable summary of an evaluated execution chain.

A receipt should identify the evaluation scope, evidence references, relevant authorization constraints, observed relationships, verification methods, findings and unresolved dependencies.

It should never claim to establish the completeness of an execution chain beyond the scope of the available observations.

A receipt is also not inherently proof that every contributing event is true. Its assurance value depends on the strength, independence and verifiability of the underlying evidence.

10. Toward interoperable assurance

Agentic infrastructure is unlikely to converge on one execution environment, identity provider or payment network.

A practical provenance layer must therefore accommodate multiple interfaces and trust models.

APP's proposed integration strategy prioritizes widely adopted technologies and emerging agent interfaces, including MCP, agent-to-agent protocols, OpenAPI, OpenTelemetry and relevant payment-event systems.

These interfaces provide potential observation and correlation points. They do not automatically guarantee sufficient provenance or authorization information.

The longer-term architectural objective is an independently evaluable representation of agentic activity that remains useful as agents move between runtime, infrastructure and commercial providers.

Conclusion

The future of agentic systems depends on more than authenticated agents and successful API calls.

It requires a defensible method for understanding which authority supported an action, what was observed across intervening systems, and how the resulting state relates to the originating instruction.

The Agentic Provenance Protocol is being developed to make these relationships independently observable, correlatable and evaluable across heterogeneous trust boundaries.

The value of such a system must ultimately be demonstrated through reproducible, cross-boundary verification rather than architectural claims alone.

---

INEVRI | Independent provenance infrastructure for the agentic economy

This paper presents a proposed architecture. Illustrative schemas and relationship types are non-normative. No third-party integration, certification or production deployment is implied.