Introducing Verifiable Execution in Dapr 1.18 | CNCF

Skip to content<br>Accessibility<br>help

KubeCon + CloudNativeCon India 2026 · 18-19 June · Mumbai · REGISTER NOW

Posted on June 11, 2026<br>by epower

CNCF projects highlighted in this post

Bringing attestation, provenance, and tamper-evident execution history to workflows and AI agents

For years, the cloud native ecosystem has focused on making distributed systems resilient.

Applications recover from failures. Services retry requests. Workflows survive crashes and resume where they left off. Durable execution has become a foundational building block for long-running business processes and, increasingly, AI agent systems.

But as organizations move AI agents and autonomous workflows into production, a new challenge is emerging:

How do you verify what happened in a tamper-proof way?

When a workflow triggers an activity, invokes a service, delegates work to another workflow, or coordinates multiple AI agents, how can downstream systems determine whether that execution context can be trusted?

How can security teams verify that execution history has not been altered? How can compliance teams establish a chain of custody for critical decisions? How can organizations prove how work was executed, trace where it originated, and verify that its history has remained intact?

Dapr 1.18 introduces a new set of capabilities designed to address these challenges: Workflow History Signing , Workflow History Propagation , and Workflow Attestation .

Together, these capabilities establish a foundation for Verifiable Execution in Dapr.

Why Observability Is Not Enough

Modern cloud native systems already generate enormous amounts of telemetry.

Logs explain what happened.

Metrics show performance.

Traces reveal execution paths.

Audit records provide historical context.

These capabilities are essential, but they all share a common limitation:

They require trust.

A log can be modified.

An audit record can be altered.

Execution context can be lost as requests move between services.

As systems become more distributed and AI agents become more autonomous, organizations increasingly need cryptographic assurances about execution history and provenance.

Observability tells you what happened.

Verifiable Execution helps you prove it.

Introducing Workflow History Signing

The first capability introduced in Dapr 1.18 is Workflow History Signing .

As workflow execution progresses, Dapr can generate cryptographic signatures over workflow history records.

These signatures create tamper-evident execution histories that can later be independently verified.

This allows organizations to detect whether workflow history has been modified after execution and establish stronger integrity guarantees around workflow state transitions.

For organizations operating in regulated environments or handling sensitive business processes, signed workflow history provides a significantly stronger foundation than relying solely on logs or database records.

Introducing workflow history propagation

Distributed systems rarely operate in isolation.

A workflow may invoke activities.

Activities may call services.

Services may trigger additional workflows.

AI agents may invoke tools that ultimately execute across multiple systems.

Understanding how a request arrived at a given component often requires reconstructing information from multiple logs and traces.

Dapr 1.18 introduces Workflow History Propagation , allowing execution lineage to travel with requests as work moves through the system.

This enables downstream services, workflows, and agents to understand:

Where execution originated

Which workflows participated

The sequence of execution events

The provenance of incoming work

Rather than treating execution context as local information, Dapr enables provenance to become a first-class part of distributed execution.

Introducing workflow attestation

History propagation establishes lineage.

Attestation establishes trust.

With Workflow Attestation , Dapr allows workflows and activities to receive cryptographically verifiable execution context.

This enables applications to make decisions based on verified provenance rather than assumptions.

For example:

A bank’s wire transfer system may only accept requests originating from approved payment workflows, preventing direct API calls from bypassing fraud checks, approvals, and compliance reviews.

A healthcare claims processor may validate workflow execution history before issuing reimbursement, ensuring the claim passed eligibility verification, fraud screening, and medical coding review.

A pharmaceutical manufacturing platform may enforce governance policies based on workflow lineage, requiring proof that every quality-control and regulatory signoff step occurred before a batch can be released.

A hospital AI care coordination agent may verify the provenance of delegated work before acting on it, ensuring medication recommendations...