Scope boundary

Owns local hardware-rooted secure or measured boot validity for the host and boot-critical chain. It does not perform fresh remote cluster admission or manage vulnerability patch rollout.

AID-H-003.004: AID-H-009.001 establishes and locally enforces the trusted boot state; AID-H-003.004 remotely verifies fresh hardware and firmware evidence and makes the cluster or workload admission decision. Local boot validity is evidence consumed by the remote admission gate.

AID-H-009.002: AID-H-009.001 validates that boot components satisfy the current approved policy; AID-H-009.002 discovers vulnerabilities and manages firmware or driver patch rollout and rollback. Secure boot verifies authorized versions but does not decide when those versions are obsolete.

Implementation guidance

• AID-H-009.001-G001: Enable Secure Boot in the server's UEFI/BIOS settings for on-premises hardware.
• AID-H-009.001-G002: Utilize cloud provider capabilities for shielded and trusted VMs.
• AID-H-009.001-G003: Enforce the use of cryptographically signed drivers for all AI accelerators.

AID-H-009.001-G001

Concept:

Secure Boot is a feature in the UEFI firmware of modern servers that prevents unauthorized or unsigned operating systems and drivers from loading during the boot process. It is the foundational step for establishing a trusted software stack.

Step-by-Step Procedure:

This is a procedural task performed by a hardware or data center engineer during server provisioning.

1. Power on or reboot the server.
2. Enter the system's UEFI/BIOS setup utility (commonly by pressing F2, F10, or DEL during boot).
3. Navigate to the 'Security' or 'Boot' tab in the UEFI interface.
4. Locate the 'Secure Boot' option.
5. Set the Secure Boot option to 'Enabled'.
6. Ensure the system is in 'User Mode' and that the default platform keys (e.g., Microsoft keys) are enrolled.
7. Save changes and exit the UEFI utility. The system will now only boot operating systems and bootloaders that are signed with a trusted key.

Action: Develop a standard operating procedure and server build checklist that makes enabling Secure Boot a mandatory step for any new physical server that will be used for AI workloads.

Keep the action safely bounded

Provision owner-controlled Secure Boot keys and TPM policy, disable unauthorized boot/debug paths, measure the full boot chain, verify effective firmware/TPM/Secure-Boot state and negative unsigned-boot fixtures, and quarantine nonconforming hosts before workload scheduling.

Verify safely

A separately credentialed verifier independently reads back or replays each eligible accelerator host's motherboard, UEFI/firmware, TPM, bootloader, kernel and approved boot keys, exercises positive, negative, boundary and dependency-failure fixtures, and reconciles the complete eligible population.

AID-H-009.001-G002

Concept:

Shielded or trusted launch provides secure boot and integrity monitoring for cloud-hosted AI workloads.

Step 1: Provision with trusted-launch flags

gcloud compute instances create ai-training-worker-shielded --zone=us-central1-f --machine-type=n2-standard-8 --shielded-secure-boot --shielded-vtpm --shielded-integrity-monitoring

Step 2: Verify configuration evidence

gcloud compute instances describe ai-training-worker-shielded --zone=us-central1-f --format="json(shieldedInstanceConfig)"

Action: Enforce trusted-launch settings in IaC and block drift via configuration-policy scans.

Verify safely

A separately credentialed verifier independently reads back or replays each eligible cloud AI VM/instance template and running instance using shielded, trusted-launch or confidential boot controls, exercises positive, negative, boundary and dependency-failure fixtures, and reconciles the complete eligible population.

AID-H-009.001-G003

Delivery level: OS-specific enforcement and readback

Do not verify nvidia-smi or another user-mode utility as a proxy for the kernel driver. The operating system must enforce driver/module signatures; this guidance reads back the active accelerator driver population and the effective enforcement state. The signed host profile supplies the approved accelerator hardware scope, providers, signers, exact module population, and supported OS releases; policy allowlists validate a discovered population and never define that population.

Linux: require kernel enforcement and inspect every loaded NVIDIA module

# File: host-audit/verify-linux-accelerator-modules.sh
#!/usr/bin/env bash
set -euo pipefail
umask 077
: "${DRIVER_POLICY:?path to signature-verified host driver policy}"
: "${DRIVER_POLICY_DIGEST:?SHA-256 of those exact verified policy bytes}"

actual_policy_digest="$(sha256sum "$DRIVER_POLICY" | awk '{print $1}')"
test "$actual_policy_digest" = "$DRIVER_POLICY_DIGEST"
jq -e '.schema_version == "aidefend.accelerator-driver-policy.v1"
  and (.linux_pci_vendor_ids | type == "array" and length > 0)
  and (.linux_modules | type == "array" and length > 0)
  and (.linux_signers | type == "array" and length > 0)'   "$DRIVER_POLICY" >/dev/null

