Join our Newsletter — 33% off our NHI Course

Interaction evidence

The record of what an AI system received, decided, and did, including prompts, responses, tool calls, and the approving identity. It is the governance artifact that supports audit, incident reconstruction, and exception handling when AI actions affect business operations.

What interaction evidence captures

Interaction evidence is the operational record of an AI system’s activity, showing what it received, how it responded, what tools it invoked, and who approved the action. It turns opaque model behaviour into something reviewable, testable, and explainable after the fact.

That distinction matters because the evidence is not just a transcript. It is the basis for reconstructing decisions, proving oversight, and separating intended automation from unintended behaviour when an AI system touches real business processes.

Why interaction evidence matters for governance

Governance teams rely on interaction evidence to answer basic questions: what happened, under whose authority, and whether the action aligned with policy. Without that record, it becomes difficult to prove that the system followed an approved path or that a human approved a sensitive step.

Good interaction evidence also supports accountability. When an AI assistant, workflow agent, or other automated system influences an outcome, the record should make it possible to trace the sequence of prompts, tool calls, outputs, and approvals that led there.

For practitioners, the important point is that interaction evidence must be complete enough to be meaningful. Partial logs, missing approvals, or records that omit the tool context can leave a governance gap even when the system appears observable on paper.

What belongs in the record

A useful interaction record usually includes the inputs the system saw, the outputs it produced, the external actions it attempted, and the decision points where approval or exception handling occurred. That combination helps preserve both the content of the interaction and the control context around it.

The approving identity is especially important because approval without attribution is weak evidence. A record that cannot show who authorised a step, and when, cannot reliably support audit, incident review, or dispute handling.

In mature environments, the record should also preserve enough surrounding context to explain why an action was taken, not only that it was taken. That often means capturing the relevant tool invocation, the request that triggered it, and any policy-relevant state at the moment of execution.

How interaction evidence supports review and response

Interaction evidence makes post-incident reconstruction possible. If an AI-driven process returns an incorrect answer, calls the wrong tool, or takes an unexpected action, the record helps investigators rebuild the chain of events and separate model output from downstream system effects.

It is also useful during exception handling. When teams override a normal control path, the evidence should show what was approved, what was bypassed, and why the exception was allowed so the organisation can review whether the decision was justified.

At the boundary between automation and oversight, interaction evidence becomes a control surface in its own right. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point because auditability, access control, and accountability are all relevant when a system can act and a person can approve.

Risk and Threat Considerations

Interaction evidence is valuable precisely because it can be incomplete, altered, or poorly scoped. If logs omit prompts, tool calls, approvals, or timestamps, an organisation may lose the ability to reconstruct an incident or prove that an AI-driven action was authorised.

Failure mechanism: Missing or tampered records break the chain of custody around an AI action, which can hide misuse, obscure root cause, or make an exception look routine when it was not.

Impact: The result can be weak auditability, slower incident response, disputed accountability, and greater exposure when AI actions influence operational or business decisions.

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 and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AU-2 — Event Logging Interaction evidence depends on recording AI actions and approvals.
AU-6 — Audit Review, Analysis, and Reporting The evidence must support review and reconstruction after AI-driven actions.
AC-6 — Least Privilege Approvals and tool use in the record show whether AI actions stayed within granted authority.
Recommendation — Log AI prompts, tool calls, outputs, and approvals as auditable events. Review interaction evidence for anomalous actions, missing approvals, and policy exceptions. Limit AI tool permissions so interaction evidence reflects minimal necessary authority.
NIST CSF 2.0 DE.CM-03 — Anomalies and Events are Analyzed Interaction evidence enables analysis of AI action sequences and exceptions.
Recommendation — Analyze interaction records to detect unexpected AI behaviour and control failures.
OWASP Agentic AI Top 10 ASI03 — Identity & Privilege Abuse The approving identity and tool-authority trail are central to interaction evidence.
Recommendation — Trace who approved each agent action and verify the agent stayed within delegated authority.

Practitioner Guidance

Why practitioners should care: Interaction evidence should be treated as a control artifact, not a convenience feature. If the record cannot support audit and reconstruction, the surrounding AI workflow is harder to govern and harder to defend after something goes wrong.

Common misunderstanding: Teams sometimes assume that application logs or model logs are enough. For this term, the record needs to preserve the decision context, the action context, and the approving identity, not just the model output.

Practitioner takeaway: Define the evidence record around the decisions that matter, then verify that it captures enough detail to explain both normal operation and exceptions.