Skip to content

Documentation / Guides / AI Agents

Giving AI agents access to private systems

This guide describes the recommended pattern for giving AI agents private, policy-controlled access to internal servers, locally hosted models and tool servers without exposing any of them to the public internet. It covers where agents run, how to give each agent a network identity, and the Enclave configuration needed to limit what an agent can reach.

Overview

An AI agent is a process that makes ordinary network connections. A coding agent opens SSH sessions and runs kubectl. A desktop assistant calls tool servers over HTTP. A workflow automation queries a database. Whatever the model decides to do, the traffic that leaves the machine is TCP and UDP on well-known ports.

An agent is enrolled as a System, given Tags, and connected to other Systems by Policy in exactly the same way as a human's laptop or a server. The same Access Control Rules, Trust Requirements, Active Hours and Auto Expiry that govern humans govern agents.

The recommended pattern has three parts:

  1. Give the agent a network identity of its own by running it on a System that is enrolled in Enclave and tagged as an agent.
  2. Write Policies from the resource's point of view so that each agent Tag can reach only the ports it needs on only the Systems it needs.
  3. Bound access in time with Auto Expiry or Active Hours for anything that runs unattended.

Where agents run

Agents take several forms, and the form determines where Enclave is installed.

Agent type Examples Where it runs Where Enclave runs
Coding agent Claude Code, Codex CLI, Gemini CLI, IDE agent modes On a technician's or developer's workstation, as a process under their user account On the workstation, as normal
Desktop assistant with tools Claude Desktop, ChatGPT desktop, LM Studio, Open WebUI On a workstation, calling tool servers over the Model Context Protocol (MCP) On the workstation and on each System hosting a tool server
Locally hosted model Ollama, LM Studio, llama.cpp, vLLM On a GPU workstation or server, serving an HTTP API On the model host
Unattended automation Scheduled agent runs, CI jobs, n8n or LangGraph workflows In a container, a VM or a CI runner Alongside the agent in the container or VM
Vendor-hosted agent Cloud sandboxes operated by the AI vendor In the vendor's environment, which usually cannot run Enclave On a proxy System the sandbox can reach

The first four cases are covered directly by this guide. For vendor-hosted agents that cannot run Enclave, see Secure access to local workloads from Cloud Workers and Lambda functions, which describes the proxy pattern.

Architecture

The core decision is whether an agent shares a human's network identity or has its own.

Technician workstation ── Enclave tunnel ──▶ Customer server (TCP 22)
  └── coding agent runs as the technician

Agent container ── Enclave tunnel ──▶ Customer server (TCP 22)
  └── enrolled with its own key, tagged ai-agents

Agents on a human's workstation

A coding agent or desktop assistant running on a workstation shares that workstation's System identity. It inherits every Policy and Trust Requirement that applies to the human, and it loses access when the human logs out or fails a Trust Requirement.

This is the right pattern for interactive, supervised use. The human is present, the agent's reach is the human's reach, and nothing new needs to be enrolled. The trade-off is that there is no separation: a Policy cannot distinguish the agent's traffic from the human's, so an agent on an IT admin's workstation can reach everything the IT admin can.

Agents on a dedicated System

An agent that runs unattended, or whose reach should be narrower than any human's, should run on its own System. This can be a VM, a container, or a small physical machine. The System is enrolled with its own Enrolment Key, tagged as an agent, and given Policies that name only the resources it needs.

For containers, use the Docker Service network mode described in the Docker setup. The agent container shares a network stack only with the Enclave container, so it has no LAN visibility at all and can be reached, and can reach out, only through Enclave.

Prefer a dedicated System for anything unattended

Putting an unattended agent on its own System is the single most valuable step in this guide. It turns "what can the agent reach?" into a question the Policy table answers, rather than one that depends on which human's workstation the agent happens to be running on.

Choosing an Enrolment Key

A dedicated agent System is enrolled with its own Enrolment Key, and the type of key should match the agent's lifetime.

