Should organisations support AI agent access on devices where the main VPN client cannot be installed?

Why This Matters for Security Teams

Supporting AI agent access on devices that cannot run the standard VPN client is a governance problem, not just a connectivity workaround. Autonomous tools still need verifiable identity, scoped network reach, and auditability, but they do not behave like fixed human users. Static device trust and broad network access can turn a convenience exception into an uncontrolled path to secrets, internal APIs, and data stores.

That risk is already visible in the field. NHIMG’s AI Agents: The New Attack Surface report notes that 80% of organisations report agent actions beyond intended scope, while only 52% can track and audit the data those agents access. The lesson is clear: constrained endpoints still need governed access, but the control plane has to follow the workload, not the device alone. Current guidance suggests pairing identity, policy, and short-lived credentials instead of extending the whole machine onto the network.

Practitioners should also treat this as a secrets problem. If the access path depends on long-lived tokens or copied credentials, the exception becomes harder to contain than the VPN limitation itself. In practice, many security teams encounter these failures only after an agent has already used a local exception path to reach systems it was never meant to touch.

How It Works in Practice

The usual pattern is a bridge architecture: the constrained device connects to a narrow local component, and that component reaches the AI gateway or broker that enforces policy. The device does not become a full network node, which reduces lateral movement risk. Instead, the agent receives access through a controlled path that can be inspected, logged, and revoked independently of the endpoint.

For agentic workloads, the strongest model is to issue access at runtime based on task context. That means short-lived secrets, task-scoped tokens, and workload identity rather than static entitlements. The identity primitive should describe what the agent is, not just where it is running. Standards-oriented teams often look to SPIFFE-style workload identity and policy engines evaluated at request time, because they fit autonomous behaviour better than pre-approved network access rules.

• Use a local bridge or relay so the device reaches only the gateway it needs, not the full internal network.
• Bind the agent to workload identity and issue ephemeral credentials per task, with automatic revocation on completion.
• Enforce policy at the gateway using current context, such as target system, action type, and data sensitivity.
• Log tool calls, token use, and downstream access so investigation can reconstruct agent behaviour after the fact.

This approach aligns with the risks described in OWASP NHI Top 10 and the external OWASP Agentic AI Top 10, both of which stress runtime control over assumed trust. It is also consistent with the NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework, which both favour continuous risk evaluation. These controls tend to break down when the bridge is treated as a generic network proxy for unmanaged laptops, because the gateway then loses the context needed to distinguish a valid task from an unsafe one.

Common Variations and Edge Cases

Tighter routing often increases operational overhead, requiring organisations to balance endpoint simplicity against policy precision. That tradeoff is real for shared kiosks, contractor devices, air-gapped workstations, and regulated environments where installing a full VPN client is not possible. Best practice is evolving, and there is no universal standard for every constrained-device scenario yet.

One common edge case is a device that can reach the gateway only through browser-based access or a local helper service. That can work, but only if the helper does not store reusable secrets and the gateway still enforces per-request authorisation. Another case is multi-agent workflows, where one agent can chain tool calls and exceed the original intent. In those environments, a narrow network path alone is not enough; the policy layer must inspect each action as it occurs.

NHIMG’s Meta AI Instagram Account Takeover and CoPhish OAuth Token Theft via Copilot Studio show how quickly agent access can be abused when identity and token scope are too broad. The practical takeaway is simple: if the device cannot host a VPN client, move the trust boundary to the gateway, keep credentials ephemeral, and avoid any design that lets the bridge become a back door.

Related resources from NHI Mgmt Group

• What breaks when organisations cannot correlate AI agents to the business capabilities they were built to support?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• Why is JIT access important for AI agent management?