Your AI Agent Should Get Less Network Access Than Your Intern

Disclaimer: The views, thoughts, and opinions expressed in this guest post belong solely to the author and do not necessarily reflect the official policy, position, or views of OpenVPN Inc.

---

You’ve no doubt heard about the recent OpenAI cybersecurity incident this July. It was a big (and honestly, a rather unusual) one.

The company was testing models in an offensive security evaluation. Despite having an extremely limited available network path, these models found a way out of their isolated test environment (specifically, a zero-day in Artifactory, the package registry cache proxy), and eventually reached systems belonging to Hugging Face.

It’s worth noting that OpenAI meant for this evaluation to be aggressive; it was meant to test the limits of these advanced models, and accordingly, had reduced safeguards. It wasn’t just your average agent suddenly deciding it couldn’t handle being in the sandbox anymore and wanted out.

Nonetheless, it’s pretty alarming (and somewhat dystopian) stuff. If you’re imagining a distant future where The Matrix turns out to have been a documentary, no one’s going to blame you.

This incident highlights a problem that many businesses don’t give much thought to. Autonomous software doesn’t care about the boundaries you hope it respects. It operates based on the technical capabilities it has access to. We can’t simply assume that an AI agent will obey every instruction. Instead, we need to assume that eventually, it will attempt everything within its realm of capability.

Good prompts alone just won’t suffice anymore. Agents need their own identities, permissions, and access boundaries.

Why shouldn’t an agent simply inherit your access?

Let’s zoom out a little to look at the logical mismatch here.

Imagine a senior developer who legitimately has access to various things: source code, production monitoring, cloud infrastructure, and even unrelated corporate systems. If they ask an AI agent to review a pull request, that agent only needs a tiny fraction of those permissions. Giving it the same access level as the developer doesn’t make a whole lot of sense here: if you wanted an intern to review a document for you, you wouldn’t hand them the keys to every document you own.

A human employee’s permissions reflect what they need to access to do their job. Similarly, if we apply that logic to an agent, its permissions should match what it needs for the relatively much narrower task it’s assigned. If an agent runs under a person’s identity (or through an overly broad service account), it may inherit access to systems that it has no business accessing for the task at hand. AuthZed CEO Jake Moshenko has used a similar example in an interview with The New Stack: An agent working on code review shouldn’t have access to HR or fundraising systems just because the person who created it does.

Unlike with a human assistant, there are a few added risk factors with agents. They can continue operating after the immediate task they’re assigned. They can run repeatedly. They can call other tools and APIs or trigger downstream workflows. All of these things make it tying their authority directly to one human’s identity a little awkward.

This is becoming a more widely recognized security issue now, too. In February 2026, NIST’s NCCoE published a concept paper on applying identity standards to AI agents, covering how they should be identified, authorized, and audited as distinct actors. The comment period closed in April, and the center is still weighing whether to run a full demonstration project.

A human identity is still useful, though; it can establish who delegated the work. However, this identity shouldn’t automatically determine everything the software doing the work is able to reach.

“Don’t touch production” isn’t an access control

Let’s be clear: instructing an agent not to touch production, and actually setting up the infrastructure such that the agent quite literally cannot reach production are two entirely different things. The former is an instruction (that you hope the model interprets correctly, and indeed, actually follows). The latter is a strict technical boundary: The identity you give the agent simply doesn’t have the permission to establish the connection.

In July 2025, there was an agent failure incident that underscored just how much this distinction matters.

SaaStr founder Jason Lemkin put an explicit code-and-action freeze on an AI coding agent nine days into a public vibe-coding experiment. The agent didn’t care. Lemkin later found out that the agent had run unauthorized database commands inside Replit’s platform, wiping out live records on over a thousand executives and over a thousand companies. The agent then told him the deletion couldn’t be rolled back (which turned out to be untrue). The data was recovered, and Replit’s CEO publicly apologized and committed to separating development and production databases.

