AI gateway identity for agents shifts access control to the network

At a glance

What this is: This is a WorkOS interview about Tailscale's AI gateway, which uses network identity to centralise API key access for humans, CI, and autonomous agents.

Why it matters: It matters because IAM teams must decide whether network-level identity is enough to govern NHI and agent access, or whether separate lifecycle, privilege, and audit controls still need to sit above it.

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.

👉 Read WorkOS's interview on Tailscale's AI gateway and agent identity

Context

AI gateway identity for agents is a network-layer approach to access control. Instead of distributing API keys to developers, CI runners, and autonomous agents, the gateway becomes the single authenticated choke point, which changes where trust is established and where identity is enforced.

That matters because many enterprise IAM programmes still assume secrets live in applications or vaults, while the real control point for agentic systems may sit in the network path. If the identity boundary moves to the tailnet, governance has to follow the execution path, not just the credential store.

Key questions

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. The key is to bind admission, authorization, and audit to authoritative identity sources, then define who owns each agent run, what it can reach, and how it is revoked. Without that, the network only hides secret sprawl, it does not eliminate it.

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. A single exposed key can serve many runs, many tools, and many environments. That creates weak attribution and broad blast radius, especially when the agent's privileges are inherited from a shared gateway or service account.

Q: What do security teams get wrong about network-based identity for workloads?

A: They often assume that network membership automatically equals trustworthy identity. In practice, membership only says the actor can connect, not that its session is correctly scoped, its privilege is minimal, or its lifecycle is managed. The failure is confusing connectivity control with end-to-end identity governance.

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.

Technical breakdown

Tailnet identity as an authentication boundary

Tailscale's model treats the tailnet as the place where identity is established. Each device or node joins with a known identity, and requests carry that identity to the gateway. That means the gateway can make policy decisions on the requester, the group, or the tag, rather than on a raw secret presented by the application. In practice, this shifts control from secret distribution to network membership and request context. The architectural gain is centralisation, but the security burden also concentrates: if the gateway is misclassified, over-permissioned, or too broadly trusted, every downstream call inherits that mistake.

Practical implication: tie gateway admission to strong device and workload identity checks, not just network reachability.

Tagged agents, federated OIDC, and per-run identity

The article describes CI and agent flows that join with federated OIDC and then present tags such as claude-pr-reviewbot or docs-reviewbot. A stable node ID identifies the specific run, which gives the gateway enough context to distinguish one execution from another. That is important because an agent's identity is not just the workload name. It is the combination of who or what launched it, what environment it ran in, and whether the session is the same execution or a new one. This is where workload identity and runtime attribution meet in one control plane.

Practical implication: preserve per-run identity and logs so agents can be reviewed as executions, not just as static service names.

Dynamic policy injection at the network layer

The gateway can receive JSON configuration through access control rules, letting request handling vary by user, group, or tag without hardcoding policy into the application. That is technically useful, but it creates a governance dependency on external policy quality. If policy becomes too dynamic without strong approval boundaries, organisations may gain flexibility while losing clarity about who can do what, when, and under which authority. For AI agents, that distinction matters because runtime behaviour can change faster than traditional application release cycles.

Practical implication: separate policy authoring from runtime execution so dynamic controls remain reviewable and auditable.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Ephemeral agent access exposes the weakness of static secret thinking. Traditional NHI controls assume a credential can be found, rotated, and reviewed as a durable asset. Agentic systems often create shorter-lived execution contexts that are tagged, scoped, and replaced far faster than manual review cycles can follow. The operational conclusion is that access governance has to move closer to session and run identity, not just secret inventory.

Runtime policy on the network will widen the gap between policy intent and actual execution unless it is tightly bounded. The more identity and authorization logic is pushed into request-time configuration, the more important it becomes to know which decisions are automated, which are inherited, and which are manually approved. That is especially true for AI agents whose tool use can expand during execution. Practitioners should re-evaluate where policy is authored, who can change it, and what audit evidence survives the request.

Named concept: network-bound identity delegation. This pattern shifts trust from application-managed secrets to network-issued identity, but it also delegates access decisions to a layer many IAM teams do not currently govern end to end. The result is a new identity boundary that can simplify distribution while obscuring owner responsibility if lifecycle, tagging, and offboarding are weak. Practitioners need to map that boundary explicitly before adoption becomes entrenchment.

From our research:

• 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.
• That is why 52 NHI Breaches Analysis is useful here, because it shows how hidden credentials and weak lifecycle control become repeated failure patterns.

What this signals

Network-bound identity delegation: if the access boundary shifts into the tailnet, IAM teams must govern admission, tagging, and revocation with the same discipline they apply to privileged accounts. Otherwise, the organisation gains cleaner routing but not cleaner accountability, especially when agents and CI jobs share the same policy fabric.

With 97% of NHIs carrying excessive privileges, per Ultimate Guide to NHIs, dynamic agent access cannot be treated as a narrow engineering problem. The programme signal is that least privilege has to be expressed per run, per tag, and per owner, not just per system name.

Practitioners should also prepare for the audit question that network controls do not answer on their own: who approved the agent's standing access, and how was it retired. For lifecycle-heavy environments, the operational reference point remains 52 NHI Breaches Analysis, because breach patterns repeatedly expose offboarding and credential persistence gaps.

For practitioners

• 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. Treat tailnet membership as a governed entitlement, not a networking convenience.
• 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. Keep the approval path for initial admission distinct from per-request authorization.
• 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. That creates the evidence needed for offboarding, incident review, and access recertification.
• Bound dynamic policy changes to auditable change control Require formal review for policy rules that vary by user, group, or tag, especially when they influence model access or tool invocation. If policy updates can alter agent behaviour in real time, the change process needs the same scrutiny as privileged IAM changes.

Key takeaways

• AI gateway identity can reduce secret distribution, but it does not replace governance over who may join, act, and be revoked.
• The biggest operational risk is confusion between network reachability and identity assurance, especially for agents and CI workloads.
• Teams should review tailnet admission, per-run attribution, and policy change control before adopting network-bound access for AI systems.

Key terms

• Tailnet identity: The identity a device, workload, or program presents after joining a private network. In practice, it becomes a control point for admission and request handling, but only if the organisation treats network membership as governed access rather than simple connectivity.
• Run-scoped identity: A short-lived identity tied to one execution of an agent, CI job, or automated workflow. It helps distinguish one session from another, which is essential when access needs to be reviewed, attributed, or revoked at the level of a specific run instead of a static service name.
• Network-bound identity delegation: A governance pattern in which identity checks and authorization decisions move into the network layer. It can reduce secret distribution, but it also pushes responsibility for lifecycle, logging, and policy ownership into a layer that many IAM teams do not yet manage end to end.

Deepen your knowledge

AI gateway identity, workload admission, and run-scoped access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents and CI pipelines from a similar starting point, it is worth exploring.

This post draws on content published by WorkOS: Tailscale is building the AI gateway for a world where agents need identity. Read the original.