Continuous Assurance: From Audit Day to Always-On Evidence

Every assurance mechanism most organisations rely on — the annual audit, the architecture review board, the pre-release gate — quietly assumes that change is slow and human-authored. You can inspect a representative sample, sign a certificate, and trust that the system will not move far before the next review. Agentic delivery breaks that assumption. When agents propose change continuously and authorship is shared across humans, agents and models, a point-in-time assessment is a photograph of a system that has already moved. The certificate on the wall is true on the day it is issued and decreasingly true every day after.

The response is not more frequent audits; it is a different shape of assurance. Trustworthiness has to be reframed from a static certificate into a signal that is generated continuously, at the speed the system actually changes. The Cloud Security Alliance puts it bluntly: point-in-time compliance is a snapshot that is obsolete within weeks. The discipline that replaces it is continuous assurance — and like everything else in agentic delivery, it works only when it is built into the pipeline as code rather than bolted on beside it.

Controls become code, evidence becomes exhaust

The mechanics are now well established. Controls, policies and the evidence that they hold are encoded as code that runs in the delivery pipeline, not as documents written once a year. Policy-as-code engines such as Open Policy Agent verify configuration and enforce rules before a change reaches production, with explicit one-to-one mappings from a stated control to the guardrail that enforces it. Continuous controls monitoring watches those guardrails between releases rather than at them. And the evidence is collected continuously into machine-readable form — the CSA’s compliance-automation work emits it as OSCAL — so an auditor is handed a live feed, not a binder assembled the week before. The shift in mindset is the important part: evidence stops being something you produce for an audit and becomes the ordinary exhaust of a pipeline that checks itself.

The cryptographic substrate: attestation in the pipeline

Underneath the policies sits a layer that makes the evidence trustworthy rather than merely plentiful: signed attestation. Frameworks such as in-toto and SLSA give each stage of the pipeline a verifiable chain of custody — a statement, signed, that this artefact was produced this way from this source. Sigstore’s Cosign signs artefacts into an immutable transparency log; verification summary attestations let a trusted verifier vouch for a policy decision so downstream stages do not re-litigate it; admission controllers such as Kyverno and Gatekeeper refuse to deploy anything that fails the check. OWASP’s 2026 application-security guidance for AI code generation makes this concrete for agentic delivery: AI-produced artefacts carry signed provenance and an AI bill of materials, and the pipeline verifies and quarantines anything unsigned or from an untrusted key. Assurance, in other words, becomes a property the pipeline can check on every change, not a judgement a person makes occasionally.

Continuous assurance does not prove who decided — it proves, continuously, that the controls held. The accountability still has to be engineered above it.

Provenance proves how, not who — and the gap is the point

It is tempting to declare the problem solved: sign everything, verify everything, and trust is automatic. It is not, and being precise about why is where this gets useful. Provenance and attestation prove how an artefact was built and that it was not tampered with. They do not prove who decided it should exist or who is answerable for it — and we were careful to confirm this rather than assume it: the claim that these frameworks cleanly capture human, model and agent attribution does not hold up. SLSA records the build, not the authorisation. This is exactly the distinction we draw in our position that audit trails do not create accountability: knowing how is not knowing who. The mature design keeps both layers and does not confuse them — continuous assurance proves the controls held; a separate, deliberately engineered attribution-and-decision trail records who accepted the risk. OWASP’s own guidance reflects the same caution, barring agents from approving, signing or deploying their own artefacts, because policy enforcement alone cannot manufacture a human owner.

Where continuous assurance goes wrong

• Evidence theatre: generating mountains of signed evidence that no control actually gates on — volume mistaken for assurance.
• Control drift: the policy-as-code rule and the real-world control it was meant to enforce slowly diverge until the green check means nothing.
• Attestation without meaning: signing artefacts while leaving the “who authorised this” question unanswered, so the chain proves integrity but not accountability.

Continuous assurance is the operating model that sits above our assurance mechanisms — the audit trail it writes, the provenance it captures, the security review it automates. The discipline is to move the controls into the pipeline as code, gate continuously on the evidence they produce, and keep a human accountability layer above the cryptography. For the record this produces, read the audit trail for agentic delivery; for the who-decided layer it cannot replace, read provenance engineering and why audit trails do not create accountability.