The Complete Guide to Zero-Trust Networking for AI Agents

Traditional cloud networking follows a "castle and moat" model. Everything inside the VPC can talk to everything else. You put a firewall on the outside and trust everything on the inside.

This model breaks down completely with AI agents.

An AI agent can be compromised - through prompt injection, through a malicious package it installs, or through a vulnerability in the model itself. If that compromised agent is inside your "trusted" network, it has access to every other service: your database, your other agents, your internal APIs.

Zero-trust networking is a different approach: nothing trusts anything by default. Every connection must be explicitly authorized. Even agents on the same account, on the same server, can't talk to each other unless you say so.

This guide explains what zero-trust means for AI agent infrastructure and how to implement it.

What goes wrong without zero-trust

Imagine a typical setup: you have three agents running on the same cloud server (or in the same Kubernetes cluster):

• Agent A - Handles customer conversations
• Agent B - Manages a private database
• Agent C - Processes payments

Without zero-trust, all three can discover and connect to each other over the internal network. Now imagine Agent A gets prompt-injected by a malicious user. The attacker sends a message that tricks Agent A into making HTTP requests to the internal network.

Agent A can now:

1. Scan the internal network and find Agent B's database
2. Query the database for customer records
3. Forward the data to an external server
4. Connect to Agent C's payment service and trigger unauthorized transactions

This is called lateral movement, and it's the single biggest risk in any multi-service architecture. A compromise in one component gives the attacker access to everything.

How zero-trust networking works

Zero-trust flips the default:

With zero-trust:

• Agent A can't see Agent B or Agent C on the network. They're invisible to each other.
• Agent B only accepts connections from specific, pre-authorized sources.
• Agent C only accepts connections on specific ports from specific services.
• A compromised agent can't discover other services because they literally don't exist on its network.

Zero-trust for AI agents specifically

AI agents make zero-trust even more important than for regular services:

Agents execute arbitrary code

A web server runs your code. An AI agent runs whatever code it decides to run. If it installs a malicious package or gets tricked by prompt injection, it's running arbitrary code with whatever network access the environment has.

Agents handle untrusted input

Every user message to an AI agent is potential prompt injection. You can't fully sanitize natural language. The agent's behavior is influenced by input you don't control.

Agents make autonomous decisions

An agent might decide to "check something" by making an HTTP request. If internal services are reachable, the agent can access them - even accidentally.

Agents chain actions

A single compromised action leads to the next. Agent decides to install a package → package has a postinstall script → script scans the network → finds database → exfiltrates data. Each step is "reasonable" on its own.

Implementing zero-trust in practice

Here's how to set up a zero-trust network for your AI agents using Oblien workspaces:

Start invisible

Every workspace starts with zero-trust networking out of the box:

• No inbound connections from any source
• No other workspace can discover or reach it
• Internet outbound is allowed (for package installation)
• No public-facing ports

You don't need to configure this - it's the default state.

Add explicit connections

When workspace A needs to talk to workspace B, you create a directed private link. This tells B's firewall to accept connections from A's IP, on specific ports.

Key properties of private links:

• They're one-way. A can reach B, but B can't reach A (unless you create a separate link).
• They're port-specific. A can connect to port 5432 on B, but not port 22 or any other port.
• They're revocable. Remove the link, and the connection is immediately blocked.
• They use internal IPs. Traffic stays on the private 10.x.x.x network. It never touches the internet.

Control internet access

For agents that don't need internet, disable it entirely:

• allow_internet: false - No outbound internet traffic at all
• The workspace becomes truly air-gapped: no internet, no other workspaces (unless explicitly linked)

For agents that need limited internet, use egress rules to allowlist specific domains:

• Allow api.openai.com but nothing else
• Allow registry.npmjs.org for package installation but block everything else

Require both network AND authentication

Even if a workspace can reach another workspace over the network, it still needs a valid authentication token. This is two-layer security:

1. Network layer - Firewall must allow the connection
2. Auth layer - Request must include a valid workspace token

Both must pass. A network path alone isn't enough to access a service.

Zero-trust architecture patterns

Pattern 1: Agent + Database

┌────────────┐    Private Link     ┌────────────┐
│   Agent    │  ───────────────►   │  Database  │
│ Workspace  │   Port 5432 only    │ Workspace  │
│            │                     │            │
│ Internet:  │                     │ Internet:  │
│ Limited    │                     │ None       │
└────────────┘                     └────────────┘

The agent can query the database on port 5432. The database can't reach the agent. Neither can reach anything else internally. The database has no internet access at all.

Pattern 2: Orchestrator + Workers

         ┌─────────────┐
         │ Orchestrator │
         │  (permanent) │
         └──┬──┬──┬──┬─┘
            │  │  │  │  Private links
         ┌──▼──▼──▼──▼──┐
         │  Workers (temp) │
         │  Air-gapped     │
         │  Auto-expire    │
         └─────────────────┘

The orchestrator can reach workers. Workers can't reach anything - not the orchestrator, not each other, not the internet. They receive a task, execute it, and the orchestrator reads the result.

Pattern 3: User-facing agent + Backend services

  Internet ──► Agent (public port 443)
                  │
                  ├──► Auth Service (port 8080)
                  ├──► Data Service (port 3000)
                  └──► Notification Service (port 4000)

The agent has one public-facing port for user traffic. It has private links to specific backend services. Each backend service is invisible to the internet and to each other.

Monitoring and auditing

Zero-trust isn't just about configuration - it's about visibility:

• Know what's connected. Review private links for every workspace. Who can reach what? Remove links that are no longer needed.
• Monitor network traffic. Check per-workspace network metrics to spot unusual patterns. An agent suddenly sending gigabytes of data is a red flag.
• Audit token usage. Track which tokens are used and from where. Rotate tokens regularly.
• Review egress rules. Tighten over time. Start with broader access, then narrow to only the domains you actually need.

Common mistakes to avoid

1. "Just put everything in one workspace." Multi-service doesn't mean multi-container-in-one-VM. Each service should be its own workspace for proper isolation.

2. "I'll add security later." Zero-trust is easier to start with than to retrofit. The default in Oblien is already zero-trust - don't open it up just because it's easier during development.

3. "My agents are trusted." Your agents execute code based on untrusted input. Even with the best prompt engineering, you can't guarantee an agent won't be tricked.

4. "Internet access is fine, it just needs to install packages." Use egress rules. Allow npmjs.org but block everything else. The less internet access an agent has, the less damage a compromised agent can do.

5. "One API key for everything." Scope your tokens. Each workspace should have the minimum permissions it needs. Full-access tokens are a single point of failure.

Getting started

Zero-trust networking is the default on Oblien. You don't need to enable it or configure it. Every workspace starts invisible.

Your job is to explicitly declare the connections you need - and nothing more:

1. Create workspaces for each component (agent, database, services)
2. Add private links for the specific connections required
3. Restrict internet access where it's not needed
4. Scope API tokens to minimum required permissions
5. Review and audit connections regularly

The safest network is the one where nothing can talk to anything unless you've explicitly decided it should.

Learn more about workspace networking →