By Supply chain attacks are compromising databases faster than security teams can respond, and autonomous AI agents are compounding the problem at scale. When an agent acts on behalf of a human who acts on behalf of another agent, traditional logs and traces cannot prove the chain of custody, and they cannot detect if that record was altered after the fact. For regulated industries, this is not a theoretical risk. It is an audit failure waiting to happen.
In this interview on TFiR, Yaron Schneider, Co-Creator and Maintainer at Dapr, walks through verifiable execution in Dapr 1.18, covering how SPIFFE-based cryptographic identity, signed workflow history events, and tamper-evident execution records give enterprise security and compliance teams proof that holds up under audit.
Guest: Yaron Schneider, Co-Creator and Maintainer at Dapr
Show: TFiR
Here is what every platform engineer, security architect, and compliance team needs to know.
Technical Deep Dive
Q: Why are logs and traces no longer sufficient for auditing AI agent activity in distributed systems?
Yaron Schneider, Co-Creator and Maintainer at Dapr, explains that logs, traces, and metrics data are not cryptographically attested, which means they can be silently tampered with, changed, or compromised after the fact. As autonomous AI agents multiply and act on behalf of humans who act on behalf of other agents, the volume of unverifiable actions grows exponentially. Without cryptographic attestation, there is no absolute certainty that the application or agent claiming to have performed an action is actually who it says it is.
“Your data and your database can no longer be trusted. If someone compromises your database, how do you actually make sure that the records you’ve written are actually cryptographically verified?” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Q: How do SPIFFE and verifiable execution work together in Dapr 1.18?
Every time an application, MCP server, or agent connects through Dapr, the runtime uses SPIFFE, an open source CNCF standard, to issue a cryptographically verifiable identity certificate to that piece of code. When a workflow is triggered, Schneider explains that Dapr signs every history event inside that workflow, creating a blockchain-style append-only event log. If anyone attempts to retroactively alter the data, the workflow detects that the current signature does not match the previous signature the next time it attempts to continue, and surfaces the discrepancy to the security team immediately.
“We write the data into an append only event log. And so if someone tries to go in retroactively and change the data, the next time the workflow seeks to continue, it will actually fail because it will have discovered that its current signature does not match the previous signature.” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Q: How does workflow history propagation and attestation close the trust gap for enterprise security teams?
Schneider frames this as a compliance necessity rather than an optional enhancement. When a financial or healthcare organization is called up for an audit and asked to prove the specific order of operations and the identity of who executed each step, a trust-based answer is no longer acceptable. Cryptographic attestation transforms that answer from a claim into tamper-proof, 100% verifiable evidence that satisfies auditors and regulators.
“Today it’s a kind of like a trust me type of answer. With cryptographic attestation, it becomes tamper proof and 100% verifiable.” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Q: How does Dapr 1.18 provide cryptographically signed proof of an agent’s history before a downstream system takes a sensitive action?
Dapr assigns a certificate to every actor in the system, whether it is an MCP server or an autonomous agent, using SPIFFE to create a unique ID for each participating application inside the workflow. Each time an application attempts to execute a step, whether that is processing a payment, validating a merchant, or moving money, Schneider explains that Dapr verifies that the specific step is being executed by the application that holds the identity for that step. This decouples the identity of the application from the underlying execution of the business logic, preventing impersonation at the execution level.
“The identity of the application is really decoupled from the underlying execution of the business logic.” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Q: Why release verifiable execution as an open source CNCF standard rather than a proprietary product?
Schneider is direct about the internal debate: the team considered shipping verifiable execution as a proprietary feature only, but concluded it belongs in the open source ecosystem because the breadth of distribution matters more than the commercial opportunity. He describes it as a revolutionary capability that has been a long-standing gap for enterprises needing 100% tamper-evident execution proof, and argues that open source is the right home because organizations can inspect and verify the code themselves rather than trusting a vendor’s claims.
“This has been a long standing gap that keeps many CISOs up at night. And this really belongs in open source where people can see and verify that the code in there is actually doing what it needs to do.” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Q: What is a real-world scenario where verifiable execution would have changed the outcome of a security audit or compliance check?
Schneider walks through a loan approval scenario. An underwriter approves a loan and that record travels to the originating bank as a separate entity. Without cryptographic attestation, the approval status could be silently altered in transit, or an attacker could impersonate the underwriter entirely, leaving the bank with no mechanism to verify the true origin of the request. With Dapr verifiable execution, the workflow detects any tampering or impersonation at the moment it occurs and surfaces it immediately rather than discovering the breach during a post-incident review.
“If someone tries to change that after the fact, or impersonate the entity that’s supposed to be giving you this information, Dapr workflows is going to essentially detect that right when it’s happening.” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Q: What is the practical advice for teams looking to integrate verifiable execution features into existing workflows?
Schneider recommends that teams start by honestly evaluating their current audit and compliance strategy and asking whether they can actually back up their claims about who is doing what inside their systems. Most teams, he suggests, will find that their current policies are not sufficient or that they are spending significant time and cost maintaining difficult infrastructure to approximate the guarantees that Dapr provides out of the box. Because Dapr is a vendor-neutral CNCF project, teams can adopt it without being locked into a specific vendor’s ecosystem.
“I think most teams will recognize that their policies today are not cutting it, or that they have to spend a lot of time just writing and maintaining a whole bunch of very, very difficult to maintain and very cost non efficient infrastructure.” — Yaron Schneider, Dapr Co-Creator and Maintainer, Dapr
Resources & Documentation
- Dapr, open source, vendor-neutral CNCF runtime for building distributed applications and autonomous agent workflows with verifiable execution
- SPIFFE, CNCF standard for cryptographically verifiable workload identity used by Dapr to issue identity certificates to applications, agents, and MCP servers
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: When it comes to distributed system, most of us think that logs and traces can tell us what went wrong with them. But the reality is in the age of autonomous AI agents, observability isn’t just enough as it used to be. Without cryptographic proof, organizations have no way to verify that execution history hasn’t been tampered with or even know which agent kicked off a critical action because agents are not now taking action on your behalf. We have with us now DAPR 1.18, which is introducing verifiable execution, bringing attestation and tamper evident history to cloud native workflows. And today we have with us once again DAPR co creator and maintainer Yaron Schneider to walk us through what this unlocks. First of all, Yaron, it’s great to have you on the show.
Yaron Schneider: Thank you so much for having me.
Swapnil Bhartiya: Yeah, it’s my pleasure. And I was talking about, I would love to hear from you. Why is traditional observability like locks and traces no longer enough when we start talking about autonomous AI agents?
Yaron Schneider: Yeah, I mean, just look at the news that we went into, going into this weekend. Another supply chain attack. It’s all over the news every other day. We’re almost seeing another attack with remote execution, basically compromising organizations data. And it’s becoming really, really apparent that your data and your database can no longer be trusted. If someone compromises your database, how do you actually make sure that the records you’ve written are actually cryptographically verified to be able to give you an absolute certainty that one application or an agent acting on behalf of an application or on behalf of a human are actually who they say they are. And with agents this is just going to get more at scale because you’re going to have a lot of agents that are acting on behalf of many humans, and those humans are going to be acting on behalf of other humans who are acting on behalf of other agents. And this can just go on and on and on. And so the ability to not rely on just logs and audits, which is what we’ve had so far, is extremely important. Logs can be tampered with, they can be changed, they can be compromised. Same thing with tracing metrics data. All of those things are not cryptographically attested to. This is what we’re trying to solve with the latest release of dapr.
Swapnil Bhartiya: Can you talk about how does spiffy and verifiable execution work together in DAPR 1.18 to create that seamless chain of custody?
Yaron Schneider: Of course. So in dapr, every time you Connect an application, an MCP server or an agent, we issue a cryptographically verifiable identity to that piece of code, which means you get a certificate that carries your id. And every time you kick off a workflow, we essentially sign every history event inside of that workflow so that it becomes like a blockchain type of thing where we write the data into an append only event log. And so if someone tries to go in retro actively and change the data, the next time the workflow will seek to continue, it will actually fail because it will have discovered that its current signature does not match the previous signature and it’ll essentially just surface up to the security team that hey, your workflow has been compromised. So it basically works by us signing every piece of the workflow history and then just continuously verifying it as the workflow progresses.
Swapnil Bhartiya: What is it about features like workflow history propagation and attestation that bridges the trust gap for enterprise security teams looking to move agents into production?
Yaron Schneider: So yes, I think it’s critical for enterprise to take this into production, otherwise they will not be able to answer questions that they were going to need to answer if they’re called up for an audit. So when someone comes to a financial company or you know, a healthcare company and basically ask them, hey, how can you verify that this specific order of operations was executed by who you say it was executed by? Then if they don’t have cryptographic attestation, they just won’t be able to provide those answers. Because today it’s a kind of like a trust me type of answer. With cryptographic attestation, it becomes tamper proof and 100% verifiable.
Swapnil Bhartiya: Perfect. Awesome. And how does DAPR 1.18 provide cryptographically sign proof of an agent’s history before a sensitive action is taken by downstream system?
Yaron Schneider: So we assign a certificate for every actor in our system, whether it’s an MCP server or an agent. And we use Spiffy, which is an open source CNCF standard, to essentially create an ID for each participating application inside of the workflow. And each time an application attempts to do something, whether it’s process, payment, validate, merchant, move money around, whatever it is your business logic is doing, we make sure that this specific step is by the application that is executing that specific step, and that application has an ID and a cryptographically attestable identity to it, so that the identity of the application is really decoupled from the underlying execution of the business logic.
Swapnil Bhartiya: And can you also talk about why is it critical to deliver this capability as an open vendor neutral standard within the CNCF ecosystem rather than a proprietary product.
Yaron Schneider: We believe that distribution of this feature matters a lot. We want to put it into the hands of many companies as possible. And look to be very, very honest, we did think about putting it inside of our proprietary product only, but we realized that this really belongs with the open source ecosystem. Just because this is a revolutionary feature, this is how we define it. For any form of enterprise who’s looking to attest in a 100% tamper evident way that what actually went on in their execution path actually happened. This has been a long standing gap that keeps many CISOs up at night. And this really belongs in open source where people can see and verify that the code in there is actually doing what it needs to do.
Swapnil Bhartiya: Is it possible for you to share a real world scenario where verifiable execution might have changed the outcome of a security audit or compliance check?
Yaron Schneider: Yeah, I imagine you have a money movement process. Actually, let’s take the scenario of a loan approval. You might have an underwriter writing a loan and approving it. Once the loan reaches the bank it originates from, from a completely different entity. And at that point, if it’s compromised at any point, someone might, for example, change if the loan was actually approved or not. And you can also get to situations where someone actually impersonates as being the underwriter to the bank. So the bank doesn’t have any actual way to know if it received the request from a verifiable identity or not. And so this is really where this feature comes into play because it allows you to attest to the identity of who approved the loan or who moved money around. And if someone tries to change that after the fact, or impersonate the entity that’s supposed to be giving you this information, dapper workflows is going to essentially detect that right when it’s happening and surface it up so that you can see that there was some sort of tampering with your data.
Swapnil Bhartiya: Last question before we wrap this up is that what is your advice for teams looking to integrate these verifiable execution features into their existing workflows?
Yaron Schneider: I would encourage them to ask what is their audit and compliance strategy today and how do they plan to essentially back up their claims about who is doing what inside of their system? I think most teams will recognize that their policies today are not cutting it or that they have to spend a lot of time just writing and maintaining a whole bunch of very, very difficult to maintain and very cost non efficient infrastructure and and I think they will find that DAPR just gives it to them out of the box by being a vendor neutral project that you can just pick up and get started with.
Swapnil Bhartiya: Iran, thank you so much for sharing these insights and for breaking down how DAPR is pushing trust in autonomous systems. Thank you for time and I look forward to chatting with you again.
Yaron Schneider: Thank you, thank you so much.
