Edge AI Shifts Security Responsibilities to Customers in New Trust Model

Edge AI shifts the responsibility of security from centralized cloud providers to customers, fundamentally altering the trust model for AI systems.

Edge AI refers to artificial intelligence systems where inference occurs on or near the data source, such as devices or sensors, rather than relying solely on centralized cloud services. This approach is often favored for reasons including cost efficiency, model selection, data sovereignty, reduced latency, and the ability to operate in disconnected environments.

Changing the Trust Model for AI Systems

In traditional Cloud AI setups, distinct entities manage and verify the hardware, platform, and model weights. However, Edge AI deployments frequently place customers in control of a larger portion of the AI stack, thereby altering the security paradigm. Customers are now tasked with establishing trust across the entire environment where the AI operates.

This shift introduces new vulnerabilities. Attacks such as prompt injection, model tampering, and malicious firmware updates can occur within the same environment that houses sensitive models, customer data, and access credentials. Consequently, the responsibility for trust decisions, previously managed by cloud providers, now falls to the customer. Both the model provider and the customer share the risk: while the provider’s models run on customer-owned infrastructure, the customer must safeguard the systems, data, and models within that environment.

Key Changes with Edge AI:

• Customers manage a larger portion of the AI stack.
• AI systems can be influenced by various inputs, including prompts and retrieval data.
• Models, credentials, and data may exist in environments beyond the provider’s direct control.
• Traditional software security measures are insufficient.

Recommended Actions for Organizations:

• Utilize attestation to verify runtimes.
• Employ provenance to verify AI artifacts.
• Constrain model actions through mediation.
• Bind and release sensitive assets only in trusted environments.

As highlighted in a post on threat modeling for AI systems, these security concerns are pertinent to Edge AI as well. A critical question arises: what evidence can confirm that the runtime and its components are trustworthy before releasing sensitive assets?

Increased Exposure with Edge AI

Deploying Edge AI can involve models, prompts, agents, retrieval data, and local data stores operating on infrastructure outside the provider’s cloud environment. This transition places sensitive AI assets and decision-making logic in potentially hostile settings. Attackers may gain physical access to devices, tamper with model artifacts, or compromise the model supply chain, creating direct pathways from model behavior to real-world consequences.

Disconnected Edge deployments cannot rely on live cloud detection or policy updates; they must maintain local verification and enforcement when cloud connectivity is unavailable. Risky AI operations should only occur where hardware can adequately protect assets and provide acceptable evidence. Otherwise, operations should be deferred or revalidated.

Why AI Changes the Security Problem

Unlike conventional software, AI models can be influenced by untrusted content while still utilizing legitimate interfaces and credentials. This necessitates a shift in security response strategies, focusing on architectures that constrain model actions and protect surrounding data and credentials.

Traditional software executes code as shipped by developers, while AI systems can alter their behavior based on various runtime inputs. Protecting code alone is no longer adequate; organizations must also establish trust in the data and context surrounding the model.

• Prompt injection can alter model behavior. Organizations should assume that prompt injection will occur, whether directly or indirectly. Inputs can affect systems similarly to executable code, as the context window itself acts as an instruction surface. Traditional controls like signed binaries and code integrity checks are not designed to mitigate this risk.
• Trusted data is not always safe data. Conventional vulnerability management does not easily apply to “data as code,” such as a poisoned retrieval document. While origin signatures can verify data sources, they do not guarantee that the content is safe for AI interpretation.
• AI behavior is not fully deterministic. The same input may yield different outputs, and minor context changes can significantly alter behavior. This variability limits the effectiveness of techniques like signature detection and fuzzing.

These characteristics indicate that organizations cannot rely solely on traditional software security controls. They must also verify the environment where AI operates and constrain the actions permitted to an AI system.

Establishing Trust Before Asset Release

Organizations must establish trust in both the environment where AI runs and the artifacts that shape AI behavior. Sensitive assets face two primary theft vectors: at-rest theft from stored artifacts and keys, and runtime theft while a compromised process holds them decrypted. Before releasing sensitive assets, verifiers should ask:

• 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 and retrieval indexes, based on the system in which they were built and delivered?

Attestation addresses the runtime question, while provenance addresses the component question. Both are necessary to fill the gaps that could arise if either question is answered in isolation.

In conclusion, Edge AI fundamentally alters the trust model for AI systems. Customers now operate more of the stack, and sensitive assets run in environments outside the provider’s direct control. Employing attestation, provenance, mediation, and evidence-based release strategies can help establish trust before exposing models, data, and credentials.

For further insights into the implications of Edge AI on security, see the full article by Microsoft here.