A first look at Aperture by Tailscale (private alpha)

Posted by geoffeg 2 days ago

Comments

Comment by frenchtoast8 2 days ago

I'm not understanding how this supports Tailscale's initiatives and mission. That isn't to say this isn't a useful feature for a business, but it feels like a random grasp at "build something, anything, AI related." As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without progress.

Comment by tptacek 2 days ago

Corporate/enterprise networks have nightmarish setups for centralizing access to LLMs. This seems like an extremely natural direction for Tailscale; it is to LLM interfaces what Tailscale itself was to VPNs, a drastically simplified system that, by making policy legible, actually allows security teams to do the access control that was mostly aspirational under the status quo ante.

Seems straightforward?

I think if you don't have friends working at e.g. big banks or whatever, you might not grok just how nutty it is to try to run simple agent workflows.

Comment by Bluecobra 2 days ago

>Corporate/enterprise networks have nightmarish setups for centralizing access to LLMs.

As someone who is on the other side of the fence on this and trying to keep the network secure and preventing data exfiltration there could be a good reason for this. More often than not we have folks doing all kinds of crazy things and ignore what’s in the handbook. For example we had someone who didn’t like MFA for remote access and would use Tailscale to have a remote permanent reverse proxy to their homelab to do whatever work they were doing. What’s funny is that we are not BOFH’s and would have helped them setup whatever they need had they just sent us an email or opened a ticket.

Comment by tptacek 2 days ago

The whole Tailscale ethos is exactly what you're talking about:

* Security/risk teams have coherent, sensible goals for managing access

* The technology stack they've landed on makes those goals performative; so complicated that they can't even express their most important goals, so annoying that users route around it

* What's needed is a radically simplified approach that centers end-user experience (particularly around onboarding).

I'm not saying banks are crazy to want to control LLM usage (I'm not bullish on it long-term either, but I see the issue), just that the systems I've talked to friends about them using today are batshit, ranging from "foundation lab shmoundation lab we'll just do our own models" to "OK you can operate in 2025 but only in a Citrix terminal".

Comment by skrtskrt 2 days ago

Yeah I think it's better to think of Tailscale as an access control company which is utilizing networks as the utility vector, not a network utility company that also has access controls.

Comment by humanlity 1 day ago

[dead]

Comment by stopachka 2 days ago

Another reason they could have built this was by listening to their users. I do believe lots of people are spinning up agents in their workplaces, and managing yet another set of api keys is probably annoying for Tailscale's customers. This feels like a great solution to me.

Comment by hwpky 2 days ago

Pressure to service larger customers to capture higher revenues is inevitable for Tailscale given the scale of VC funding, valuation, and operating costs involved.

Trying to be all things to all people will inevitably dilute focus, and it’s understandable that OP might be looking at this sub-product and wondering where the value is for their use cases.

They’re probably not the only ones questioning whether they’re still part of Tailscale’s core ICP (ideal customer profile), either.

Edit: expanded ICP for clarity.

Comment by micromacrofoot 2 days ago

yes this inevitably happens to companies that can't grow infinitely, you pivot to enterprise because you can sell to one person that has the equivalent spend of thousands... it really is unfortunate for the individuals

Comment by verdverm 2 days ago

I have a secret manager, why would I want tails ale involved in the management of secrets, they are a networking company

Tails ale is not a company I see being involved in my core AI ops. I don't need their visibility tools, I already have LGTM.

Tailscale should focus on their core competency, not chase the gilded Ai hype cycle. I have sufficient complaints about their core product that this effort is a red flag for me. To do this now, instead of years ago, shows how behind the times they are

Comment by danudey 2 days ago

They're not a networking company, they're an access control company. Their original product is based around networking, and now this new one is based around AI access and metrics.

This product isn't about managing and distributing API keys, it's about managing and distributing access to these services throughout the org. In fact, it's more about being able to avoid managing and distributing API keys, which is IMHO even better.

Comment by verdverm 2 days ago

The first I heard of them was they were the company around WireGuard, a networking technology.

We recently brought them into the stack to manage said access, it has been painful, aiui their configuration is not intuitive (not the one working on it). I suspect any further expansion will be a big ask after the dismal experience. I certainly don't trust them to manage my secrets and access afterwards. I haven't even found an enjoyable DX talking point in either my personal or professional usage either

> They're not a networking company, they're an access control company.

This is like Ripping saying they are not an HR company, they are an access control company. I got into this very argument with them on a sales call looking for a payroll provider. They wanted to manage the keys to everything, I don't trust them to safely guard access to my cloud projects, nor is it something I even want my HR/payroll company even considering doing. This new product sounds like TailScale was the keys to the kingdom and I sure as hell am not giving it to them after the disappointing rollout of their established networking technology

Comment by jen20 2 days ago

What would you say Microsoft are? A word processor company? An operating system company?

It's conceivable surely to anyone that a company could do more than one thing?

Comment by danudey 2 days ago

Not to mention that storing the API keys on a developer machine (or distributing them to a developer machine) is the first step towards a developer's API keys getting leaked or exfiltrated. With this approach, the developer never has the API key on their machine at all (and you don't have to rotate or invalidate the key when they leave).

Comment by gneray 2 days ago

This ^^

There's a set of common needs across these gateways, and everyone is building their own proxies and reinventing the wheel, which just feels unnecessary.

