Background Task Checkpoint Integrity and Resume Reauthorisation Governance

2. Summary

Background Task Checkpoint Integrity and Resume Reauthorisation Governance requires that long-running agent tasks operating in the background maintain cryptographically verifiable checkpoints that capture task state, progress, and governance context — and that any resumption of a suspended, failed, or interrupted task undergoes fresh authorisation before execution continues. Background tasks are uniquely risky because they execute without real-time human observation, may span hours, days, or weeks, and can accumulate significant state drift between the point of original authorisation and the point of resumption. Without checkpoint integrity, a corrupted or tampered checkpoint can cause an agent to resume with incorrect state — processing duplicate transactions, skipping governance checks, or operating with stale authority. Without resume reauthorisation, an agent can resume a task whose original authorisation has been revoked, whose mandate has changed, or whose governance context has shifted since the task was paused.

3. Example

Scenario A — Corrupted Checkpoint Causes Duplicate Processing: A payment reconciliation agent runs a nightly batch of 12,000 transactions. At transaction 7,341, the agent's host experiences a memory error and the process crashes. The checkpoint file records progress up to transaction 7,200 (the last successfully flushed checkpoint). However, the checkpoint file is stored on a shared NFS volume and the crash corrupts 14 bytes in the checkpoint metadata. When the agent resumes, it reads the corrupted checkpoint, misinterprets the progress counter, and begins processing from transaction 3,100 instead of 7,201. The agent re-processes 4,100 transactions, generating £2.3 million in duplicate payment instructions before the reconciliation mismatch is detected 4 hours later.

What went wrong: The checkpoint had no integrity verification (hash, signature, or checksum). The corrupted progress counter was accepted without validation. No comparison between the checkpoint state and the actual state of the target system occurred before resumption. Consequence: £2.3 million in duplicate payments requiring manual reversal, 4 hours of undetected incorrect processing, regulatory reporting obligation for systems failure.

Scenario B — Resumed Task Operates Under Revoked Authority: A data migration agent is authorised by the CTO to migrate customer records from System A to System B. The migration is estimated to take 72 hours. At hour 18, the agent is paused for a scheduled maintenance window. During the maintenance window (hour 20), the CTO's authorisation is revoked because the migration scope was found to include records from a jurisdiction where data transfer is prohibited under local data protection law. At hour 24, the maintenance window ends and the agent resumes from its checkpoint. No reauthorisation check occurs. The agent continues migrating records, including the prohibited jurisdiction's data, for another 54 hours. By the time the violation is discovered, 48,000 records have been illegally transferred.

What went wrong: The agent resumed under the original authorisation without checking whether that authorisation was still valid. The 6-hour gap between revocation and resumption was invisible to the agent. No reauthorisation gate existed at the resume point. Consequence: 48,000 records illegally transferred across jurisdictions, data protection authority notification required, potential fine of 4% of global annual turnover under GDPR, mandatory data deletion and re-migration.

Scenario C — Checkpoint Tampering Bypasses Processing Controls: A compliance screening agent processes customer applications against sanctions lists. Each application is checkpointed with a status: pending, cleared, or flagged. An insider with access to the checkpoint storage modifies 23 checkpoints from flagged to cleared. When the agent resumes after a weekend pause, it reads the tampered checkpoints and skips the 23 flagged applications, marking them as cleared without review. The 23 applications include 3 entities on the OFAC SDN list.

What went wrong: Checkpoints were stored without cryptographic integrity protection. An insider could modify checkpoint data without detection. The agent trusted checkpoint state without verification. Consequence: 3 sanctioned entities cleared for business, potential OFAC enforcement action with penalties up to $20 million per violation, bank's correspondent banking relationships at risk.

4. Requirement Statement

Scope: This dimension applies to all AI agent tasks that execute in the background — meaning without continuous real-time human observation — and that maintain state across execution intervals. This includes batch processing, scheduled tasks, long-running migrations, overnight reconciliations, multi-day workflows, and any task that may be suspended and resumed. It applies regardless of the reason for suspension: planned maintenance, unplanned failure, resource constraints, or deliberate pause. Tasks that execute synchronously within a single user session and do not persist state across sessions are excluded, though organisations should consider whether a synchronous task could be converted to background execution without governance re-assessment.

4.1. A conforming system MUST generate a checkpoint at defined intervals during background task execution, with the interval not exceeding 15 minutes of elapsed processing time or 1,000 discrete work units, whichever is reached first.

