Runtime Attestation and Trusted Execution Governance

2. Summary

Runtime Attestation and Trusted Execution Governance requires that every component in the governance enforcement chain — from the policy evaluation engine through the enforcement gateway to the audit log — can cryptographically prove that it is running the expected code, on the expected infrastructure, with the expected configuration, at the time of each enforcement decision. Attestation provides the evidence chain that connects a governance policy (AG-134) to an enforcement decision: the policy was loaded by a verified evaluation engine, running on verified infrastructure, applying verified precedence rules (AG-135), within a verified separation boundary (AG-136). Without attestation, the separation, the policy, and the precedence rules are all trust-me claims — they may be true, but there is no cryptographic evidence that they are true at the moment the enforcement decision is made.

3. Example

Scenario A — Compromised Governance Container Reports False Compliance: An organisation deploys its governance control plane as a containerised service. An attacker compromises the container registry and replaces the governance image with a modified version that accepts all actions (returns "permit" for every evaluation) while logging "evaluated against policy v47 — compliant." The container orchestrator deploys the compromised image on the next restart. For 72 hours, every agent action is approved regardless of policy. The audit log shows normal evaluation records with correct policy references. Post-incident review finds no anomalies in the audit trail because the compromised container generated plausible log entries.

What went wrong: No attestation mechanism verified that the running governance container matched the expected image. The container registry was a single point of trust — compromise of the registry meant compromise of the governance engine with no detection mechanism. The audit log was generated by the compromised component and therefore was untrustworthy. Consequence: 72 hours of uncontrolled agent operation, 14,237 actions approved without genuine policy evaluation, total exposure of £23,400,000 across all agents, 6-month remediation programme, regulatory notification for loss of governance controls.

Scenario B — Silent Configuration Drift in Policy Evaluation Engine: A governance enforcement engine is deployed on virtual infrastructure. Over time, system administrators apply patches, library updates, and configuration changes to the underlying operating system and runtime environment. One update changes the default locale settings, which alters the string comparison behaviour in the policy evaluation engine — policy conditions comparing counterparty names now use locale-aware collation instead of byte-level comparison. A counterparty named "OFAC_BLOCKED" no longer matches the policy's "ofac_blocked" check due to the changed comparison semantics. 4 transactions with the blocked counterparty are approved over 2 weeks before an independent compliance review detects the discrepancy.

What went wrong: No attestation mechanism verified the complete execution environment — not just the application binary, but the operating system configuration, library versions, and runtime settings. A configuration change to the underlying environment altered the enforcement engine's behaviour without any change to the enforcement code or policy. No mechanism detected the drift between the expected and actual execution environment. Consequence: 4 transactions with a sanctioned counterparty totalling £1,890,000, sanctions violation exposure, regulatory notification, and fundamental loss of confidence in the governance engine's behaviour.

Scenario C — Cloud Provider Maintenance Migrates Governance to Unverified Hardware: A financial services firm runs its governance control plane on a cloud provider's confidential computing instances (AMD SEV-SNP). During a scheduled maintenance window, the cloud provider migrates the governance workload to a non-confidential-computing instance due to a capacity issue. The migration is transparent to the application — it continues running — but the hardware attestation properties (memory encryption, attestation report) are lost. The governance engine continues operating, but it is no longer running in a trusted execution environment. An attacker with hypervisor-level access (e.g., a compromised cloud administrator) can now inspect the governance engine's memory, including policy details and signing keys.

What went wrong: The governance system did not continuously verify that it was running on the expected hardware platform. Initial attestation at deployment was not sufficient — the execution environment changed during runtime without detection. The cloud provider's maintenance process did not preserve the confidential computing properties. Consequence: exposure of policy signing keys, exposure of policy content to potential cloud-level adversaries, loss of the hardware trust anchor for all governance decisions made after the migration, requirement to rotate all keys and re-attest all enforcement points.

4. Requirement Statement

Scope: This dimension applies to all AI agent deployments where the trustworthiness of the governance enforcement mechanism cannot be established solely through architectural design (AG-136) and must be continuously verified at runtime. This includes all production deployments where: (a) the governance infrastructure is managed by personnel who could introduce unauthorised changes, (b) the governance infrastructure runs on shared or cloud infrastructure where the physical environment is not under the organisation's exclusive control, (c) the deployment operates in a regulated environment where auditors or regulators require evidence that controls were operational at specific historical moments, or (d) the threat model includes supply-chain attacks, insider threats, or sophisticated adversaries capable of modifying the governance infrastructure. Systems where the governance enforcement is implemented in tamper-resistant hardware (e.g., a hardware security module implementing a fixed policy) with no software component may be excluded if the hardware attestation is inherent in the device.

