On-Device Agent

What an on-device agent is doing on the endpoint

An on-device agent moves some decision-making and execution to the user’s device instead of relying only on a remote service. That changes the security boundary: the endpoint becomes part of the trust model, and the agent can act on local state, local policy, and device-scoped credentials while offline or in a degraded network state.

Because the software runs where the user works, it can reduce round trips and preserve responsiveness, but it also inherits endpoint realities such as local compromise, OS-level policy enforcement, and the risk that sensitive material is available closer to the user session.

In practice, the term is broader than “AI on a laptop.” It can include automation that checks access locally, inspects telemetry on the device, or filters content before anything is sent to a server. The common thread is that execution authority is partially local, not purely cloud-mediated.

Why the local execution model changes security assumptions

On-device execution narrows some exposure, but it also creates a different attack surface. If the agent can read local state or hold device-scoped credentials, then a compromised endpoint may expose more than just application data, it may expose the control plane the agent uses to make decisions.

This is why device hardening, secure storage, and OS policy enforcement matter so much. A local agent is only as trustworthy as the platform it runs on, the permissions it is granted, and the protections around its cached data, tokens, and configuration.

For AI-heavy implementations, the same principle applies to model and runtime protection. NHIMG’s On-Device AI Security Guide covers how shipped models, local runtimes, and OS AI features can be exposed when too much trust is placed in the endpoint.

How on-device agents differ from server-side agents

A server-side agent centralises control, logging, and policy enforcement, while an on-device agent distributes those responsibilities across many endpoints. That can be useful for latency, resilience, privacy, and offline operation, but it also makes fleet-wide consistency harder because each device becomes a smaller enforcement point.

The distinction matters when comparing access checks, telemetry, or content filtering. On a server, those controls can be imposed centrally. On-device, they often depend on the endpoint’s integrity, its management posture, and whether the local environment can be trusted to enforce policy faithfully.

That is also why identity and delegation questions appear quickly. If the agent performs actions on the user’s behalf, the design must make clear whether it is using its own local authority, a delegated user context, or a device-bound trust relationship. NHIMG’s AI Agent Authorisation Guide explains why least privilege and per-action checks matter when an agent is allowed to act.

What protects device-scoped credentials and local state

The most important safeguard is to minimise what the agent can hold locally. If the endpoint stores long-lived secrets, broad session material, or reusable tokens, compromise of the device can become compromise of the broader identity context. Short-lived tokens, bound credentials, and server-side validation reduce that blast radius.

Local state should be treated as sensitive even when it is “just cache.” Cached decisions, prompts, policy results, and telemetry can reveal workflow details, user behaviour, or access patterns. That makes storage protection, encryption, and careful retention policies part of the security model, not optional extras.

Where the agent operates in an agentic workflow, the trust boundary extends to every action it can trigger. NHIMG’s OWASP Agentic Top 10 ASI03 Guide is relevant because overbroad privileges and weak action scoping are often what turns a useful local assistant into a risky local operator.

When on-device agents improve privacy and resilience

Running locally can improve privacy because less raw data needs to leave the device. It can also improve resilience when the agent must continue working during limited connectivity, or when the organisation wants to keep some decisions close to the user and away from a central service.

Those benefits are real, but they only hold if the endpoint is sufficiently trustworthy and the operating model is clear. If the device is unmanaged, the agent’s autonomy can become a weakness rather than an advantage, especially when local decisions affect authentication, policy enforcement, or content handling.

For mobile and endpoint use cases, the control lesson is simple: local execution is valuable when it is paired with strong device posture, constrained permissions, and a clear boundary around what the agent may decide without remote confirmation. NHIMG’s Android Banking Trojans Guide shows why endpoint controls matter when local abuse paths can be used to intercept or redirect sensitive activity.

Related resources from NHI Mgmt Group

• Device Agent
• What breaks when an endpoint agent is still installed on a former employee's device?
• What is the difference between OAuth device flow and CIBA for agent approval?
• What is the difference between user agent spoofing and device fingerprinting?