What is the difference between compliance paperwork and runtime evidence for agent governance?

Compliance paperwork describes how the organisation intends to govern the system. Runtime evidence shows what the system actually did, on whose authority and with what effect. In agent governance, the second is the one auditors and regulators can test. If the runtime does not emit that evidence, paperwork cannot reconstruct it later.

Paperwork shows intent, runtime evidence shows execution

Compliance paperwork is a governance artefact. It can describe policy, approvals, review cadence, and the control design the organisation says it follows, but it does not prove that an agent actually obeyed those rules in a live run. Runtime evidence is the operational record of action, decision, identity, and effect, which is what you need when a reviewer asks what really happened.

For agent governance, that difference matters because an agent can be documented as constrained while still behaving outside the intended boundary under real workload, prompt, tool, or delegation conditions. A paper trail can support an audit narrative, but it cannot reconstruct missing execution detail after the fact unless the system emitted those records at runtime.

What runtime evidence must actually prove

Useful runtime evidence is specific enough to answer who or what acted, under what authority, against which resource, at what time, and with what outcome. That usually means event logs, decision traces, policy evaluations, tool calls, approvals, denial events, and correlation data that ties the agent’s action to a user, service, or delegated context.

In practice, the question is not whether the organisation has a governance document. The question is whether the system can show that an action was authorised, bounded, and attributable when the action occurred. If the evidence only exists in design docs or post-incident summaries, it is weak for assurance because it cannot demonstrate the actual runtime state.

Why this difference changes auditability and control design

Audit and regulatory review increasingly depends on observable behaviour, not just declared process. For that reason, the control design should make runtime records a first-class output of the agent, not an afterthought bolted on by the compliance team. The most defensible posture is one where governance statements, policy enforcement, and logs all describe the same real behaviour.

That is also why governance for autonomous systems needs to be instrumented, not merely documented. When approval, delegation, or policy checks happen outside the execution path, you create a gap between the paper model and the live system. A mature control environment closes that gap by making the runtime record the source of truth for what the agent was allowed to do and what it actually did.

Risk and Threat Considerations

When organisations rely on paperwork instead of runtime evidence, they create an assurance gap that can hide overreach, policy bypass, or unauthorised action. In agent environments, that gap is especially important because authority can be delegated, reused, or chained across tools and sessions, which makes after-the-fact reconstruction difficult.

Failure mechanism: The control is described in policy, but the system does not emit sufficient action logs, decision records, or attribution data at execution time, so a later reviewer cannot verify whether the agent stayed within its authority.

Impact: Issues that should have been detected as execution failures may look compliant on paper, which weakens audit credibility, slows incident investigation, and can leave material misuse or privilege drift undiscovered until damage is done.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent governance hinges on proving delegated authority and bounded action.
Recommendation — Enforce per-action authorization and record the policy decision for each agent action.
NIST SP 800-53 Rev 5	AU-2 — Event Logging	Runtime evidence depends on capturing the events that show what the agent did.
	AU-6 — Audit Record Review, Analysis, and Reporting	Auditors need reviewable records that support verification of actual behaviour.
Recommendation — Log agent decisions, tool calls, approvals, and outcomes at the point of execution. Review logs for unauthorized actions, policy bypass, and missing attribution.
ISO/IEC 27001:2022	A.5.28 — Collection of evidence	Compliance and investigation require evidence that preserves what actually occurred.
Recommendation — Preserve runtime records that can substantiate governance and incident findings.
CSA Cloud Controls Matrix	LOG — Logging and Monitoring	Agent governance needs operational logs, not just policy documents.
Recommendation — Implement logging that ties each agent action to authority, identity, and outcome.

Practitioner Guidance

What to verify: Confirm that runtime records can answer the full chain of accountability, including the principal, delegated authority, policy decision, tool invocation, target resource, and result. If any one of those elements is missing, the evidence is usually too thin for serious governance review.

What good looks like: A reviewer should be able to reconcile policy intent, approval state, and observed execution from the same evidence set without relying on manual explanation. The strongest signals are tamper-resistant logs, clear correlation IDs, and records that capture denied as well as permitted actions.

Practitioner takeaway: Treat compliance paperwork as the promise and runtime evidence as the proof; if the proof is missing, the control has not really been demonstrated.