4.1. A conforming system MUST implement cryptographic attestation for every component in the governance enforcement chain, such that each component can produce a signed attestation report containing: the component's identity, the hash of its executable code, the hash of its loaded configuration (including policy), and the timestamp of the attestation.

4.2. A conforming system MUST verify attestation reports before trusting enforcement decisions — an enforcement decision from an unattested or incorrectly attested component MUST be treated as invalid and the action MUST be blocked.

4.3. A conforming system MUST perform attestation verification on a periodic basis during runtime (not only at startup), with a period no longer than the organisation's maximum acceptable window of undetected governance compromise.

4.4. A conforming system MUST maintain a reference manifest — a signed, versioned record of the expected attestation values (code hashes, configuration hashes, platform identifiers) for every governance component — such that attestation reports can be verified against expected values.

4.5. A conforming system MUST detect and alert on attestation failures within a defined SLA (e.g., 60 seconds for high-value deployments, 5 minutes for standard deployments) and MUST suspend governance operations for the affected component until attestation is restored.

4.6. A conforming system SHOULD leverage hardware-backed attestation mechanisms (TPM 2.0, Intel SGX, AMD SEV-SNP, ARM TrustZone, or equivalent) where the threat model includes hypervisor-level, firmware-level, or physical access adversaries.

4.7. A conforming system SHOULD implement remote attestation, allowing an independent verification service to validate the governance infrastructure's state without trusting any component within the governance infrastructure itself.

4.8. A conforming system SHOULD maintain a continuous attestation log — a time-series record of all attestation reports from all governance components — enabling historical verification that the governance infrastructure was in an expected state at any past moment.

4.9. A conforming system MAY implement sealed storage, where cryptographic keys used for policy signing and audit log integrity are accessible only when the governance component is in an attested state, preventing key extraction from a compromised environment.

5. Rationale

Runtime Attestation and Trusted Execution Governance addresses the gap between architectural design and operational reality. AG-136 requires that the governance control plane be architecturally separated from the agent data plane. But architectural separation is a design property — it describes how the system should be. Attestation is a runtime property — it provides cryptographic evidence of how the system actually is, right now, at the moment of each enforcement decision.

The distinction matters because the operational environment drifts from the designed architecture continuously. Container images are updated. Operating system patches change runtime behaviour. Virtual machines are migrated between physical hosts. Configuration files are modified by administrators. Libraries are upgraded. Hardware is replaced. Each of these changes can alter the governance engine's behaviour, and many of them are invisible to the governance engine itself — it continues running, producing enforcement decisions, but the environment in which it runs has changed in ways that may compromise its trustworthiness.

Attestation solves this by requiring each governance component to prove its state. The proof is cryptographic — not a self-report (which a compromised component could fake) but a measurement verified against a reference manifest. The measurement covers the complete trust chain: the hardware platform, the firmware, the operating system, the runtime environment, the application binary, and the loaded configuration. If any element in this chain has changed from the expected value, the attestation fails, and the component is no longer trusted.

This is particularly important for cloud-hosted governance infrastructure, where the organisation does not control the physical hardware. A cloud provider's routine maintenance — VM migration, hardware replacement, hypervisor update — can change the execution environment in ways that invalidate the governance infrastructure's trust properties. Without continuous attestation, the organisation discovers these changes only when an incident occurs.

6. Implementation Guidance

AG-137 requires organisations to implement a cryptographic attestation infrastructure for their governance control plane. The implementation complexity depends on the threat model: software-only attestation is appropriate for threats limited to application-level compromise; hardware-backed attestation is required for threats including hypervisor-level or physical access.

Recommended patterns:

