Tailscale Credentials: Leaked Auth Key and Token Response

A leaked Tailscale auth key can put an attacker's machine inside your private network, and revoking the key does not remove the devices it already added. Tailscale credentials are network credentials: auth keys enrol devices, API access tokens and OAuth clients administer the tailnet, and the policy file decides what each enrolled device can reach. This guide explains what each credential type reaches, how to read the configuration audit log for misuse, the revoke and clean-up steps from Tailscale's own knowledge base, and the controls (tags, device approval, Tailnet Lock, workload identity federation) that make a leak survivable. It is for network, platform and security engineers who run Tailscale for servers, CI runners, containers or remote access.

Key takeaways

Revoke the key, then delete the devices. Tailscale states that revoking an auth key does not deauthorise nodes that used it; you must also remove those devices from the Machines page.
Reusable keys are the worst case. A reusable auth key can enrol any number of devices until it expires (1 to 90 days, default 90), so Tailscale itself warns to be very careful with them.
API access tokens have full API permission. A leaked token can change devices, keys and the policy file for up to its 90-day maximum lifetime; scoped OAuth clients or federated identities are the narrower alternative.
Tags and policy set the blast radius. A device enrolled with a tagged key gets only what the policy grants that tag, while an untagged key authenticates the device as the user who created it.
The audit log shows every key and node event. Configuration audit logs are always on for all plans, cover key creation, node creation, approvals and policy changes, and keep 90 days unless you stream or export them.

How identity and access work in Tailscale

A tailnet has human users, who sign in through an identity provider, and devices (nodes), each with its own node key. Machines join either through an interactive login or with an auth key. Administration happens in the admin console or through the Tailscale API, authenticated with API access tokens, OAuth client credentials or workload identity federation. Access between nodes is governed by the tailnet policy file, including tagOwners, autoApprovers and Tailscale SSH rules.

Credential	Used for	What a leak allows	Lifetime	Revocation
One-off auth key	Enrolling one device	Enrol one device, if not already used	1 to 90 days; revoked automatically after use	Keys page, Revoke
Reusable auth key	Enrolling fleets, CI runners, images	Enrol many devices as the creator or as the key's tags	1 to 90 days, default 90	Keys page, Revoke; then delete enrolled devices
Ephemeral auth key (setting)	Containers, functions, short-lived workloads	As above; devices are removed after going offline	As above	As above
Pre-approved auth key (setting)	Skipping device approval	Enrolled devices bypass the approval queue	As above	As above
API access token	Scripts and integrations using the API	Full permission to the Tailscale API	1 to 90 days	Keys page; revoked tokens listed there
OAuth client secret	Ongoing API access via client credentials	Mint one-hour access tokens with the client's scopes; with `auth_keys`, mint tagged auth keys	Tokens one hour; the secret persists until revoked	Revoke or delete the client (Owner, Admin, Network admin, IT admin)
Node key	A device's identity in the tailnet	Traffic as that device if the device is compromised	Default 180 days; expiry disabled by default for tagged devices	Delete the device or expire its key
Tailnet Lock disablement secret	Turning Tailnet Lock off	Anyone holding one can disable Tailnet Lock	Until used; then treated as public	Store offline; cannot be rotated without re-initialising

All of these values begin with tskey- in Tailscale's examples and are case-sensitive, which helps secret scanners and responders classify a finding quickly. Never paste a suspected key into a ticket or chat to ask what it is; look it up on the Keys page by its description and creation date.

Admin roles and privileged access

Who can mint keys: Owners, Admins, IT admins and Network admins can generate auth keys and API access tokens. Revocation of auth keys is limited to those roles and, per Tailscale, only for their own keys, so an Owner or Admin may need to act for a departed colleague by deleting devices and rotating policy.
OAuth client grants: Owners and Admins can grant any scope and tag to an OAuth client. Other roles can grant only scopes and tags they already hold; a Network admin cannot grant devices:core, but an IT admin can. The all scope covers every other scope and all device tags.
Clients belong to the tailnet: OAuth clients keep working after the user who created them loses tailnet access. That is good for automation continuity and bad for forgotten clients, so give each one an owner outside Tailscale.
Device approval: Owners, Admins and IT admins approve devices when device approval is on. A device awaiting approval cannot send or receive traffic. A pre-approved auth key removes that safeguard for every device enrolled with it.
Policy file editors: whoever can change the policy file can widen what a tag reaches or enable Tailscale SSH. Treat policy edit rights, and API credentials that can write the policy, as privileged access.

