What an Unverifiable Agent Chain Costs You in an Audit

Why durable execution isn't enough for agent systems, and how Diagrid Catalyst, built on Dapr, brings verifiable execution lineage to agent workflows.

The question every workflow engine quietly avoids

Picture a payment workflow. A customer service workflow validates the order, calls a fraud detection workflow that runs checks and captures human approval, which then calls a payment service that actually charges the card.

The obvious question is: how does the payment service know the right things happened before it was called?

This isn't a problem in a single-process system owned by a single team. On traditional monolithic systems, everything ran in one place under one identity - the workflow's history was the workflow's memory, and there was nothing to verify because nothing crossed a trust boundary. But modern workflows aren't built that way. Each step can run in a different process, often owned by a different team, often under a different identity. That distribution is the whole point: it's how teams scale, deploy independently, and let specialists own specialist services. The cost is that no one service has the full picture in the chain. The chain only exists across the calls, not in any one place where someone can check it.

How does it know the fraud check actually ran? That a human actually approved this? That an upstream agent didn't already exceed its budget for the session? That the identity verification step wasn't quietly skipped because someone refactored the parent workflow last Tuesday? That the middle steps aren't compromised?

The honest answer, in every major workflow engine on the market today, is: it doesn't. It trusts whatever the caller puts in the payload. That's not verification.

Developers compensate today by building verification by hand - signed tokens, claims checks, custom audit trails. The same way HTTPS moved encryption from application code into the transport layer, verifiable execution lineage moves trust from the application into the runtime.

Why durable execution stopped being the hard part

For the last several years, the workflow conversation has been about durability. Survive crashes. Retry reliably. Keep the state consistent. That problem is largely solved - Dapr Workflows solved it well, Temporal solved it well, a handful of others solved it well enough.

But durability answers the question "will this workflow finish?" It doesn't answer "should this step be allowed to run, given what did or didn't happen upstream?"

That second question is the one AI agent systems are about to make unavoidable. Agents call tools, often across organizational boundaries, often making decisions a human used to make. The MCP ecosystem is the most visible example - tool servers receiving requests from agents invoked by other agents, in chains nobody at design time fully enumerated.

In that world, "is the caller authorized?" is no longer enough on its own. There's a second question on top of it: "did the right things happen, in the right order, before this request reached me - and can I prove it?" You cannot answer that with identity. You cannot answer it with a JWT. You cannot answer it with a context object the caller filled in. You can only answer it with a verifiable execution lineage that the runtime - not the application, not the caller - guarantees.

No major open-source workflow engine or product on the market offers this. Until now.

Why Temporal isn't the answer

Temporal comes up immediately in this conversation, so let's address it directly. Temporal is designed for durable execution. But on the specific dimension of verifiable execution lineage across application boundaries, Temporal doesn't have an equivalent. And the reasons are architectural, not cosmetic:

• Nexus is Temporal's mechanism for invoking workflows across namespace boundaries, through a service contract. But Nexus is peer-to-peer by design, not hierarchical. Temporal's own documentation describes caller and handler workflows as "siblings that communicate across Namespace boundaries" through a service contract. The caller's workflow history records that a Nexus operation was scheduled, started, and completed - but the handler's internal execution history isn't propagated to the caller, and the caller's accumulated history isn't propagated to the handler. That's not an oversight, it's how Nexus was designed. [^1] [^2]
• Visibility is workflow-level, not chain-level. Temporal Visibility lets you query workflows using system and custom search attributes. There is no documented API for traversing a chain of workflow executions and answering questions about ancestors. If you want to ask "did fraud detection complete two hops ago," you build that correlation yourself - custom search attributes, external tracing, your own conventions - and trust that everyone in the chain implemented them correctly. [^3]