• Software-based attestation with signed digests. At the minimum level, implement attestation by computing cryptographic hashes (SHA-256 or SHA-384) of every governance component's binary, configuration, and loaded policy at startup and on a defined schedule (e.g., every 60 seconds). The hashes are signed by the component's attestation key and submitted to a remote verification service. The verification service compares the reported hashes against the reference manifest. If any hash does not match, the verification service revokes the component's authorisation to render enforcement decisions. Example: the governance evaluation engine computes sha256(binary) = a1b2c3..., sha256(policy_v47) = d4e5f6..., sha256(config) = 789abc... every 60 seconds. The attestation report {component: "eval-engine-01", binary_hash: "a1b2c3...", policy_hash: "d4e5f6...", config_hash: "789abc...", timestamp: "2026-03-30T14:00:00Z", signature: "RSA-PSS(attestation_key, ...)"} is sent to the verification service. If any hash deviates, the verification service instructs the enforcement gateway to reject decisions from eval-engine-01.
• Hardware-backed attestation with TPM 2.0. For deployments on physical or virtual infrastructure with TPM support, use the TPM's Platform Configuration Registers (PCRs) to measure the boot chain (firmware, bootloader, OS kernel, runtime, application). At startup, the TPM extends PCR values with measurements of each boot stage. The governance application extends a designated PCR with its own binary hash and configuration hash. Remote attestation uses the TPM's Attestation Identity Key (AIK) to sign a quote containing the PCR values, which the verification service checks against the reference manifest. The TPM's hardware root of trust means that even a compromised OS cannot fake the attestation — the PCR values reflect actual measurements, not reported values.
• Confidential computing attestation (AMD SEV-SNP / Intel TDX). For cloud deployments, use the cloud provider's confidential computing offerings. The governance control plane runs in a confidential VM or enclave. The hardware generates an attestation report containing the VM's launch measurement (hash of the initial memory state), the hardware platform identity, and the security version numbers. The attestation report is signed by the hardware's attestation key, rooted in the processor manufacturer's certificate chain. The verification service validates the report against AMD's or Intel's root certificates and the organisation's reference manifest. Example: a governance engine running in an AMD SEV-SNP confidential VM produces an attestation report containing {launch_measurement: "xyz...", platform_version: "Milan-v3", policy: "0x30000", signature: "ECDSA(vcek, ...)"}. The verification service checks the launch_measurement against the expected value derived from the governance engine's build artefact.
• Continuous attestation with sealed storage. Combine attestation with sealed storage: cryptographic keys used for policy signing, audit log integrity, and enforcement decision signing are sealed to the attestation state. The keys are accessible only when the platform is in the expected attested state. If the attestation state changes (e.g., the binary is modified, the configuration drifts, or the platform is migrated to unverified hardware), the keys become inaccessible, and the governance component cannot sign enforcement decisions. This creates a self-enforcing mechanism: a compromised governance component cannot produce valid enforcement decisions because it cannot access the signing key.

Anti-patterns to avoid:

• Self-attestation without external verification. A governance component that reports its own hash values without external verification provides no assurance. A compromised component can report the expected values while running modified code. Attestation must be verified by an independent party that does not trust the attesting component.
• Startup-only attestation. Verifying the governance component's state only at startup and then trusting it for the remainder of its lifetime ignores runtime drift. Configuration changes, library updates, memory corruption, and runtime migration all occur after startup. Attestation must be continuous or periodic with a period short enough to bound the window of undetected compromise.
• Attestation without a reference manifest. Verifying that a component produces an attestation report is meaningless without knowing what the report should contain. A reference manifest — the expected hashes for each component — must be maintained, versioned, and signed by the governance authority. Without it, attestation is a measurement without a standard.
• Trusting the cloud provider's attestation without verification. Cloud providers offer attestation services, but the organisation must independently verify the attestation chain. Trusting the cloud provider's assertion that "this VM is confidential" without verifying the hardware attestation report against the processor manufacturer's root certificate leaves the organisation dependent on the cloud provider's internal controls.
• Attesting the application but not the environment. Verifying the governance engine binary but not the operating system, runtime, libraries, or configuration leaves the attestation incomplete. Scenario B above demonstrates how an environmental change (locale settings) can alter enforcement behaviour without changing the application binary. The attestation must cover the complete execution environment.

Industry Considerations

Financial Services. PRA SS1/23 and FCA expectations for model risk management increasingly emphasise the ability to demonstrate that controls were operational at specific historical moments. AG-137's continuous attestation log provides this evidence — for any historical enforcement decision, the organisation can produce the attestation report showing the governance infrastructure's verified state at that moment. This directly supports supervisory requests for evidence of control effectiveness.

