How to build a secure network zone for an AI agent with Tailscale

In our previous article, we discussed the 12 controls a company should implement before allowing an AI agent to access real systems. These include the agent’s own identity, restricted network connections, tool-specific authorisation, human approval, logging and a tested kill switch. [1]

In this article, we focus on one of these layers: technically restricting an AI agent’s network access with Tailscale.

The goal is not to build a small internal network in which the agent can move freely. The goal is an identity-based microsegment in which only the connection paths required by the agent’s task exist.

Network access requirements

This is a much more specific security feature than the generic claim that the agent is “behind the VPN”.

A secure network zone is not the same as a trusted internal network

A traditional network segment is often built around a VLAN, subnet, or firewall zone.

For example, an agent can be placed on a network:

10.40.20.0/24

A firewall may block traffic to other subnets, but workloads within the same network may still see each other. Network policy is primarily based on IP addresses and network location.

In the Tailscale architecture, the network zone can be modelled differently:

1. Source identityWho or what initiates the connection?
2. Target identityWhat named resource is the connection established to?
3. Network capabilityWhat protocol and port are allowed?

In a Tailscale Grants policy, a connection is defined by at least three pieces of information:

src = who or what is allowed to initiate the connection
dst = to which resource the connection can be established
ip = what protocol and port to use

The Grants rule model is deny-by-default: a connection is not allowed unless the complete policy contains a matching rule. A new tailnet can nevertheless include a broad pre-populated policy, so that starter policy must be replaced before least privilege is achieved. The Tailscale control plane distributes identity, key and policy information to devices, while WireGuard-encrypted data traffic remains in the data plane. Netmap trimming reduces peer information, but a device can still see permitted destinations, usable exit nodes, devices authenticated as the same user and devices that may initiate connections to it. [2] [21] [23]

A secure network zone is therefore, in practice, a graph of allowed connections:

Reachability(ai-agent) = {
  ai-llm-gateway:443,
  ai-tool-gateway:443
}

Everything else remains outside the graph.

Reachability(ai-agent, prod-db:5432) = false
Reachability(ai-agent, prod-admin:22) = false
Reachability(ai-agent, erp-api:443) = false

This corresponds to the access path thinking used by Defense First:

1. Identify
2. Model
3. Implement
4. Prove

First, the actual business need is identified. The connection path is then modelled, enforced with the Grants policy and proven with both allowed and denied tests. [3]

Threat model: assume the agent misbehaves

The reference architecture should not be designed only around normal agent behaviour.

The initial assumption of the architecture should be that one of the following occurs:

1. The agent interprets the task incorrectly.
2. The agent reads a document containing a prompt-injection attack.
3. The tool used by the agent or the MCP server is compromised.
4. A software dependency used by the agent is compromised in a supply-chain attack.
5. The agent's workload identity or application ID is stolen.
6. Code execution is obtained in the agent execution environment.
7. An agent is trying to reach a system it should not be using.

OWASP identifies agent-goal hijacking, tool misuse, identity and permission abuse, agentic supply-chain weaknesses and unexpected code execution among the risks of agent systems. International government guidance therefore recommends tightly restricted resources and actions, least privilege, short-lived credentials, isolation and gradual deployment. [4] [22]

The security goal of the network layer is not: the agent never tries to do anything dangerous.

A better goal is: even if an agent tries to perform a dangerous operation, the required network path does not exist.

The reference architecture for this article is based on the following security requirements:

1. I1The agent has no direct connection to the database.
2. I2The agent does not have a direct connection to the ERP system.
3. I3The agent does not have an SSH or management connection to production.
4. I4The agent does not hold the model provider’s API key.
5. I5The agent accesses business systems only through the tool and API gateway.
6. I6Reading, approval and writing are separated into different services and identities.
7. I7Traffic to the public internet only goes through a separately managed gateway.
8. I8Each allowed and blocked Tailscale connection is tested.
9. I9Agent network access can be removed centrally.
10. I10Actions performed by the agent can be correlated across network, tool and application logs.

Reference architecture

The architecture below is suitable, for example, for an agent handling invoices, support requests, customer data or other internal business processes.

In the architecture, the agent is a deliberately low-trust workload.

The agent is allowed to process untrusted content and generate suggestions, but cannot directly connect to high-impact systems.

get_invoice(invoice_id)
get_supplier(supplier_id)
create_invoice_draft(invoice_data)
request_payment_approval(payment_data)