Agents that run as a job - a scheduled run, a CI job, a container that performs one task and exits - should use an Ephemeral Enrolment Key. The System exists for exactly as long as the agent is working:

  • Every run enrols a fresh System, and the System is removed from the organisation when the agent disconnects. Nothing accumulates in the Systems list, and no agent identity outlives the task it was created for.
  • Between runs there is no System for a Policy to match. A compromised host has no standing network identity to reuse.
  • Enrolment is automatic. Ephemeral keys cannot be gated behind approval, so a scheduler or CI runner never waits for a human.

Two settings matter for agents in particular. The Disconnect Timeout defaults to 30 minutes and can be reduced to one minute. Set it short, so that an agent that crashes rather than exiting is removed promptly. A graceful shutdown removes the System immediately, so the agent's container should exit cleanly rather than being killed. For CI, the enclave-networks/setup-enclave GitHub Action installs Enclave into a workflow run.

Agents that run as a service - an always-on assistant or a long-lived automation host - should use a General Purpose Enrolment Key with a Use Limit of one and Approval Mode set to Gated. The System is enrolled once, approved by a human, and the key is disabled.

The ephemeral key is a standing credential

An Ephemeral Enrolment Key has no use limit and no approval step, and it must stay permanently enabled for the next run to enrol. Anyone holding the key can enrol any number of agent Systems, each auto-tagged and auto-approved. Treat the key as a credential: store it in the scheduler's or CI platform's secret store, apply IP Address Constraints so it works only from the runner's egress addresses, and rotate it as described in Enrolment key management.

Controlling what an agent can reach

Tags and Policies

Apply an agent Tag such as ai-agents through the Enrolment Key's Auto Tags, so that every agent System is tagged the moment it enrols. Then write Policies that put the agent Tag on the Sender side and the resource Tag on the Receiver side, following the X for Y naming pattern.

Policy Sender Tags Receiver Tags Access Control Rules
Servers for AI Agents ai-agents servers TCP 22
AI Models for Developers developers ai-model-hosts TCP 11434
MCP Server for IT Admins it-admins mcp-servers TCP 8080

Every new Policy starts with an All Traffic rule. Remove it and add only the ports the agent needs. Access Control Rules are applied on the Receiver side, so an agent System's reach is exactly the union of the rules in the Policies that name its Tag, and nothing else.

Systems that cannot run Enclave

Many of the things an agent needs to reach cannot run Enclave themselves: domain controllers, network appliances, NAS devices, managed databases. Deploy an Enclave Gateway in the same network and write a Gateway Access Policy so that the agent Tag can reach the advertised subnet. The Gateway also forwards DNS, so an agent can use internal names such as dc1.corp.trantor.example.

Time-bound access

Agents that run on a schedule, or that are granted access for a single task, should not hold standing access.

  • Active Hours restrict a Policy to a window, such as a nightly maintenance run.
  • Auto Expiry disables or deletes a Policy at a set time. The Enable For shortcut in the Policy table grants access for a fixed period with one click.
  • Ephemeral Enrolment Keys remove the agent System itself when the job ends, so there is nothing for a Policy to match outside the run.

Combining a single-port Access Control Rule with an Auto Expiry gives an agent access to one port on one System for one hour, with nothing to remember to revoke afterwards. Active Hours limit when a Policy applies. An ephemeral System limits when the agent exists at all. For a scheduled agent, use both.

Trust Requirements

Trust Requirements apply to agents in the same way as to humans.

  • For agents on a human's workstation, a User Authentication requirement means the agent works only while the human is signed in. The agent's access ends when the human's session does.
  • For agents on a headless System, User Authentication is completed using the device flow described under Non-interactive Contexts. In practice, a Public IP Address requirement is usually a better fit, pinning the agent to a known egress address.

Stable names for configuration

