Feature request: Restrict a tunnel to the currently signed-in user (user-only access control)

[factoredvoid]

Summary

devtunnel already supports restricting access by Microsoft Entra tenant (--tenant) and by GitHub organization (--organization) on devtunnel access create. In some scenarios, those scopes are still too broad. I’d like to request support for restricting tunnel access to only the currently signed-in user (the identity already required to create/manage tunnels).

Background / Motivation

Today it’s possible to:

• Allow/deny access to users from a specific Microsoft Entra ID tenant via --tenant
• Allow/deny access to users in a GitHub organization via --organization

However, there are cases where:

• The tenant contains many users, and we need the tunnel to be accessible only by a single user (myself).
• I’m a member of a GitHub org, but I don’t want org membership to grant access (or I want to avoid maintaining org-based allowlists/denylists).
• I want a simple “loopback” sharing mode to ensure the tunnel is reachable only by the tunnel owner for security/testing.

Since devtunnel already requires an authenticated user session to create tunnels, having a first-class “current user only” restriction seems like a natural option.

Request

Add an option to restrict tunnel access to the current signed-in user only.

Possible UX (examples; maintainers can choose the best design):

• devtunnel access create --user self (or --current-user)
• devtunnel access create --user me
• devtunnel access create --principal <current-user-id> (where CLI can resolve “self”)
• A higher-level convenience flag on tunnel creation, e.g. devtunnel create --private or --owner-only (if that fits the model better)

Expected behavior

When configured for “current user only”:

• Only the authenticated user who owns/created the tunnel can connect.
• Other users in the same Entra tenant are denied (even if --tenant would otherwise allow them).
• Other members of the same GitHub org are denied (even if --organization would otherwise allow them).
• Ideally it should work consistently regardless of whether the user is signed in via Microsoft identity, GitHub identity, or both (depending on how devtunnel models identities internally).

Additional notes / considerations

• It would be helpful if devtunnel access list clearly shows a rule like “Owner only / current user”.
• If the access control model already supports user principals internally, this could be exposed as a CLI convenience for selecting the current principal.
• If there are security implications or design constraints (e.g., multiple linked identities, federated auth), I’d appreciate guidance on the recommended best practice today.

Why this matters

This would enable a safer default for personal/dev scenarios and reduce the chance of unintentionally granting broader access (tenant-wide or org-wide) when only single-user access is desired.

NOTE: Issue drafted with the help of Copilot (but carefully reviewed/modified manually before posting).