"Automating our invoicing with AI agents went smoothly, but recently our auditing firm asked, 'Can you prove under whose authority and on what basis the agent executed this bank transfer?' and we couldn't answer." During a recent consultation, the head of IT at a mid-sized enterprise opened with this dilemma. The agent was functioning properly, and logs existed. However, the standalone logs could prove neither that they remained untampered with after the fact nor which policies were active at the moment of execution.
This is hardly an isolated incident. An agency proposes AI automation, delivers working software, and six months later finds itself in a crisis when stakeholders realize they cannot explain or audit whether the system truly executed as intended or why it made a specific judgment. The vague concern that decision-makers harbor—fearing they cannot prove actions post hoc—is technically justified. Drawing on Verifiable Execution introduced in Dapr 1.18 in June 2026, this article outlines how to design audit trails when incorporating AI automation into custom client systems. Dapr is merely one mechanism; the true focus is the architectural philosophy of how to guarantee auditability.
Why "we have logs" fails audit scrutiny
In many environments, audit readiness for AI agents begins and ends with "we output application logs." Yet agent logs suffer from three inherent vulnerabilities absent in traditional systems.
The first is an inability to detect tampering. Standard application logs are append-only text or JSON files that leave no trace if modified after the fact. From 2026 onward, auditors are increasingly discounting logs that cannot be proven tamper-free.
The second is the omission of authorization origin. Because agents call external systems using shared service accounts or API keys, logs only capture "accessed by Service Account X," failing to record which human initiated the prompt or under what delegated authority it ran. This omission is critical under regulatory frameworks mandating individual attribution, such as GDPR and SOX.
The third is the absence of the rationale behind actions. The factual record that an agent "deleted a file" is separate from "why it determined deletion was appropriate." An audit-grade record requires not just the execution fact, but the evaluated policies, tool invocations, and specific arguments at that exact point in time.
| Logging tier | Information recorded | Audit viability |
|---|---|---|
| Application logs only | "Action completed" plain text | Fails (no tamper detection) |
| Structured logs | Tool names, arguments, timestamps | Weak (lacks tamper detection and authority attribution) |
| Verifiable execution | Above plus signatures, delegated authority, and policy evaluations | Passes (tamper-evident with provenance) |
What "verifiable execution" introduced in Dapr 1.18 entails
Introduced in June 2026, Verifiable Execution in Dapr 1.18 is a suite of capabilities that injects cryptographic trust into workflow and AI agent execution records. It comprises three core capabilities.
Workflow History Signing cryptographically signs workflow execution histories with workload identities based on SPIFFE standards, generating tamper-evident records. Each step's signature is produced under an X.509 SPIFFE identity over sidecar mTLS and chained to the previous step's signature, validating the entire chain whenever state is read. Modifying even a single intermediate step breaks the chain and triggers detection.
Workflow History Propagation carries execution lineage across service, workflow, and application boundaries. Downstream systems can trace where a request originated and which preceding actions influenced it.
Workflow Attestation provides activities and child workflows with a validated execution context, enabling policy and compliance evaluations grounded in verified provenance.
Technically, the Dapr workflow engine hashes inputs, outputs, and tool-call metadata for every step, generating signed "execution receipts" using workload-scoped keys issued by SPIFFE/SPIRE, which are saved as append-only ledgers via state management APIs. In essence, it builds an immutable ledger of agent actions directly at the runtime execution layer. Crucially, this does not rely on application-level logging logic, embedding cryptographic proof directly into the workflow.
This is where an identity foundation identifying whose authority guided execution becomes indispensable. Structuring authority via SPIFFE identifiers links directly to establishing distinct agent identities, as detailed in Authentication and Authorization Design for AI Agents, layering digital signatures and audit trails atop that identity base.
Why auditability has become a core procurement issue today
Before examining technical mechanics, it is essential to understand why this has surfaced as a board-level and compliance priority. The catalyst is regulatory compliance.
High-risk AI system mandates under the EU AI Act take effect on August 2, 2026. Article 12 mandates that high-risk systems technically enable the automatic recording of events over their operational lifetime, stipulating a minimum log retention period of six months (with comprehensive technical documentation retained for ten years post-decommissioning). Non-compliance carries penalties of up to €15 million or 3% of total worldwide annual turnover. Because AI impacting credit scoring, critical infrastructure, and employment qualifies as high-risk, the scope extends far beyond niche industries.
| Dimension | Regulatory requirement |
|---|---|
| Execution recording | Automatic logging of what, when, and with which tools |
| Attribution to individuals | Identifying the guiding human instruction and delegated authority |
| Tamper-evident immutability | Proof that records were not altered after the fact |
NIST also launched a standardization initiative in February 2026 treating agentic AI as an independent regulatory category, harmonizing global regulatory momentum around accountability, behavioral transparency, and human oversight. Procurement stakeholders' unease about proving actions post hoc is not mere paranoia; regulations are actively mandating it. Crucially, retrofitting audit trails is notoriously fragile and expensive. Adding tamper-evident logging six months down the line to a system that produced no cryptographic evidence during execution amounts to a near-total rewrite.
Reasoning traces are not audit trails
Here lies a confusion common in custom development: the belief that "retaining LLM reasoning traces satisfies accountability requirements." This assumption is half true and half perilous.
Reasoning traces provide valuable context regarding why an agent deemed a decision sound, but they do not constitute an audit trail on their own. The reason is simple: reasoning traces can be altered, and carry no inherent cryptographic link to execution. Even if a trace reads "determined deletion was appropriate," an auditor will dismiss it unless you can prove that the trace corresponds directly to the actual deletion invocation and has not been edited post-facto.
Audit-resilient records require capturing both the observation of execution (what was done) and the observation of intent (why it was done), each preserved in a tamper-evident manner cryptographically bound to the execution. The reason Dapr's verifiable execution hashes and signs tool-call metadata alongside inputs and outputs is precisely to render the entire execution payload—reasoning and intent included—collectively immutable. Retaining reasoning traces is commendable, but whether they qualify as an audit trail hinges on cryptographic signatures and tight coupling to execution.
Case study: re-architecting credit assessment automation after falling into unprovability
A commercial financial services firm approached us regarding their production system. The company had delegated first-round application assessments to an AI agent, which evaluated external credit bureau APIs, internal transaction histories, and a rule engine to output an "Approve, Hold, or Reject" decision. Processing roughly 8,000 cases monthly, human underwriters reviewed only applications flagged for hold by the agent.
The vulnerability surfaced when a rejected applicant filed a formal complaint, and the internal team attempted to reconstruct why the application was declined. While application logs recorded `decision: reject`, they could identify neither the score values referenced during evaluation, the version of the rule engine applied, nor the credentials under which the agent queried external APIs. Furthermore, logs were stored as plaintext in an application database, offering zero proof against tampering. With customers in the EU, this vulnerability was unacceptable ahead of the August 2026 high-risk AI mandates.
Our remediation followed a three-phase approach. First, we re-architected agent steps as Dapr workflows, migrating them to an execution platform that captures inputs, outputs, and tool calls as signed receipts. Second, we bound external API calls to SPIFFE identities, embedding records of which workload executed calls under which delegated authority. Third, we recorded rule engine versions and evaluated policies directly within the decision context, allowing teams to reconstruct that "this decision was rejected under Rule v2.3 due to a score below threshold X."
As a result, reconstructing decision rationales for contested applications—which previously took several days on average—can now be reproduced the same day via ledger queries. Cryptographic signature chains allow the company to demonstrate to audit firms that logs have not been altered, meeting the August compliance deadline. Total effort spanned roughly seven weeks. Splicing verifiable trails into the execution runtime avoided extensive rewrites to core agent logic, keeping delivery timelines contained.
In this project, establishing review processes for agent-generated code also became an immediate priority. Preparing audit trails without governing the quality of generated code remains an incomplete solution, a dynamic explored in detail in Review and Governance of AI-Generated Code.
Core design principles for audit trails in custom AI automation
Whether utilizing Dapr or not, implementing AI automation in custom client projects requires including auditability in the Scope of Work (SOW) from day one. It is a discipline where retrofitting is impractical. Below are key alignments to solidify during design.
| Discussion point | Why retrofitting fails | Decisions to settle upfront |
|---|---|---|
| Tamper detection | Post-hoc signatures cannot validate historic logs | Whether to implement runtime signing and hash chaining |
| Authority attribution | Shared service account operations cannot be disaggregated later | Whether to assign unique workload identities to agents |
| Policy preservation | Historic rule versions cannot be retroactively reconstructed | Whether to include policy versions within decision contexts |
| Retention and submission | Incompatible formats cannot be utilized during audits | Establishing retention periods and export formats per regulations |
Preventing vendor lock-in is equally vital. Dapr is a CNCF open-source project built upon industry-standard SPIFFE identity primitives, minimizing lock-in to specific clouds or vendors. However, treating Dapr adoption as an end in itself misses the point. Commissioning stakeholders must focus not on product branding, but on whether the design satisfies three tenets: are executions tamper-evident, can authority origin be traced, and can decision rationale be reproduced?
Another frequently neglected control is governing unauthorized agents outside official workflows. Hardening official pipelines with verifiable execution leaves compliance gaps if business units deploy shadow AI agents in parallel. This reality must be addressed alongside Shadow AI Governance.
Next step: test whether your current system can prove its actions
Prior to greenlighting implementation, test a simple scenario against your existing AI automation: select a recent transaction executed by your agent, and attempt to reconstruct what was done, when, under whose authority, and why, accompanied by proof of non-tampering. If your team cannot provide this, you will face the exact same shortfall during an audit.
Any unanswerable question highlights a gap in your architectural requirements: missing tamper detection, unrecorded authority delegation, or absent policy versioning. Identifying these gaps clarifies whether an architecture like Dapr's verifiable execution is necessary or whether refining structured logging will suffice. Prioritizing business functions governed by strict regulations (such as credit evaluation, HR, and critical infrastructure) offers the most pragmatic starting point.
At GleamHub, we provide end-to-end custom development services, ranging from audit trail design reviews for operational AI systems to implementing production verifiable execution architectures. If you have automated workflows with AI but lack confidence in proving their actions post hoc, or if you need guidance preparing for 2026 regulatory mandates, feel free to reach out via our contact form. Building functional software and building provable software represent two entirely distinct architectural commitments.
Sources
- Dapr 1.18 Introduces Verifiable Execution, Bringing Cryptographic Trust to AI Agents and Workflows（InfoQ）
- Introducing Verifiable Execution in Dapr 1.18（CNCF Blog）
- Why Dapr 1.18’s verifiable execution puts cryptographic proof inside the workflow itself（diginomica）
- Article 12: Record-Keeping（EU Artificial Intelligence Act）
- AI Agent Accountability: Reasoning Traces vs Real Audit Trails（Apptitude）
