Before-and-after delta

A before-and-after delta records the state of a model interaction before inference and immediately after it completes. In practice, it captures inputs, policy context, outputs, and decision outcomes so reviewers can verify the full path from request to result and detect tampering or missing context.

Expanded Definition

A before-and-after delta is an evidence trail for a single model interaction, showing what was known, requested, authorised, and produced at the moment before inference and immediately after completion. For AI security and identity governance, the value is not just in recording the prompt and response, but in preserving the policy context, tool permissions, model version, and decision outcome that shaped the result. That makes the delta useful for review, incident response, and control validation when behaviour needs to be reconstructed accurately.

The concept is closely related to audit logging, but it is more specific than a generic log entry because it compares two states at a transaction boundary. In practice, organisations use it to verify whether context was stripped, whether a tool call was altered, or whether a response was generated outside expected guardrails. The idea aligns well with the accountability focus reflected in the NIST Cybersecurity Framework 2.0, especially where traceability and governance are required across automated workflows.

The most common misapplication is treating a before-and-after delta as a simple prompt transcript, which occurs when teams record only user input and model output while omitting policy state, identity context, and tool execution details.

Examples and Use Cases

Implementing before-and-after deltas rigorously often introduces storage and correlation overhead, requiring organisations to weigh stronger forensic visibility against the cost of capturing and protecting more execution context.

• Recording a customer support agentic workflow where the pre-inference state includes user identity, ticket classification, and allowed tools, while the post-inference state shows the drafted response and any escalation decision.
• Capturing a code-generation request where the delta preserves the policy checks, retrieved context, and final code suggestion so reviewers can confirm whether restricted libraries or unsafe patterns were introduced.
• Logging an identity verification workflow where the pre-state includes assurance level, risk signals, and session context, and the post-state shows whether the request was approved, stepped up, or denied.
• Monitoring a retrieval-augmented generation flow where the delta reveals which documents were available before inference and which citations or answers were produced after retrieval, supporting review of OWASP guidance for LLM applications.
• Documenting an automated admin action where the delta shows the exact authorisation state before the agent acted and the resulting change after execution, helping detect privilege drift or unauthorised tool use.

These examples are most useful when the delta is linked to a stable request ID, a consistent identity source, and immutable storage. Without that linkage, reviewers may know that something happened, but not whether the model behaved within the boundaries that were in force at the time.

Why It Matters for Security Teams

Security teams need before-and-after deltas because AI-driven systems fail in ways that are hard to reconstruct after the fact. Missing context can hide prompt injection, policy bypass, stale permissions, or tool misuse. In agentic AI environments, that is especially important because the system may have had execution authority, not just a passive chat interface. A usable delta helps prove whether the model acted within approved boundaries, whether the right identity was bound to the session, and whether the decision path can withstand review.

This matters operationally for incident response, model governance, and access control verification. Teams that cannot compare pre- and post-inference state often struggle to explain why an agent approved a request, exposed data, or triggered an action. The control value is strongest when the delta is treated as evidence, not commentary, and when it is retained with the surrounding policy and identity metadata. Guidance in the NIST Cybersecurity Framework 2.0 reinforces the need for traceability and accountability across security operations, while identity and NHI programmes rely on that traceability to connect actions back to the authority that enabled them.

Organisations typically encounter the forensic gap only after an agent has made an unexpected decision or changed a system state, at which point the before-and-after delta becomes operationally unavoidable to reconstruct what really happened.

Related resources from NHI Mgmt Group

• Should organisations enforce least privilege for AI agents before or after deployment?
• Should organisations evaluate AI agent security tools before or after identity controls are in place?
• What breaks when fraud controls sit after authentication instead of before it?
• Should organisations block exploit behaviour before or after incident response?