Why do traditional VPN and OAuth controls fall short for AI agents?

Why Traditional VPN and OAuth Controls Fall Short for AI Agents

VPNs and OAuth were designed around a human operator or a predictable service account, not an autonomous agent that can decide, chain, and execute new actions mid-workflow. A VPN may prove network reachability, but it does not prove task intent. OAuth scopes may authorise broad API access, but they often fail to express what an agent should do right now, in this context. That mismatch is why agent behaviour is a security boundary, not just the token.

This problem is already visible in current deployments. NHIMG’s analysis in AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have performed actions beyond intended scope, while only 44% have implemented policies to govern them. Industry guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to runtime controls as the more durable answer.

In practice, many security teams discover overbroad agent access only after the agent has already chained tools, crossed environments, or disclosed data outside the intended workflow.

How It Works in Practice

The security model shifts from durable trust to task-scoped trust. Instead of assuming a VPN session or OAuth grant is enough, teams should treat each agent action as a separate authorisation decision. The practical pattern is a combination of workload identity, short-lived credentials, and policy evaluation at request time. That means the agent proves what it is, requests only what it needs, and receives access only for the task at hand.

For implementation, current guidance suggests using workload identity primitives such as SPIFFE or OIDC-backed service identities to establish cryptographic proof of the agent workload. That identity can then be paired with just-in-time credential issuance so secrets, tokens, or API keys exist only for a narrow TTL and are revoked automatically after task completion. This reduces the blast radius if an agent is compromised or begins unexpected tool chaining.

Policy should also be evaluated dynamically. A static OAuth scope like “read all tickets” is too coarse for an agent that may only need to retrieve one record, summarise it, and draft a response. Instead, policy-as-code approaches such as OPA or Cedar can evaluate the request context, task objective, data sensitivity, environment, and recent agent behaviour before allowing the call. NHIMG’s OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reinforce this move toward runtime control and threat-aware governance.

• Replace long-lived OAuth grants with short-lived, task-bound tokens.
• Bind agent identity to the workload, not the human who launched it.
• Evaluate permissions at request time using policy and context.
• Revoke credentials automatically when the task ends or behaviour changes.

These controls tend to break down when legacy systems only support coarse scopes or when agents must operate across many unmanaged SaaS tools because context-aware policy cannot be enforced end to end.

Common Variations and Edge Cases

Tighter agent controls often increase integration overhead, requiring organisations to balance operational speed against the risk of over-permissioned automation. That tradeoff becomes sharper when an agent spans multiple APIs, vendor platforms, or internal services with inconsistent identity models.

One common edge case is delegated human approval. A human may approve a task, but that approval should not become a blanket authorisation for every downstream action the agent chooses to take. Another is shared infrastructure, where multiple agents run on the same cluster or orchestration layer. In those environments, workload identity must distinguish each agent instance, not just the platform. Best practice is evolving, but there is no universal standard for this yet.

Another failure mode appears when teams rely on broad network trust after a VPN login. That model assumes a stable perimeter and predictable access paths, which agentic systems do not provide. If the agent can call tools, invoke other agents, or process sensitive data in real time, the security decision must move closer to the action itself. The NIST AI Risk Management Framework and MITRE ATLAS adversarial AI threat matrix are useful references for mapping these runtime risks, while NHIMG’s Salesloft OAuth token breach illustrates how quickly token abuse can translate into enterprise data exposure.

Teams that keep static VPN and OAuth assumptions in place usually learn the hard way that agent compromise is not a login problem, but a workflow-control problem.

Related resources from NHI Mgmt Group

• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern AI agents that use OAuth access?
• Why do AI agents create a different access-risk profile than traditional applications?
• Why do traditional CIAM controls fall short for AI agent access?