Agents are configured in files and environment variables, and those references need to stay valid when a host is replaced. Create custom DNS records that resolve by Tag, such as ollama.trantor.example for ai-model-hosts and mcp.trantor.example for mcp-servers, and use those names in agent configuration rather than an Enclave IP.

Example: a private MCP server

James Walker, an IT admin at Trantor International, runs an MCP server that gives a desktop assistant access to an internal ticketing system. The server must not be reachable from the internet or from the office LAN.

The MCP server runs as a container on a server in Menlo Park, with Enclave in Service network mode so that the container is reachable only through Enclave:

version: "3.8"

services:
  mcp-server:
    image: trantor/ticketing-mcp
    command: ["--host", "0.0.0.0", "--port", "8080"]

  enclave:
    container_name: enclave
    image: enclavenetworks/enclave
    network_mode: service:mcp-server
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    environment:
      ENCLAVE_ENROLMENT_KEY: ${ENCLAVE_ENROLMENT_KEY}
    volumes:
      - enclave-config:/etc/enclave/profiles
      - enclave-logs:/var/log/enclave

volumes:
  enclave-config:
  enclave-logs:

The Enrolment Key auto-tags the System mcp-servers. A DNS record mcp.trantor.example resolves to that Tag. The Policy MCP Server for IT Admins allows TCP 8080 from it-admins to mcp-servers, with a User Authentication Trust Requirement against Trantor's Entra ID tenant.

James's desktop assistant is configured with http://mcp.trantor.example:8080/mcp as a remote tool server. No inbound firewall rule exists on the server, on the office edge, or anywhere else on the path. If James signs out of Enclave, the assistant loses the tool.

Example: a locally hosted model

Emma Taylor, a developer, wants to use a model served by Ollama on a GPU workstation in the Menlo Park office from her laptop when working remotely.

The GPU workstation is enrolled and tagged ai-model-hosts. Ollama is configured to listen on the workstation's Enclave address rather than on all interfaces, so the API is not reachable from the office LAN. The Policy AI Models for Developers allows TCP 11434 from developers to ai-model-hosts.

Emma's tools point at http://ollama.trantor.example:11434. The connection is peer-to-peer over Enclave, so it works from any network without port forwarding on the office router.

Example: an unattended agent reaching customer servers

Trantor's IT team runs a nightly agent that reviews logs on a group of servers over SSH. It runs as a container on a schedule, starts at 02:00, and exits when the review is complete.

The container enrols with an Ephemeral Enrolment Key that auto-tags it ai-agents, with a Disconnect Timeout of one minute and an IP Address Constraint limiting the key to the scheduler host's public address. The key is stored in the scheduler's secret store. The Policy Servers for AI Agents allows TCP 22 from ai-agents to servers, with Active Hours set to 02:00 to 04:00.

Outside the run, the Systems list contains no agent at all. When the container exits, the System is removed from the organisation and its keys are gone with it. If the container crashes, the System is removed a minute later. If the container hangs past 04:00, the Policy is inactive and it cannot reach the servers. Each of the three controls covers a failure of the others.

Further considerations

Enclave controls reach, not behaviour. A Policy decides which ports on which Systems an agent can connect to. It does not inspect what the agent sends over those connections. Tool permissions, approval prompts and command allow-lists belong in the agent itself, and should be configured there as well.

Audit. Security Events record every change to Policies, Tags and Enrolment Keys, including who made it and when. To see what an agent actually connected to, enable Network Flow Metadata export on the agent System or on a Gateway it uses.

Revoking access. Disable the Policy, or remove the agent System from the organisation. Either takes effect on existing connections as well as new ones.

Agents that need broad access. An agent that helps administer many customer environments should have a System per customer, or a Policy per customer with its own Auto Expiry, rather than one Tag that reaches everything. The goal is that the Policy table for any agent reads as a short list of resources a human would be comfortable signing off.

Having problems? Contact us at support@enclave.io or visit our support options.

Last updated September 10, 2026