Free cookie consent management tool by TermsFeed Generator Update cookies preferences

Continuous Remote Attestation for the AI Era: A MITRE Framework

Invary, MITRE, and Fr0ntierX contributed to a new framework for continuously verifying system and workload integrity across AI, cloud, confidential computing, edge, and other high-assurance environments. Available for public review here.
Contact us to discuss the specification and see how Invary's Runtime Integrity verification implements Layer 3 of the framework →

AI is changing the assumptions behind cybersecurity.

The speed, variability, and scale of AI-enabled systems are putting more pressure on the infrastructure beneath them. Models are making decisions. Agents are taking actions. Sensitive data is moving through cloud, edge, and hybrid environments. Security teams are being asked to rely on increasingly complex systems, while adversaries are becoming more automated, adaptive, and difficult to predict.

In that environment, it is not enough to know that a workload started in the expected state.

Organizations need evidence that systems and workloads remain in the expected state while they are running.

That is the basic idea behind Runtime Integrity. Continuous remote attestation is how that integrity can be measured, verified, and communicated to relying parties.

Attestation has traditionally been used to verify a system or workload at a point in time, often when it starts. That is important, but it leaves a gap. A workload can begin in a known-good state and later be modified, compromised, redirected, or manipulated. Unauthorized code can execute. Runtime behavior can drift. Kernel memory can be altered. AI model pipelines can be tampered with. Communications can be relayed through endpoints that are not the systems they claim to be.

The question is no longer simply, “Did this system start correctly?”

The question is, “Can an independent relying party continuously verify that this system remains in a known and acceptable state without simply trusting the provider, the platform, or the workload to say so?”

MITRE, Fr0ntierX, and Invary have been working together to help answer that question through a new Framework for Continuous Remote Attestation, now released for public review. (MITRE press release here.)

Why Continuous Attestation Matters

Modern security depends on the assumption that the systems producing security data, enforcing policy, and running sensitive workloads are operating as expected.

That assumption is becoming harder to defend.

Security tools depend on system state. AI systems depend on system state. Compliance assertions depend on system state. Identity and access decisions increasingly depend on signals generated by systems that may themselves be targets.

If the underlying system is compromised, the signals coming from that system become suspect. Logs can be manipulated. Sensors can be blinded. Runtime controls can be bypassed. Model behavior can be influenced. Policy enforcement can be undermined.

This is why Runtime Integrity matters.

It gives organizations a way to ask whether the system is still in the state they believe it is in. Continuous attestation turns that question into evidence that can be shared with an independent verifier, a relying party, or an enforcement system.

That distinction is important.

A provider can claim that infrastructure is secure. A platform can report that a workload launched correctly. A workload can say it is healthy. But in high-assurance environments, claims are not enough. Organizations need verifiable evidence that can be evaluated outside the system making the claim.

Continuous remote attestation provides a framework for doing exactly that. It allows system and workload integrity to be evaluated continuously, communicated cryptographically, and used to drive decisions such as access, alerting, isolation, key release, compliance assertions, or revocation.

For AI, this becomes even more important.

An AI system may be protected from observation but still be influenced by a compromised runtime, unauthorized dependency, altered guardrail, manipulated data source, or unverified execution path. In those environments, integrity is not just a security property. It becomes part of decision confidence.

The Framework’s Core Idea

The Framework for Continuous Remote Attestation introduces an open, implementation-neutral architecture for verifying system and workload integrity over time.

At a high level, the framework defines a layered evidence model. Each layer answers a different integrity question.

Layer 1 focuses on platform state. Is the workload running inside a genuine, properly configured hardware-protected environment with acceptable firmware and platform measurements?

Layer 2 focuses on image and software state. Is the operating system, container, application, dependency set, and other declared workload artifact consistent with the expected baseline?

Layer 3 focuses on runtime state. Is the system still behaving as expected after launch, including kernel integrity, process activity, runtime measurements, network behavior, and other signs of compromise or drift?

That third layer is where the industry has historically had the least structure, and where Invary’s work is most directly aligned.

Runtime is where many of the most consequential attacks happen. It is where attackers manipulate kernel structures, hide processes, alter execution paths, and attempt to persist beneath conventional security tools. It is also where AI workloads, sensitive applications, and critical services actually operate.

A system that was valid yesterday, an hour ago, or at startup may not be valid in the moment a decision depends on it.

Continuous attestation gives relying parties a way to evaluate integrity as a living property, not a one-time claim.

Why This Is Bigger Than Confidential Computing

The framework is rooted in confidential computing because that is where remote attestation has advanced most visibly. Hardware-protected environments provide a strong foundation for proving where a workload is running and what state it started from.

But the broader issue is not limited to confidential computing.