Healthcare. HIPAA requires that organisations implement mechanisms to verify that electronic protected health information (ePHI) has not been altered or destroyed. AG-137 extends this principle to the governance controls themselves — not just the data, but the enforcement mechanism that protects the data, must have integrity verification.

Critical Infrastructure. NERC CIP-010 requires configuration management and vulnerability assessment of cyber systems. AG-137's attestation mechanism provides continuous verification that governance systems remain in their approved configuration. For AI agents controlling critical infrastructure, the ability to cryptographically prove that the governance engine was running expected code at the time of every enforcement decision is essential for post-incident investigation.

Cloud Deployments. Organisations using cloud infrastructure should evaluate confidential computing options (AWS Nitro Enclaves, Azure Confidential Computing, Google Confidential VMs) as the hardware trust anchor for governance attestation. The cloud provider's attestation service provides the hardware root of trust; the organisation's verification service validates against its own reference manifest. This layered approach provides assurance even in a shared-infrastructure environment.

Maturity Model

Basic Implementation — The organisation computes cryptographic hashes of governance component binaries, configurations, and loaded policies at startup and on a periodic schedule (e.g., every 5 minutes). Hashes are compared against a reference manifest maintained in a separate, access-controlled system. Mismatches generate alerts to the security operations team. The governance component continues to operate while the alert is investigated. This level detects post-deployment modifications but does not prevent a compromised component from operating between detection and remediation.

Intermediate Implementation — Attestation is hardware-backed (TPM 2.0 or equivalent). The attestation covers the complete boot chain and runtime environment. Remote attestation is implemented — an independent verification service validates attestation reports. Attestation failures cause automatic suspension of the affected component's enforcement decisions within the defined SLA. A continuous attestation log provides historical evidence of governance infrastructure state. Reference manifests are versioned, signed, and maintained independently of the governance infrastructure. Sealed storage protects critical keys, making them inaccessible outside the attested state.

Advanced Implementation — All intermediate capabilities plus: confidential computing enclaves (AMD SEV-SNP, Intel TDX, or equivalent) provide hardware-level memory encryption and attestation. The attestation chain is rooted in the processor manufacturer's certificate authority, providing a trust anchor independent of both the organisation and the cloud provider. Continuous attestation runs on every enforcement decision (not just periodically). Formal verification of the attestation protocol ensures that no known attack can produce a valid attestation from a compromised component. Third-party audit of the attestation infrastructure confirms that the root of trust is genuine and the verification logic is correct. The organisation can provide, for any historical enforcement decision, a cryptographic proof chain from the hardware attestation through the software state to the enforcement decision.

7. Evidence Requirements

Required artefacts:

• Attestation architecture documentation. Description of the attestation mechanism including: what is measured (binary hashes, configuration hashes, platform state), how measurements are taken (software hash, TPM PCR extension, hardware attestation report), who verifies the measurements (verification service architecture), and what happens on attestation failure (suspension SLA, alert mechanism).
• Reference manifest. The current and historical reference manifests defining expected attestation values for every governance component. Include version history, signing authority, and change control records. Minimum 12 months history.
• Continuous attestation log. Time-series records of all attestation reports from all governance components, including the attestation values, verification results, and timestamps. Retention aligned with the enforcement decision audit trail (minimum 3 years, 7 years for financial services).
• Attestation failure records. Records of all attestation failures, including the component affected, the specific deviation detected, the response taken (suspension, alert, remediation), and the root cause analysis.
• Hardware attestation chain evidence. For hardware-backed implementations: the attestation certificate chain from the hardware manufacturer (e.g., AMD VCEK certificate chain), evidence of certificate validation, and the hardware platform identity.

Retention requirements:

• Attestation logs and reference manifests: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Attestation failure records: minimum 5 years for regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. An auditor must be able to independently verify any historical attestation by following the certificate chain and re-validating the attestation report against the reference manifest.

8. Test Specification

Test 8.1: Attestation Report Generation and Verification

• Stimulus: Deploy a governance component from a known-good image. Request an attestation report. Verify the report against the reference manifest.
• Expected behaviour: The attestation report contains accurate measurements of the component's binary, configuration, and platform state. Verification against the reference manifest succeeds.
• Pass criteria: The attestation report is generated, contains all required fields, and passes verification. The measured values match the reference manifest values.
• Fail criteria: The attestation report is missing fields, contains incorrect measurements, or fails verification against the reference manifest.

