Continuous runtime evidence is the basis for AI audit readiness

At a glance

What this is: This editorial argues that AI governance cannot rely on attestation alone, because audit-ready evidence has to be captured while the system is running and reacting to drift.

Why it matters: It matters because identity and access teams now need runtime proof that agent actions, approvals, and stop controls match policy, not just a paper record after the fact.

Context

The core governance gap is simple: if you only reconstruct AI activity after the fact, you cannot prove whether the running system matched the approved design. In AI programmes, runtime evidence is the difference between policy on paper and control in operation, especially when decisions, tool use, and data access happen continuously.

This is a governance problem, not a model-quality problem. The article treats drift, runtime logging, and interruption capability as the evidence chain that turns AI oversight into something auditable rather than merely documented.

Key questions

Q: How should security teams prove what AI agents did in production?

A: Security teams should require a complete, cryptographically protected action trail that links the initiating request, every delegation step, the credential or token used, and the final system effect. If the trail cannot be replayed and independently verified, it is useful for operations but weak for audit, incident response, and legal defence.

Q: Why does AI drift create a governance problem instead of a simple configuration issue?

A: Because drift changes the approved operating boundary without necessarily breaking the system. A prompt update, tool expansion, or permission increase can alter behaviour while leaving the service running, which means the programme may still look healthy even as it departs from policy. Governance has to detect and respond to that live deviation.

Q: What should teams do when an AI system acts outside its approved bounds?

A: They need a selective disengage path that can stop the system or the specific action stream without waiting for a manual shutdown. The important part is containment before more damage occurs, while also preserving enough evidence to explain what happened and who approved the response.

Q: What is the relationship between audit readiness and blast radius in AI governance?

A: Audit readiness tells you whether you can prove what happened, while blast radius controls how much harm occurs before you can intervene. A programme that can only reconstruct events later is not resilient enough, and a programme that cannot bound damage while it investigates is still exposed even if the logs are perfect.

Technical breakdown

Why runtime evidence is different from attestation

Attestation says a control exists. Runtime evidence shows that the control actually operated while the system was executing. In agentic workflows, that difference matters because prompts, tools, permissions, and outputs change in motion, not just at release time. If you wait until quarterly review or annual audit, you are reconstructing history from logs that may not have captured the control point you need. Runtime evidence is therefore an operational property of the system, not a document about the system. It has to capture what was decided, what was accessed, what was invoked, and what changed while the workflow was live. See the Audit Evidence and Continuous Controls Monitoring Guide.

Practical implication: Design evidence collection to observe live control operation, not to reconstruct it after a review cycle.

How drift turns approved AI design into an unauditable state

Drift is any material change between the approved design and what the system is doing in production. In this context, drift includes prompt changes, tool additions, widened permissions, and model swaps that happen without a corresponding governance event. The technical problem is that an AI system can remain operational while moving outside its approved boundary, so the control plane must compare live behaviour to the design of record. When drift is detected, the system should notify the right people and support enforced action, otherwise the audit trail only shows that deviation occurred, not that it was governed.

Practical implication: Monitor live behaviour against the approved baseline and treat unreviewed changes as governance events, not mere configuration noise.

What a true stop or disengage control must do

A stop control is not the same as a pause button in a dashboard. It must let a governed party supersede, disengage, or deactivate an AI system that is acting outside intended use, and it must do so selectively enough to limit damage while preserving the rest of the environment. The article also makes the key limitation clear: stopping a system is reversible, but actions already taken are not. That is why runtime control has to combine interruption capability with blast-radius reduction through scoped permissions and short-lived credentials. The architectural goal is containment, not reversal.

Practical implication: Build selective disengage controls alongside constrained credentials so an unsafe run can be stopped before further harm accumulates.

NHI Mgmt Group analysis

Audit-readiness is now a runtime property, not a documentation exercise. The article’s central argument is that a control is only meaningful when it can be shown operating while the system is live. That shifts AI governance from periodic attestation to continuous proof, which is a materially different operating model for identity, access, and oversight. The practitioner conclusion is straightforward: if evidence is not captured at runtime, the programme does not yet have evidence.

Drift is the governance failure mode that matters most. The problem is not only that a model changes, but that prompts, tools, and permissions can shift without a formal deployment event. That breaks the assumption that approved design remains stable until the next review. The implication is that governance has to watch for live deviation, not just pre-release approval, because the control boundary moves under the programme’s feet.

Blast-radius control is the decisive companion control to stop capability. The article is right to separate interruption from impact limitation, because stopping an agent cannot undo actions already taken. That means the real governance question is how much damage a single bad run can do before it is halted. The named concept here is runtime evidence gap: the space between what the programme can say in policy and what it can prove in operation. The practitioner conclusion is to govern at execution time, not after the fact.

AI auditability is converging with identity governance expectations. The standards cited in the article all assume that someone can intervene, attribute, and verify outcomes in production. That is the same logic IAM and IGA already apply to privileged activity, only now it is extended to AI-driven decisions and actions. The implication for practitioners is that AI oversight, access control, and operational evidence need to be designed as one control system, not separate disciplines.

Read next: Audit Evidence and Continuous Controls Monitoring Guide

What this signals

Runtime evidence gap: Organisations will need to treat evidence capture as a live control, because post hoc reconstruction cannot prove whether an agent stayed inside its approved boundary. That pushes AI governance closer to identity operations, where attribution and action tracing matter at the moment of execution, not after review.

Audit programmes that rely on periodic attestation will struggle as AI workflows become more dynamic. The practical shift is toward continuous control monitoring, selective interruption, and evidence lineage that can survive both drift and rapid remediation.

For practitioners

• Instrument runtime decision capture Record what the agent decided, what data it accessed, what tools it invoked, and what changed while the workflow was active.
• Compare live behaviour to the approved design Treat prompt changes, tool additions, permission widening, and model swaps as drift events that require automatic detection and review.
• Implement selective disengage controls Provide a way to stop or deactivate an unsafe system without shutting down unrelated services, and preserve the evidence needed for review.
• Reduce blast radius with scoped credentials Limit what a misbehaving workflow can do by constraining permissions and using short-lived credentials for sensitive actions.

Key takeaways

• AI governance fails when teams confuse attestation with proof of control operation, because runtime behaviour is what auditors and operators actually need to see.
• The article frames drift, selective interruption, and live logging as the three controls that determine whether an AI programme can be verified in production.
• Practitioners should treat evidence capture as part of the control plane, not as an after-the-fact reporting task.

Related NHI Mgmt Group resources: Audit Evidence and Continuous Controls Monitoring Guide · Compliance Automation Guide · Ultimate Guide to NHIs: Regulatory and Audit Perspectives

Key terms

• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
• Drift: Any difference between the intended configuration recorded in code and the actual state running in the environment. Drift becomes risky when it accumulates unnoticed, because the live system no longer matches the controls or assumptions used to approve it.
• Selective disengage: The ability to stop an AI system, or a specific action stream, without unnecessarily shutting down the wider environment. It is a containment control, not a reversal mechanism, because it limits further harm while preserving the evidence needed to understand what already happened.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.