Tailscale or SSO? Giving the right people access to the AI server

Once the server is in place and the language model is answering, the question that decides whether the system gets used arrives: how do people reach it? The answer depends on what your IT looks like today, and there are two routes I recommend over and over.

The ground rule

The AI server should never be reachable directly from the internet. No open port, no public address. Everything that talks to it should do so through a layer that knows who the user is. Then the only question is which layer.

Route one: Tailscale

Tailscale builds a private network between your devices on top of WireGuard. Every laptop, phone and server gets an identity, and traffic flows encrypted directly between them without passing through anything you do not control. The server is visible only to the devices you have approved.

It fits when:

• You are a smaller company or a department without an identity platform of your own.
• You have many people working from home or on the road.
• You want to be up in a day with something that just works.

In practice it looks like this: the user installs a client, signs in with their usual Google or Microsoft account, and can then open the chat interface on an internal address. The administrator sees every device in a console and can cut one off in seconds. For the server itself, SSH with keys is enough for whoever operates it.

The limitation is that access is governed per device and user in Tailscale, not in your existing groups and roles. For most smaller organisations that is not a problem. It is a simplification.

Route two: federated SSO

If you already have an identity provider, such as Microsoft Entra ID, Okta or your own Keycloak, the AI services should be connected to it. The user signs in to the chat interface with the same account as everywhere else, groups from your directory decide who sees what, and when someone leaves, access disappears automatically with the account.

Technically this happens through OpenID Connect. The common interfaces for local models support it out of the box, and a reverse proxy in front of the API does the same job for tools that call the model machine to machine.

It fits when:

• You have an IT department with a directory you already trust.
• You need per-user traceability, for example for audits.
• Different groups should have access to different models or different data.

The cost is more configuration up front and a dependency on the directory being well kept. The gain is that the AI server becomes one system among others, following the same rules.

And the combination

The two do not exclude each other. A common setup is Tailscale as the network layer, so the server is never public, with SSO on top for signing in to the interface. Then you have two independent controls: which devices reach the server and which people may log in.

What not to do

Do not open a port in the firewall "temporarily". Do not share one password across the department. Do not trust that an internal IP address is protection enough. I have seen all three, and any one of them is enough to turn an otherwise excellent local AI solution into a security incident.

Which route is right for you is settled in the assessment, and it also determines what the server needs in terms of logging. It is rarely the hardest part of the project, but it is the part that decides whether the rest may be used.