Why do VPN-based controls fail for ChatGPT-style tool access?

Why This Matters for Security Teams

VPN-based controls were built to decide whether a device or user can join a network, not whether an autonomous cloud model should be allowed to invoke a database, read a file, or write back to a system of record. That distinction matters because ChatGPT-style tool use is request-driven and context-sensitive. The security problem is not the tunnel itself, but the authority behind each tool call. NHI Management Group’s Ultimate Guide to NHIs treats this as an identity and authorization problem, not a perimeter problem.

Traditional VPN logic also collapses under model behaviour that changes with prompts, retrieved context, and chained tool actions. Once the model is operating from outside the corporate perimeter, a network tunnel can no longer express intent, task scope, or data sensitivity. Current guidance from the OWASP Non-Human Identity Top 10 and broader NHI practice points toward workload identity and policy-based authorization instead of static network trust. In practice, many security teams discover over-permissioned tool access only after an agent has already queried data it was never meant to see.

How It Works in Practice

The practical replacement for VPN-based trust is to bind each tool request to a workload identity and evaluate policy at runtime. The model or agent should present cryptographic proof of what it is, then request short-lived authorization for the specific action it is trying to perform. That is fundamentally different from a persistent network session. In agentic systems, the safer pattern is usually a combination of identity, intent, and context: who or what is calling, what task is being attempted, what data is involved, and whether that action is allowed right now.

That often means combining ephemeral credentials with policy-as-code. A service like SPIFFE or OIDC can represent the workload identity, while an authorization layer such as OPA or Cedar can decide whether the call should proceed. For tool access, just-in-time credentials should be issued per task, scoped tightly, and revoked automatically when the task ends. This reduces the value of stolen tokens and prevents a model from reusing standing access across unrelated prompts. NHI-specific research on LLMjacking shows why that matters: when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

• Authenticate the workload, not the network location.
• Authorize each tool call at request time, not through a blanket VPN grant.
• Use short-lived secrets and revoke them after the task completes.
• Separate read, write, and administrative tools so one prompt cannot escalate into another.

This approach aligns with the SPIFFE model for workload identity and the emerging agent security guidance in NIST AI Risk Management Framework. These controls tend to break down when legacy apps only accept network-based trust and cannot evaluate per-request identity or policy.

Common Variations and Edge Cases

Tighter per-request authorization often increases operational overhead, requiring organisations to balance control granularity against developer friction and latency. That tradeoff becomes especially visible in hybrid environments where some tools are modern API services and others still depend on coarse network segmentation. There is no universal standard for this yet, so best practice is evolving toward layered controls rather than a single replacement for VPNs.

Some teams use a VPN as one ingredient in a broader access model, but that should be treated as transport protection only, not as the decision point for tool use. Shared service accounts, long-lived API keys, and flat tool permissions are especially risky because they let one successful prompt inherit broad authority. The State of Secrets in AppSec underscores the problem: leaked secrets often persist long enough to be exploited, and fragmented secrets handling weakens central control. For governance, the Ultimate Guide to NHIs — Standards is the better starting point than network-centric thinking.

Edge cases also appear when the agent can chain tools, call external APIs, or write outputs that trigger downstream automation. In those environments, a VPN may still encrypt traffic, but it cannot express whether a model may read one record, update another, or trigger a workflow. That is why current guidance suggests treating the model as an autonomous workload with its own identity and policy boundary, not as a user sitting behind a corporate tunnel.

Related resources from NHI Mgmt Group

• How should security teams replace VPN access with identity-based controls?
• How should security teams govern privileged access when replacing VPN access with gateway-based controls?
• How should teams choose a Kubernetes ingress controller for identity-based access?
• How do access controls differ between the API layer and the retrieval layer?