Approval Chain Visibility Governance requires that the full approval path for every AI agent action — from the initial request through every approval step to final execution — is visible, queryable, and auditable by authorised reviewers. Every link in the chain must be traceable: who requested the action, who approved it at each tier, what authority they were exercising, what context they reviewed, and when each step occurred. Approval chains that are opaque, fragmented across systems, or reconstructable only through manual investigation defeat the purpose of multi-party governance. This dimension ensures that the approval chain is a first-class auditable artefact, not a forensic reconstruction exercise.
Scenario A — Fragmented Approval Trail Prevents Audit: An AI procurement agent processes a £890,000 contract that requires Tier 3 approval (two-party plus legal review). The procurement request is initiated in System A, the first approval occurs in System B (the procurement workflow tool), the legal review is recorded in System C (the legal matter management platform), and the final approval is logged in System D (the ERP system). When an auditor requests the complete approval chain, no single system contains it. The procurement team must manually reconstruct the chain by correlating timestamps and reference numbers across four systems. The reconstruction takes 11 days. During reconstruction, the team discovers that the legal review in System C references a different contract version than the one ultimately executed — a discrepancy that went undetected because no system provided an end-to-end view.
What went wrong: The approval chain was fragmented across four systems with no unified visibility layer. No single query could return the complete approval path. The fragmentation concealed a version discrepancy that a unified view would have revealed. Consequence: 11 days to reconstruct an audit trail (vs. 48-hour regulatory requirement), undiscovered contract version discrepancy, audit finding for inadequate approval chain documentation.
Scenario B — Approval Chain Gaps Conceal Unauthorised Action: An AI payment agent processes a £67,000 payment. The payment log shows the action was executed at 14:32. The approval log shows an approval at 14:28. However, no record links the specific approval to the specific payment — the approval log records the approver's identity and the time but not the action identifier. When challenged, the approver states they approved a different payment at 14:28 and have no knowledge of the £67,000 payment. Investigation reveals that the agent executed the payment without a linked approval — the temporal proximity of an unrelated approval created the appearance of authorisation.
What went wrong: The approval chain lacked explicit linking between the approval record and the action record. The system relied on temporal correlation rather than structural linkage. The absence of an explicit approval-action link created a gap that concealed an unauthorised action. Consequence: £67,000 in unauthorised payment, fraud investigation, control failure finding.
Scenario C — Retrospective Approval Chain Fabrication: Following an incident, an investigation reveals that an AI agent executed several high-value actions without proper approval. The team responsible for the agent retroactively creates approval records — backdated entries in the approval log that make it appear the actions were properly approved. Because the approval log is a mutable database table with no integrity protection, the fabricated records are indistinguishable from genuine records.
What went wrong: The approval chain was stored in a mutable format without integrity protection. Retrospective fabrication was possible because there was no mechanism to verify that approval records were created contemporaneously with the approval decision. Consequence: fabricated governance records, when discovered — criminal investigation for fraud, regulatory enforcement for falsified compliance records, loss of all audit credibility.
Scope: This dimension applies to all AI agent actions that pass through an approval workflow, and to the systems that record, store, and present approval chain information. The scope includes every system that participates in the approval lifecycle: request systems, workflow systems, approval interfaces, execution systems, and audit repositories. The scope extends to the integrity of the approval chain data itself — not just whether the data exists, but whether it can be trusted.
4.1. A conforming system MUST maintain a unified, queryable approval chain record for every AI agent action that requires approval, containing: the action identifier, the request timestamp, the requester identity, every approval step (approver identity, approval timestamp, authority exercised, context reviewed), and the execution timestamp.
4.2. A conforming system MUST structurally link each approval record to the specific action it authorises, using a unique action identifier — not temporal correlation or implicit association.
4.3. A conforming system MUST store approval chain records in an append-only or integrity-protected format that prevents retrospective modification, deletion, or fabrication.
4.4. A conforming system MUST make the complete approval chain queryable from a single point — an auditor must be able to retrieve the full chain for any action through a single query, regardless of how many systems participated in the approval.
4.5. A conforming system MUST detect and flag actions that were executed without a complete, linked approval chain — the absence of a chain is an auditable event, not a silent gap.
4.6. A conforming system SHOULD implement cryptographic chaining of approval records — each record includes a hash of the previous record, creating a verifiable sequence that detects insertion, deletion, or reordering.
4.7. A conforming system SHOULD provide a real-time approval chain dashboard showing: active approval workflows, completed chains, pending approvals, and any detected chain integrity anomalies.
4.8. A conforming system SHOULD enable approval chain comparison across similar actions, allowing auditors to identify anomalous patterns (e.g., an action that bypassed a normally required approval step).
4.9. A conforming system MAY implement machine-readable approval chain exports in a standardised format (e.g., JSON-LD, XBRL) to support automated regulatory reporting and cross-organisation audit.
Approval is only as valuable as the ability to verify that it occurred. In the physical world, a signed document serves as both the approval and the evidence of approval. In digital governance of AI agents, the approval and its evidence are separate — the approval is a decision, and the evidence is a record of that decision. If the record is incomplete, fragmented, or fabricable, the approval cannot be verified after the fact.
For AI agent governance, approval chain visibility serves three critical functions. First, it enables real-time oversight: a governance function monitoring active approval chains can detect anomalies (skipped steps, unusually fast approvals, approvals by unqualified individuals) before actions execute. Second, it enables retrospective audit: regulators, auditors, and internal reviewers can verify that every action was properly authorised by examining the approval chain. Third, it enables accountability: when an action produces an adverse outcome, the approval chain identifies who approved it, what information they had, and what authority they exercised — enabling proportionate accountability.
The integrity requirement is critical because approval chains, if fabricable, become worse than useless — they create false confidence. An organisation that presents fabricated approval records to a regulator faces not just the original governance failure but a second failure for falsified records, which typically carries more severe consequences than the original issue.
Approval chain visibility implementation requires a unified chain record format, structural action-approval linkage, integrity protection, and query infrastructure.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Approval chain visibility maps directly to MiFID II transaction reporting and record-keeping requirements. FCA-regulated firms must be able to demonstrate the full authorisation chain for every transaction. The 48-hour regulatory production requirement necessitates single-query access.
Healthcare. Clinical action approval chains must support medico-legal review. In the event of a clinical incident, the approval chain for the AI agent's recommendation and the clinician's approval must be reconstructable with legal-evidence-grade integrity.
Public Sector. Approval chains for decisions affecting citizens must support administrative law challenge. A citizen challenging an AI-informed government decision is entitled to understand who approved what and on what basis. Freedom of information requests may target approval chain records.
Basic Implementation — Approval chain records exist for all AI agent actions requiring approval. Records include action identifier, approver identity, and timestamps. Records are queryable. This meets minimum mandatory requirements but records may be fragmented across systems, structural action-approval linkage may be incomplete, and integrity protection may not be implemented.
Intermediate Implementation — A unified approval chain ledger aggregates records from all participating systems. Structural action-approval binding via unique action identifiers eliminates temporal correlation. Single-query access returns the complete chain for any action. Append-only storage prevents retrospective modification. Orphaned execution records are detected and flagged.
Advanced Implementation — All intermediate capabilities plus: cryptographic hash chaining provides tamper-evident integrity verification. Real-time dashboards monitor active and completed approval chains. Automated anomaly detection identifies unusual patterns (skipped steps, unusual timing, atypical approvers). Machine-readable chain exports support automated regulatory reporting. Independent adversarial testing confirms that chain fabrication, record modification, linkage manipulation, and orphan concealment attacks all fail.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Complete Chain Retrieval
Test 8.2: Structural Action-Approval Linkage
Test 8.3: Integrity Protection Against Modification
Test 8.4: Orphan Detection
Test 8.5: Retrospective Fabrication Prevention
Test 8.6: Chain Completeness Before Execution
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 12 (Record-keeping) | Direct requirement |
| EU AI Act | Article 13 (Transparency) | Supports compliance |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Direct requirement |
| FCA SYSC | 9.1.1R (Record Keeping) | Direct requirement |
| MiFID II | Article 16(6) (Record Keeping for Transactions) | Direct requirement |
| NIST AI RMF | MAP 3.5, MANAGE 4.1 | Supports compliance |
| ISO 42001 | Clause 9.1 (Monitoring, Measurement, Analysis) | Supports compliance |
| UK GDPR | Article 5(2) (Accountability Principle) | Supports compliance |
Article 12 requires that high-risk AI systems be designed with logging capabilities that enable recording of events relevant to identifying risks and facilitating post-market monitoring. The approval chain is a critical log: it records the governance events (approvals) that authorised the AI agent's actions. Without approval chain visibility, the logging requirement of Article 12 is not met for the governance dimension.
SOX auditors require evidence that internal controls operated effectively during the period. For AI agent actions affecting financial reporting, the approval chain is the primary evidence that the approval control operated. If the chain is incomplete, fragmented, or unreliable, the auditor cannot conclude that the control was effective, which may result in a control deficiency or material weakness finding.
SYSC 9.1.1R requires firms to maintain orderly records of their business and internal organisation, including records of transactions and approvals. The approval chain directly satisfies this requirement for AI agent operations. The 48-hour production requirement necessitates single-query access.
MiFID II requires comprehensive transaction records, including all authorisations. For AI agents executing transactions, the approval chain constitutes the authorisation record.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Organisation-wide — approval chain visibility failures affect all auditable AI agent operations |
Consequence chain: Without approval chain visibility, the organisation cannot demonstrate that AI agent actions were properly authorised. In the best case, this means time-consuming manual reconstruction for every audit or regulatory inquiry. In the worst case, it means that unauthorised actions are undetectable — actions without approvals blend seamlessly into actions with approvals because neither has a verifiable chain. The regulatory consequence is severe: inability to produce approval evidence within regulatory timeframes (typically 48 hours) constitutes a compliance failure independent of whether the underlying actions were properly approved. The financial consequence includes the cost of manual reconstruction (11 days in Scenario A) and the exposure from undetectable unauthorised actions (£67,000 in Scenario B). The reputational consequence is that an organisation without verifiable approval chains has no credible governance narrative — every claim of governance is unverifiable.
Cross-references: AG-079 (Delegation Chain Provenance) provides the delegation lineage that forms part of the approval chain. AG-290 (Tiered Approval Threshold Governance) defines the approval tiers that the chain must reflect. AG-291 (Approval Quorum Diversity Governance) defines the quorum diversity requirements that the chain must evidence. AG-292 (Approval Context Completeness Governance) defines the context that the chain must record. AG-296 (Dual-Control for Policy Change Governance) requires approval chains for policy changes. AG-298 (Post-Approval Mutation Detection Governance) detects changes after approval that would create a discrepancy in the chain. AG-170 (Approval Quality and Substantive Review) addresses the quality of the decisions recorded in the chain. Siblings in this landscape: AG-289 through AG-298.