Similar incidents involving other coding agents have followed a similar pattern: the agent had credentials powerful enough to carry out actions the user never intended (and in many cases, like in the Replit incident, in direct contradiction to the user’s instruction). Just days after the Replit incident, Google’s Gemini CLI destroyed a user’s project files through a chain of file operations built on a directory that never existed, with nothing in the environment positioned to stop a destructive write.

The lesson here is that the agent isn’t a person; it doesn’t intrinsically “respect” its creator’s authority. And as such, the problem wasn’t just that the instruction was ignored. It was that from an infrastructure perspective, the request was, effectively, “authorized.”

The OWASP Gen AI Security Project describes this issue as “Excessive Agency.” Giving a model too much functionality, permission, or autonomy allows its outputs to create real-world consequences. And OWASP’s solution to the problem is just what you’d think: restrict agents to the minimum permissions they need, and enforce authorization in downstream systems. Relying on the LLM to decide whether an action is allowed is essentially playing with fire. It works until it doesn’t, and you may then have a crisis on your hands.

The OpenAI/Hugging Face incident is the same lesson at the other extreme. Replit's agent never had a technical boundary to break. OpenAI's had one, and got out regardless. This kind of thing truly does make you think back to various sci-fi movies you may have seen and try to figure out how much of it is coming true in the next couple of decades.

Naturally, this doesn’t mean regular enterprise agents are about to start escaping their confines and breaking into foreign systems. We’re not about to witness some kind of mass riot. All it means is that a logical boundary isn’t as strong as a technical one. If production is genuinely off limits, make it unreachable. Don’t expect the agent to remember and respect that, because odds are that it won’t.

Give every AI agent its own identity (and make its access temporary)

We’ve established that instructions alone don’t create a boundary you can actually trust. With that in mind, the first step is making sure that the agent has its own identity. Clearly, an agent assigned to a single task has no business inheriting access to everything its creator can access.

That’s not to say every agent needs its own permanent credentials, or that identity is the entire solution (in fact, it’s only the starting point). The agent should get as little access as it needs for the job at hand, and for no longer than it needs it. The Cloud Native Computing Foundation (CNCF) wrote a post on agentic standards which discusses a model built around the following principles:

• The Principle of Least Privilege (PoLP): The agent should only receive the minimal permissions needed for its operation. CNCF’s framing is worth noting: agents are built to explore their options, so assume that every granted permission will eventually be used.
• Just-in-Time (JIT) access: Permissions for the task should be short-lived and temporary, and agents should only request access when they need it. And when the task is done, the access expires automatically, reducing the risk of accumulating permissions the agent no longer needs.
• Workload partitioning: Agents should be isolated per trust boundary, using namespace separation, container isolation, network segmentation, or hardware partitioning. In practical terms, a staging agent shouldn’t automatically have a route into production.

If an agent never needs permanent access to production, why would you need to give it permanent credentials that can reach it?

This approach isn’t just academic; HashiCorp has demonstrated this using Boundary and Vault together. In its walkthrough, an agent receives a dynamically created account for a specific infrastructure action, along with a short-lived SSH certificate that expires automatically. There’s an added layer of accountability, too: Boundary records which human operator initiated the agent. This is important because it means that in the audit logs, you can actually tell apart the agent’s actions from those of the person who created it.

This combination is key. The identity tells the organization which agent is acting; tightly scoped permissions determine where the agent can go; short-lived credentials limit how long that authority survives. And finally, audit logs create a record well after the access has disappeared.

Where do business VPN and ZTNA fit into agent security?

An agent with its own identity solves one part of the problem: not knowing where (or whom) a request came from. The next part is what that identity should actually be able to reach. This is where business VPN and ZTNA can both find a unique, but complementary part to play.

Business VPN: Secure the path