For how network credentials fit a wider privileged access model, see the Service Account Security Guide.

Integrations, API tokens and service accounts

Auth keys spread to wherever devices are built. During an incident, search these locations for the leaked key and for other copies of it:

Container images and Dockerfiles: keys passed as build arguments or baked into entrypoint scripts. The Docker Hub secrets leak found credentials copied into public images through .env files and whole project directories, most never revoked.
CI/CD: keys stored as pipeline secrets so ephemeral runners can reach private services. These are often reusable and untagged for convenience.
Infrastructure as code and cloud-init: user data, Terraform variables and Helm values for subnet routers, exit nodes and Kubernetes operators.
Integrations using the API: scripts that sync devices or edit the policy file, frequently running on a long-lived API access token created by one admin.
Workloads in cloud platforms: these can use workload identity federation instead of any stored secret. A workload presents its platform OIDC token (Azure, Google Cloud, AWS, GitHub Actions or a custom public issuer), Tailscale checks it against claim-matching rules, and returns a short-lived API token. Node registration needs the auth_keys scope and advertised tags must match the federated identity's tags. Client version 1.94.0 and later can fetch the platform token itself on AWS, Google Cloud and GitHub Actions.

Leak response: revoke and rotate

Use this order with the general Leaked Credential Response Playbook.

Classify the credential. Find it on the admin console Keys page (auth keys and API access tokens) or the OAuth clients list. Note whether an auth key is reusable, ephemeral, pre-approved or tagged, who created it and when.
Revoke it. On the Keys page, find the key and select Revoke. For an OAuth client, revoke or delete the client, which also stops it minting new auth keys. Expect access tokens already issued to an OAuth client to keep working until their one-hour lifetime ends.
Find every device it enrolled. Filter the configuration audit log for node creation events in the exposure window and match them to the key; node creation, approval, login and tag update events are all recorded. For an OAuth client, also look for auth keys it created.
Remove unknown devices. Delete any device you cannot attribute from the Machines page. Revoking the key alone leaves them authorised until their node keys expire, which defaults to 180 days and is disabled by default for tagged devices.
Check for configuration changes. Review policy file diffs (the log keeps the full file diff, including comments), changes to tagOwners, autoApprovers and Tailscale SSH rules, route approvals, new API tokens, new OAuth clients and new federated identities.
Check what the devices reached. If network flow logs are enabled, review flows from the removed nodes. Otherwise use logs on the services those tags or users could reach.
Replace the credential properly. Use a tagged, ephemeral, one-off or short-expiry key, generated on demand by an OAuth client or federated identity, and keep it in a secrets manager rather than in the image.
Close the source. Remove the key from images, repositories and logs, rebuild affected images and resolve the scanner alert with the devices removed and keys revoked.

Logging and detection

Configuration audit logs are available on all plans, always on, and keep the most recent 90 days. Each entry has a timestamp, action, actor (a user, or "Tailscale service" for control plane actions), target and a diff; API output adds origin (for example ADMIN_UI or NODE), eventGroupID and eventTime. Export with GET /api/v2/tailnet/{tailnetId}/logging/configuration using start and end in RFC3339 and a credential with the logs:configuration:read scope. Log streaming to a SIEM (Splunk HEC, Datadog, Elasticsearch, Panther, Cribl, Axiom, S3, Azure Blob, Google Cloud Storage and others) is on the Premium and Enterprise plans and also carries network flow logs once those are enabled.

Event or signal	What to look for	Likely meaning
Auth key created	Reusable, pre-approved or untagged keys, especially by API	Risky key issued; possible persistence after an API token leak
Node created	Hostnames, operating systems or locations that do not fit the key's purpose	Leaked auth key in use
Node approved	Approvals outside working hours or by unexpected actors	Abuse of admin access to bypass device approval
Policy file updated	New grants for a tag, Tailscale SSH rules, `autoApprovers` for routes	Blast radius widened deliberately
API access token or OAuth client created	New credentials, `all` scope	Persistence
Failed API request, insufficient permission	Repeated failures from one credential	A scoped credential being probed
Log streaming endpoint changed or deleted	Any unexpected change	Attempt to blind detection

