Verifiable execution

Durable execution guarantees that a workflow survives failure and resumes exactly where it stopped. Verifiable execution guarantees something different: that the recorded history of what ran cannot be altered without detection. Catalyst cryptographically signs every event in a workflow's history as it is written, turning the append-only history log into a tamper-evident chain that anyone can independently verify. The result is a provable record of which steps executed, in what order, and with what inputs and outputs. This capability builds on Dapr's workflow history signing, the open-source runtime underneath Catalyst, and on the SPIFFE identity every workload already carries.

Why it matters

A workflow's history is normally trusted because it lives in a database you control. But database rows can be modified, reordered, or deleted after the fact, and an audit that depends on them can only say what the store currently claims happened. History signing raises that bar: it lets you prove cryptographically that a history is the one Catalyst actually produced, not one edited afterward. For regulated work this changes what you can attest to. A bank can show a payment was executed by an approved workflow rather than an ad-hoc API call, and a healthcare system can demonstrate that a claim passed every required screening step. As agents increasingly delegate work and call tools on their own, the same record answers not just who made a request, but how the execution reached that point, providing a complete chain of custody for autonomous systems.

How it works

Batches of workflow events are hashed with SHA-256 and signed using the workflow's short-lived X.509 SPIFFE certificate, the same cryptographic identity Catalyst issues for mTLS. Every signature also incorporates the previous signature's digest, so the events form a linked chain, with each signing input computed as SHA-256(previousSignatureDigest || eventsDigest). The signatures, certificates, and events are persisted together in a single atomic write. Whenever Catalyst loads a workflow's state, it verifies the whole chain: that each link matches, that the event range is contiguous, that the digest recomputed from the stored bytes is unchanged, that the signature is valid, and that the signing certificate chains back to a trusted certificate authority under the expected workload identity. If any check fails, Catalyst halts the workflow instance and marks its history as tampered, preserving the untrusted history for forensic analysis instead of continuing on corrupted state.

Attestation across workflows and activities

Verification also extends across trust boundaries in Catalyst. When a child workflow or an activity runs under a different identity than its parent, it produces a cryptographic attestation before its result is written into the parent's history. Each attestation commits to the parent instance ID, the task ID, a digest of the inputs and outputs, and the final status, so a result injected by anything other than the actual child cannot be accepted. For multi-agent systems, where one agent hands work to another or invokes an external tool, this is what makes a delegated result provably originate from the workload that was supposed to produce it.

Enabling it

Verifiable execution is enabled per project and can only be turned on at project creation, after which it applies to every workflow that runs there. Because it builds on the workload identity and mTLS Catalyst already provides, there is nothing to configure in your application code. For the steps and the constraints to plan around, see Enable verifiable execution.

Why it matters​

How it works​

Attestation across workflows and activities​

Enabling it​

See also​

Why it matters

How it works

Attestation across workflows and activities

Enabling it

See also