Reviewed by Oleksandr Sobovyi, Founder & CEO of CORVUS AI — editorial responsibility statement below.

Microsoft has published a new security architecture for Edge AI — models and agents operating directly on devices, in vehicles, manufacturing environments, hospitals, and other customer infrastructure.

Microsoft’s key point is that moving AI from a provider-controlled cloud environment into customer-owned infrastructure changes the trust model itself. The customer gains control over substantially more elements of the AI stack and, accordingly, must take responsibility for establishing trust in the runtime, firmware, model artifacts, retrieval data, credentials, and tool configuration.

For CORVUS, this is particularly important given our work with industrial AI, autonomous systems, drones, and dual-use technologies.

1. What Has Changed

Cloud AI typically follows a structure along these lines:

provider infrastructure → provider model → API → customer application.

A significant proportion of security controls remains with the hyperscaler or model provider.

Edge AI looks different:

hardware → firmware → runtime → model → retrieval data → agent → credentials → physical system.

A much larger part of this chain is now controlled by the deployer/operator.

Microsoft highlights an additional problem: an edge environment may simultaneously contain:

• model weights;

• customer data;

• credentials;

• local tools;

• access to physical equipment.

As a result, compromising a single environment may give an attacker simultaneous access to AI capability + authority + sensitive assets + physical effect.

This is materially different from conventional SaaS risk.

2. Microsoft’s Core Rule: Model Output Should Not Itself Create Authority

The strongest element of the new architecture is deterministic mediation.

Microsoft formulates a principle that is very close to the approach CORVUS needs:

Model output should recommend actions, not authorize them.

An independent deterministic control layer should sit between the AI system and real-world action.

That layer can:

allowlist actions

→ constrain arguments

→ impose frequency limits

→ release credentials only for an authorised action

→ require independent approval for high-consequence operations.

Critically, Microsoft specifically emphasises that this mediator should not itself be another AI model.

This is a significant practical standard.

For industrial and physical AI, the appropriate architecture therefore becomes:

AI proposes → deterministic policy checks → authority released → action executed.

Rather than:

AI decides → AI executes.

3. For CORVUS, This Provides a Stronger Model for Human Oversight

Until now, we have often framed the control model as:

human approval → execution.

Microsoft demonstrates why, for physical and edge AI, this may not always be sufficient.

Two independent layers are needed:

Human authority

and

machine-enforced operating boundaries.

For example, a drone or robotics agent may receive human authorisation to perform a mission, while the deterministic layer should still block:

• entry into a prohibited geographic zone;

• exceeding an established speed limit;

• use of a prohibited tool;

• action outside the authorised mission scope;

• use of an unverified credential.

In other words:

human approval authorises the mission; deterministic control limits the means.

For defence and autonomous systems, this is a particularly strong governance principle.

4. The Second Major Shift: Before Releasing Keys or Data, the Environment Must Prove That It Can Be Trusted

Microsoft proposes two distinct mechanisms:

Attestation — evidence that the runtime/environment is in the expected state.

Provenance — evidence of the origin and integrity of components that influence AI behaviour.

Importantly, verification should extend beyond:

model weights,

to include:

• agent definitions;

• tool descriptors;

• retrieval indexes;

• prompts and policies;

• software updates.

Microsoft effectively proposes making the release of credentials and data conditional:

evidence valid → asset released.

If the environment no longer matches the approved baseline:

evidence fails → credentials/data are withheld or revoked.

This comes very close to the concept of continuous conformity.

5. Why This Matters Legally for the AI Act + Product and Industrial Law

Here, it is important to distinguish carefully between regulatory obligations and good engineering practice.

The AI Act does not say: “use hardware attestation.” However, for AI embedded in physical products or industrial systems, an organisation must be able to demonstrate that the relevant risk controls actually operated in the deployed environment.

Accordingly, evidence that:

“we tested the model”

is increasingly weak.

A much stronger assurance record would capture:

model version

→ approved runtime

→ approved artifacts

→ permissions

→ policy state

→ execution evidence.

This becomes particularly important where AI governance intersects with machinery and product safety, cybersecurity, and product liability.

6. A New Risk: Configuration Drift Becomes a Legal Assurance Problem

Microsoft makes another useful observation.

Even an approved runtime can change over time:

firmware update → new retrieval index → changed agent definition → new tool → modified policy.

Approval should therefore not automatically extend to a materially changed system state.

The principle can be formulated as follows:

A previously approved AI deployment should not automatically remain approved after a material change to its runtime or behaviour-shaping artifacts.

This aligns particularly well with the CORVUS Material Change Trigger concept already under development.

Opportunity for CORVUS

This creates a strong specialised workstream within AI System Assurance:

Edge & Physical AI Assurance

Particularly for:

industrial automation / robotics / drones / defence / logistics / autonomous systems.

The assurance scope could cover:

Model

→ Runtime

→ Hardware

→ Agent

→ Tools

→ Credentials

→ Physical authority

→ Deterministic controls

→ Attestation

→ Provenance

→ Change management.

Commercially, this is materially stronger than generic AI-policy work because it directly connects law + system architecture + physical risk.

Disclaimer

This article has been prepared by CORVUS AI for general informational and educational purposes only. It is intended to make complex legal and regulatory developments easier to understand.

It does not constitute legal advice and does not create a professional adviser–client relationship. The information should not be relied upon as a substitute for advice based on the specific facts, circumstances and applicable law relevant to your organisation or project.

The article reflects our understanding of the law and regulatory framework as of the date of publication. Legislation, case law, regulatory guidance and administrative practice may subsequently change. While reasonable care has been taken in preparing this article, CORVUS AI does not warrant that the information is complete or remains current after the date of publication. We do not undertake to update this content.

To the fullest extent permitted by applicable law, CORVUS AI excludes liability for loss arising from reliance on this article. Nothing in this article constitutes an offer or solicitation to provide regulated legal services in any jurisdiction where doing so would be unlawful.

AI-assisted preparation: This article was prepared with the assistance of AI tools. Its legal analysis, conclusions and final text were subject to human review and editorial control and were reviewed and approved prior to publication by Oleksandr Sobovyi, Founder & CEO of CORVUS AI. CORVUS AI retains editorial responsibility for the published content.

For advice tailored to your organisation, project or specific circumstances, please contact CORVUS AI.