Test 8.2: Tampered Binary Detection

• Stimulus: Deploy a governance component from a modified image (e.g., change one byte in the binary). Request an attestation report and verify against the reference manifest.
• Expected behaviour: The binary hash in the attestation report does not match the reference manifest. Verification fails. The component is flagged as compromised.
• Pass criteria: The modification is detected. The attestation verification fails. The component's enforcement decisions are suspended within the defined SLA.
• Fail criteria: The modification is not detected, or the attestation verification passes despite the modification, or the component continues to render enforcement decisions after detection.

Test 8.3: Configuration Drift Detection

• Stimulus: Modify the governance component's configuration file (e.g., change a locale setting, modify a library path, alter a runtime parameter) without changing the application binary. Request an attestation report and verify.
• Expected behaviour: The configuration hash in the attestation report does not match the reference manifest. Verification fails.
• Pass criteria: The configuration drift is detected through the attestation mechanism, not just through application-level monitoring.
• Fail criteria: The configuration drift is not detected by attestation, or is detected only by application-level monitoring that the compromised component could disable.

Test 8.4: Periodic Attestation Verification

• Stimulus: Deploy a valid governance component. After successful initial attestation, modify the component's binary (simulating a runtime compromise). Measure the time between the modification and the system's detection via the next periodic attestation.
• Expected behaviour: The modification is detected at the next periodic attestation cycle. The time-to-detection is within the defined maximum attestation period.
• Pass criteria: Detection occurs within the defined maximum attestation period (e.g., 60 seconds for high-value deployments). The component is suspended within the defined SLA after detection.
• Fail criteria: Detection takes longer than the defined attestation period, or the modification is not detected by periodic attestation.

Test 8.5: Attestation Failure Response — Suspension

