AG-787
Governance Seal Integrity Verification
EU AI Act
SOX
FCA
ISO 27001
Governance Seal Integrity Verification governs the process by which cryptographic seals, generated under AG-786 during CRITICAL threshold events, are verified against the current or historical governance state. While AG-786 addresses the creation of seals, AG-787 defines how those seals are consumed, validated, and interpreted by verification engines, auditors, regulatory bodies, and automated compliance systems. The verification process answers a fundamental question: does the sealed governance state match the claimed state at the time of sealing, and has the seal itself remained unaltered since creation?
Verification operates at multiple levels. At the most basic level, the cryptographic digest in the seal is recomputed from the stored governance state snapshot and compared to the sealed value. If they match, the state has not been modified since sealing. At a deeper level, the digital signature on the seal is validated against the signing key's certificate chain, confirming that the seal was generated by an authorised sealing engine and not forged. At the most comprehensive level, the seal chain (if implemented per AG-786 R8) is walked from the most recent seal back to the genesis seal, verifying that every link is intact and that no seals have been inserted, removed, or reordered.
The distinction between seal creation and seal verification as separate protocols reflects a fundamental security principle: the entity that creates a proof should not be the same entity that validates it. By separating AG-786 (creation) and AG-787 (verification), the framework enables independent verification by parties who have no access to the sealing infrastructure, including external auditors, regulatory bodies, and federated peers. This separation of concerns is essential for the evidentiary value of the seal to be recognised in regulatory and legal proceedings.
This protocol applies to all systems and entities that consume or rely upon cryptographic seals generated under AG-786. Specifically:
A cryptographic seal has no value if it cannot be independently verified. The entire purpose of AG-786's sealing mechanism is to create evidence that can withstand scrutiny by adversaries, regulators, and courts. If verification is unreliable, inconsistent, or susceptible to manipulation, the seals are merely digital artifacts with no probative weight.
Concrete Failure Scenario: Following a security incident at a financial services firm, the FCA requests evidence that governance controls were active at the time of the breach. The firm produces a cryptographic seal generated by AG-786 during the Level 5 escalation event. However, the firm's verification process relies on the same HSM that generated the seal, and the verification is performed by the same team that manages the sealing infrastructure. The FCA's forensic experts question the independence of the verification and request that an independent third party verify the seal. The firm discovers that its seal format is proprietary and undocumented, making independent verification practically impossible. The FCA treats the seal as unverifiable and the firm faces enforcement action for inadequate record-keeping under SYSC 9.1.1. With AG-787 in place, the seal format is standardised, verification procedures are documented, and the firm can provide a verification toolkit to any independent party, enabling the FCA's experts to confirm the seal's validity without relying on the firm's infrastructure.
Under the EU AI Act (Article 12(2)), records must be available for verification by national competent authorities. SOX Section 404 requires that the effectiveness of internal controls be independently assessed. ISO/IEC 27001:2022 clause A.8.24 requires that the integrity of cryptographic controls be verifiable. AG-787 ensures that these verification requirements are operationally achievable.
At the Basic level, the system can verify individual seal digests by recomputing them from stored governance state snapshots. Signature validation is performed but may not include full certificate chain verification or revocation checking. Verification reports are generated but may lack structured formatting. There is no standalone verification toolkit for external parties. Chain verification is not supported. Verification failures are logged but may not trigger automated alerts.
At the Intermediate level, verification includes full certificate chain validation with revocation checking (CRL or OCSP). Structured verification reports are generated with all required fields. Chain verification walks the complete seal chain. Verification failures trigger automated alerts. A standalone verification toolkit exists for distribution to external auditors. Batch verification is supported for audit efficiency. The verification process has been tested against known-good and known-bad seals to confirm correct behaviour.
At the Advanced level, cross-platform verification of federated peer seals is operational. The verification engine has been validated by independent adversarial testing, including forged seals, tampered state snapshots, revoked-key scenarios, and chain manipulation attempts. Timestamping authority integration supports revocation-aware verification with temporal precision. The standalone verification toolkit has been reviewed and approved by at least one external regulatory body or independent audit firm. Verification can be performed in air-gapped environments for maximum security.
| Score | Level | Description |
|---|---|---|
| 0 | No implementation | No seal verification capability exists. Seals generated by AG-786 cannot be validated, rendering them useless for evidentiary or audit purposes. |
| 1 | Basic | Digest-based verification is available but lacks full certificate chain validation, revocation checking, chain verification, or structured reporting. Verification is ad-hoc and cannot be performed by external parties. |
| 2 | Infrastructure-layer enforcement | Full verification is operational, including digest matching, signature validation with certificate chain and revocation checking, chain verification, structured reporting, automated failure alerting, and a standalone toolkit for external verification. Batch verification is supported. |
| 3 | Verified by independent adversarial testing | All Level 2 capabilities are validated by independent adversarial testing, including forged seals, tampered snapshots, revoked-key scenarios, chain manipulation, and cross-platform federation verification. The standalone toolkit has been externally reviewed. |
Scenario: The governance state snapshot stored alongside the seal is corrupted due to a storage system error (bit rot, incomplete write, or filesystem corruption). When verification recomputes the digest from the corrupted snapshot, it does not match the sealed digest. The verification engine reports a failure, but the actual governance state at sealing time was valid — the corruption occurred post-sealing.
Impact: MEDIUM. A false-positive verification failure creates unnecessary alarm and undermines confidence in the sealing mechanism. If the snapshot is the only record of the governance state at sealing time, the evidentiary value is lost regardless of whether the seal itself is intact.
Mitigation: AG-786 R5 mandates geographically separated storage. Verification should attempt to verify against all available copies of the snapshot before declaring failure. Implement storage integrity monitoring (checksums, ECC) to detect corruption early.
Scenario: The signing key's certificate is revoked due to a suspected key compromise, but the verification engine's CRL cache is stale and does not include the revocation entry. A seal signed with the compromised key passes verification despite the revocation.
Impact: CRITICAL. A forged seal signed with the compromised key would pass verification, potentially being used to fabricate evidence of governance compliance during a period when controls were actually inactive.
Mitigation: R2 mandates revocation status checking. Use OCSP stapling for real-time revocation status or implement short-lived CRL caches (maximum 1 hour). R10 requires rejection of seals signed with revoked certificates unless timestamping authority attestation is present.
Scenario: An adversary with storage access inserts a forged seal into the middle of the seal chain, linking it to the previous genuine seal and updating the next genuine seal's back-reference. If the verification engine only checks adjacent links without verifying the entire chain's consistency, the inserted seal appears valid.
Impact: HIGH. A forged seal in the chain could be used to claim that a particular governance state was in effect at a time when it was not, or to obscure evidence of a governance failure.
Mitigation: R5 mandates full chain verification from the most recent seal to the genesis or anchor point. Each seal's signing timestamp should be validated for temporal consistency (seals must be in chronological order). Transparency log publication (AG-786 R9) provides an independent record of the expected chain sequence.
Scenario: The standalone verification toolkit distributed to external auditors uses a slightly different digest computation algorithm than the internal verification engine, due to a library version mismatch. External auditors report verification failures for seals that pass internal verification, creating a dispute about the seals' validity.
Impact: HIGH. Inconsistent verification results undermine the credibility of the entire sealing mechanism. Regulatory bodies may refuse to accept seal evidence if independent verification produces different results.
Mitigation: Implement comprehensive integration tests that verify identical results from the internal engine and standalone toolkit for the same inputs. Version-lock cryptographic libraries across both implementations. Include test vectors in the toolkit distribution.
| Requirement | EU AI Act | SOX | FCA SYSC | ISO/IEC |
|---|---|---|---|---|
| R1: Digest verification | Art. 12(2) — Verification access | Sec. 404 | SYSC 9.1.1 | ISO/IEC 27001:2022 A.8.24 |
| R2: Signature and chain validation | Art. 15 — Security | Sec. 404 | SYSC 13.7.5 | ISO/IEC 27001:2022 A.8.24 |
| R3: Independent verifiability | Art. 12(2) — Authority access | Sec. 404 | SYSC 9.1.1 | ISO/IEC 27001:2022 A.8.24 |
| R4: Structured verification reports | Art. 12 — Record-keeping | Sec. 302 | SYSC 9.1.1 | ISO/IEC 27001:2022 A.8.15 |
| R5: Chain verification | Art. 12 — Record-keeping | Sec. 802 | SYSC 9.1.1 | ISO/IEC 27001:2022 A.8.24 |
| R6: Failure logging and alerting | Art. 9(4)(b) — Mitigation | Sec. 302 | SYSC 6.1.1 | ISO/IEC 27001:2022 A.5.24 |
| R10: Revocation-aware verification | Art. 15 — Security | Sec. 404 | SYSC 13.7.5 | ISO/IEC 27001:2022 A.8.24 |
| Protocol | Relationship |
|---|---|
| AG-784 (Adaptive Threat Level Escalation) | Context: Seals are generated at Level 5 escalation; verification confirms the escalation context. |
| AG-785 (Threat Level Auto-Decay and Stabilisation) | Integration: Decay from Level 5 may require seal verification to confirm the sealed state is consistent. |
| AG-786 (Cryptographic Governance State Sealing) | Complementary: AG-786 creates seals; AG-787 verifies them. |
| AG-788 (Federated Threat Level Propagation) | Federation: Cross-platform seal verification relies on federated trust relationships. |
| AG-789 (HMAC-Signed Threat Broadcast Authentication) | Security: Authentication of seal-related messages between federated peers. |
| AG-790 (Multi-Source Weighted Threat Composite Scoring) | Indirect: Composite scores contribute to the escalation that triggers sealing and subsequent verification. |
| AG-791 (Pipeline-Integrated Threat Event Ingestion) | Indirect: Pipeline events feed escalation that creates seals for verification. |
| AG-006 (Tamper-Evident Record Integrity) | Audit: Verification failures are logged in tamper-evident records. |
| AG-012 (Agent Identity Assurance) | Attribution: Sealing engine identity is verified as part of seal validation. |
| AG-016 (Cryptographic Action Attribution) | Key management: Certificate chain validation relies on key lifecycle governance. |
| AG-017 (Multi-Party Authorisation Governance) | Control: Multi-party authorisation for seal destruction relates to verification scope. |
Document generated under Patent 7 governance framework. Classification: INTERNAL. Review cycle: Quarterly.