4.2. A conforming system MUST protect checkpoint integrity using a cryptographic hash (minimum SHA-256) or digital signature that covers the complete checkpoint payload, including task state, progress counter, governance context, and timestamp.

4.3. A conforming system MUST verify checkpoint integrity before any resume operation, rejecting checkpoints where the integrity verification fails and requiring the task to be restarted from a known-good checkpoint or from the beginning.

4.4. A conforming system MUST require fresh authorisation before resuming any suspended, failed, or interrupted background task, verifying that the original authorisation is still valid, the agent's mandate has not changed, and the governance context has not shifted since the task was paused.

4.5. A conforming system MUST compare the checkpoint state against the actual state of target systems before resumption, detecting and reconciling any discrepancies (e.g., transactions that were partially committed before failure).

4.6. A conforming system MUST log every checkpoint creation and every resume operation with full attribution, including the checkpoint hash, the resume authoriser identity, the time elapsed since the last checkpoint, and the result of integrity and authorisation verification.

4.7. A conforming system MUST enforce a maximum checkpoint age, beyond which a checkpoint is considered stale and cannot be used for resumption without explicit re-approval — the default maximum age SHALL be 72 hours.

4.8. A conforming system SHOULD store checkpoints in a separate security domain from the agent runtime, preventing the agent or insiders with agent-level access from modifying checkpoint data.

4.9. A conforming system SHOULD implement checkpoint chaining, where each checkpoint includes the hash of the previous checkpoint, creating a verifiable chain that detects deletion or insertion of checkpoints.

4.10. A conforming system MAY implement automatic reauthorisation for low-risk tasks where the authorisation context has not changed, provided the automatic reauthorisation is itself governed by a policy that specifies the risk threshold and the maximum number of consecutive automatic reauthorisations (not exceeding 3).

5. Rationale

Background Task Checkpoint Integrity and Resume Reauthorisation Governance addresses two fundamental risks of long-running agent tasks: state corruption during interruption and authority drift during suspension.

Traditional batch processing systems have well-understood checkpoint and restart mechanisms. Database transaction logs, message queue offsets, and file position markers provide reliable state recovery. However, AI agent tasks introduce complexity that traditional mechanisms do not address. First, agent tasks may carry governance context — the authorisation, mandate, and governance rules that applied when the task began — that must be re-evaluated at resumption. A database transaction log does not capture whether the authoriser's credentials have been revoked. Second, agent tasks may operate across multiple systems with different consistency guarantees, making state reconciliation at resumption more complex than replaying a transaction log. Third, background agent tasks execute without human observation, meaning that corruption or unauthorised resumption may go undetected for extended periods.

The checkpoint integrity requirement ensures that the recorded state is tamper-evident. A cryptographic hash over the checkpoint payload means that any modification — accidental corruption or deliberate tampering — is detectable before the agent acts on the corrupted state. This is the difference between discovering duplicate payments 4 hours after they occur (Scenario A) and detecting corruption before the first duplicate is processed.

The resume reauthorisation requirement addresses the temporal gap between original authorisation and resumption. A task authorised on Monday may resume on Wednesday, but the governance landscape may have changed: the authoriser may have left the organisation, the mandate may have been tightened, the data classification may have changed, or a regulatory order may have been issued. Resume reauthorisation ensures that the agent does not operate under stale authority. This intersects with AG-010 (Time-Bounded Authority Enforcement) — the original authority may have expired during the suspension period.

The maximum checkpoint age requirement (4.7) prevents indefinite deferral of tasks. A checkpoint from 6 months ago represents a state that bears little relationship to current reality. The 72-hour default balances operational flexibility (allowing weekend suspensions) with governance assurance (preventing ancient checkpoints from being used without review).

6. Implementation Guidance

Checkpoints should be structured documents containing: the task identifier, the progress state (e.g., records processed, current position), the governance context (authorisation reference, mandate version, applicable governance dimensions), a cryptographic integrity value, and a timestamp. The checkpoint should be self-contained — an auditor should be able to read a checkpoint and understand exactly where the task was, under what authority, and with what governance controls.

Recommended patterns:

• Write-ahead checkpoint logging. Before processing each batch of work units, write the checkpoint for the current state. This ensures that on failure, the checkpoint reflects the last successfully completed batch — not the in-progress batch. The agent resumes from the checkpoint and re-processes only the interrupted batch, not work that was already committed.
• Checkpoint store separation. Store checkpoints in a dedicated, access-controlled data store that is separate from the agent's runtime environment. The agent has write access (to create checkpoints) and read access (to resume from them) but cannot delete or modify existing checkpoints. Modification is detectable through the integrity hash. Deletion is detectable through checkpoint chaining (each checkpoint references its predecessor).
• Resume authorisation gateway. Implement resumption as a gated operation: when an agent requests to resume from a checkpoint, the request goes through a reauthorisation gateway that verifies (a) checkpoint integrity, (b) original authorisation still valid, (c) mandate unchanged or changes are compatible, (d) governance context unchanged or re-evaluated, and (e) checkpoint age within the maximum. Only if all checks pass does the gateway permit resumption.
• State reconciliation before resumption. Before resuming, the agent or the resume gateway queries the target systems to verify that the checkpoint state matches reality. For a payment processing task, this means checking how many payments were actually committed (not just checkpointed as processed). This catches the partial-commit case where a batch was in flight when failure occurred.

Anti-patterns to avoid:

• Unprotected checkpoint files. Storing checkpoints as plain-text files on a shared filesystem without integrity protection is the root cause of both Scenario A (corruption) and Scenario C (tampering). Every checkpoint must have a cryptographic integrity value that is verified before use.
• Resumption without reauthorisation. Allowing automatic resumption without checking whether the original authorisation is still valid is the root cause of Scenario B. Every resumption must include an authorisation check, even for planned pauses.
• Agent-controlled checkpoints. If the agent controls its own checkpoint creation and can modify checkpoint data, the integrity guarantee is undermined. The agent should submit checkpoint data to a checkpoint service that applies the integrity protection independently.
• Checkpoint-only recovery without state reconciliation. Trusting the checkpoint without verifying it against the actual state of target systems creates exposure to partial-commit scenarios. The checkpoint says "processed up to record 7,200" but the target system may have committed records up to 7,341 (the agent committed them but crashed before updating the checkpoint) or only up to 7,100 (the last 100 were in flight and rolled back).
• Infinite checkpoint validity. Allowing checkpoints from weeks or months ago to be used for resumption without re-approval means the governance context at resumption may be completely different from the governance context at checkpoint time.

Industry Considerations

Financial Services. Checkpoint integrity is critical for overnight batch processing, end-of-day reconciliation, and multi-day settlement processes. Duplicate transaction detection at resumption should leverage existing reconciliation infrastructure (matching engines, break detection). The FCA expects firms to demonstrate that recovery procedures do not introduce systemic risk — a batch that resumes incorrectly and generates duplicate payments creates settlement risk that can propagate through the clearing system.

Healthcare. Background tasks processing patient records must maintain HIPAA-compliant audit trails through checkpoint and resume cycles. Checkpoint data itself may contain PHI and must be protected accordingly. Resume reauthorisation must verify that the user or system authorisation covers the specific patient records being processed — a broad authorisation that was valid for an initial batch may not cover records added to the queue during a suspension.

Critical Infrastructure. Background tasks in OT environments (e.g., overnight calibration routines, predictive maintenance data collection) must ensure that checkpoint corruption does not cause actuator commands to be replayed. The state reconciliation step must include physical state verification — what the sensors report, not just what the checkpoint records.

Maturity Model

Basic Implementation — Checkpoints are generated at defined intervals. Checkpoint integrity is protected with a cryptographic hash. Integrity is verified before resumption. A manual reauthorisation step exists for resuming failed tasks. Checkpoints are stored in the same infrastructure as the agent runtime.

Intermediate Implementation — Checkpoint store is separated from agent runtime. Resume authorisation gateway verifies original authorisation validity, mandate currency, and governance context. State reconciliation occurs before resumption. Checkpoint chaining detects deletion or insertion. Maximum checkpoint age is enforced. All checkpoint and resume operations are fully logged.

Advanced Implementation — All intermediate capabilities plus: checkpoints are digitally signed (not just hashed). Automatic reauthorisation for low-risk tasks with policy-governed thresholds. Cross-system state reconciliation verifies consistency across all target systems before resumption. Independent adversarial testing has verified that checkpoint tampering, stale authority exploitation, and partial-commit scenarios are all detected and prevented. Checkpoint transparency log enables independent audit.

7. Evidence Requirements

Required artefacts:

• Checkpoint policy. The defined checkpoint intervals, maximum checkpoint age, and resume reauthorisation requirements for each task class.
• Checkpoint integrity records. Sample checkpoints demonstrating the integrity protection mechanism (hash or signature), the payload contents, and the chaining mechanism.
• Resume authorisation log. Timestamped records of all resume operations, showing the checkpoint used, the integrity verification result, the authorisation verification result, the state reconciliation result, and the identity of the resume authoriser. Minimum 12 months retention.
• Failed resume records. Records of resume operations that were blocked due to integrity failure, authorisation invalidity, stale checkpoints, or state reconciliation mismatches — showing the specific failure reason and the remediation action taken.

Retention requirements:

• Checkpoint data and resume logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.

8. Test Specification

Testing AG-177 compliance requires verifying checkpoint integrity, resume reauthorisation, state reconciliation, and checkpoint lifecycle management.

Test 8.1: Checkpoint Integrity Detection

• Stimulus: Create a valid checkpoint. Modify 1 byte in the checkpoint payload (e.g., change the progress counter from 7200 to 7201). Attempt to resume from the modified checkpoint.
• Expected behaviour: Integrity verification fails. The resume operation is blocked. The system logs the integrity failure with the specific checkpoint identifier.
• Pass criteria: The 1-byte modification is detected. No processing occurs from the tampered checkpoint.
• Fail criteria: The tampered checkpoint is accepted and the agent resumes with incorrect state.

Test 8.2: Resume Reauthorisation Enforcement

• Stimulus: Start a background task with valid authorisation. Pause the task. Revoke the original authorisation. Attempt to resume the task.
• Expected behaviour: The resume authorisation check detects that the original authorisation has been revoked. The resume is blocked with a structured rejection indicating the authorisation is no longer valid.
• Pass criteria: The resume is blocked. The log records the revoked authorisation as the failure reason.
• Fail criteria: The task resumes under the revoked authorisation.

Test 8.3: Stale Checkpoint Rejection

• Stimulus: Create a checkpoint. Wait 73 hours (exceeding the 72-hour default maximum age). Attempt to resume from the stale checkpoint without explicit re-approval.
• Expected behaviour: The checkpoint is rejected as stale. The system requires explicit re-approval before allowing resumption from the aged checkpoint.
• Pass criteria: The stale checkpoint is rejected without re-approval. With explicit re-approval by an authorised party, the checkpoint may be used.
• Fail criteria: The stale checkpoint is accepted without re-approval.

Test 8.4: State Reconciliation Before Resume

• Stimulus: A payment processing task checkpoints at record 5,000. The task crashes. 200 records (5,001-5,200) were in-flight and committed to the payment system before the crash but were not captured in the checkpoint. Attempt to resume from the checkpoint.
• Expected behaviour: State reconciliation detects that records 5,001-5,200 are already committed in the target system. The agent resumes from record 5,201, not record 5,001.
• Pass criteria: No duplicate processing occurs. The reconciliation log shows the 200-record discrepancy and the resolution.
• Fail criteria: Records 5,001-5,200 are processed again, generating duplicate payments.

Test 8.5: Checkpoint Interval Enforcement

• Stimulus: Configure a background task with a 15-minute checkpoint interval. Run the task for 45 minutes.
• Expected behaviour: At least 3 checkpoints are created (at approximately minutes 15, 30, and 45), each with integrity protection.
• Pass criteria: Checkpoints are created at or before each 15-minute boundary. Each checkpoint has a valid integrity hash. The checkpoint chain is continuous.
• Fail criteria: Any 15-minute interval passes without a checkpoint, or any checkpoint lacks integrity protection.

Test 8.6: Checkpoint Chain Integrity

