Coding Agents Use Case

To build and test the code they write, coding agents often need access to Resources that aren’t on the internet. Twingate lets an agent connect to those Resources without exposing them publicly. For example:

• Before it opens a pull request, an agent can check its fix by running the app against a staging environment, calling internal APIs, and running end-to-end tests.
• With access to a development or test database, an agent can read the schema, run migrations, and run integration tests against PostgreSQL, MySQL, or MongoDB.
• An agent can install packages from an internal registry and clone repositories from a self-hosted Git server.
• Agents can also call internal MCP servers, LLM gateways, and ticketing or documentation systems.
• For infrastructure work, an agent can run kubectl against a development Kubernetes cluster whose API server isn’t public.

Local, cloud, and self-hosted agents

How an agent connects to Twingate depends on where it runs its commands. When an agent runs locally, it uses the developer’s Twingate Client. Cloud and self-hosted agents use the headless Client, a version of the Client with no user interface, which connects as a Service. A Service is a Twingate account for automated processes. It authenticates with a Service Key instead of a user’s sign-in.

Local agents

Local agents, such as Claude Code, Codex CLI, and Cursor, run in a developer’s terminal or IDE. Consider a local agent when a developer works alongside it and reviews its changes as it goes. The agent’s traffic goes through the developer’s Twingate Client like any other app on the device, under the developer’s Security Policies. There’s nothing extra to set up, but the agent gets all of the developer’s access and only works while their machine is awake.

Cloud agents

Cloud agents run their commands in a sandbox, a VM or container that someone else hosts. Consider cloud agents when you want them to work unattended and in parallel without tying up a developer’s machine. Once you run the headless Client in the sandbox with a Service Key, the agent can access the Resources assigned to that Service.

Some agent platforms, such as Devin and Cursor’s cloud agents, host the sandbox themselves and let you run the Client in it. Others lock down their sandboxes in ways that keep the Client from running. If your platform can send the agent’s commands to a sandbox provider, such as Depot or Daytona, you can run the Client there instead. The provider still hosts the sandbox, but you have more control over how it’s set up.

Self-hosted agents

For the most control, some agent platforms can run the agent’s sandbox on infrastructure you manage, such as VMs in your cloud account or a Kubernetes cluster. Devin Outposts can run Devin’s commands on your own VMs, and Cursor’s self-hosted machines do the same for Cursor’s agents. Consider self-hosted agents when the Client can’t run in a platform’s or provider’s sandbox, or when agents need to run on machines you control. You set up the headless Client there the same way as in a cloud sandbox. In exchange, you run and maintain that infrastructure yourself.

Benefits of using Twingate with coding agents

• Through a Service, an agent can access only the Resources assigned to that Service, such as a few hostnames on specific ports. Its sandbox doesn’t get an address on your private network.
• Connectors only make outbound connections, so you don’t need to open inbound firewall ports or allowlist an agent platform’s IP addresses.
• You can give each agent platform its own Service Key with an expiration date and revoke one key without disconnecting the others.
• Cloud and self-hosted agents can use Twingate while your employees keep their current remote access setup.
• You can manage Services and Service Keys with Terraform, Pulumi, or the Admin API.

Guides for using Twingate with coding agents

• Services
• Linux Headless Mode
• Userspace Networking
• Route Traffic from Kubernetes
• Best Practices for Securing Access to Non-production Environments