How to secure edge AI in customer-owned environments

Summary

Edge AI shifts AI model execution and data processing to customer-owned infrastructure, necessitating new security paradigms. Organizations must now verify the trustworthiness of these environments, including hardware, software, and AI models, before releasing sensitive data and credentials. This involves attesting runtimes, verifying AI artifacts through provenance, constraining model actions, and binding assets only to trusted environments, especially in disconnected deployments.

Full text

Share Link copied to clipboard! TagsFrontier AI modelsContent typesResearchProducts and servicesMicrosoft Security CopilotTopicsActionable threat insights Edge AI moves model execution, model IP, customer data, and system authority into infrastructure the customer owns and operates. That changes who must verify the stack before sensitive assets are released. Edge AI includes AI systems where inference runs on or near the device, sensor, or other local environments where data is produced and acted on, rather than relying entirely on a centralized cloud service. It is chosen for cost, model selection, sovereignty, latency, and disconnected operation. Edge AI changes the trust model for AI systems In Cloud AI, separate companies own and attest the hardware, platform, and model weights. Edge AI deployments often place customers in control of more of the AI stack. This changes the security model because the customer is now responsible for establishing trust across the environment where the AI operates. In Edge AI, attacks such as prompt injection, model tampering, or malicious firmware updates can occur in the same environment that stores the model, customer data, credentials, and access to physical systems. This shifts trust decisions that were previously handled by cloud providers to the customer. Both the model provider and the customer now share risk: the provider’s models run on customer-owned infrastructure, while the customer must protect the systems, data, and models operating in that environment. What changes with Edge AI? Customers operate more of the AI stack. AI systems can be influenced by prompts, retrieval data, agent instructions, and runtime inputs. Models, credentials, and data can live in environments outside the provider’s direct control. Traditional software security controls alone are not enough. What should organizations do? Verify runtimes using attestation. Verify AI artifacts using provenance. Constrain model actions through mediation. Bind and release sensitive assets only to trusted environments. Our post on threat modeling for AI systems covers safety and security issues related to the underlying model. These concerns apply to Edge AI as well. Edge AI adds another question: before releasing weights, keys, or data, what evidence shows the runtime and loaded components can be trusted? Why Edge AI increases exposure An Edge AI deployment may include models, prompts, agents, retrieval data, policies, local data stores, and update mechanisms running on infrastructure outside the provider’s cloud environment. This moves sensitive AI assets and decision logic into potentially hostile environments. Attackers may have physical access to devices, local access to model artifacts, opportunities to tamper with retrieval data or tool configurations, compromise model supply chain and more direct paths from model behavior to real-world consequences. Disconnected Edge deployments cannot rely on live cloud detection, policy updates, or revocation. They must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should run only where hardware can protect assets and provide acceptable evidence. Otherwise, the operation should be deferred or revalidated. Why AI changes the security problem Unlike conventional software, AI models can be influenced by untrusted content while still using legitimate interfaces and credentials. This article focuses on the security response: architectures that constrain model actions and protect the model, credentials, and data around it. Traditional software executes code developers ship. AI systems can change behavior based on prompts, retrieval data, agent instructions, and other runtime inputs. Protecting code alone is no longer sufficient; organizations must also establish trust in the data, context, and actions surrounding the model. Prompt injection can change model behavior. Assume prompt injection will occur, whether direct or indirect. Inputs can affect systems just like executable code because the context window itself acts as an instruction surface. Traditional controls such as signed binaries and code integrity checks were not designed to address this risk. Trusted data is not always safe data. Traditional vulnerability management does not map cleanly to “data as code,” such as a poisoned retrieval document. Origin signatures can prove where data came from, but they do not prove that the content is safe for an AI system to interpret. AI behavior is not fully deterministic. The same input may produce different outputs, and small context changes can significantly alter behavior. This limits the effectiveness of techniques such as signature detection and fuzzing. Grounding and tuning improve reliability, but they cannot enforce an acceptable risk boundary. At the authority boundaries it mediates, deterministic policy can still constrain actions when alignment, prompt-injection defenses, or content filters fail to stop an unsafe instruction. Prompt injection, MCP, multi-agent systems, and computer-use agents on Edge expose different surfaces of these problems. Tool calls are delegated authority, agent output is untrusted input, and screen state is input, not authorization. These characteristics mean organizations cannot rely on traditional software security controls alone. They also need to verify the environment where AI runs and constrain the actions an AI system is permitted to take. Constrain model actions through deterministic mediation Model output should recommend actions, not authorize them. A deterministic mediator outside the model enforces policy by allowlisting actions, scoping arguments, limiting frequency, and releasing credentials only when approved. The mediator is a logical boundary, not another model. It may be provided by the platform or integrated by the customer. In this pattern, the mediator and its credentials are protected and attested. Mediation bounds what the model can do but does not guarantee that every permitted action is safe; high-consequence or irreversible actions require independent approval, an interlock, or fail-safe behavior. Establish trust before releasing sensitive assets Organizations must establish trust in the environment where AI runs and in the artifacts that shape AI behavior. Sensitive assets face two theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before release, the verifier asks two questions: Do I trust this runtime and the platform on which I am about to execute this workload? Do I trust these components, such as model weights, tool descriptors, agent definitions, and retrieval indexes, because I trust the system in which they were built and delivered? Attestation answers the runtime question. Provenance answers the component question. Verifier policy requires both. Either question alone leaves a gap: an approved runtime can load a poisoned artifact, while a trusted artifact can run on a compromised platform. In this trust model, the build system that produced an artifact is treated as another runtime whose evidence is evaluated, and the chain continues until it reaches hardware the verifier accepts. Evidence comes from across the hardware, firmware, runtime, model, integration, and customer layers. It serves different relying parties: customers containing model behavior, publishers protecting model IP, and integrators validating the supply chain. The verifier combines that evidence to gate release. Verify runtime before releasing sensitive assets This pattern evaluates a runtime by whether it is measurable, can report its state, and matches an approved baseline before sensitive assets are released. Confidential compute provides one way to do this. Without end-to-end confidential computing, a privileged host or unprotected accelerator path may be able to read or modify decrypted weights, credentials, and data. GPU/NPU drivers and

Entities