enforcement_file="/sys/module/module/parameters/sig_enforce"
test -r "$enforcement_file"
case "$(tr '[:lower:]' '[:upper:]' < "$enforcement_file")" in
  Y|1) ;;
  *) echo "kernel module signature enforcement is not active" >&2; exit 1 ;;
esac

mapfile -t expected_modules < <(
  jq -r '.linux_modules[]' "$DRIVER_POLICY" | LC_ALL=C sort -u
)
test "${#expected_modules[@]}" -eq "$(jq '.linux_modules | length' "$DRIVER_POLICY")"

declare -A discovered=()
collect_module() {
  local module="$1" holder_path holder
  test -n "$module"
  test -d "/sys/module/$module"
  if [[ -n "${discovered[$module]:-}" ]]; then return; fi
  discovered["$module"]=1
  for holder_path in "/sys/module/$module/holders/"*; do
    [[ -e "$holder_path" ]] || continue
    holder="$(basename -- "$holder_path")"
    collect_module "$holder"
  done
}

device_count=0
for device in /sys/bus/pci/devices/*; do
  [[ -d "$device" && -r "$device/vendor" ]] || continue
  vendor="$(tr '[:upper:]' '[:lower:]' < "$device/vendor")"
  if jq -e --arg vendor "$vendor" \
      '.linux_pci_vendor_ids | index($vendor) != null' \
      "$DRIVER_POLICY" >/dev/null; then
    device_count=$((device_count + 1))
    test -L "$device/driver/module"
    collect_module "$(basename -- "$(readlink -f -- "$device/driver/module")")"
  fi
done
if (( device_count == 0 || ${#discovered[@]} == 0 )); then
  echo "no active policy-scoped accelerator device/module was discovered" >&2
  exit 1
fi
mapfile -t discovered_modules < <(
  printf '%s\n' "${!discovered[@]}" | LC_ALL=C sort
)
if ! diff -u \
    <(printf '%s\n' "${expected_modules[@]}") \
    <(printf '%s\n' "${discovered_modules[@]}"); then
  echo "active accelerator module population differs from signed policy" >&2
  exit 1
fi

report="$(mktemp)"
trap 'rm -f -- "$report"' EXIT
printf '[' > "$report"
first=1
while IFS= read -r module; do
  test -d "/sys/module/$module"
  module_path="$(modinfo -n "$module")"
  test -f "$module_path"
  signer="$(modinfo -F signer "$module")"
  sig_id="$(modinfo -F sig_id "$module")"
  sig_hash="$(modinfo -F sig_hashalgo "$module")"
  test -n "$signer"
  test -n "$sig_id"
  test -n "$sig_hash"
  jq -e --arg signer "$signer" '.linux_signers | index($signer) != null'     "$DRIVER_POLICY" >/dev/null
  digest="$(sha256sum "$module_path" | awk '{print $1}')"
  if (( first )); then first=0; else printf ',' >> "$report"; fi
  jq -nc     --arg module "$module" --arg path "$module_path" --arg signer "$signer"     --arg sig_id "$sig_id" --arg sig_hash "$sig_hash" --arg sha256 "$digest"     '{module:$module,path:$path,signer:$signer,sig_id:$sig_id,
      sig_hash_algorithm:$sig_hash,sha256:$sha256}' >> "$report"
done < <(printf '%s\n' "${discovered_modules[@]}")
printf ']\n' >> "$report"
install -m 0400 "$report" evidence/linux-accelerator-module-signatures.json

The Linux adapter discovers PCI devices by signed hardware-vendor scope, follows each bound driver's loaded module and holder closure, and requires that complete discovered set to equal the exact signed module set; an omitted or extra active module therefore fails. Signature enforcement makes the kernel reject an untrusted module; non-empty modinfo signer alone is not the enforcement mechanism.

Windows: query the active signed PnP driver, not the CLI binary

# File: host-audit/Verify-WindowsAcceleratorDriver.ps1
$ErrorActionPreference = "Stop"
$policyPath = $env:DRIVER_POLICY
$expectedPolicyDigest = $env:DRIVER_POLICY_DIGEST
if ([string]::IsNullOrWhiteSpace($policyPath) -or
    $expectedPolicyDigest -notmatch '^[0-9a-f]{64}$') {
    throw "signature-verified driver policy binding is missing"
}
$actualPolicyDigest = (Get-FileHash -Algorithm SHA256 -LiteralPath $policyPath).Hash.ToLowerInvariant()
if ($actualPolicyDigest -ne $expectedPolicyDigest) {
    throw "driver policy bytes changed after verification"
}
$policy = Get-Content -Raw -LiteralPath $policyPath | ConvertFrom-Json
if ($policy.schema_version -ne "aidefend.accelerator-driver-policy.v1" -or
    $policy.windows_provider_names.Count -lt 1 -or
    $policy.windows_signers.Count -lt 1) {
    throw "driver policy schema is invalid"
}

$driverRows = @(Get-CimInstance -ClassName Win32_PnPSignedDriver)
$driverByDeviceId = @{}
foreach ($row in $driverRows) {
    if ([string]::IsNullOrWhiteSpace($row.DeviceID) -or
        $driverByDeviceId.ContainsKey($row.DeviceID)) {
        throw "missing or duplicate signed-driver inventory identity"
    }
    $driverByDeviceId[$row.DeviceID] = $row
}
$devices = @(
    Get-PnpDevice -PresentOnly |
    Where-Object { $_.Class -in @("Display", "ComputeAccelerator") }
)
if ($devices.Count -eq 0) {
    throw "no present display or compute-accelerator device was found"
}
$drivers = foreach ($device in $devices) {
    if ([string]::IsNullOrWhiteSpace($device.InstanceId) -or
        -not $driverByDeviceId.ContainsKey($device.InstanceId)) {
        throw "present accelerator device lacks a signed-driver inventory row: $($device.InstanceId)"
    }
    $driverByDeviceId[$device.InstanceId]
}
$findings = foreach ($driver in $drivers) {
    if ($policy.windows_provider_names -notcontains $driver.DriverProviderName -or
        $driver.IsSigned -ne $true -or
        [string]::IsNullOrWhiteSpace($driver.Signer) -or
        $policy.windows_signers -notcontains $driver.Signer) {
        throw "active accelerator driver is unsigned or has an unapproved signer: $($driver.DeviceID)"
    }
    [ordered]@{
        device_id = $driver.DeviceID
        inf_name = $driver.InfName
        driver_name = $driver.DriverName
        driver_version = $driver.DriverVersion
        provider = $driver.DriverProviderName
        signer = $driver.Signer
        is_signed = [bool]$driver.IsSigned
    }
}
New-Item -ItemType Directory -Force -Path evidence | Out-Null
$findings | ConvertTo-Json -Depth 5 |
    Set-Content -Encoding utf8 -LiteralPath evidence/windows-accelerator-driver-signatures.json
pnputil /enum-drivers /devices /files /format xml /output-file evidence/windows-driver-store.xml
if ($LASTEXITCODE -ne 0) { throw "PnPUtil driver-store readback failed" }

Fleet gate

Run the matching adapter on every eligible accelerator host or immutable node image and bind its policy digest, OS build, driver version, module/package population, signer, file digest, and host identity to the compliance result. A missing host, unapproved signer, disabled OS enforcement, absent expected module/package, inventory error, or unsupported OS adapter is insufficient coverage and blocks a green fleet assertion. Firmware authenticity remains with the hardware/firmware update control; this method owns loaded accelerator drivers.

Open-source tools

• tianocore/edk2 (open-source UEFI implementation)
• GRUB2 (Linux Secure Boot)
• shim (Linux Secure Boot)
• tpm2-tools (local TPM measurement and policy inspection)
• Keylime

Commercial / hosted tools

• Google Cloud Shielded VM (Secure Boot, vTPM, and integrity monitoring)
• Microsoft Azure Trusted Launch (Secure Boot and vTPM for supported VMs)
• Amazon EC2 (UEFI Secure Boot and NitroTPM on supported instances)

Threat mappings

MITRE ATLAS

• AML.T0010 AI Supply Chain Compromise
• AML.T0010.000 AI Supply Chain Compromise: Hardware

MAESTRO

• Supply Chain Attacks (Cross-Layer)

OWASP LLM Top 10 2026

• LLM04:2026 Supply Chain

OWASP ML Top 10 2023

• N/A

OWASP Top 10 for Agentic Applications 2026

• N/A

NIST Adversarial Machine Learning 2025

• N/A

Cisco Integrated AI Security and Safety Framework

• AITech-14.1 Unauthorized Access (Verifies the AI host boot chain before workload admission)

Google Secure AI Framework 2.0 - Risks

• N/A

Databricks AI Security Framework 3.0

• N/A