~All of our customers at Oso (the launch partner in the article) have been asking us how to get a handle on this stuff...bc their CEO/board/whatever is asking them. So to us it was a no-brainer. (We're also Tailscale customers.)

Comment by dbushell 2 days ago

I realised I wasn't Tailscale's target customer when I reported a 100% reproducible iOS bug/regression over a year ago. It was confirmed, logged, and forgotten.

Comment by traceroute66 1 day ago

> As a paying customer I'm concerned about the company's focus being blurred when there are 3.8k open issues on their Github repo and my company has been tracking some particular issues for years without progress.

I feel exactly the same way.

So many open issues, the majority thoroughly deserving of a resolution.

I would rather they get their house in order on the core product first before rushing out shiny new things .... because the shiny new alpha/beta things will only exponentially increase the number of open issues.

Comment by sauercrowd 2 days ago

This seems quite useful to me, especially for a larger org. If your dev's are working on LLM features, they'll need access to the OpenAI APIs. So are you just gonna give all of them a key? the same key?

No idea how this is solved at the moment, so seems like a smart step

Comment by scottyah 2 days ago

There's actually a mass acquisition game going on right now in this space. Companies want to use genAI, but don't necessarily want to hire people to run their own models in-house. It may not be obvious to startup-y employees, but keeping data in-house is huge for big companies. LLM traffic is a lot different from established traffic that firewalls have been built up for. You can't block data leaks as easily as shutting down access to google drive. When you can't trust all of your employees, genAI presents a lot of new attack vectors.

Comment by preisschild 2 days ago

I like tailscale itself but a lot of basic stuff (such as dynamic routing) or ephemeral node auth are very lacking, wish they would concentrate more on their core product we all like and want to see improve

Comment by 9rx 2 days ago

> we all like

Building software users like doesn't make for a good business model. Especially if that model has to satisfy VC.

Comment by nunez 2 days ago

Loads of enterprisey companies are asking for exactly this, and Tailscale is becoming more enterprisey. That's how, I'd think.

Comment by wildzzz 2 days ago

A huge chunk of the open issues are feature requests with many of those already being implemented years ago but not yet marked closed. And a vast majority of the bugs are repeats, they clearly need someone to clean up their issue tracker.

Comment by notepad0x90 2 days ago

In times of peace, the hardest part of running a military is keeping the troops busy.

Comment by esseph 2 days ago

> my company has been tracking some particular issues for years without progress

Sounds like something your Account Manager or similar would need to work through. Development roadmaps are often driven by the largest, or loudest customers.

Comment by _pdp_ 2 days ago

Came to say this. It looks like a Mozilla move.

Comment by apenwarr 1 day ago

[Tailscale CEO here] I see a lot of comments asking why Tailscale would branch away from our "core product" and build this thing that seems unrelated at first. One answer is that just about every single Tailscale customer (or homelab user!) is dipping their toes into AI right now, and they often come to us and ask how to integrate their stuff into Tailscale. Aperture is our answer to that.

A separate goal I have personally: demonstrate that anyone can build really neat stuff directly on top of the "Tailscale platform." One of my rules for the Aperture team was, you're not allowed to change core Tailscale, you have to build entirely on top as if you were some partner company. So this is a demo of how anybody can make pretty slick, easy-to-use, and yet highly secure stuff by building on Tailscale (the open source packages, or the commercial product, or both).

Comment by nojs 2 days ago

“Aperture” is a pretty creepy name for this.

> By collecting usage information into a single place, engineering and IT leaders can get a complete picture into both user and agent token efficiency across the organization and providers.

What exactly is “user token efficiency”?

Comment by sheepscreek 2 days ago

Not trying to diss or anything but a capable engineer could spin this up within their organization in a day or two. So I’m not sure how useful this is going to be to the average customer. Perhaps to the largest customers who have sophisticated security and compliance needs but even for them this would need to be very very competitively priced to be worthwhile (cheaper than the salary of 2 devs for a year).

The true moat of Tailscale is the core product. That can’t be easily replicated (still). Perhaps some product to simplify controlling what resources agents in the organization have access to and having 100% visibility + audatability for them will be way more useful.

Comment by storystarling 2 days ago

I built a similar gateway for my own stack and thought it would be a quick project, but the complexity is hidden in the details. A basic proxy is simple enough, but getting accurate token counts for streaming responses turned out to be a huge pain since every provider handles chunks differently. You also end up spending a lot of time writing adapters to unify the schemas so your application logic stays clean. If you care about precise billing or logging, it is definitely not a two day build.

Comment by suralind 2 days ago

Oh man. Not saying this is not needed or anything, but it feels like Tailscale needed to pivot to something something AI… What a shitty time to be alive, companies doing good products that actually work well need to appeal to investors and do random things like that.

Comment by ddtaylor 1 day ago

Maybe I'm confused this seems like OpenRouter?

Comment by SSLy 2 days ago

unrelated, but what's the path of least resistance to expose a couple of localhost-bound services to the tailnet, ideally with each having own hostname entry as the browser sees it?

they're not containerised, just plain old daemons.

Comment by JayWS 2 days ago

https://tailscale.com/kb/1552/tailscale-services

Tailscale services will do that. You can do the proxying with tailscale serve, services gives you the MagicDNS name and virtual IP address bound to it.

Comment by SSLy 2 days ago

oh, that indeed worked. cheers!

Comment by timwis 2 days ago

This should work out of the box with Magic DNS (part of tailscale features). If machine A is named larrys-laptop and is running a service on :8080, then from sandras-laptop just navigate to http://larrys-laptop:8080 and it should work, provided both machines are on the same tailnet.

Comment by lkosewsk 2 days ago

Give Tailscale serve a shot (https://tailscale.com/kb/1312/serve).

*edited; I initially pointed to Funnel which would be used for sharing outside your tailnet.

Comment by kotaKat 1 day ago

Wellp, looks like it's time for me to downgrade from Personal Pro. Don't think Tailscale needs my five bucks anymore if they're suddenly swinging into AI rentseeking.