How Cleric uses tsnet to securely automate software operations

At Cleric, we are building the first autonomous AI Site Reliability Engineer (SRE). Our mission is to handle the heavy lifting of software operations. Cleric investigates incidents, triages alerts, and captures production context, so that engineering teams can focus on building.

For an AI SRE to be effective, it needs to query the same internal tools, databases, and telemetry providers that a human engineer would. This presents a significant architectural challenge: How do we gain secure, low-latency access to our customers' private resources without creating a massive burden for their platform and security teams?

By leveraging Tailscale and the tsnet library, we’ve built a secure connectivity layer that is easy for the customer to integrate and for us to operate.

The Connectivity Problem

Our customers’ environments are as diverse as the services they run. We see everything from AWS shops with strict VPC requirements to modern, identity-perimeter setups where every service is authenticated via an identity provider (IdP). Some require VPNs for any internal access; others leverage complex peering models across multiple clouds.

When we set out to build Cleric’s connectivity layer, we had three non-negotiables:

1. Security: We must follow the principle of least privilege. We shouldn't have access to any network endpoints that the customer does not desire us to have.
2. Ease of Use: If a customer has to spend three weeks configuring routing tables and getting through security review just to try Cleric, we’ve already lost.
3. Scalability: We cannot manage a unique, bespoke networking stack for every individual customer.

Why traditional methods fall short

Before landing on Tailscale, we evaluated the "standard" ways of connecting to private infrastructure. Each came with trade-offs that were ultimately unacceptable.

The reverse proxy

We could ask customers to set up an authenticated reverse proxy to expose specific internal endpoints to our agent. This sounds reasonable on the surface, but in practice it’s a nightmare for everyone involved. For the customer, it’s extra infrastructure to maintain and a high-friction security review. For us, it creates "implementation debt", in that we have to maintain custom logic for how we integrate with each specific customer’s proxy.

Cloud-native connectivity (VPC peering & PrivateLink)

Solutions like AWS VPC peering or Azure VNet peering are robust, but they require significant coordination. There are CIDR block overlaps to worry about, routing table updates, and cross-account permissions. Furthermore, as a multi-cloud provider, managing a heterogeneous mix of provider-specific connection mechanisms would quickly become an operational bottleneck for our team.

Building a private overlay with Tailscale

We realized that what we actually needed wasn't direct connectivity into the customer’s network; we needed a private, programmable overlay network. We wanted to control exactly which endpoints were exposed, with zero changes to the customer’s existing network configuration.

Tailscale provided the perfect foundation. By using Tailscale’s WireGuard™-based mesh, we could establish encrypted, peer-to-peer connections between our agent and customer resources regardless of where they sit.

The breakthrough for us was tsnet, Tailscale’s library that allows you to embed Tailscale directly into a Go binary.

How it works: virtualizing the network

Instead of asking a customer to install a VPN client on a gateway or bastion host, we provide them with a simple binary or Helm chart. This "Cleric Connector" acts as a device (or several) on a Tailscale tailnet.

Here is how we’ve structured the implementation:

• Endpoint modeling: We model each customer resource (a database, a Prometheus instance, etc.) as a distinct "device" within our internal architecture.
• The tsnet advantage: Using tsnet, we virtualize these devices into a single process. Our agent doesn't see a complex web of subnets; it sees a flat, secure namespace of authorized services.
• Zero-config deployment: To the customer, the setup is "drop-in." They provide the Connector with a list of internal endpoints they wish to expose, and Tailscale handles the NAT traversal and encrypted tunneling automatically. No firewall holes, no public IPs, and no routing table headaches.

Security by design: beyond the bastion

One of the most significant advantages of this model is that it avoids the "all-or-nothing" trap of traditional VPNs.

In a traditional VPN or bastion host model, once you are "inside," you often have broad visibility into the private network. If the internal firewall rules are misconfigured, an external agent could potentially reach any resource on that subnet.

With the Cleric + Tailscale model, lateral movement is impossible. Because we model each endpoint as a unique device, our agent can only see the specific endpoints it has been explicitly granted access to. In other words, we don’t route based on IP ranges, we connect based on identity. If a resource isn't explicitly configured for the Connector, it doesn't exist as far as the Cleric agent is concerned.

For the security team, this model is trivially auditable: just look at what endpoints have been configured on the Connector. Cleric has no access to private endpoints beyond what’s on that list.

The result

By building on Tailscale, we’ve turned a complex infrastructure hurdle into a competitive advantage. This solution has been running in production for several months now and has cut our time-to-value substantially, in some cases eliminating weeks of process time.

We’ve stopped worrying about network topologies, and started focusing on what we do best: building the future of autonomous operations.