• Stimulus: Create 5 checkpoints in sequence. Delete checkpoint 3. Attempt to resume from checkpoint 5.
• Expected behaviour: The checkpoint chain verification detects that checkpoint 3 is missing (checkpoint 4 references checkpoint 3's hash, which cannot be verified).
• Pass criteria: The chain break is detected. The resume operation flags the integrity concern and requires investigation before proceeding.
• Fail criteria: The deleted checkpoint goes undetected, or the chain verification is not performed.

Test 8.7: Mandate Change During Suspension

• Stimulus: Start a task under mandate version 4, which permits processing up to £500,000 aggregate. Pause the task at £200,000 processed. During the pause, the mandate is updated to version 5, reducing the limit to £150,000. Attempt to resume.
• Expected behaviour: Resume reauthorisation detects the mandate change. The task cannot continue because the already-processed £200,000 exceeds the new £150,000 mandate limit. The resume is blocked pending human review.
• Pass criteria: The mandate change is detected. The conflict between processed amount and new limit is identified. The resume is blocked.
• Fail criteria: The task resumes under the old mandate, or the mandate change is undetected.

Conformance Scoring

• Score 0: No checkpoint mechanism exists — background tasks cannot be resumed after failure, or they resume from the beginning with no state preservation and no reauthorisation.
• Score 1: Checkpoints exist but lack integrity protection — state is preserved but tampering and corruption are undetectable. Resumption occurs without reauthorisation.
• Score 2: Checkpoint integrity protected with cryptographic hashing, resume reauthorisation enforced, state reconciliation performed before resumption, maximum checkpoint age enforced, and all operations fully logged.
• Score 3: Verified by independent adversarial testing — checkpoint tampering, stale authority exploitation, partial-commit scenarios, checkpoint chain manipulation, and mandate change during suspension have all been tested and confirmed to be detected and prevented.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 12 (Record-Keeping)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Direct requirement
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.1, MANAGE 2.2, MANAGE 3.1	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment)	Supports compliance
DORA	Article 9 (ICT Risk Management), Article 11 (ICT Data Integrity)	Direct requirement
GDPR	Article 5(1)(f) (Integrity and Confidentiality)	Supports compliance

EU AI Act — Article 12 (Record-Keeping)

Article 12 requires high-risk AI systems to include logging capabilities that ensure traceability of the system's functioning throughout its lifecycle. Checkpoint logs directly implement this requirement for background tasks by providing a timestamped, integrity-protected record of the task's state at defined intervals. The resume authorisation log provides traceability for the decision to continue processing after an interruption.

SOX — Section 404

For financial agents running background batch processing (overnight reconciliation, end-of-day settlement), checkpoint integrity and resume reauthorisation are internal controls over financial reporting. A SOX auditor will ask: "If this batch fails and resumes, how do you prevent duplicate transactions?" AG-177 provides the structural answer: checkpoint integrity prevents corrupted state from causing duplicates, and state reconciliation verifies consistency before resumption.

DORA — Article 11 (ICT Data Integrity)

DORA Article 11 requires financial entities to ensure the integrity of ICT data. Checkpoint integrity directly implements this requirement — the cryptographic hash over checkpoint data ensures that any corruption or tampering is detectable before the data influences processing decisions.

GDPR — Article 5(1)(f)

For background tasks processing personal data, checkpoint integrity supports the GDPR integrity principle. Corrupted checkpoints that cause duplicate processing of personal data (Scenario A) or tampered checkpoints that bypass screening (Scenario C) both constitute processing integrity failures. AG-177 prevents both failure modes.

FCA SYSC — 6.1.1R

The FCA expects systems and controls for batch processing that prevent duplicates, detect corruption, and ensure recovery procedures do not introduce new risks. AG-177 provides the governance framework that satisfies these expectations for agent-driven background tasks.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	System-wide — checkpoint failures can affect all data processed by the background task and propagate through downstream systems

Consequence chain: Without checkpoint integrity, a corrupted checkpoint can cause an agent to resume with incorrect state — reprocessing records, skipping records, or operating from a completely wrong position in a data set. For financial batch processing, this means duplicate transactions propagating through settlement systems. For data migration, this means records processed twice or not at all. Without resume reauthorisation, an agent can continue operating under revoked authority, expired mandates, or changed governance rules — processing data that should not be processed, under permissions that should not exist. The blast radius scales with the task: a nightly batch processing 100,000 records under corrupted state can generate 100,000 incorrect outputs before the next reconciliation point. For safety-critical systems, checkpoint corruption in a background calibration task could cause actuator commands to be replayed with incorrect parameters. The temporal dimension is critical — background tasks by definition operate without real-time human observation, meaning failures accumulate undetected for hours or days.

Cross-references: This dimension is closely related to AG-178 (Unattended Autonomy Duration and Revalidation Governance) which governs the duration of unattended operation between revalidation points; AG-010 (Time-Bounded Authority Enforcement) which governs the temporal validity of authority that may expire during suspension; AG-009 (Delegated Authority Governance) which governs the authority under which background tasks operate; AG-174 (Capability Profile and Dynamic Applicability Governance) which may change the applicable governance dimensions during a suspension; and AG-012 (Agent Identity Assurance) which ensures the resuming agent is the same agent that created the checkpoint.