An agent needs a secure, private connectivity path between it and the infrastructure it needs to access (and that the organization doesn’t want exposed to the wider internet). This is exactly what a business VPN can provide. Traffic can cross the public internet via an encrypted tunnel, while the systems behind that connection are shielded; they’re still very much part of a private network environment. For example, OpenVPN’s CloudConnexa uses VPN tunnels to create a private overlay network, which connects users, devices, and resources.

If an agent needs to interact with internal systems (like APIs, databases, or codebases) that shouldn’t be exposed to the internet at large, this is key; the VPN handles the secure connection into that private environment.

ZTNA: Narrow what the agent can reach

Granting your agent secure connectivity to the private infrastructure it needs to access is a good start. But there’s a second question that’s left unanswered here: what resources should this agent be allowed to access?

ZTNA moves the decision toward each individual resource. It doesn’t assume that a successful connection should provide broad access to everything available behind it. Instead, policies can be built around the identity making the request, and the specific application or service it’s requesting access to.

For example, a troubleshooting agent might legitimately need access to:

• Logs
• A monitoring API
• A staging service

But doesn’t need a network path to:

• Payroll systems
• Customer databases
• The production control plane

NIST’s zero-trust model follows the same principle: access should be granted to individual resources with the minimum privileges necessary, rather than assuming trust just because something has already made it into a given network.

The two controls are complementary

Identity, VPN, and ZTNA answer three different questions, which is why none of them can replace the others.

As agents get more involved with internal systems and trigger more downstream workflows, these distinctions become increasingly important. To make sure agents can only communicate with authorized tools and services, CNCF recommends explicit network-level enforcement boundaries such as service meshes, network policies, and API gateways in its guidance for Kubernetes-based deployments.

There’s still one more missing piece in this puzzle, though: controlling which applications an agent can reach doesn’t determine what it’s allowed to do once it gets there. Application authorization, PAM, and other policy controls are the tools we need to approach this.

ZTNA controls access, not every action

Let’s say a ZTNA policy rightly determines that a database-maintenance agent should be allowed to connect to an internal database, and grants it access. This is already useful; the agent can’t just wander into other unrelated systems it doesn’t need access to.

But what happens next, once it’s inside the database? Is it allowed to read data? Change schemas? Create accounts? Delete records? ZTNA alone won’t necessarily make these decisions; there will need to be other controls alongside the network-access layer.

Taking a step back, it’s clear that different parts of the security stack have different jobs:

• Business VPN: Provides secure, private connectivity

• ZTNA: Defines which resources a given identity can reach
• IAM/workload identity: Establishes who or what is requesting access

• PAM and secrets management: Controls privileged and temporary credentials

• Application or database authorization: Governs access inside each given resource

• External policy or approval engines: Gates higher-risk operations

• Sandboxing: Creates an isolated, restricted environment in which an agent runs
• Logging and monitoring: Provides an independent historical record of what happened

There’s a caveat here, though, as Jake Moshenko highlighted in The New Stack. Even if every layer is doing its job correctly, an authorized agent can still make a bad decision inside the resource it was legitimately allowed to reach.

In short, ZTNA doesn’t solve the agent security issue entirely by itself. It’s certainly a powerful tool, though: it shrinks the set of systems an agent can reach, thereby reducing the potential blast radius if something were to go wrong.

Give agents less trust, not more

An intern may lack a little experience, but they still work within a defined role (usually, at least), answer to other people, apply their human judgment, and typically have limits on what they can access. (They’re also certainly not looking to get in trouble with their boss.)

An autonomous agent, on the other hand, can operate continuously, move between tools and systems, and perform actions at machine speed.

Giving that agent the same permissions as the employee that happened to deploy it, in a way, gets the trust model backwards. A more autonomous model needs stronger boundaries.

We know it’s not enough to just rely on better prompts or hope that the agent remembers where its boundaries should be; there are enough high-profile incidents that reaffirm this. AI agents are already working alongside human employees, and this is probably only going to become more and more commonplace. This absolutely doesn’t mean they should inherit the same keys.