• Stimulus: Cause an attestation failure (e.g., by modifying the governance component's binary). Verify that the system suspends enforcement decisions from the affected component and blocks all agent actions that depend on it.
• Expected behaviour: Within the defined SLA, the affected component's enforcement decisions are treated as invalid. Agent actions that require evaluation by the affected component are blocked (fail-safe).
• Pass criteria: No enforcement decision from the unattested component is trusted after detection. Agent actions are blocked until attestation is restored or a verified replacement component is deployed.
• Fail criteria: Enforcement decisions from the unattested component continue to be trusted, or agent actions are permitted without governance evaluation during the suspension.

Test 8.6: Reference Manifest Integrity

• Stimulus: Attempt to modify the reference manifest without authorisation (e.g., change an expected hash value to match a compromised binary). Verify that the modification is rejected.
• Expected behaviour: The reference manifest is protected by the same integrity controls as governance policies (cryptographic signing, access control, version control). Unauthorised modifications are rejected.
• Pass criteria: No unauthorised modification to the reference manifest is accepted. The verification service continues using the last validly signed manifest.
• Fail criteria: An unauthorised modification is accepted, potentially allowing a compromised component to pass attestation verification.

Test 8.7: Sealed Storage Key Protection

• Stimulus: (For implementations using sealed storage.) Modify the governance component's binary to change the attestation state. Attempt to access the sealed cryptographic keys (policy signing key, audit log signing key) from the modified component.
• Expected behaviour: The sealed keys are inaccessible because the attestation state has changed. The modified component cannot sign enforcement decisions or audit entries.
• Pass criteria: The keys are inaccessible from the modified component. No valid enforcement decisions or audit entries can be produced by the modified component.
• Fail criteria: The keys remain accessible despite the changed attestation state, or an alternative key access path exists that bypasses the sealing mechanism.

Conformance Scoring

• Score 0: No attestation mechanism exists — the governance infrastructure's state is assumed trustworthy based on deployment procedures alone.
• Score 1: Software-based attestation with hash verification against a reference manifest, periodic checks, and alerting on mismatches — detects post-deployment modifications but cannot prevent a compromised component from operating between detection and remediation.
• Score 2: Hardware-backed attestation (TPM 2.0 or equivalent) with remote verification, automatic suspension on failure, continuous attestation log, and sealed storage for critical keys — provides strong assurance of governance infrastructure integrity with bounded detection-to-suspension time.
• Score 3: All Score 2 capabilities plus confidential computing enclaves, per-decision attestation, formal verification of the attestation protocol, independent third-party audit of the trust chain, and the ability to produce a cryptographic proof chain for any historical enforcement decision.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance
PRA SS1/23	Model Risk Management — Control Effectiveness Evidence	Direct requirement
NIST AI RMF	GOVERN 1.1, MANAGE 2.2, MEASURE 2.6	Supports compliance
NIST SP 800-193	Platform Firmware Resiliency	Supports compliance
IEC 62443	Security Levels (SL 3, SL 4) — Integrity Verification	Direct requirement
NERC CIP-010	Configuration Management and Vulnerability Assessment	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Supports compliance

EU AI Act — Article 15 (Accuracy, Robustness and Cybersecurity)

Article 15 requires high-risk AI systems to achieve an appropriate level of cybersecurity. Runtime attestation directly addresses the cybersecurity resilience requirement by ensuring that governance infrastructure has not been compromised. The regulation's requirement that security measures be "appropriate to the relevant circumstances and the risks" maps to AG-137's tiered implementation — software-only attestation for moderate-risk deployments, hardware-backed attestation for high-risk deployments.

PRA SS1/23 — Model Risk Management

SS1/23 expects firms to demonstrate that their model risk management controls are effective. For AI agent governance, this means demonstrating not just that policies exist but that the enforcement mechanism was operating correctly at the time of each decision. AG-137's continuous attestation log provides this evidence — for any historical decision, the firm can produce the attestation report showing the verified state of the governance infrastructure at that moment.

NIST SP 800-193 — Platform Firmware Resiliency

SP 800-193 provides guidelines for platform firmware resiliency, including integrity verification and recovery. AG-137 extends these principles to the governance control plane, ensuring that the firmware and software chain on which governance enforcement depends is verified and that failures are detected and recovered.

IEC 62443 — Security Levels

IEC 62443 SL 3 and SL 4 require integrity verification of system components. AG-137's attestation mechanism provides this for governance infrastructure. Hardware-backed attestation at advanced maturity aligns with SL 4's requirement for protection against sophisticated adversaries with extended resources.

SOX — Section 404

Section 404 requires evidence of control effectiveness. AG-137's attestation provides cryptographic evidence that the governance control was running expected code on expected infrastructure at the time of each enforcement decision. This is a stronger form of evidence than periodic testing — it provides continuous assurance.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — all agents governed by the unattested control plane; scope extends to any decision made during the unattested period

Consequence chain: Without runtime attestation, the organisation cannot verify that its governance infrastructure is operating correctly at any given moment. The governance engine may have been compromised (Scenario A), its environment may have drifted (Scenario B), or its hardware trust properties may have been lost (Scenario C) — and none of these would be detected. The failure mode is a silent loss of governance assurance: the system appears to be governing correctly, logs show normal enforcement decisions, compliance dashboards report green — but the actual enforcement mechanism may be operating on modified code, corrupted configuration, or compromised infrastructure. The operational consequence is that every enforcement decision made during the unattested period is of unknown validity. The organisation cannot retroactively determine whether any specific decision was correct because it cannot verify the state of the system that made the decision. The regulatory consequence is an inability to demonstrate control effectiveness for any period where attestation was not in place — a fundamental gap in audit evidence that regulators will view as a material control weakness. Cross-reference with AG-136 (Independent Control-Plane Separation Governance) which provides the architectural separation that attestation verifies, and AG-046 (Operating Environment Integrity) for the broader environment integrity that attestation supports.

Cross-references: AG-134 (Machine-Checkable Policy Semantics) defines the policies whose correct loading attestation verifies. AG-135 (Policy Precedence and Conflict Arbitration Governance) defines the precedence logic whose correct implementation attestation verifies. AG-136 (Independent Control-Plane Separation Governance) provides the architectural separation that attestation measures and confirms. AG-138 (High-Assurance Invariant Verification Governance) provides formal proofs that attestation evidence can support. AG-007 (Governance Configuration Control) governs the reference manifest lifecycle. AG-046 (Operating Environment Integrity) addresses the broader environment integrity that attestation contributes to. AG-005 (Instruction Integrity Verification) addresses agent-side integrity that is complementary to control-plane attestation.