Useful metrics: number of reusable auth keys (target near zero), share of auth keys that are tagged, number of API access tokens versus scoped OAuth clients or federated identities, number of devices with key expiry disabled that are not tagged servers, and time from leak alert to both key revocation and enrolled-device removal. See the NHI Detection Engineering Guide for turning these into rules.

Hardening baseline

Control	Tailscale feature	Effect on a leak
Tag every machine key	Tagged auth keys with narrow `tagOwners`	Enrolled device gets only the tag's grants, not a human's
Prefer one-off and ephemeral keys	Key settings at generation	A leaked used key is dead; ephemeral devices clean themselves up
Short key expiry	1 to 90 days	Shrinks the window for any copy left in an image
Device approval	Device management settings; avoid pre-approved keys	New devices cannot send traffic until approved
Tailnet Lock	Signing nodes (2 to 20), pre-signed keys via `tailscale lock sign`	New node keys need a signature from a trusted key; cannot be combined with device approval
Scoped API access	OAuth clients with minimal scopes, or workload identity federation	No full-permission token sitting in scripts
Log retention	Log streaming or scheduled API export	Evidence beyond 90 days

Device approval or Tailnet Lock: the two cannot be combined. Device approval suits organisations where an admin team can review every new device and wants approval workflows through the nodeNeedsApproval webhook. Tailnet Lock suits estates that want protection even against a compromised control plane, and that can manage signing nodes and keep the ten disablement secrets safe offline; losing them without having given one to Tailscale support means the tailnet cannot be recovered. Small teams usually start with device approval and tagged ephemeral keys; larger, high-assurance estates move to Tailnet Lock with pre-signed keys for automation.

Framework mapping

Concern	MITRE ATT&CK	NIST SP 800-53 Rev 5	NIST CSF 2.0
Auth key in an image, repository or CI variable	T1552.001 Credentials In Files	IA-5	PR.AA-01
Rogue device joining through the overlay network	T1133 External Remote Services	AC-17 (remote access), CM-8	DE.CM-01
API token used to change the tailnet	T1550.001 Application Access Token	AC-6	PR.AA-05
New keys or clients for persistence	T1098.001 Additional Cloud Credentials	AC-2, AU-6	DE.CM-03
Revoke, remove devices, contain	n/a	IR-4	RS.MI-01

Common misconfigurations

Revoking the key and stopping there. Devices enrolled with the key stay authorised; tagged ones may never expire.
Reusable, untagged, pre-approved keys in images. The combination enrols unlimited devices as a human user with no approval step, which is the worst possible leak.
Broad tag grants. A CI tag that can reach production databases turns a CI key leak into production access.
Long-lived API access tokens in scripts. They have full API permission; an OAuth client with one scope does the same job with far less exposure.
Disablement secrets kept online. Storing all Tailnet Lock disablement secrets in the same password vault as admin credentials undoes the protection.
No log export. After 90 days the configuration audit log no longer covers the enrolment you need to investigate. The 230 Million AWS Cloud Environments campaign shows how long harvested keys from exposed .env files can circulate before anyone looks.

Practitioner checklist

List all auth keys, API access tokens, OAuth clients and federated identities with creator, scope, tags and expiry.
Replace reusable untagged keys with tagged ephemeral or one-off keys generated on demand.
Move API automation from access tokens to scoped OAuth clients or workload identity federation.
Turn on device approval or Tailnet Lock and stop issuing pre-approved keys for fleets.
Review tag grants in the policy file so each machine tag reaches only what it needs.
Stream or export configuration audit logs and enable network flow logs where your plan allows.
Alert on new reusable or pre-approved keys, new API credentials and policy file changes.
Write the leak runbook so it always includes deleting the devices a key enrolled.
Scan container images and CI logs for tskey- values before publishing.

Tailscale credentials: Stop a leaked key from joining your network