• Authorization gates who can call, not what happened before the call. Nexus uses endpoint-level access controls: the handler namespace allowlists which caller namespaces can reach it. Temporal Cloud routes Nexus requests across a global mTLS-secured mesh. That secures the individual hop. It doesn't produce a verifiable record of the chain that a downstream service can inspect. [^4]

None of this is a bug. Temporal is solving a different problem. But if your roadmap includes AI agents making consequential decisions across services and organizations, Temporal does not give you the primitive you need. And no amount of clever payload engineering will close the gap - because the trust boundary is in the wrong place. Diagrid has what Temporal doesn't: application identity as a first-class runtime concept, present on every workflow, every call, every event. The receiver has to trust the sender's claims, full stop. That's fine for the workflows Temporal was built for. It's not fine for agent systems where the question "did the right things happen upstream" is no longer optional.

Putting the trust boundary in the right place requires a runtime that sits between applications and owns the propagation itself. That's what Dapr was built to do, and what Diagrid Catalyst makes production-grade.

Why Dapr is the only place this could come from

This isn't a feature Temporal forgot to ship. It's a feature that's hard to bolt onto an engine that wasn't designed to carry context across application boundaries in the first place.

Dapr has a specific advantage here: it was built from day one as a runtime that sits between applications and treats cross-application communication as a first-class concern. The sidecar model means the runtime - not your app code - is the one stitching calls together. That's the only place where verifiable lineage can actually be enforced. If the application is responsible for propagating history, the application can lie about it. If the runtime does it, the application can't.

Dapr v1.18 introduces Workflow History Propagation. It wasn't a feature added to compete with anyone. It was the natural consequence of the runtime already being in the right position.

(Check out the Dapr 1.18 release webinar or release blog to learn more)

Here's what changes. Instead of a downstream activity asking "who is calling me?", it asks "what actually happened, in what order, and can I prove it?" The propagated history travels as sidecar data on the gRPC path - never embedded in history events themselves, which keeps nested history from leaking through trust boundaries by accident. Propagation is opt-in, with a notion of trust boundaries: you can pass full lineage to a service inside your trust domain, or only your own history when you're crossing into someone else's. Coupled with history signing, the chain becomes cryptographically verifiable end-to-end - your application doesn't manage trust anchors or keys, because if the history is in your hands, the runtime has already verified it for you.

In a verified-lineage world, your application code stops doing trust management. It just makes decisions. The runtime is the trust boundary.

What history signing actually guarantees

History propagation puts the chain in the receiver's hands. Signing makes the chain provable. Dapr v1.18 introduces three cryptographic mechanisms that work together to make execution lineage verifiable end-to-end:

• Local history signing: Every workflow's history is cryptographically signed and chained together. If something tampers with the state store, then the next load fails verification, and Dapr marks the workflow FAILED with error type DAPR_WORKFLOW_HISTORY_TAMPERED instead of acting on forged data.
• Cross-identity completion attestation: When a child workflow or activity runs under a different identity than its parent and reports back, the executor signs an attestation committing to its identity, its input, and its output. The parent verifies before the result enters its inbox. A remote app cannot lie about a result, and an attacker with state-store access cannot inject fake results into the chain.
• Lineage chunk signatures: When a workflow forwards its accumulated history to a child across apps, each app's contribution to the chain is signed by that app's identity and verified independently on arrival. A compromised app in the middle of a chain cannot rewrite what came before it without detection.

Together, these answer a category of questions that AI agent systems are about to be asked constantly, and currently cannot.

• Did a human actually consent to this elevated permission, in a way that's verifiable after the fact?
• Can this agent release a payment, or did an upstream approval actually occur?
• Did the identity verification step actually run, or did someone refactor it out last Tuesday?
• Can this agent export sensitive data, given what did or didn't happen earlier in the session?
• Did a second human with greater privileges authorize this transaction?

These are the kinds of questions being formalized in the AAIF working groups - the Agentic AI Foundation, hosted by the Linux Foundation alongside Anthropic, OpenAI, and others, where Diagrid is a Gold Member.

