Published 09/02/2026
Originally published by Invary.
Written by
Jason Rogers
.
As AI makes decisions on infrastructure that changes by the minute, MITRE is formalizing how to verify those systems stay trustworthy while they run, not just when they boot.
Why MITRE built a new framework #
For most of computing history, we verified a system once and trusted it from there. A machine was provisioned, checked at startup, and assumed good until something obvious went wrong. The AI era has broken that assumption. Systems now make decisions and take actions faster than any team can supervise, across cloud, edge, and confidential computing environments that change constantly. A workload verified at launch may run for weeks. The distance between when a system is checked and when it is trusted has grown so wide that a clean start no longer tells you much about the present state.
This is why MITRE has put forward a new Framework for Continuous Remote Attestation, co-authored by Invary and Fr0ntierX, now open for public review.
MITRE convened a working group because the industry had advanced attestation at startup but left the harder question largely undefined: how do you continuously verify that a system stays trustworthy while it is actually running?
The assumption every security tool inherits #
Every log, every alert, every access decision, and every compliance assertion inherits its reliability from the system that produced it. The tools are only as trustworthy as the ground they stand on.
Attestation has traditionally verified that ground once, usually at startup. Confidential computing advanced this, giving organizations hardware-rooted proof that a workload began inside a genuine, protected environment. That proof is valuable, and MITRE's position is that it is no longer enough on its own.
A workload that passes every check at boot can later load unauthorized code, suffer a kernel-level compromise, or have its data manipulated, and nothing in a boot-time model re-examines it. MITRE states it plainly in the specification: verifying trust only at boot is no longer sufficient, because in a Zero Trust environment trust cannot be static and must be continuously verified.
Why this connects to MITRE ATT&CK #
MITRE is not new to this problem. The security community spent a decade building shared language for adversary behavior through MITRE ATT&CK, which catalogs the tactics and techniques attackers use and has become the reference that detection and response programs are built around.
ATT&CK's power rests on a condition rarely stated out loud: the telemetry feeding those detections has to be truthful. ATT&CK-aligned tooling reasons about process execution, file changes, and network connections, all reported by the system under observation.
That is the condition the deepest runtime compromises breaks. Techniques that manipulate kernel memory directly, including DKOM-style rootkits, alter what the operating system reports about itself. The system keeps answering queries. It just answers with a version of reality the attacker has edited.
Cataloging adversary behavior does not help when the record of that behavior is being written by the adversary. This is the layer where the industry has had the least structure, and it is the layer MITRE's new framework is built to address.
Where ATT&CK gave the industry a language for what attackers do, continuous remote attestation gives it a way to confirm the system is still trustworthy enough to be reporting on them at all.
What the MITRE framework defines #
The MITRE-led Framework for Continuous Remote Attestation defines a way to verify integrity continuously rather than once. MITRE developed it with founding collaborators Fr0ntierX and Invary, and released it through the Confidential Computing Layered Attestation Working Group.
It organizes the problem into layers. One covers the hardware platform. One covers the software and images. A third covers runtime state: whether the running system still matches the one that was verified, across kernel integrity, process activity, and runtime measurements. That third layer, runtime state, is where runtime integrity verification lives, and where Invary's contribution to the framework is rooted.
The clearest way to see why continuous verification matters is the patch gap.
The patch gap: the window between active exploitation and an applied fix, where conventional tooling cannot see an OS-layer compromise.
A vulnerability is disclosed. Within days it is being exploited. The median fix arrives weeks later. Through that window a system is exploitable but not yet patched, and conventional tooling operating on top of the operating system cannot see an OS-layer compromise during it.
Continuous runtime attestation verifies whether a system is still trustworthy regardless of patch status, so the exposed window is covered rather than waited out.
Why AI makes it urgent #
AI raises the stakes at exactly this layer. A compromised host does not need access to a model's weights to do damage. It can corrupt outputs, alter a guardrail, or manipulate a data source, and the model will appear to function normally while the results it produces are wrong.
Boot-time attestation confirms the system was clean when the workload started. Continuous runtime attestation confirms whether it stayed clean while the work was happening. For AI infrastructure, that difference carries real weight.
Trust has to be earned continuously #
This cross-cutting problem spans cloud providers, hardware and GPU vendors, confidential computing platforms, AI operators, standards bodies, and compliance regimes, each with different visibility and requirements.
By defining architectural roles, evidence layers, and trust stances rather than prescribing a product, MITRE gives that fragmented ecosystem a common language: what evidence is collected, which part of the system it describes, who may verify it, and what happens when it changes.
As trust becomes something earned continuously rather than assumed once, the organizations that can produce current, layered, verifiable evidence of runtime integrity will be the ones able to answer with proof rather than assumption.
The framework is open for public review now. Practitioners across confidential computing, AI infrastructure, and Zero Trust are invited to read the specification and help shape it.
About the Author
Jason Rogers is the Chief Executive Officer of Invary, which provides Runtime Integrity verification, leveraging technology exclusively licensed from the NSA. Invary is a founding collaborator on the MITRE-led Framework for Continuous Remote Attestation.
Unlock Cloud Security Insights
Subscribe to our newsletter for the latest expert trends and updates
Related Articles:
AI Governance Programs: What CISOs Say vs. What They Actually Do Published: 08/31/2026
What Zero Trust Can Teach Us About AI Watermarks Published: 08/28/2026
Multi-Cloud Data Pipelines: Why Key Management Can’t Be an Afterthought Published: 08/25/2026