Tailscale hat mit Aperture ein Produkt gebaut, das Hunderte AI-Modelle über die bestehende Tailnet-Identität zugänglich macht. Die eigentliche Besonderheit ist nicht die Zahl der Modelle. Sie liegt in der Authentifizierung: Mitarbeiter, Agenten und interne Tools müssen nicht für jeden Modellanbieter eigene API-Keys erhalten.
Der Zugriff wird stattdessen an die Identität im Tailscale-Netz gebunden. Wird ein Nutzer oder Gerät aus dem Tailnet entfernt, verschwindet damit auch der Zugriff auf die freigegebenen Modelle.
Vercel beschreibt den Aufbau in einer Fallstudie vom 11. September, weil Aperture für das Routing Vercels AI Gateway verwendet. Für SaaS- und Agentensysteme ist die Architektur vor allem als Beispiel dafür interessant, wie Model Routing, Netzwerkidentität und Credential Management zusammengelegt werden können.
Das Problem beginnt mit dem zweiten Modellanbieter
Ein einzelnes AI-Feature lässt sich relativ einfach über einen API-Key anbinden. Sobald mehrere Anbieter hinzukommen, wächst daraus ein Credential-System.
OpenAI, Anthropic, Google, Mistral oder andere Provider besitzen jeweils eigene Schlüssel, Rollen, Limits und Abrechnungsmodelle. Entwickler brauchen Zugang in lokalen Umgebungen, CI-Systemen und produktiven Diensten. Interne Agenten benötigen wiederum eigene Credentials oder müssen auf zentrale Proxys zugreifen.
Die naheliegende Lösung ist ein Model Gateway. Anwendungen senden Requests an einen zentralen Endpunkt, während das Gateway die Provider-Zugangsdaten hält und zum gewünschten Modell routet.
Damit verschwindet jedoch nur ein Teil des Problems. Das Gateway selbst muss weiterhin wissen, welcher Nutzer, welches Gerät oder welcher Agent welche Modelle verwenden darf.
Aperture verwendet dafür Tailscales bestehende Netzwerkidentität.
Modellberechtigung folgt dem Tailnet
Ein Tailnet ist Tailscales privates Overlay-Netzwerk für Geräte, Nutzer und Dienste. Unternehmen definieren dort bereits, welche Identitäten auf welche Ressourcen zugreifen dürfen.
Aperture übernimmt dieses Modell für AI-Zugriff. Ein Nutzer im Tailnet kann auf freigegebene Modelle zugreifen, ohne selbst den Provider-Key zu besitzen. Wird die Berechtigung entzogen, muss kein Schlüssel auf einem Laptop gesucht oder rotiert werden.
Das ist ein anderes Sicherheitsmodell als die übliche .env-Datei mit mehreren Provider-Tokens.
Der Client beweist zunächst seine Identität gegenüber dem Netzwerk. Das Routing-System entscheidet anschließend, ob diese Identität das angeforderte Modell verwenden darf. Die eigentlichen Provider-Credentials bleiben zentral.
Für interne Tools kann das den Credential-Sprawl deutlich reduzieren.
Ein Model Router ist mehr als ein einheitliches API-Format
Viele Gateways werden vor allem als Kompatibilitätsschicht verkauft: ein Request-Format, mehrere Modelle dahinter.
In produktiven Systemen entstehen schnell weitere Aufgaben. Modelle müssen nach Kosten, Verfügbarkeit, Latenz oder Fähigkeiten ausgewählt werden. Zugriffe brauchen Rate Limits. Teams sollen möglicherweise unterschiedliche Modellgruppen sehen. Abrechnung und Observability müssen modellübergreifend funktionieren.
Aperture koppelt diese Kontrollschicht zusätzlich an eine Identität, die bereits außerhalb des AI-Stacks existiert.
Das hat einen praktischen Vorteil: Die Anwendung muss keine zweite Benutzerverwaltung nur für Modellzugriff führen.
Es hat aber auch eine klare Voraussetzung. Die Organisation muss Tailscale bereits als relevante Identitätsschicht akzeptieren. Für Anwendungen mit externen Endkunden oder öffentlich zugänglichen APIs reicht Tailnet-Mitgliedschaft allein naturgemäß nicht aus.
Agenten profitieren stärker als normale Chat-UIs
Bei einem internen Chat-Frontend wäre ein einzelner zentraler Backend-Key oft ausreichend. Agentische Systeme machen die Berechtigungsfrage komplizierter.
Ein Agent kann aus einer IDE, einem Build-System, einem Server oder einer lokalen Maschine gestartet werden. Mehrere Subagenten können unterschiedliche Modelle benötigen. Dazu kommen automatisierte Jobs ohne interaktiven Login.
Wenn jede dieser Laufzeiten eigene Provider-Keys erhält, entsteht ein großes Secret-Management-Problem. Schlüssel müssen verteilt, gespeichert, rotiert und bei Geräteverlust oder Mitarbeiterwechsel widerrufen werden.
Netzwerkgebundene Identität verschiebt den Kontrollpunkt. Der Agent bekommt Zugriff auf den Router, nicht auf die eigentlichen Provider-Secrets.
Das reduziert nicht automatisch alle Risiken. Ein kompromittierter Rechner kann weiterhin Requests im Namen seiner Identität senden, solange diese Identität gültig ist. Dafür werden bestehende Netzwerkregeln, Device-Trust-Mechanismen und Revocation relevanter.
Das Gateway wird zur kritischen Infrastruktur
Zentralisierung vereinfacht Credentials, erhöht aber die Bedeutung des Routers.
Wenn alle AI-Requests über einen Gateway laufen, beeinflussen dessen Ausfall, Fehlkonfiguration oder Policy-Fehler viele Anwendungen gleichzeitig. Ebenso konzentriert sich dort ein großer Teil der Nutzungsdaten.
Ein Unternehmen muss deshalb klären, welche Prompts, Responses und Metadaten das Gateway sehen oder speichern kann, wie Provider-Fallbacks funktionieren und welche Limits bei Störungen greifen.
Das gilt unabhängig von Tailscale. Jeder zentrale Model Router wird zu einer Infrastrukturkomponente, sobald mehrere produktive AI-Funktionen davon abhängen.
Modellwahl wird zur Policy statt zum Codepfad
Der architektonisch spannendere Teil liegt deshalb nicht bei einem weiteren Proxy vor einer API.
Wenn Identität und Routing zentralisiert sind, muss die Anwendung weniger Providerlogik enthalten. Ein Team kann theoretisch festlegen, dass bestimmte Nutzer nur günstige Modelle verwenden dürfen, während ein Coding-Agent Zugriff auf leistungsfähigere Modelle erhält. Ein anderes Modell kann bei Ausfällen einspringen, ohne dass jede Anwendung eigene Credential-Sets pflegt.
Vercels Fallstudie nennt Hunderte Modelle, die Aperture seinen Kunden zur Verfügung stellt. Das ist eine Hersteller- beziehungsweise Kundenangabe und sagt noch nichts darüber aus, wie viele davon ein einzelnes Unternehmen tatsächlich sinnvoll einsetzen sollte.
Der relevante Punkt ist die Kontrollfläche. Bei Multi-Model-Systemen wandert Modellwahl zunehmend aus dem einzelnen Feature in eine gemeinsame Infrastruktur aus Routing, Identität, Kostenkontrolle und Policies.
Tailscale zeigt dafür eine besonders konsequente Variante: Wer bereits über die Netzwerkidentität weiß, wer auf Datenbanken, Server und interne Dienste zugreifen darf, kann dieselbe Information auch für AI-Modelle verwenden.
Für SaaS-Produkte mit eigenen Endkunden ist das nicht automatisch die passende Lösung. Für interne Developer Tools und Agentenplattformen ist es aber ein gutes Gegenmodell zu immer mehr API-Keys in immer mehr Secrets Stores.