AI security
Microsoft Proposes an Evidence Gate for Edge AI: Verifying Both the Execution Environment and the Model Supply Chain
Microsoft recommends checking both hardware-rooted remote attestation and AI artifact provenance before releasing model weights, data, or credentials to edge devices. Models should only propose actions; actual authorization should be handled by a predictable external policy layer to prevent prompt injection from directly gaining system privileges.

Microsoft has published an AI security architecture for customer-owned edge environments. Rather than adding another security model, its core idea is to establish an “evidence gate” before releasing sensitive assets. Edge inference moves model weights, retrieval data, agent definitions, tool credentials, and control of physical equipment into locations that the provider cannot directly manage. Attackers may therefore gain simultaneous access to firmware, drivers, model files, and input content, meaning that signing application binaries alone is insufficient to describe a trusted state.
The architecture divides verification into two chains. The first is execution environment attestation: a hardware root of trust generates evidence, which is submitted to a Verifier that evaluates, according to policy, whether the firmware, operating system, drivers, and accelerators conform to an approved baseline. The result determines whether decryption keys or identity credentials are released. This aligns with the Attester, Verifier, and Relying Party model defined in IETF RFC 9334. The second chain concerns artifact provenance: model weights, prompts, tool descriptions, agent configurations, and retrieval indexes should all include information about their build provenance and the integrity of their inputs. SLSA provenance can describe the build definition, dependencies, and builder used to produce an artifact.
Microsoft also argues that model output should only “recommend” actions. A deterministic mediator outside the model should authorize them using allowlists, parameter ranges, rate limits, and credentials released on demand. Irreversible or high-consequence operations should still require human approval or safety interlocks. Attestation should not serve as a one-time pass; it should use expiring leases that require re-verification after device state drifts.
The article presents a design pattern, not a downloadable product, reference implementation, or performance study. Remote attestation can prove only that measured values comply with policy; it cannot prove that the model, retrieved documents, or permitted actions are themselves safe. GPU/NPU drivers, DMA paths, and physical attacks also expand the trusted computing base. Engineering teams should next examine common evidence formats spanning CPUs, accelerators, and model artifacts, as well as how disconnected devices can update baselines, revoke trust, and maintain fail-closed behavior.