Every organization running high-value workloads faces the same basic question: how do we know that the systems we depend on remain in the state we expect?

That question applies to AI infrastructure. It applies to cloud workloads. It applies to edge systems. It applies to critical infrastructure and OT environments. It applies to regulated workloads where compliance evidence needs to be current, machine-verifiable, and tied to actual technical state.

Continuous remote attestation gives the industry a common language for these questions.

  • What evidence is being collected?
  • Which part of the system does that evidence describe?
  • Who is allowed to verify it?
  • What assumptions are being made about the provider, platform, workload, or operator?
  • What happens when the evidence changes?

Those questions are becoming central to the next phase of security architecture.

AI Raises the Stakes

AI introduces integrity challenges that traditional infrastructure security was not designed to address.

Model weights can be enormous. RAG pipelines may depend on external data sources. Guardrail configurations may become security-relevant assets. Inference pipelines may execute across CPUs, GPUs, containers, and distributed services. GPU-based TEEs are becoming part of the confidential AI stack. Runtime behavior may matter as much as static code identity.

The framework recognizes these realities by mapping AI-specific controls into the same layered model.

Model weight integrity, model provenance, RAG data source registration, guardrail configuration integrity, GPU TEE attestation, and inference pipeline behavior can all become part of a continuous evidence model.

That matters because AI security cannot be reduced to protecting prompts or encrypting data. Those are important, but they do not answer the full set of integrity questions:

  • Was the right model loaded?
  • Were the right artifacts used?
  • Was the runtime environment modified?
  • Were data sources changed?
  • Were guardrails altered?
  • Is the communications path bound to the attested workload?
  • Is the system still in an acceptable state?

These are not theoretical questions. They are practical requirements for deploying AI in environments where decisions, data, safety, or compliance matter.

Runtime Integrity Is Foundational

Invary’s perspective on this work is straightforward: Runtime Integrity is becoming a foundational security control.

Security stacks depend on the systems they monitor. If those systems are compromised below the level where traditional tools operate, the entire security stack can lose confidence in what it is seeing.

This is why Runtime Integrity belongs in the attestation conversation.

Layer 1 can tell you about the platform. Layer 2 can tell you about the intended software. But Layer 3 is what helps answer whether the system has remained in an acceptable state during operation.

Invary’s technology is designed to detect sophisticated runtime threats, including advanced kernel memory manipulation and DKOM-style rootkits. These are the kinds of threats that can undermine system state without showing up as simple file changes or conventional event alerts.

This is not about replacing EDR, XDR, identity, cloud security, or application security. It is about strengthening the foundation those tools depend on.

You cannot make confident decisions from an unverified runtime.

Open, Interoperable, and Implementation-Neutral

One of the most important aspects of the framework is that it is not tied to a single vendor, product, cloud provider, or implementation.

That is the right approach.

The integrity problem is too important and too cross-cutting for any one company to solve alone. The ecosystem includes cloud providers, silicon vendors, GPU vendors, confidential computing platforms, AI operators, standards bodies, compliance regimes, and end users. Each has different requirements and different visibility into the system.

A useful framework has to account for those differences.

The framework introduces a multi-perspective model that recognizes that cloud providers, infrastructure tenants, application operators, and end users do not all consume attestation evidence in the same way. It also introduces provider trust stances, giving relying parties a way to express which trust anchors and verification paths they are willing to accept.

That is important because evidence is not just technical. It is also about who is making the claim, what the relying party is willing to accept, and what assumptions are valid for a given deployment.

By making those assumptions visible, the framework helps organizations reason more clearly about integrity, accountability, and risk.

The Direction Is Clear

The industry is moving toward environments where sensitive workloads run across cloud, edge, confidential computing, AI accelerators, and distributed infrastructure. At the same time, adversaries are moving faster and attacking deeper.

Static assumptions will not be enough.

Organizations will need ways to continuously verify that systems and workloads remain in an expected state. They will need evidence that is current, layered, cryptographically grounded, and usable by the parties that need to make decisions.

That is what continuous remote attestation is about.

Invary is proud to collaborate with MITRE and Fr0ntierX on this framework because it advances an idea we believe is essential for the AI era: Runtime Integrity must be continuously verifiable.

Confidential computing gives organizations stronger isolation.

Continuous attestation helps verify that the systems inside and around that isolation remain worthy of the decisions being placed on them.

As AI becomes more deeply embedded in enterprise, government, and critical infrastructure, that verification will become increasingly important.

The future of security will depend not only on protecting data, but on continuously proving the integrity of the systems that process it.

Read MITRE's press release and review the framework.

Contact us to discuss the specification and see how Invary's Runtime Integrity verification implements Layer 3 of the framework →