Your AI Router Needs Network Identity, Not Another Shared Provider Key

An AI provider key is easy to paste into an environment variable. That is its best feature and its worst one. Once the key sits in a browser client, a long-lived agent workspace, three internal services, and a helpful spreadsheet, nobody can say with much confidence who is using it or how to stop one user without stopping everyone.

Tailscale's Aperture architecture points at a better default. Model access follows tailnet identity. Add a user or device to the approved network and access appears. Remove it and access disappears. The router can then enforce provider, retention, and budget policy without asking every agent to carry a separate provider credential.

A Router Is Useful When It Carries Policy

Calling several model APIs through one endpoint is convenient. The real value is a place to express policy: which models a team may use, which requests need zero data retention, how spend is attributed, and where a fallback is acceptable.

That does not mean every company should build a model router. Tailscale's own story is useful partly because it describes deciding not to maintain provider plumbing when a gateway already supplied the work they needed. The goal is not another internal platform. It is fewer invisible keys and clearer decisions.

Identity Beats Credential Distribution

An agent should receive the authority required by its task, not a general-purpose key that happens to work. Network or workload identity makes that easier to express.

user or workload identity
  -> policy evaluates task and data class
  -> router selects an approved model route
  -> short-lived sandbox receives narrow capability
  -> tool action is attributed and auditable

The model call is only one step. If the agent can read private files, call a SaaS API, or run code, those capabilities need their own scopes and revocation path too.

Revocation Has to Be Boring

The strongest argument for identity-based access is not the onboarding demo. It is the offboarding test. Can a team remove a contractor, disable a compromised device, or stop a misbehaving agent without rotating a shared secret and hoping no copy was missed?

If the answer is no, the access model is optimistic rather than operational. Identity lets a system remove permission at a control point. Shared keys turn the same event into a scavenger hunt.

Zero Retention Is a Routing Constraint

Tailscale highlights zero-data-retention routing as a requirement for its customers. This is where a router earns its name. A request with a retention requirement should only reach providers and models that satisfy it. The policy should be visible in the trace, not left to the last developer who changed a default.

Do not overstate the guarantee. Retention requirements, contractual terms, and provider features change. Treat them as configuration with an owner, review cadence, and a failure mode. If no compliant route exists, fail clearly instead of quietly sending the request somewhere convenient.

Sandboxes Limit the Other Half of the Risk

Model access is not the same as execution access. An agent that can work with files, browse, or call tools needs a place to run and a boundary around what it can reach. Disposable sandboxes let a team scope files and credentials per task, collect artifacts, and discard the environment afterward.

That boundary still needs design. A sandbox that contains a broad production token is only a neatly packaged incident. Use short-lived credentials, explicit outbound network rules, artifact retention limits, and approval gates for consequential actions.

Cost and Observability Belong With Identity

One of the practical details in the Tailscale story is cost data returned with model requests. Centralizing it makes it possible to attribute spend to a customer, team, task, or agent. Without that link, a surprising bill becomes a philosophical discussion about usage.

Record enough to reconstruct a decision: identity, task, policy version, requested and selected model, provider route, latency, cost, tools, approvals, and outcome. Avoid turning observability into another unbounded store of customer prompts.

Do Not Route Around Authorization

A router can make the provider layer tidy. It cannot decide whether an agent should issue a refund, change a deployment, or read a document belonging to another customer. Keep those decisions in the application tool layer. Make irreversible actions explicit and reviewable.

The useful architecture is not one powerful key in a nicer service. It is a chain of narrow, attributable decisions. That is less exciting than a screenshot of hundreds of models. It is also what lets a real team revoke access at 5 PM without discovering that the agent had a copy of the world.

---