Trust Is the New Uptime in Cloud-Native Security
Cloud-native security for modern distributed and AI-driven systems is shifting from protecting code at build time to continuously verifying trust, provenance, and integrity at runtime using cryptographic verification and mutual TLS enforcement across services and supply chains.
That shift is no longer theoretical. Diagrid has released Dapr 1.18, introducing "Verifiable Execution" to add cryptographic trust, provenance, and tamper-evident execution records for distributed applications and AI agents. The Argo CD project has shipped a v3.5 release candidate that brings mutual TLS enforcement for internal components and Git commit signature verification for supply chain security. These changes signal a clear direction: uptime and resilience are not enough. If you cannot prove who did what, when, and with which artifact, your platform is insecure by design. The industry’s earlier focus on SBOMs and signed artifacts is now being extended into the live systems where AI agents and workflows make business-critical decisions.
Dapr’s Verifiable Execution: From Durable to Auditable Workflows
Dapr 1.18 is one of the most significant releases since Dapr 1.10 because it turns runtime behavior into a cryptographically verifiable asset rather than a black box of logs. Under the banner of Verifiable Execution, it introduces Workflow History Signing, Workflow History Propagation, and Workflow Attestation so organizations can check how workflows were executed, which identities performed actions, and whether history has been altered. Workflow histories can be cryptographically signed using SPIFFE-based identities, creating tamper-evident records that can be independently verified and chained across services, workflows, and AI agents.
This is a direct response to the trust problem in agentic AI: when an AI agent approves a transaction or accesses sensitive data, teams must know who initiated the action and whether the record is clean. Dapr extends supply chain security concepts beyond software artifacts into runtime execution, allowing workflows and AI agents to emit verifiable evidence of what happened and who did it. According to the project maintainers, the next phase of cloud-native computing will be about verifiable execution, where cryptographic accountability is built into the platform, not bolted on as an afterthought.
Argo CD 3.5: Mutual TLS Enforcement and Source Integrity by Default
Argo CD 3.5’s release candidate tackles two long-standing weaknesses in GitOps pipelines: internal traffic that was previously unencrypted and sources that were assumed trustworthy by default. The repo-server now enforces mTLS, requiring client certificates from every internal component that connects, and can generate self-signed certificates in memory when custom ones are not provided. This closes the gap where traffic between the repo-server, API server, and controllers sat outside usual mTLS protections, a known weakness in large deployments.
On the supply chain side, Argo CD now verifies Git commit signatures before syncing, through Source Integrity validation that can be toggled per application or via CLI. That means a compromised Git repository can no longer silently deploy unsigned or tampered manifests without tripping policy. Combined with features like ApplicationSet UI and concurrency controls, which help operators safely preview and limit the number of applications processed to avoid overwhelming clusters or Git APIs, Argo CD is making it harder to claim ignorance when something untrusted ends up in production. If you run GitOps at scale and still treat internal traffic and commits as inherently safe, this release is a wake-up call.
Supply Chain Security Meets Runtime Cryptography
For years, supply chain security has focused on build-time controls: signed binaries, SBOMs, and artifact attestations. That work matters, but it stops at the moment software starts running. Dapr 1.18 pushes those guarantees into runtime by creating cryptographic chains of custody across workflows, services, and AI agents, providing records that can be independently validated. In effect, your workflow history becomes as trustworthy and auditable as the data it produces. At the same time, Argo CD 3.5 ensures that the manifests driving those workflows are both transported over mTLS and verified via Git commit signatures, removing the blind trust that once existed between Git and the cluster.
This is not optional hygiene. As AI systems become more autonomous, organizations face growing demands for explainability, regulatory compliance, and operational accountability. On the GitOps side, previous Argo CD deployments had gaps in internal security posture and visibility that could undermine those demands. Now, cryptographic verification is becoming the connective tissue between supply chain, control plane, and AI agents. If your cloud-native security strategy stops at signed containers and ingress mTLS, you are leaving wide attack paths open inside your own infrastructure.
What Enterprises Should Do Next
Enterprises deploying distributed systems and AI agents across complex infrastructure need to treat cryptographic verification as a first-class design requirement, not a later hardening step. Dapr 1.18 shows that runtime execution can and should emit signed, tamper-evident histories using open identity standards, while also adding practical improvements like component and configuration hot reloading so security does not mean downtime. Argo CD 3.5 shows that internal mTLS and commit signature verification can be enforced even in large GitOps environments without sacrificing usability, thanks to features like ApplicationSet UI and concurrency limits that protect clusters and upstream Git APIs.
The takeaway is blunt: if your AI agent trust model is based on logs and good intentions, it is already obsolete. Supply chain security now extends from source repositories, through signed artifacts, into mTLS-protected control planes, and finally into verifiable runtime execution. The organizations that accept this and invest in cryptographic accountability will be able to prove the integrity of their systems; the rest will rely on hope and after-the-fact forensics when something goes wrong.
