When the AI Runs on Your Hardware, You Own the Security Problem
Microsoft says customers running AI on their own kit inherit a security job cloud providers used to handle. Here is what that actually means.
Key points
- Microsoft's Security Response Center has told organisations running AI on their own hardware that they, not Microsoft, must now verify the system is safe before models, keys or customer data are released to it.
- The guidance covers Edge AI, meaning AI that runs on a device or local server rather than in a centralised cloud data centre.
- Microsoft warns that prompt injection, where hidden instructions in a document or web page hijack an AI, should be treated as inevitable rather than hypothetical.
- The company recommends a "deterministic mediator", a separate piece of software that decides whether the AI is actually allowed to do what it just suggested.
- The advice applies directly to buyers of Azure Local, Microsoft's on-premises version of Azure that runs on customer-owned machines.
Microsoft has published guidance on securing AI systems when they run on hardware the customer owns. The honest summary: the trust work that used to be someone else's problem is now yours.
The advice comes from the Microsoft Security Response Center. It targets Edge AI, meaning AI models that run on a local machine or back-office box rather than inside a distant cloud.
Why does this matter to a normal business?
The security model flips. In a cloud AI service, the provider proves the hardware is genuine, the software hasn't been tampered with, and the model weights (the large file that makes the AI work) haven't been swapped out. On Edge AI, the customer's own IT team has to prove all of that.
Microsoft is direct about the exposure. The model, the credentials, customer data and the ability to control physical systems can all end up sitting on the same box, in a room an attacker might be able to walk into.
What is Microsoft actually telling people to do?
Four things, and they're worth translating.
| Microsoft's term | What it means in plain English |
|---|---|
| Attestation | The machine has to prove, using a hardware chip, that it is running the software it claims to be running. |
| Provenance | Every model file, plugin and reference document has to come with a verifiable record of where it was built. |
| Deterministic mediation | A separate, non-AI gatekeeper decides whether the AI is allowed to run the action it just proposed. |
| Confidential compute | The data stays encrypted even while the chip is using it, so a rogue administrator cannot peek. |
The mediator idea is the one worth dwelling on. Microsoft is saying the model should recommend actions, never authorise them. Something else, something predictable, checks the request against an allowlist before any credential is released or any button is pressed. We first covered confidential computing on 23 July 2026, and our DDRop story from 17 September shows exactly why hardware-level attestation isn't foolproof: a small circuit can trick confidential computing into reading stale data as fresh.
Where does Azure Local fit in?
Directly. Azure Local is Microsoft's product for running Azure services on hardware the customer owns, including disconnected sites like ships or sovereign government facilities. It's managed through the normal Azure portal, but the boxes sit in the customer's building. That's exactly the setup this guidance is written for.
Disconnected sites get a special mention. If the machine can't phone home, it can't rely on Microsoft to spot a bad model update or revoke a stolen key. Local verification has to run every time, without a safety net.
What about prompt injection?
Microsoft's line is refreshingly blunt: assume it will happen. Prompt injection is when an attacker hides instructions inside something the AI reads, a support ticket, a PDF, a web page, so the model quietly follows the attacker's orders instead of the user's. Signed binaries and antivirus were never designed to catch this, because the AI is doing exactly what its inputs told it to do.
That's why the mediator matters more than any content filter. Filters fail. A hard-coded rule that says a particular account cannot take a high-value action without a human click doesn't.
Should you worry?
If you're running an AI agent connected to real systems and there's no deterministic gatekeeper in front of it, yes. Multi-factor authentication won't save you here. The AI already holds the credentials. What matters is who decides when it gets to use them, and right now, at most Edge AI deployments, the answer is: the model does.
