AI Account Recovery Evidence Checklist
KairoNull · Published and reviewed 14 October 2026
AI-assisted account recovery can involve an identity check, a recommendation, a human review and a reset in separate systems. To explain one outcome, those records need to connect to the same recovery attempt. This checklist helps identity, security and risk teams assess that connection.
It is an evidence review method. It does not certify an identity control, replace fraud prevention or establish that a workflow meets a particular legal requirement.
Define the recovery attempt
Select one historical attempt with the workflow owner. Establish the time window, the relevant account reference and a correlation identifier across the systems involved. Use pseudonymous references where possible. If systems use different identifiers, document how you map them and how confident that mapping is.
Review the record at each stage
- Recovery request: can you identify the request and its origin using records your organisation is authorised to hold?
- Identity-check result: is the result available, including the relevant check version and time? Avoid copying raw identity documents into an evidence bundle unless necessary and authorised.
- AI recommendation: can you establish which recommendation was released and the available model and configuration identifiers?
- Policy evaluation: can you connect the policy version and check result to that attempt?
- Approval or exception: does the reviewer or automated authority have an identifiable decision, time and scope?
- Reset execution: can you connect the authorisation to the action that actually ran, including retries and failures?
- Outcome: do records show completion, denial, reversal or escalation? Keep an inference separate from an observed result.
Questions to ask before calling the workflow provable
- Do the request, recommendation, approval and reset refer to the same attempt?
- Are timestamps comparable, or are there clock and timezone uncertainties?
- Can a reviewer identify an override without relying on someone's memory?
- Are missing records distinguishable from records the system was never designed to collect?
- Can an independent reviewer inspect the permitted export and available integrity material?
Record the conclusion and its limits
Classify each finding as PROVEN, PARTIALLY PROVABLE, NOT CURRENTLY PROVABLE or UNKNOWN. A successful password reset is evidence of an outcome, not proof that all preceding controls operated. An unavailable approval record is an evidence gap, not automatic proof of an unauthorised reset.
For each gap, name the missing artifact, its expected source and the owner who can investigate it. Separate a process change, such as requiring an approval, from an instrumentation change, such as recording and linking the approval already required.
Synthetic walkthrough: can we explain this recovery?
Illustrative deployment scenario. The following records, identifiers, policy and timestamps are invented. This is not a customer result, a production export or an executed product/verifier demonstration. No customer artifacts were used.
A customer reports losing access after a recovery. Select fictional attempt SYN-REC-0042. The review question is whether the recorded recommendation, approval and executed email change refer to the same authorised action. The report alone does not establish an account takeover.
In this example, fictional policy RECOVERY-7/v3 calls for a second factor and human approval after a recent device change. The policy document is supplied; its deployment history is not.
| Time | Supplied artifact | Boundary of the finding |
|---|---|---|
| 10:02:11 | Request with recent-device-change flag | Does not establish the requester's real identity. |
| 10:02:13 | AI response recommends manual review | No released-response receipt is supplied. |
| 10:02:14 | Check names RECOVERY-7/v3 and returns REQUIRE_APPROVAL | No record establishes which policy version was deployed. |
| 10:03:06 | Operator note says approval occurred | It is not bound to the exact request, response and authorised action. |
| 10:03:08 | Identity-service event records an email change with the same correlation ID | Recorded execution does not establish legitimate approval or second-factor completion. |
| 10:08:40 | Notification provider accepts a request | Acceptance does not establish inbox delivery or readership. |
Classify the supplied evidence
- PROVEN within the fictional bundle: the request, recommendation, check and execution records share a correlation ID. This is a statement about the supplied records, not independent proof that events happened as described.
- PARTIALLY PROVABLE: an approval is asserted and a policy is named, but their scope and effective deployment are not established.
- NOT CURRENTLY PROVABLE: second-factor completion and approval of the exact executed action cannot be demonstrated from this bundle.
- UNKNOWN: the requester's identity, whether omitted evidence exists elsewhere, and whether the change caused the reported loss of access.
A missing approval record is an evidence gap. It does not prove that approval never happened. Keep those conclusions separate when briefing the incident owner.
Ask for the next useful artifacts
Ask the workflow owner for the deployed-policy history, released-response identifier, second-factor outcome and approval record linked to the executed action. Preserve originals. Label any later reconstruction with its actual creation date and sources.
Separate process remediation, such as defining who may approve an exception, from instrumentation, such as recording the scope and linking an approval already required. Check that the resulting records arrive and can be joined before declaring the gap closed.
State the integrity limit
No signed manifest, trusted anchor or verified timestamp is supplied in this fictional bundle. A digest matching an untrusted manifest would establish only internal consistency. A coordinated rewrite of both can remain consistent. Independently retained references can strengthen comparison when actually implemented and verified, but do not prove that an approval was legitimate.
The practical outcome is a bounded missing-artifacts list, an owner for each follow-up and a clear statement of what remains unknown. It is not a compliance certificate or proof of a successful customer deployment.
Keep the review proportionate
Agree access, retention, redaction and sharing arrangements before transferring customer records. Do not email identity documents or credentials as an initial enquiry. A synthetic example is often sufficient for the first conversation.
Use the incident reconstruction guide to structure a timeline. The synthetic sample report illustrates an evidence-oriented output, and the methodology explains integrity limits.
Review one workflow with KairoNull
The AI Evidence Readiness Assessment reviews one to three workflows and attempts to reconstruct one selected historical decision for the engagement. Findings depend on the material supplied. The output helps teams decide which process changes and evidence instrumentation to prioritise before a scoped pilot.
Explore the assessment or discuss an account-recovery workflow.