Notifications
Clear all
Topic starter
07/06/2026 8:16 pm
TL;DR: Tailscale's AI gateway centralises API key use behind tailnet identity so developers, CI runners, and autonomous agents can authenticate through the network rather than distribute secrets broadly, according to WorkOS. The shift is useful, but it also exposes how much agent governance still depends on policy enforcement outside the application layer.
NHIMG editorial — based on content published by WorkOS: Tailscale is building the AI gateway for a world where agents need identity
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern AI agent access when the network is the control point?
A: They should treat the network as an enforcement layer, not as the full governance model.
Q: Why do AI agents complicate traditional API key and secrets management?
A: AI agents complicate secrets management because they can multiply access paths faster than teams can review or rotate credentials.
Q: What do security teams get wrong about network-based identity for workloads?
A: They often assume that network membership automatically equals trustworthy identity.
Practitioner guidance
- Map gateway trust boundaries to identity ownership Document which users, workloads, and agent runs are allowed to join the tailnet, who approves them, and which identity source is authoritative for each admission decision.
- Separate static secrets from run-scoped access Remove long-lived API keys from developers, CI runners, and agent workflows where possible, then require the gateway to mediate all downstream calls with run-specific context.
- Log and review agent runs as discrete identity events Capture stable node IDs, tags, request context, and tool calls for each execution so that suspicious behaviour can be tied to a specific run rather than a generic bot label.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The exact tailnet and TSNet flow for joining programs and agents without distributing keys.
- The request-tagging model used to distinguish a laptop session from a GitHub Actions run.
- Examples of per-group access policies that vary model usage and request quotas.
- The network-is-sandbox design discussion, including multiple and ephemeral tailnets.
👉 Read WorkOS's interview on Tailscale's AI gateway and agent identity →
AI gateway identity for agents: are network controls enough?
Explore further
07/06/2026 10:07 pm
Network identity for agents is a control plane, not a governance programme. Moving API key use behind a tailnet reduces secret sprawl, but it does not by itself solve lifecycle, privilege, or accountability. The network can decide whether something may connect, yet the identity programme still has to decide whether that thing should exist, what it may call, and who owns it. Practitioners should treat the gateway as an enforcement point, not the governance model.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Should organisations use the same access model for humans, CI pipelines, and autonomous agents?
A: No. Humans, CI pipelines, and autonomous agents have different risk profiles, review cadences, and revocation needs. A shared access layer can be convenient, but the policy decisions behind it should differ by actor type, especially where autonomous execution can change actions mid-session without human intervention.
👉 Read our full editorial: AI gateway identity for agents shifts access control to the network