This is not a workflow feature. It is an authorization primitive for agent systems, expressed in workflow terms because workflows are where the chain of decisions actually lives.

Why Diagrid Catalyst is where this actually becomes usable

Open-source Dapr gives you the primitive. But shipping the primitive isn't the same as running it in front of an agent platform where a wrong answer means a real-world action you can't take back. That's where Diagrid Catalyst comes in.

If you're building durable AI agent orchestration or MCP server infrastructure - the kind of system where something is taking real-world actions and one of them is going to be wrong in front of an auditor someday - there are a few things you need that no amount of Helm charts will give you for free:

• A managed control plane that handles workflow durability, history retention, and cross-application propagation without you operating a Placement service, a Scheduler, and a state store yourself. The infrastructure producing the lineage is exactly the kind of thing most teams shouldn't be running by hand - it's a distributed system with strong correctness requirements, and getting it wrong silently undermines the guarantee you adopted it for.
• Chain-integrity monitoring you can't build yourself. Signing lets the runtime verify each hop. But noticing that a signature failed somewhere, that an expected upstream event is missing, that the same agent has produced anomalously short chains all morning - that's pattern detection across every workflow in every application, and it only works if something is watching the whole picture. A managed control plane is structurally in the right position to do that. Your own deployment isn't.
• Operational visibility that matches the new mental model. When the question is "did fraud detection complete two hops ago," you need an operator surface that can actually answer it across dozens of applications, not one workflow at a time. Open-source Dapr gives you the events. A managed runtime is what turns them into a queryable, retained view a human can actually use at 2am.
• Production-grade history retention and query. Verified lineage is only useful if you can still get at it when you need it - during an incident, during an audit, during a regulator's request six months after the fact. That's an operational problem before it's a runtime problem, and it's not one most teams want to solve themselves on top of their own state store.

In other words: Dapr makes verified execution lineage possible. Catalyst - built on Dapr, the open-source runtime used by thousands of organizations - makes it something you can actually depend on a Tuesday morning, for the agent systems you're going to put real money behind.

Why this matters right now, not in two years

Two reasons not to wait. First, the agent systems being built right now - the ones that will be in production a year from now - are accumulating architectural debt in exactly this area. Every payload or "context object" passed between agents today is a future trust incident. The teams that pick the right primitive now won't pay that bill later.

Second, the regulatory and audit conversation around agent-driven actions is going to converge on something that looks a lot like verifiable execution lineage. "Show me the verifiable chain of decisions that led to this transaction" is a question that's going to be asked. The teams that can answer it with a runtime guarantee will be in a very different position than the teams answering it with grep or with blind trust.

Is the system you built actually trustworthy?

Durable execution is solved. The next problem is trustworthiness - proving what happened across a chain of calls, not just that each call succeeded. Temporal can't do that across application boundaries. Dapr v1.18 can, because the sidecar model puts the runtime in the right place to enforce it. Diagrid Catalyst is where that primitive turns into something you can actually run a business on.

If you're choosing a workflow engine for an agent-heavy roadmap, the question to ask is no longer "can this engine survive a crash?" Every serious engine can. The question is "can your agent platform cryptographically prove what happened?" Right now, there is one answer. The teams that recognize it first will be the ones running agent systems their auditors, their regulators, and their customers can actually trust.

Where to go from here? Try Diagrid Catalyst

Catalyst is in free trial today. There are three places to start, depending on what you're trying to do:

• If you want to see it run, start a free Catalyst trial. Workflow history propagation is available now.
• If you're evaluating workflow engines for an agent-heavy roadmap, contact our team.
• If you want to dig into the primitive itself, review the Dapr v1.18 release notes and the workflow history propagation documentation. The capability is open source, so you can verify every claim in this post against the runtime.

Sources

• Temporal Nexus overview
• Temporal Nexus operations
• Temporal Visibility
• Temporal Nexus security