GET /invoices/7421

SELECT * FROM invoices;

{
  "action": "create-payment",
  "invoice_id": "7421",
  "recipient": "FI00 0000 0000 0000 00",
  "amount_eur": 1240.00
}

Agent identity and tag structure

In Tailscale, servers, containers, automation, and other non-personal devices can be identified with tags.

A tag is not just a descriptive label. It is used as the identity of the workload and as the source or target selector for the Grants policy. When a device is tagged, it is treated as a tag identity instead of the user's personal identity. [6]

A generic tag should be avoided:

tag:ai-agent

It does not tell what the agent does, in which environment it operates, whether it has read or write permissions, or what system it is associated with.

A better tag might be:

tag:ai-agent-invoice-prod

Or more specifically:

tag:ai-invoice-reader-prod
tag:ai-invoice-drafter-prod
tag:ai-payment-executor-prod

One identity for one purpose

Development, test and production environments should not be combined with the same identity:

tag:ai-agent-invoice-dev
tag:ai-agent-invoice-test
tag:ai-agent-invoice-prod

Similarly, reading and writing operations should be separated:

tag:ai-invoice-reader-prod
tag:ai-invoice-write-executor-prod

The permissions of Tailscale tags are combined additively. If multiple tags are assigned to the device, the permissions obtained through all tags can take effect. The combination of tags cannot be treated as a requirement "tag A and tag B" in the standard rule, so clear combination tags should be used instead of unclear combinations of many tags. [6]

tag:ai-agent
tag:production
tag:finance

tag:ai-finance-agent-prod

Permission to assign a tag is high-risk

tagOwners defines who can associate a device with a specific tag identity.

If an attacker can assign this tag to their own workload:

tag:ai-write-executor-prod

they may also obtain the network paths granted to that identity.

Permission to assign tags must therefore be restricted to a security administration group or controlled automation. tagOwners delegates who may assign the identity through normal workflows; tailnet Owners, Admins and Network admins can apply any tag as part of their administrative role. Tag ownership does not itself grant network access, which is defined separately in Grants. [6] [7]

Smallest functional Grants implementation

The first version can be built with one agent and one gateway.

Illustrative Tailscale policy:

{
  "groups": {
    "group:security-admins": [
      "security-admin@example.com"
    ]
  },

  "tagOwners": {
    "tag:ai-agent-read-prod": [
      "group:security-admins"
    ],
    "tag:ai-tool-gateway-prod": [
      "group:security-admins"
    ],
    "tag:prod-db": [
      "group:security-admins"
    ],
    "tag:prod-admin": [
      "group:security-admins"
    ]
  },

  "grants": [
    {
      "src": [
        "tag:ai-agent-read-prod"
      ],
      "dst": [
        "tag:ai-tool-gateway-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    }
  ],

  "tests": [
    {
      "src": "tag:ai-agent-read-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-tool-gateway-prod:443"
      ],
      "deny": [
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    }
  ]
}

The policy has three separate issues.

tagOwners

"tagOwners": {
  "tag:ai-agent-read-prod": [
    "group:security-admins"
  ]
}

Only the specified security group is allowed to associate the device with the agent's identity.

grants

{
  "src": [
    "tag:ai-agent-read-prod"
  ],
  "dst": [
    "tag:ai-tool-gateway-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

The agent is allowed to establish a TCP connection to gateway port 443.

This rule does not allow the agent to access other gateway ports, the database, the administration server or other tailnet devices.

tests

{
  "src": "tag:ai-agent-read-prod",
  "proto": "tcp",
  "accept": [
    "tag:ai-tool-gateway-prod:443"
  ],
  "deny": [
    "tag:prod-db:5432",
    "tag:prod-admin:22"
  ]
}

The test shows both allowed and blocked connections.

Tailscale runs the tests defined in the policy file whenever the policy changes. If a test expectation is not met, the policy change is rejected. Tests are particularly important because Grants rules are additive: another overbroad rule can inadvertently give the agent more access than its own narrowly defined rule suggests. [7]

Production-grade Grants reference policy

The following example implements the entire reference architecture.

Identities used are:

tag:ai-agent-invoice-prod
tag:ai-llm-gateway-prod
tag:ai-tool-gateway-prod
tag:ai-read-api-prod
tag:ai-approval-api-prod
tag:ai-write-executor-prod
tag:erp-api-prod
tag:prod-db
tag:prod-admin

Illustrative policy:

{
  "groups": {
    "group:security-admins": [
      "security-admin@example.com"
    ]
  },

  "tagOwners": {
    "tag:ai-agent-invoice-prod": [
      "group:security-admins"
    ],
    "tag:ai-llm-gateway-prod": [
      "group:security-admins"
    ],
    "tag:ai-tool-gateway-prod": [
      "group:security-admins"
    ],
    "tag:ai-read-api-prod": [
      "group:security-admins"
    ],
    "tag:ai-approval-api-prod": [
      "group:security-admins"
    ],
    "tag:ai-write-executor-prod": [
      "group:security-admins"
    ],
    "tag:erp-api-prod": [
      "group:security-admins"
    ],
    "tag:prod-db": [
      "group:security-admins"
    ],
    "tag:prod-admin": [
      "group:security-admins"
    ]
  },

  "grants": [
    {
      "src": [
        "tag:ai-agent-invoice-prod"
      ],
      "dst": [
        "tag:ai-llm-gateway-prod",
        "tag:ai-tool-gateway-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    },
    {
      "src": [
        "tag:ai-tool-gateway-prod"
      ],
      "dst": [
        "tag:ai-read-api-prod",
        "tag:ai-approval-api-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    },
    {
      "src": [
        "tag:ai-approval-api-prod"
      ],
      "dst": [
        "tag:ai-write-executor-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    },
    {
      "src": [
        "tag:ai-write-executor-prod"
      ],
      "dst": [
        "tag:erp-api-prod"
      ],
      "ip": [
        "tcp:443"
      ]
    }
  ],

  "tests": [
    {
      "src": "tag:ai-agent-invoice-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-llm-gateway-prod:443",
        "tag:ai-tool-gateway-prod:443"
      ],
      "deny": [
        "tag:ai-read-api-prod:443",
        "tag:ai-approval-api-prod:443",
        "tag:ai-write-executor-prod:443",
        "tag:erp-api-prod:443",
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    },
    {
      "src": "tag:ai-tool-gateway-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-read-api-prod:443",
        "tag:ai-approval-api-prod:443"
      ],
      "deny": [
        "tag:ai-write-executor-prod:443",
        "tag:erp-api-prod:443",
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    },
    {
      "src": "tag:ai-approval-api-prod",
      "proto": "tcp",
      "accept": [
        "tag:ai-write-executor-prod:443"
      ],
      "deny": [
        "tag:erp-api-prod:443",
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    },
    {
      "src": "tag:ai-write-executor-prod",
      "proto": "tcp",
      "accept": [
        "tag:erp-api-prod:443"
      ],
      "deny": [
        "tag:prod-db:5432",
        "tag:prod-admin:22"
      ]
    }
  ]
}

Grant 1: agent can only reach two gateways

{
  "src": [
    "tag:ai-agent-invoice-prod"
  ],
  "dst": [
    "tag:ai-llm-gateway-prod",
    "tag:ai-tool-gateway-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Agent can use approved model service and approved tools.

It cannot directly reach the read API, approval service, write-action executor, ERP system, database or administration server.

Grant 2: the tool API is allowed to read and create an approval request

{
  "src": [
    "tag:ai-tool-gateway-prod"
  ],
  "dst": [
    "tag:ai-read-api-prod",
    "tag:ai-approval-api-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

The tool API can fetch limited information and leave the proposal for approval. However, it cannot perform a write operation directly.

Grant 3: the approval service is allowed to initiate a write operation

{
  "src": [
    "tag:ai-approval-api-prod"
  ],
  "dst": [
    "tag:ai-write-executor-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

Only the approval service has a network path to the write operator. The agent or tool API does not have this path.

Grant 4: the executor may only use the ERP system’s restricted API

{
  "src": [
    "tag:ai-write-executor-prod"
  ],
  "dst": [
    "tag:erp-api-prod"
  ],
  "ip": [
    "tcp:443"
  ]
}

The write-action executor may use the ERP API but not the production database or administration server.

Because of this, the ERP API can implement action-specific authorisation, object-level access, quantity limits, idempotency, event logging and rollback support.

Network policy does not replace application authorisation

A regular Tailscale Grant can allow a connection:

tag:ai-tool-gateway-prod
    →
tag:ai-read-api-prod:443

A grant alone does not decide which HTTP method or API operation a gateway can use:

GET    /invoices/7421
POST   /payments
DELETE /suppliers/91

The network layer answers the question: is the source allowed to establish a network connection to the destination?

The application layer answers the question: what is the source allowed to do after establishing a connection?

Tailscale Grants also supports application-specific capability definitions, but the target application itself must implement and interpret the respective permissions. Tailscale treats application capability parameters as opaque JSON data and does not implement application business logic. [2]

A secure overall design therefore requires at least three authorisation layers:

1. Tailscale network policyCan the agent reach the service?
2. Tool and API Gateway PolicyIs the agent allowed to use that tool with those parameters?
3. Target application's own authorisationCan the service read or change this particular business object?

Close paths that bypass Tailscale

Tailscale policy protects Tailscale traffic. It does not automatically prevent the service from being reachable also via a public IPv4 or IPv6 address, the cloud service's internal network, the local LAN network, the Kubernetes cluster's normal service network, or another network interface.

Tailscale Grants does not change what a device can reach on the local network outside Tailscale. If the database is directly accessible via a regular subnet, the agent may bypass the fine-grained tailnet policy entirely. [8]

Close public ingress

An internal API service should not listen openly on all network interfaces, such as 0.0.0.0:443, unless a public connection is specifically intended.

The service can be bound to localhost or its Tailscale IP address, protected with a host firewall or cloud security group, published inside the tailnet with Tailscale Serve, or connected through a tsnet identity embedded in the application.

Tailscale Serve can bring a service running on localhost to tailnet for internal use, so that tailnet's access policy remains in effect. Tailscale Funnel, on the other hand, publishes the service to the public internet, so it should not be confused with a private agent architecture. [9]

Restrict ordinary internet egress

By default, a Tailscale Grant does not control the agent’s ordinary internet traffic outside Tailscale. If the operating system has a default route to the internet, the agent may establish an HTTPS connection to an external destination without that connection passing through Tailscale policy.

The agent's internet egress must be limited separately, for example, with a cloud platform or operating system firewall, Kubernetes NetworkPolicy, egress proxy, separate network namespace, controlled NAT gateway or controlled exit node and the firewall behind it.

AI agent
    │
    │ Tailscale
    ▼
Internal LLM gateway
    │
    │ controlled egress
    ▼
Approved model provider

In this case, only the LLM gateway is allowed to connect to the model provider.

Tailscale App Connectors can route traffic for specified SaaS services through a managed exit and provide a predictable public source address. However, App Connector alone does not make the route mandatory if the workload still has another open internet route. [10]

An exit node can centralise internet traffic through one point. Permission to use it is defined separately with the autogroup:internet destination, but destination or domain restrictions must still be enforced by the exit node’s firewall, proxy or another egress control. [11]

How to attach an agent to Tailscale

The implementation depends on the agent's execution environment and lifecycle.

Agent container
      │
      │ localhost / container network
      ▼
Tailscale sidecar
      │
      ▼
Tailnet

Same physical server:

invoice-reader   → its own tsnet identity
invoice-writer   → its own tsnet identity
reporting-agent  → its own tsnet identity
admin-tool       → its own tsnet identity

Test the policy at three levels

A successful demo alone does not demonstrate a secure architecture. Testing must cover at least three levels:

1. Static policy testDoes the Grants policy implement the intended connection matrix?
2. Real network connection testDo allowed and blocked paths behave as expected in the real environment?
3. Application and Functionality TestAre tools, objects and approvals delineated correctly after connection?

1. Tailscale policy tests

The testssection of the policy file verifies that the Grants policy produces the intended connectivity matrix.

{
  "src": "tag:ai-agent-invoice-prod",
  "proto": "tcp",
  "accept": [
    "tag:ai-tool-gateway-prod:443"
  ],
  "deny": [
    "tag:erp-api-prod:443",
    "tag:prod-db:5432",
    "tag:prod-admin:22"
  ]
}

The test must be run as part of every policy change. In addition to a positive test, explicit negative tests are needed. Otherwise, some other broad Grant may allow the connection without changing the agent's own rule.

2. Real network connection tests

In addition to the policy, the connections must be tested from the real agent execution environment.

3. Application level tests

A working network connection to the gateway does not prove that application authorisation is working.

Tailscale policy tests show tailnet network level reachability. They do not test the business logic of the API, the access permissions of target records, or the correctness of human approval.

Logging: what do you need to be able to prove?

A single agent run should form a compound chain of events. The same correlation tag, for example run_id: ai-run-2026-07-28-000142, is associated with the agent execution log, the LLM gateway log, the tool API log, the approval object, the write action log, and the target application event log.

In this case, it is possible to find out afterwards who started the task, which agent performed it, which model and tools were used, which network objects were connected, which data was read, who approved the operation and what was changed in the system.

Tailscale Configuration Audit

Tailscale's audit log records administrative changes: who changed the policy, what setting was changed, when the change was made, and the previous and new state of the policy. This helps show when an agent's access permissions were changed and who made the change. [15]

Network flow logs

Network flow logs record connection metadata such as source and destination nodes, protocol, port and transferred data volume. They do not record traffic content. The feature is currently available on Premium and Enterprise plans, retains the most recent 30 days in Tailscale and requires supported clients to send telemetry.

Flow logs describe observed flows; they should not be treated as a complete record of denied connection attempts or as a stand-alone IDS, SIEM or real-time threat-detection system. Depending on the use case, local Tailscale logs, host and egress firewall logs or gateway logs are needed to detect and evidence denied attempts. [16]

Log streaming, currently available on Premium and Enterprise plans, can send supported audit and network logs to centralised storage or a SIEM. [17]

Implement a real kill switch

Stopping an agent must not depend on whether the agent is no longer responding to management commands. The stop must be outside the agent.

1. Stop agent workload.
2. Remove agent's Tailscale device or its Grants privileges.
3. Revoke agent application and API IDs.
4. Prevent agent internet egress.
5. Prevent new tool calls on gateway.
6. Keep logs for investigation.
7. Rotate or revoke any exposed auth keys, API tokens and other credentials.
8. Revert the changes made by the agent.

Revoking the original Tailscale auth key does not automatically revoke access for a device that has already joined the tailnet with it. An auth key is used to register the device; the registered node then has its own device and key lifecycle. If necessary, remove the node or change its access policy. [18]

Likewise, removing the Tailscale network access does not alone revoke the application tokens already obtained by the agent. It must be possible to revoke the network identity and application credentials independently of each other.

Common mistakes

Optional further development: stable service identity

In a production environment, there can be multiple parallel instances of a tool API or LLM gateway. Tailscale Services separates a stable service identity from individual hosts.

{
  "src": [
    "tag:ai-agent-invoice-prod"
  ],
  "dst": [
    "svc:ai-tool-gateway"
  ],
  "ip": [
    "tcp:443"
  ]
}

The agent uses a stable service name, and the service can be implemented on multiple tagged, approved hosts. This makes it easier to replace instances and build high availability without tying the agent's policy to one server. Tailscale Services currently supports TCP services, so protocol, client-version and host-approval requirements must be checked before adopting this pattern. [19]

When is the agent’s network zone ready for production?

An agent’s network zone is not production-ready merely because Tailscale is installed. A new tailnet’s initial default policy may allow broad device-to-device traffic. A least-privilege Grants policy, tag ownership and policy tests must be designed separately. [3] [23]

You should be able to demonstrate at least the following things about production readiness:

• The agent has its own purpose-bound workload identity.
• Development, test and production environments are separated.
• Tag issuing permissions are limited.
• The agent has only named targets, protocols and ports.
• The agent has no direct database or administration connection.
• Read, approval and write paths are separated.
• Application authorisation works in addition to network policy.
• Public and local network bypass routes are closed.
• Internet egress is limited by a separate control.
• The policy has both pass and block tests.
• The tests cover the additive effects of the entire policy.
• Real end-to-end connections have been tested.
• Network, agent, tool, and application logs can be combined.
• Suspension and token revocation have been tested.
• There is a documented rollback procedure for the change.
• The agent access path has a named owner.

A secure network zone limits the blast radius

The safety of an AI agent cannot be built on the assumption that the model always understands the user's intent, recognizes all malicious instructions, and chooses a safe action in all situations.

However, a deterministic limit can be implemented in the network layer:

Tailscale in this architecture implements workload identity, an encrypted connection layer, and tightly bounded network accessibility. The application, API gateway, approval service, firewall and monitoring implement the other layers.

Tailscale is not a substitute for application authentication, data access permissions, vulnerability management, EDR system, SIEM solution or incident response. The customer is also responsible for device updates, identity management, tag and group management, and an appropriate access policy. [3]

A good first implementation is deliberately small:

Defense First identifies the customer's actual access path, models the target state, implements it with Tailscale Grants and produces tests, documentation and a recovery plan for both allowed and denied connections. [20]