tsnet is a Go library that embeds Tailscale directly into an application so the app can join a tailnet as its own device. Each embedded service can have its own IP address, DNS name, certificates, and access controls. That lets teams bind connectivity to application state instead of external network plumbing.
Expanded Definition
tsnet integration is the practice of embedding Tailscale networking into an application so the service joins a tailnet as a managed endpoint rather than depending on a separate proxy, VPN, or static network path. In NHI terms, this shifts connectivity from infrastructure-centric routing to identity-bound service reachability.
That distinction matters because tsnet does more than “open a tunnel.” It can assign an embedded service its own IP address, DNS identity, certificates, and access controls, which makes the application itself part of the trust boundary. For NHI governance, this aligns with the idea that a workload should be authenticated, authorized, and observable as its own non-human identity. Guidance varies across vendors on how much of this should be treated as networking versus identity control, but the operational pattern is clear: access follows the application instance, not the subnet.
For broader control language, the least-surprise reference point is NIST Cybersecurity Framework 2.0, especially when organisations map tsnet to least privilege, segmentation, and asset visibility. The most common misapplication is treating tsnet as a simple connectivity shortcut, which occurs when teams deploy it without lifecycle controls, identity binding, or service-to-service authorization review.
Examples and Use Cases
Implementing tsnet rigorously often introduces a tighter coupling between application lifecycle and access policy, requiring organisations to weigh simpler deployment against more disciplined identity operations.
- A Go microservice in a private environment joins a tailnet through tsnet so it can expose only the ports and DNS name needed by one internal consumer.
- A compliance logging service uses embedded certificates and per-service identity, reducing the need for shared VPN access or broad network segmentation rules.
- An internal API behind a development sandbox is reachable only by approved workloads, which makes its access path easier to review than a flat network route. This pattern is often discussed alongside NHIMG’s Klue OAuth Supply Chain Breach because identity-bound access is central to reducing blast radius.
- A SaaS integration service uses tsnet so its external support workflow can be limited to a specific NHI and rotated independently from the host.
- An engineering team tests service-to-service authorization by pairing tsnet with the service’s own policy scope, rather than granting device-wide trust.
The model also pairs well with identity-centric guidance from NIST Cybersecurity Framework 2.0, because the network path becomes secondary to who or what is allowed to connect. In incident review, similar patterns have appeared in NHIMG reporting such as the GitHub Repo Breach — Heroku and Travis CI OAuth Tokens, where secret handling and delegated access were decisive.
Why It Matters in NHI Security
tsnet integration matters because it can turn a service into a first-class NHI with its own access surface, instead of leaving it hidden behind shared infrastructure. That is useful, but it also means misconfiguration creates identity risk, not just network risk. If a service inherits overly broad access, the compromise of one workload can become the compromise of many. If certificates or join credentials are not rotated, the embedded endpoint may remain trusted long after its intended lifecycle. If ownership is unclear, offboarding becomes guesswork.
NHIMG research shows why this discipline matters: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, and 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to NHI Mgmt Group. In practice, tsnet can reduce network sprawl, but only if the embedded identity is governed like any other privileged workload identity, with review, revocation, and monitoring.
Organisations typically encounter the full impact only after a service is leaked, cloned, or redeployed with stale credentials, at which point tsnet integration becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Embedded service identities create NHI exposure, authorization, and lifecycle risk. |
| NIST CSF 2.0 | PR.AC-4 | tsnet maps to identity-based least privilege and segmented access to assets. |
| NIST Zero Trust (SP 800-207) | PA-3 | Zero Trust requires continuous verification of workload identity before access is granted. |
| NIST SP 800-63 | AAL2 | Although built for humans, its assurance concepts inform credential strength and proofing rigor. |
| OWASP Agentic AI Top 10 | AI-04 | Autonomous services with tool access need constrained, auditable connectivity boundaries. |
Treat each tsnet-enabled service as a governed NHI with ownership, policy scope, and revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
